--- title: 指标与告警 url: https://doc.liz6.com/distributed-systems/08-observability/02-metrics-and-alerts locale: zh area: distributed-systems tags: - distributed-systems - 可观测性 date: 2026-06-30 modified: 2026-07-11 description: RED(Rate/Errors/Duration)看服务端的外部视角,USE(Utilization/Saturation/Errors)看资源的内部视角——两者互补。SLI 是实际测量值,SLO 是承诺目标,SLA 是违约后果。告警设计的第一原则:page 只对人需要立即行动的事,其他进 dashboard——误报… --- # 指标与告警 > RED(Rate/Errors/Duration)看服务端的外部视角,USE(Utilization/Saturation/Errors)看资源的内部视角——两者互补。SLI 是实际测量值,SLO 是承诺目标,SLA 是违约后果。告警设计的第一原则:page 只对人需要立即行动的事,其他进 dashboard——误报会训练值班工程师忽略告警,比漏报告更危险。 ## RED 与 USE 方法论两个互补的视角： ### RED (Rate, Errors, Duration) 面向**服务**——每个 service endpoint: - **Rate**: 每秒请求数——了解流量模式 - **Errors**: 失败率——500s, 超时, 连接错误 - **Duration**: 延迟分布（P50/P90/P99/P99.9）——用户体验 RED 适合所有在线服务（HTTP/gRPC worker），每个 endpoint 至少 3 个 metrics。 ### USE (Utilization, Saturation, Errors) 面向**资源**——CPU, memory, disk, network: - **Utilization**: 资源的使用率（CPU%, memory bytes） - **Saturation**: 资源的等待队列（CPU run queue, memory OOM score, IO await） - **Errors**: 资源的错误（disk IO errors, NIC errors, dropped packets） USE 适合所有物理/虚拟资源——在它们达到 usage limit 之前提前检测。 ## Prometheus HA Prometheus 本身无状态——scrape on each instance。高可用靠两个相同实例独立 scrape: Grafana 查询 Thanos → 自动去重 A 和 B 的 same time series（利用 Prometheus 的 `external_labels` 区分）。 ## SLI → SLO → SLA ``` SLI (Service Level Indicator): 实际测量的指标例: 过去 28 天的 GET /api success rate = 99.95% SLO (Service Level Objective): 我们承诺的目标例: GET /api success rate >= 99.9% SLA (Service Level Agreement): 不达目标的后果例: 若 SLO 不达 → 赔 10% credit Error budget = 100% - SLO = 0.1% 可以"烧"掉: 如果实在要发快速 hotfix (可能短暂破坏 SLO), error budget 是你的"配额" ``` ## Alert 设计原则 1. **Page only on user-visible SLO violation**: 如果指标显示 `P99 latency > 500ms` 但用户仍能使用，不应 pager。只有 `4xx/5xx rate > SLO` 时发 page 2. **Symptom over cause**: alert 应该是"用户看到 500 errors"，不是"CPU 70% 了" 3. **Eliminate noise**: 每个告警都要有明确的 actionable runbook，否则 → 降级为 ticket 4. **Tune for sensitivity vs specificity**: `for: 5m` (至少持续 5 分钟才 fire) 过滤短暂毛刺。`for` 越长 → 检的越晚，但 false positive 越少 ## 误报治理 ``` 常见误报原因: - 阈值固定 (P99=200ms)，但白天 vs 夜间流量模式不同 → 用 percentile over larger window - Alert 在部署期间触发 → 加 maintenance window or suppress during rollout - 误报过多 → alert 被忽略 → 真正的故障漏掉 → 这叫 alarm fatigue ``` 治理：定期 review alert fires——哪些 alert 触发了但没有对应的用户影响？→ 调高阈值 or 改为 ticket。 ## 参考 - **Google SRE Book**: Chapter 6 — Monitoring Distributed Systems - **USE Method**: brendangregg.com/usemethod.html - **RED Method**: grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services *Keywords: RED, USE, SLI, SLO, SLA, error budget, Prometheus HA, alert design, alarm fatigue*