1. 课程导论：Golden Signals 概念起源与日志工程定位
1.1 概念起源：Google SRE 的四大黄金信号
Golden Signals（黄金信号）概念最早由 Google 在《Site Reliability Engineering》（SRE 运维解密）一书中正式提出。它是 Google 在多年大规模分布式系统运维实践中，提炼出的一组用于衡量用户侧服务健康度的核心指标集。SRE 团队发现，无论系统架构如何复杂，只要持续监控以下四个维度，就能在绝大多数场景下快速定位故障、评估服务质量。
| 黄金信号 | 英文 | 核心关注点 | SRE 经典定义 |
|---|---|---|---|
| 延迟 | Latency | 请求处理耗时 | 服务响应请求所花费的时间，区分成功与失败的延迟 |
| 流量 | Traffic | 请求负载量 | 系统服务请求的速率，通常以 RPS、QPS、吞吐量衡量 |
| 错误 | Errors | 请求失败率 | 显式错误（HTTP 5xx）与隐式错误（返回成功但结果错误） |
| 饱和度 | Saturation | 资源耗尽程度 | 系统资源（CPU、内存、磁盘、连接池）被占用的比例 |
关键认知：Golden Signals 并非凭空创造，而是 Google SRE 团队从“用户可见的可用性”出发，反向推导出的最小必要监控维度。任何偏离这四个维度的指标，在故障排查中往往属于噪音。
1.2 四大黄金信号在日志工程中的价值与定位
传统监控体系（如 CPU、内存、网络 IO）关注的是“系统视角”，而 Golden Signals 关注的是“用户视角”。在日志工程中，日志是唯一能够同时承载这四个信号原始信息的载体。将 Golden Signals 映射到日志字段，意味着我们可以从日志中直接还原出用户请求的全生命周期状态。
- 延迟（Latency）→ 日志字段：响应时间、耗时分布
日志中记录请求开始时间与结束时间，或直接记录耗时字段（如duration_ms）。通过聚合日志中的延迟字段，可以计算 P50/P90/P99 等分位延迟，识别慢请求。 - 流量（Traffic）→ 日志字段：请求计数、请求路径
每一条请求日志天然就是一个流量计数单元。通过统计日志条数或日志中的request_id去重计数，即可获得实时流量曲线。 - 错误（Errors）→ 日志字段：状态码、异常堆栈
日志中的status_code、error_type、exception字段直接反映错误信号。显式错误（如 HTTP 500）与隐式错误（如业务返回 success=false）均可从日志中提取。 - 饱和度（Saturation）→ 日志字段：资源使用量、队列深度
日志中记录的资源使用快照（如cpu_usage、thread_pool_active）或队列等待时间，是判断系统是否接近饱和的直接证据。
日志工程核心命题：将 Golden Signals 从“监控指标”转化为“日志字段映射规范”，使得每一行日志都成为可被检索、可被聚合、可被告警的结构化信号源。
1.3 为什么日志工程需要 Golden Signals？
在微服务与云原生架构下，指标（Metrics）、日志（Logs）、链路（Traces）三大可观测性支柱各有侧重。然而，日志是唯一能够提供请求级上下文的数据源。Golden Signals 为日志工程提供了以下核心价值：
- 统一故障排查语言：开发、运维、SRE 团队围绕“延迟、流量、错误、饱和度”四个维度沟通，避免指标口径不一致。
- 日志结构化规范：以 Golden Signals 为字段设计目标，推动日志从“文本字符串”向“结构化事件”演进。
- 告警降噪：只有与 Golden Signals 相关的日志异常才触发告警，大幅减少无效告警。
- 容量规划依据：通过日志中的饱和度字段（如连接池使用率、队列深度）预测系统瓶颈。
常见误区：不要试图在日志中记录所有指标。Golden Signals 强调“少而精”。日志字段映射应优先覆盖这四个信号，其余指标交给 Metrics 系统处理。
1.4 从 SRE 理论到日志工程实践的桥梁
本课程的核心目标，是建立一套从 Golden Signals 理论到日志字段映射的完整设计方法。下图展示了本课程的技术路线：
1.5 本章小结
- Golden Signals 源自 Google SRE 实践，是衡量用户侧服务健康度的四个核心维度：延迟、流量、错误、饱和度。
- 在日志工程中，Golden Signals 为日志字段映射提供了明确的设计目标，使日志从“文本”升级为“结构化信号”。
- 本课程将围绕这四个信号，逐步展开字段规范、采集、存储、告警与故障定位的完整实践。