你如何处理容器的日志记录和监控？

Question

你如何处理容器的日志记录和监控？

Accepted Answer

容器化应用程序需要**集中式日志记录**和**监控**，因为容器是短暂的且数量众多——必须在外部收集日志和指标，以便在容器移除后仍然保留这些信息，并提供整个系统的可见性。这是生产容器必不可少的可观测性。

## 日志记录：向 stdout/stderr 输出，集中聚合

```text
BEST PRACTICE: containers should log to STDOUT/STDERR (not to files inside the container):
  → Docker captures these (`docker logs`); a logging DRIVER forwards them elsewhere
  → WHY: containers are EPHEMERAL — logs in a removed container are LOST. Centralize them.
```

```text
Logging drivers / pipelines forward logs to a central system:
  → json-file (default), syslog, fluentd, awslogs, gelf, etc. (--log-driver)
  → Aggregation stacks: ELK/Elastic (Elasticsearch+Logstash+Kibana), Loki+Grafana,
    cloud logging (CloudWatch, Stackdriver), Datadog, etc.
→ Centralized logs: searchable, persistent, span ALL containers/hosts → real visibility
```

## 监控：指标、健康检查、告警

```text
✓ METRICS — collect CPU, memory, network, app metrics per container
  → Prometheus (scrapes metrics) + Grafana (dashboards) — the common stack
  → cAdvisor / node-exporter for container/host metrics
✓ HEALTH — health checks + orchestrator status (which containers are healthy)
✓ ALERTING — alert on failures, resource limits, errors (Alertmanager, etc.)
✓ DISTRIBUTED TRACING — trace requests across microservices (Jaeger, OpenTelemetry)
```

## 为什么容器可观测性不同

```text
Containers are EPHEMERAL (created/destroyed dynamically) and NUMEROUS (many across hosts):
  → can't rely on logging into a box or local log files (containers come and go)
  → need EXTERNAL, centralized, dynamic collection that handles churn
  → orchestrators add labels/metadata to correlate logs/metrics to services
→ Observability must be designed for dynamic, distributed, ephemeral workloads.
```

## 为什么这很重要

理解容器的日志记录和监控是重要的高级知识，因为**可观测性对于运营生产系统至关重要**，而容器的短暂性、数量众多、分布式特性使其与传统方法不同。

关键的**日志记录**实践——容器应该**向 stdout/stderr 输出日志**（而不是向容器内的文件写入），以便平台能够捕获并将其转发到**集中聚合**——这至关重要，因为**容器是短暂的**：存储在容器内的日志在**容器被移除时会丢失**，因此需要集中这些日志（通过日志驱动程序转发到 ELK、Loki/Grafana、云日志记录等）来保留日志并获得整个容器和主机的可见性。**监控**同样重要：收集**指标**（CPU、内存、应用程序指标，通常通过 Prometheus + Grafana）、跟踪**健康状况**（健康检查和编排器状态）、**告警**出现的问题，以及**分布式追踪**（使用 Jaeger/OpenTelemetry 跟踪跨微服务的请求）提供了理解系统行为、诊断问题和响应故障所需的可见性。

理解**为什么容器可观测性不同**——容器是短暂的（动态创建/销毁，因此无法依赖本地文件或登录到机器）且分布在多个主机上（需要外部动态收集来处理容器的频繁变化，通过编排器元数据将日志/指标与服务相关联）——这是概念性的洞察，它决定了如何为容器化系统设计可观测性。

由于运营生产系统需要可观测性（你无法管理看不到的东西），而且容器的短暂性和分布式特性要求设计用于动态工作负载的集中式、外部收集的日志记录和监控，理解容器日志记录和监控是负责任地运行容器化应用程序的重要高级知识——必不可少的可观测性使容器化系统在生产中可操作、可调试和可维护，也是管理容器部署的高级角色所期望的运营成熟度的体现。