1. Golden Signals 概述：定义四大黄金信号
在可观测性工程中，Golden Signals（黄金信号）是由 Google SRE 团队提炼出的四个核心指标类别，用于衡量用户侧与系统侧的真实健康状态。它们不是简单的监控项，而是从海量日志、指标、链路数据中抽象出的最小完备集——只要这四个信号完整，就能快速定位绝大多数生产故障。
1.1 四大黄金信号定义
| 信号 | 英文 | 核心含义 | 日志/指标典型来源 |
|---|---|---|---|
| 延迟 | Latency | 请求从发出到收到响应所消耗的时间 | 访问日志中的响应时间字段、APM 链路耗时 |
| 流量 | Traffic | 系统承载的请求量或数据吞吐量 | HTTP 请求计数、消息队列积压量、网络带宽 |
| 错误 | Errors | 显式错误（5xx）与隐式错误（慢响应、错误业务码） | 日志中的 status >= 500、业务异常堆栈、超时记录 |
| 饱和度 | Saturation | 系统资源被消耗的程度，越接近上限越危险 | CPU/内存/磁盘使用率、连接池占用、goroutine 数 |
关键认知： 四个信号必须同时观察。只看延迟可能漏掉流量突增导致的排队；只看错误可能忽略即将饱和的资源。Golden Signals 的威力在于交叉验证。
1.2 在可观测性中的核心地位
可观测性三大支柱——日志（Logs）、指标（Metrics）、链路（Traces）——各自产生海量数据。Golden Signals 的作用是降维：将分散的观测数据映射到四个业务/系统维度，让 SRE 团队在告警风暴中快速找到根因。
- 日志 → 错误与延迟：通过结构化日志提取 status、duration、error_code，直接计算错误率与 p99 延迟。
- 指标 → 流量与饱和度：通过计数器（Counter）和仪表盘（Gauge）聚合 QPS、CPU 使用率、磁盘 IO 等待。
- 链路 → 延迟分解：通过 Trace 的 Span 耗时，定位延迟是发生在网关、业务逻辑还是数据库。
实践建议： 在日志采集阶段就为每条日志打上
golden_signal_type 标签（latency/traffic/error/saturation），后续压缩与存储策略可以按信号类别差异化处理——例如错误日志保留更久，饱和度指标采样率更高。
1.3 Golden Signals 关系图
下图展示了四大黄金信号如何从原始日志/指标中提取，并汇聚到可观测性平台进行故障定位：
1.4 为什么日志工程必须关注 Golden Signals
本课程的核心主题是日志指标数据压缩与存储优化。理解 Golden Signals 是优化策略的前提：
- 差异化保留策略：错误信号日志需要全量保留 30 天以上；饱和度信号可以降采样后只保留趋势；延迟信号需要保留 p50/p95/p99 分位值而非全量。
- 压缩优先级：流量信号通常数据量最大（每条请求一条日志），优先采用列式压缩（如 Parquet + ZSTD）；错误信号数据量小但价值高，采用低压缩比高保真存储。
- 存储成本控制：通过 Golden Signals 分类，可以将热数据（最近 7 天）与冷数据（7 天以上）的存储引擎分离——热数据用 SSD + 高 IOPS，冷数据用 HDD + 高压缩比。
常见误区： 不要试图对所有日志使用相同的压缩算法和保留周期。错误日志的压缩比可能只有 2:1，而流量日志可以达到 10:1。统一策略会导致存储浪费或数据丢失。Golden Signals 分类是精细化存储设计的第一步。
1.5 四大信号在日志中的典型字段映射
| 信号 | 日志字段示例 | 聚合方式 | 典型告警阈值 |
|---|---|---|---|
| 延迟 | response_time_ms, upstream_latency |
p50 / p95 / p99 分位 | p99 > 500ms 持续 5 分钟 |
| 流量 | request_count, bytes_sent |
QPS / RPS / 吞吐量 | QPS 突增 > 200% 基线 |
| 错误 | status_code, error_type, exception_class |
错误率 = 错误数 / 总请求数 | 错误率 > 1% 持续 3 分钟 |
| 饱和度 | cpu_usage, mem_usage, disk_io_wait |
均值 / 最大值 / 趋势斜率 | CPU > 85% 或磁盘 IO 等待 > 50ms |