开始 - 日志监控概述

凌晨两点，支付回调接口开始超时。客服群里不断出现“订单已扣款但页面显示未支付”的反馈。研发打开服务器，第一反应是看日志，但很快发现三个问题：

• 日志散落在多台机器上，要一台台登录。
• 每个服务的日志格式不同，有的有订单号，有的只有错误文本。
• 监控只显示 CPU 正常，没有任何告警说明接口已经大量超时。

这就是日志监控告警系统要解决的问题。它不是简单收集日志，而是让团队在系统异常时具备三种能力：

1. 发现问题：错误率、延迟、吞吐或业务指标异常时，系统能主动提醒。
2. 定位问题：能从告警跳到相关日志、指标和调用链，找到故障发生在哪里。
3. 复盘问题：能保留足够上下文，分析影响范围、持续时间和根因。

可观测性的三类数据

日志监控告警系统通常处理三类数据：

数据	解决的问题	示例
日志	发生了什么具体事件	一条订单处理失败记录
指标	系统状态是否异常	错误率、P95 延迟、队列积压
链路追踪	一次请求经过了哪里	API -> 订单服务 -> 支付服务 -> MySQL

只有日志，团队会陷入海量文本搜索；只有指标，知道异常却不知道细节；只有链路追踪，缺少整体趋势和告警能力。完整系统需要把三者串起来。

核心指标

设计这套系统时，要先定义平台自身的指标：

• 采集延迟：日志从应用产生到可查询需要多久。
• 丢失率：Agent、网络或存储故障时是否会丢日志。
• 查询延迟：排障时搜索最近 15 分钟日志是否足够快。
• 告警准确率：告警是否真的指向需要处理的问题。
• 噪音率：无效告警是否让值班人员逐渐麻木。

这些指标会影响后续架构选择。为了降低采集延迟，我们需要本地缓冲和批量发送；为了减少告警噪音，需要聚合、抑制和升级策略；为了提升定位效率，需要统一字段和 trace id。

课程主线

我们先解决“日志在哪里”的问题，建设采集链路；再解决“日志能不能被理解”的问题，做结构化解析；随后从日志中提炼指标并接入告警；最后用链路追踪和可视化把故障排查流程串起来。

这门课的目标不是堆出一套复杂工具，而是让你理解可观测平台的设计逻辑：每个模块都要服务于发现、定位和复盘。

下一章节日志采集设计应用日志采集链路，包括 Agent、缓冲、批量发送、重试和限流