日志与监控 — 从 docker logs 到 Elastic Stack 与 Prometheus¶

这一章回答: 容器到处跑、随死随删,证据(日志)和健康(指标)怎么集中看? 答案两条管道:日志管道把每个容器的输出汇到一处可搜索; 指标管道定期采集数字、画图、超阈值报警。主线例子:先让 Filebeat 把日志送进 Kibana,再用三个语言的小服务喂 Prometheus。

1. 为什么单机日志不够用¶

分布式、任务关键的应用在运行时,必须尽可能洞察内部¹。docker container logs 能看,但容器是朝生暮死的——本地日志随容器消失,多主机时更是散落各处。所以最佳实践三条:配日志滚动与保留策略防磁盘撑爆;用日志管理系统集中; 配过滤与告警抓关键事件²。

2. 滚动与保留:max-size 和 max-file¶

第 03 章见过这两个参数,本章给全配置法。全局:daemon.json 里

{ "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "5" } }

单容器:--log-driver=json-file --log-opt max-size=10m --log-opt max-file=5。含义:单文件到 10 MB 就滚动、最多留 5 个、删最旧——磁盘占用有了硬顶³。

3. 日志管道:Elastic Stack(ELK)+ Filebeat¶

集中式日志的主角是 Elastic Stack(旧称 ELK:Elasticsearch、Logstash、Kibana), 四个角色分工⁴:

组件	角色
Filebeat	轻量日志搬运工,从容器/宿主机收日志转发出去
Logstash	(可选)处理、转换、富化日志
Elasticsearch	中央的搜索与分析引擎
Kibana	给人查询和可视化的人机界面

Linux 上 Filebeat 直接读 Docker 的 JSON 日志:/var/lib/docker/containers/*/*.log, filebeat.yml 里配 type: container 的 input,output 指向 Elasticsearch,然后 systemctl 起服务⁵。

Mac/Windows 的坑与绕行(本章最有移植价值的段落)。 Desktop 的 Docker 跑在 VM 里,宿主路径 /var/lib/docker 根本不存在。书里的绕行法:让所有应用把日志写进一个共享卷的文件,Filebeat 容器挂同一个卷去 tail 那些文件——容器化应用写日志到挂载目录,Filebeat 追读并转发,元数据(如 service.name)在配置里补上, Kibana 里照样按服务过滤⁶。

管道两端都接上后,在 Kibana Discover 里建 data view,查询长这样:

  service.name : "node-api"        ← 只看某个服务的日志
  message : "ERROR"                ← 只看报错行

多服务排障就是这两类过滤的组合⁷。(书还解释了为什么 Docker Desktop 上没有 container.name 这类 Docker 元数据字段——VM 隔离,所以要自己补 service.name。)

Docker 守护进程自己的日志(容器事件的来源)也要收:Linux 上走 journald; Windows 上 Docker Desktop 的 VM 日志在 C:\ProgramData\DockerDesktop\service\DockerDesktopVM.log,用 PowerShell 的 Get-Content -Tail 看最后若干行⁸。

4. 指标管道:Prometheus 的拉取模型¶

日志说"发生了什么",指标(metics,数值化的性能/资源/业务测量)说"系统随时间怎么表现"⁹。Prometheus 是最常用的开源指标与告警工具,模型是拉取(pull): 它定期访问应用的 /metrics HTTP 端点,把暴露的指标抓回来⁹。

主线例子:三个微型服务(Go、Python、C# 各一),各自暴露一个请求计数器:

// Go 版(prometheus/client_golang 一等公民支持)
var reqCounter = prometheus.NewCounter(prometheus.CounterOpts{
    Name: "go_requests_total", Help: "Total number of requests"})
http.Handle("/metrics", promhttp.Handler())   // Prometheus 来抓的端点

# Python 版(Flask + prometheus_client)
counter = Counter('py_requests_total', 'Total HTTP requests handled')
@app.route('/metrics')
def metrics():
    return generate_latest(), 200, {'Content-Type': CONTENT_TYPE_LATEST}

  Prometheus 配置(prometheus.yml)声明去哪些目标抓:
    scrape_configs:
      - job_name: 'services'
        static_configs:
          - targets: ['go-service:8081', 'py-service:8082', 'cs-service:8083']

  在 Prometheus Web UI 的 Query 页可直接查:
    go_requests_total / py_requests_total / cs_requests_total[^10]

起法照旧是 Compose:三个服务 + Prometheus(+ Grafana)一个文件, up -d 全套起来。Grafana 接 Prometheus 数据源,把指标画成 dashboard; 再进一步可以在 Prometheus 里配 alerting rules,超阈值告警——从"看得见" 升级到"主动叫"¹¹。

5. 可观测性三支柱与安全监控¶

收尾的概念框架,三个名词要分清(书里叫 three pillars)¹²:

支柱	回答
日志	发生了什么(事件级细节)
指标	趋势和模式(聚合数字)
追踪	一个请求穿过多个服务的全程

三者合起来才能答"为什么发生"。安全是另一条平行线:容器特有的风险—— root 运行、镜像里有漏洞依赖、意料外的网络连接——靠三样盯:

镜像扫描(Docker Scout、Trivy、Snyk):部署前就抓已知漏洞;
运行时监控(Falco、Sysdig):容器里出现可疑行为(比如在 web 容器里起了一个 shell)就告警;
审计日志:Docker/Kubernetes 的审计日志进集中日志,留"谁何时做了什么"¹³。

书里定位诚实:完整的可观测性栈通常在编排层(Kubernetes)才正式引入, 但"监控不只关乎性能,关乎健康、可靠与安全"这一层意思,单机阶段就该懂¹³。

6. 作者的判断与证据¶

"日志必须集中、可搜、可视"是立场,依据是容器短暂与多节点的现实²。
Mac/Windows 共享卷绕行是经验证的 workaround,书里说明了它同时兼容 Linux 原生路径——这是跨平台日志方案的实用结论⁶。
三支柱框架是行业共识;安全监控三件套的选型(Docker Scout/Trivy/Snyk、 Falco/Sysdig)是 2026 年主流名单,会随时间漂移¹³。

判断(我们的,不是书里的): 本章两条管道有一个共同的设计模式值得抽象出来: "生产者暴露标准化端点,收集器主动来取"(Prometheus 的 /metrics 是显式的, 容器的 STDOUT 是隐式的——Docker 就是那个收集器)。理解了"暴露端点 > 推送数据", 就理解了为什么今天的新系统(Otel Collector、eBPF 探针)都长成拉取/汇聚的样子。 如果错,会错在: 高基数或超大规模日志场景里,推送式(如 OTLP 直推)反而比拉取式更常见;拉取模型的优势在"被监控方保持简单",不是普适最优。

7. 边界与局限¶

Filebeat/ELK 配置细节以官方文档为准,书里给的是最小可用集; Elastic 栈本身资源胃口大,开发机上跑全套要小心内存。
Prometheus 单机部署(无持久化、无告警管理器 Alertmanager)只适合演示; 生产要配存储、告警路由、高可用——第 18 章才补。
追踪(traces)本章只出现在"三支柱"概念里,工具链在第 06(Jaeger)与第 18(OpenTelemetry)章。
安全监控是预告片,展开在 13(安全专章)。

8. 可带走的¶

单机日志的三条纪律:滚动保留、集中管理、过滤告警²。
max-size/max-file:日志磁盘占用的硬顶³。
ELK 四角色:Filebeat 搬、Logstash 加工、Elasticsearch 存搜、Kibana 看⁴。
Desktop 的日志在 VM 里:共享卷 + tail 文件是通用绕行法⁶。
Kibana 查询:service.name : "node-api"、message : "ERROR"⁷。
Prometheus = 拉取模型:应用暴露 /metrics,Prometheus 定期抓⁹。
埋点三语言都有现成库;计数器是最小演示指标(go_requests_total 等)¹⁰。
三支柱:日志/指标/追踪;安全三线:扫描、运行时、审计¹²¹³。

9. 原文地图¶

主题	原书章	原文位置
为什么要集中日志	Why logging and monitoring matter	`text/135-fm-why-logging-and-monitoring-matter.txt:7`(搜「insight」)
三条最佳实践	Shipping container logs	`text/136-fm-shipping-container-logs.txt:13`(搜「best practices」) · `text/136-fm-shipping-container-logs.txt:14`(搜「rotation」) · `text/136-fm-shipping-container-logs.txt:16`(搜「centralize」)
max-size/max-file	Shipping container logs	`text/136-fm-shipping-container-logs.txt:69`(搜「max-size」) · `text/136-fm-shipping-container-logs.txt:71`(搜「max-file」) · `text/136-fm-shipping-container-logs.txt:78`(搜「log-opts」)
ELK 四角色	Shipping container logs	`text/136-fm-shipping-container-logs.txt:100`(搜「centralized」) · `text/136-fm-shipping-container-logs.txt:101`(搜「ELK」) · `text/136-fm-shipping-container-logs.txt:104`(搜「Filebeat」) · `text/136-fm-shipping-container-logs.txt:109`(搜「Elasticsearch」) · `text/136-fm-shipping-container-logs.txt:111`(搜「Kibana」)
Filebeat Linux 配置	Shipping container logs	`text/136-fm-shipping-container-logs.txt:142`(搜「filebeat.inputs」) · `text/136-fm-shipping-container-logs.txt:145`(搜「/var/lib/docker/containers」)
Desktop 绕行	Shipping container logs	`text/136-fm-shipping-container-logs.txt:175`(搜「will not run」) · `text/136-fm-shipping-container-logs.txt:180`(搜「workaround」) · `text/139-fm-collecting-and-scraping-metrics-with-prometheus.txt:10`(搜「log-file-volume」)
Kibana 查询	Querying a centralized log with Kibana	`text/139-fm-collecting-and-scraping-metrics-with-prometheus.txt:14`(搜「service.name」) · `text/139-fm-collecting-and-scraping-metrics-with-prometheus.txt:15`(搜「message」)
Docker Desktop VM 日志	Shipping Docker daemon logs	`text/138-fm-querying-a-centralized-log-with-kibana.txt:1`(搜「PowerShell」) · `text/138-fm-querying-a-centralized-log-with-kibana.txt:5`(搜「DockerDesktopVM.log」)
Prometheus 拉取模型	Collecting and scraping metrics with Prometheus	`text/139-fm-collecting-and-scraping-metrics-with-prometheus.txt:26`(搜「Logs tell us」) · `text/139-fm-collecting-and-scraping-metrics-with-prometheus.txt:31`(搜「most widely used」) · `text/139-fm-collecting-and-scraping-metrics-with-prometheus.txt:32`(搜「pull model」)
三语言计数器	Collecting and scraping metrics with Prometheus	`text/139-fm-collecting-and-scraping-metrics-with-prometheus.txt:63`(搜「go_requests_total」) · `text/139-fm-collecting-and-scraping-metrics-with-prometheus.txt:114`(搜「py_requests_total」)
Grafana 与告警	Monitoring a containerized application	`text/141-fm-observability-and-security-monitoring.txt:1`(搜「instrument」) · `text/141-fm-observability-and-security-monitoring.txt:2`(搜「dashboards」) · `text/141-fm-observability-and-security-monitoring.txt:3`(搜「alerts」)
三支柱	Observability and security monitoring	`text/141-fm-observability-and-security-monitoring.txt:12`(搜「three pillars」) · `text/141-fm-observability-and-security-monitoring.txt:16`(搜「event-level」)
安全监控三件套	Observability and security monitoring	`text/141-fm-observability-and-security-monitoring.txt:25`(搜「running as root」) · `text/141-fm-observability-and-security-monitoring.txt:29`(搜「Docker Scout」) · `text/141-fm-observability-and-security-monitoring.txt:31`(搜「Falco」) · `text/141-fm-observability-and-security-monitoring.txt:33`(搜「Audit logs」)

出处:「Why logging and monitoring matter」第 1–16 段(text/135-fm-why-logging-and-monitoring-matter.txt:7,搜「insight」)。 ↩
出处:「Shipping container logs」第 7–18 段(text/136-fm-shipping-container-logs.txt:11,搜「Centralizing」;:13,搜「best practices」;:14,搜「rotation」;:16,搜「centralize」;:17,搜「alerting」)。 ↩↩↩
出处:「Shipping container logs」第 64–95 段(text/136-fm-shipping-container-logs.txt:69,搜「max-size」;:71,搜「max-file」;:75,搜「log-opts」;:88,搜「--log-opt」)。 ↩↩
出处:「Shipping container logs」第 97–115 段(text/136-fm-shipping-container-logs.txt:101,搜「ELK」;:104,搜「Filebeat」;:106,搜「Logstash」;:109,搜「Elasticsearch」;:111,搜「Kibana」)。 ↩↩
出处:「Shipping container logs」第 130–163 段(text/136-fm-shipping-container-logs.txt:142,搜「filebeat.inputs」;:145,搜「/var/lib/docker/containers」;:150,搜「output.elasticsearch」)。 ↩
出处:「Shipping container logs」第 174–200 段与「Collecting and scraping metrics with Prometheus」开头的总结(text/136-fm-shipping-container-logs.txt:180,搜「workaround」;:182,搜「mount that volume」;text/139-fm-collecting-and-scraping-metrics-with-prometheus.txt:10,搜「log-file-volume」)。 ↩↩↩
出处:「Querying a centralized log with Kibana」(该节正文因转码顺序位于文件 139 开头:text/139-fm-collecting-and-scraping-metrics-with-prometheus.txt:14,搜「service.name」;:15,搜「message」)。 ↩↩
出处:「Shipping Docker daemon logs」(该节正文因转码顺序位于文件 138:text/138-fm-querying-a-centralized-log-with-kibana.txt:1,搜「PowerShell」;:6,搜「DockerDesktopVM.log」)。 ↩
出处:「Collecting and scraping metrics with Prometheus」第 25–38 段(text/139-fm-collecting-and-scraping-metrics-with-prometheus.txt:26,搜「Logs tell us」;:31,搜「most widely used」;:32,搜「pull model」;:33,搜「/metrics」)。 ↩↩↩
出处:「Collecting and scraping metrics with Prometheus」第 46–130 段(text/139-fm-collecting-and-scraping-metrics-with-prometheus.txt:63,搜「go_requests_total」;:75,搜「promhttp」;:101,搜「8082」;:114,搜「py_requests_total」)。 ↩
出处:「Monitoring a containerized application」(该节要点因转码顺序位于文件 141 开头:text/141-fm-observability-and-security-monitoring.txt:1,搜「instrument」;:2,搜「dashboards」;:3,搜「alerts」)。 ↩
出处:「Observability and security monitoring」第 9–24 段(text/141-fm-observability-and-security-monitoring.txt:12,搜「three pillars」;:16,搜「event-level」;:18,搜「trends」;:20,搜「single request」)。 ↩↩
出处:「Observability and security monitoring」第 25–37 段(text/141-fm-observability-and-security-monitoring.txt:25,搜「running as root」;:29,搜「Docker Scout」;:31,搜「Falco」;:33,搜「Audit logs」;:36,搜「orchestrator level」)。 ↩↩↩↩