这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
凌晨两点的故障
凌晨两点，支付开始超时
凌晨两点，支付回调接口开始超时。
客服群里不断出现「订单已扣款但页面显示未支付」的反馈。研发打开服务器，第一反应是看日志，但很快发现三个问题：
- 日志散落在多台机器上，要一台台登录。
- 每个服务的日志格式不同，有的有订单号，有的只有错误文本。
- 监控只显示 CPU 正常，没有任何告警说明接口已经大量超时。
这就是日志监控告警系统要解决的问题。
它不是简单收集日志
它要让团队在系统异常时具备三种能力：
| 能力 | 含义 |
|---|---|
| 发现问题 | 错误率、延迟、吞吐或业务指标异常时，系统能主动提醒 |
| 定位问题 | 能从告警跳到相关日志、指标和调用链，找到故障发生在哪里 |
| 复盘问题 | 能保留足够上下文，分析影响范围、持续时间和根因 |
故障现场的三个教训
- 分散的日志不可用：多实例时代，逐台登录翻日志是灾难。
- 非结构化日志不可查：没有统一字段，无法聚合和关联。
- 只看 CPU 是盲区：接口超时是应用层问题，基础设施指标反映不出来。
一句话
凌晨的故障暴露了三个缺口：日志分散、格式不一、监控无效。日志监控的目标不是收集数据，而是让团队能发现、定位、复盘问题。
发现内容有问题？
告诉我们哪里需要改进。