1. Golden Signals 概述
1.1 定义与来源
Golden Signals(黄金信号)由 Google SRE 团队在《Site Reliability Engineering》一书中正式提出,是衡量分布式系统健康状态与用户体验的四个核心指标集合。其设计初衷是:用最少的指标,覆盖用户可见故障与系统内部瓶颈,避免指标爆炸导致运维盲区。
四个黄金信号并非凭空创造,而是从 Google 多年大规模生产运维经验中提炼——任何系统故障,最终都会体现在延迟、流量、错误或饱和度中的一个或多个维度上。SRE 团队发现,只要持续监控这四类信号,就能在 90% 以上的场景中快速定位根因。
核心原则: Golden Signals 不是“所有指标”,而是“最小必要指标集”。在日志工程中,我们通常将这四个信号作为日志采集、存储与告警策略的顶层分类依据。
1.2 四大黄金信号详解
| 信号 | 英文 | 定义 | 典型日志/指标示例 |
|---|---|---|---|
| 延迟 | Latency | 请求从发出到收到完整响应所消耗的时间 | API 响应时间、数据库查询耗时、消息队列投递延迟 |
| 流量 | Traffic | 系统在单位时间内处理的请求量或数据量 | QPS、RPS、每秒写入字节数、并发连接数 |
| 错误 | Errors | 请求处理失败或返回非预期结果的比率 | HTTP 5xx 状态码、业务异常日志、超时错误计数 |
| 饱和度 | Saturation | 系统资源被占用的程度,越接近上限越危险 | CPU 使用率、内存占用、磁盘 IO 等待、连接池耗尽 |
1.3 四大信号在日志工程中的映射关系
在日志存储与可观测性场景中,Golden Signals 并非只存在于指标系统,日志本身也承载着这些信号的关键信息。理解映射关系,是后续优化存储策略的前提:
- 延迟 → 访问日志中的响应时间字段:每条请求日志的
duration_ms或latency字段,是延迟信号的直接来源。 - 流量 → 日志条数/吞吐量:日志系统每秒接收的日志条数、日志体积,本身就是流量信号的一种体现。
- 错误 → 错误日志级别与状态码:
ERROR级别日志、HTTP 5xx 状态码日志,是错误信号的核心载体。 - 饱和度 → 日志系统自身的资源使用:日志存储集群的磁盘使用率、写入队列长度、索引速率,是饱和度信号在日志工程中的具体表现。
存储策略启示: 不同黄金信号对日志存储的要求不同——延迟和错误日志需要低延迟检索,流量日志需要高压缩比,饱和度日志需要高频采样但可接受低精度。这正是后续章节“按信号分类存储”的底层逻辑。
1.4 Golden Signals 关系架构图
1.5 为什么 Golden Signals 对日志存储策略至关重要
在传统运维中,日志存储往往采用“一刀切”策略——所有日志统一采集、统一存储、统一保留周期。这种模式在日志量较小时尚可接受,但当系统规模增长到每天数十 TB 甚至 PB 级日志时,会暴露出三个严重问题:
- 存储成本失控:大量低价值日志(如健康检查、调试日志)占用昂贵的高性能存储。
- 检索效率低下:错误日志与延迟日志被淹没在流量日志中,排查问题时需要扫描大量无关数据。
- 告警噪音过高:未按信号分类的告警规则容易产生误报或漏报。
Golden Signals 为日志存储策略提供了清晰的分类维度:
- 延迟与错误日志 → 需要 热存储(SSD + 高索引密度),保留周期短但查询性能要求高。
- 流量日志 → 适合 温/冷存储(HDD + 高压缩比),保留周期长但查询频率低。
- 饱和度日志 → 可采用 采样存储(降精度 + 聚合),保留周期中等。
常见误区: 不要将“所有日志都存到同一个索引/表中”。这会导致热数据与冷数据混合,既浪费成本又降低查询速度。Golden Signals 的核心价值之一,就是指导我们按信号特征设计分层存储策略。
1.6 四大信号在日志存储中的优先级矩阵
| 信号 | 存储优先级 | 推荐存储介质 | 保留周期 | 索引策略 |
|---|---|---|---|---|
| 延迟 | 高 | NVMe SSD | 7-30 天 | 全字段索引 |
| 错误 | 最高 | NVMe SSD | 30-90 天 | 全字段索引 + 副本 |
| 流量 | 中 | SATA HDD / 对象存储 | 90-365 天 | 仅索引关键字段 |
| 饱和度 | 低-中 | SATA HDD | 30-90 天 | 聚合索引 / 采样 |