1. 课程导论：Logging Platform 拓扑概述与数据管道核心组件
1.1 典型 Logging Platform 拓扑结构
在生产环境中，一个成熟的日志平台通常采用多层解耦的拓扑设计，确保数据从产生到消费的路径清晰、可扩展且具备高可用性。下图展示了标准的三层架构：
1.2 数据管道核心组件详解
每个组件在管道中承担不同职责，故障表现也各不相同。下表总结了各组件的功能、常见实现及故障特征：
| 组件角色 | 核心功能 | 主流实现 | 典型故障特征 |
|---|---|---|---|
| 采集器 | 从应用/系统日志文件中读取、解析、过滤日志行 | Filebeat, Fluent Bit, Logstash | 日志行截断、解析失败、文件句柄泄漏、采集速率下降 |
| 缓冲 | 削峰填谷，防止下游背压导致数据丢失 | Kafka, Redis Streams, NATS | 分区偏移量不一致、消费者滞后、磁盘写满、消息积压 |
| 传输 | 可靠地将日志从缓冲层投递到存储层 | Logstash output, Kafka Connect, Fluentd | 网络超时、序列化错误、批量提交失败、重试风暴 |
| 存储 | 持久化原始日志数据，支持高效检索 | Elasticsearch, OpenSearch | 分片未分配、段合并阻塞、磁盘 I/O 打满、写入拒绝 |
| 索引 | 对日志内容建立倒排索引，加速查询 | Elasticsearch mapping, Ingest pipeline | 映射冲突、动态字段爆炸、索引速度慢于写入速度 |
实战经验： 80% 的管道故障发生在采集器与缓冲层之间（网络抖动、认证过期、配置不匹配）以及缓冲与存储层之间（消费者组 rebalance、序列化 schema 不兼容）。排查时应优先检查这两个边界。
1.3 故障排查的通用方法论
面对日志管道故障，切忌盲目重启或随意调整参数。推荐采用以下五步排查法：
- 界定范围：确认故障是全局性（所有日志丢失）还是局部性（仅某个业务线/节点）；是写入故障还是查询故障。
- 检查黄金指标：查看吞吐量、延迟、错误率、饱和度四项指标，定位异常组件。
- 逐层隔离：从采集器开始，依次检查缓冲、传输、存储、索引各层状态，缩小故障域。
- 分析日志与指标：查看组件自身的运行日志、JMX 指标、Prometheus 指标，寻找异常模式。
- 制定修复方案：根据根因选择扩容、回滚配置、重启组件或调整参数，并验证修复效果。
1.4 黄金指标：快速定位故障的罗盘
在日志管道场景下，我们重点关注以下四大黄金指标，它们能帮助你在海量告警中快速锁定问题组件：
| 指标类别 | 指标名称 | 采集层 | 缓冲层 | 存储层 |
|---|---|---|---|---|
| 吞吐量 | 每秒处理日志行数 (eps) | 采集速率 vs 发送速率 | 生产速率 vs 消费速率 | 写入速率 vs 索引速率 |
| 延迟 | 端到端延迟 (p50/p99) | 采集到发送耗时 | 消息在队列停留时间 | 写入到可查询耗时 |
| 错误率 | 失败操作占比 | 解析失败 / 网络发送失败 | 生产超时 / 消费提交失败 | 写入拒绝 / 查询超时 |
| 饱和度 | 资源使用率 | CPU / 内存 / 文件句柄 | 磁盘使用率 / 分区数 | 堆内存 / 磁盘 I/O / 分片数 |
常见误区： 不要只盯着“吞吐量下降”这一个指标。很多时候吞吐量下降是结果而非原因——例如存储层写入拒绝导致背压，采集器自动降速。此时真正的根因是存储层饱和度超标，而非采集器故障。
1.5 故障排查的通用流程
将方法论与黄金指标结合，形成可执行的排查流程：