1. 课程导论：ELK 技术栈概述、Docker 日志收集的挑战、后端发布拓扑中的日志价值
1.1 ELK 技术栈概述
ELK 是 Elasticsearch、Logstash 和 Kibana 三个开源项目的首字母缩写，是目前业界最主流的日志集中管理解决方案。其核心工作流程为：采集 → 传输 → 存储 → 检索 → 可视化。
| 组件 | 角色 | 核心功能 |
|---|---|---|
| Elasticsearch | 分布式搜索与分析引擎 | 日志数据的存储、索引、全文检索与聚合分析；提供 RESTful API 接口 |
| Logstash | 服务端数据处理管道 | 从多种输入源采集日志，进行过滤、解析、转换，并输出到 Elasticsearch |
| Kibana | 数据可视化与管理平台 | 基于 Web 的仪表盘，支持日志搜索、图表绘制、告警配置与索引管理 |
提示： 在容器化场景中，常使用 Filebeat 替代 Logstash 作为轻量级日志采集器，以降低资源消耗。本课程后续章节将重点讲解 Filebeat + Logstash 的混合部署模式。
1.2 Docker 日志收集的挑战
在 Docker 容器化环境中，日志收集面临与传统虚拟机或物理机截然不同的技术挑战。容器具有临时性、动态性、资源隔离性等特点，使得日志采集变得复杂。
- 日志生命周期短： 容器随时可能被销毁或重建，日志文件随容器消失，必须实时外传。
- 标准输出 vs. 文件日志： Docker 默认仅捕获容器的 stdout/stderr，但大量应用将日志写入容器内部文件，需额外挂载或使用采集 Agent。
- 资源竞争与噪音： 日志采集 Agent 与业务容器共享宿主机资源，采集行为不应影响业务性能。
- 多行日志解析： 异常堆栈、JSON 多行日志需要特殊处理，否则会被拆成多条记录。
- 元数据关联： 需要将容器 ID、镜像名称、服务名、Kubernetes Pod 标签等元数据注入日志记录，否则无法定位问题来源。
常见误区： 很多团队直接使用
docker logs 命令查看日志，这在单机调试时可行，但在微服务集群中完全不可用——无法聚合、无法检索、无法保留历史。必须建立集中式日志平台。
1.3 后端发布拓扑中的日志价值
在后端服务的发布与部署过程中，日志是故障定位、性能分析、发布回滚决策的核心依据。一个典型的后端发布拓扑通常包含：负载均衡器、网关、微服务实例、消息队列、数据库与缓存等组件。
日志在发布拓扑中的具体价值体现在以下四个维度：
- 灰度发布验证： 通过对比新旧版本的日志流量、错误率、响应时间，快速判断新版本是否健康。
- 全链路追踪： 结合 Trace ID 串联网关、服务、数据库的日志，定位请求瓶颈或异常节点。
- 容量与异常告警： 基于日志中的 4xx/5xx 状态码、慢查询、OOM 等关键字触发实时告警。
- 审计与合规： 记录所有发布操作、配置变更、权限访问，满足内部审计与安全合规要求。
实战经验： 在某电商大促期间，通过 ELK 实时分析网关层日志，发现某新发布的服务实例在 5 分钟内 502 错误率飙升到 15%，立即触发自动回滚，避免了全站故障。日志平台将平均故障定位时间从 30 分钟缩短到 3 分钟。
1.4 本章小结
通过本章导论，我们明确了以下核心认知：
- ELK 技术栈是日志集中管理的标准范式，Elasticsearch 负责存储与检索，Logstash/Filebeat 负责采集与传输，Kibana 负责可视化。
- Docker 环境下的日志收集面临生命周期短、多行解析、元数据关联等独特挑战，需要专门的设计方案。
- 在后端发布拓扑中，日志不仅是排错工具，更是灰度验证、全链路追踪、容量告警和审计合规的核心数据源。