Prometheus 告警（Alerting）最佳实践（中文总结）

本文档来自 Prometheus 官方文档 - Alerting，核心思想源自 Google 工程师 Rob Ewaschuk 的《My Philosophy on Alerting》，强调简洁、有效、可操作的告警设计。

一、核心原则

1. 告警应基于“症状”，而非“原因”

  • ✅ 告警用户可见的问题：如高延迟、错误率上升、服务不可用。
  • ❌ 避免告警底层原因：如磁盘快满、CPU 使用率高（除非已直接影响用户体验）。
  • 好处：减少噪音，聚焦真正需要响应的问题。

2. 告警必须可操作

  • 每个告警都应有明确的值班人员可执行的动作。
  • 如果收到告警后“什么也做不了”或“只需等待自动恢复”，就不该触发页面通知（Pager）。

3. 保持告警数量极少

  • 只保留那些真正需要人工干预的告警。
  • 目标：每天最多几条有效告警，避免“告警疲劳”。

二、告警层级策略

1. 分层告警（只在关键点告警）

  • 延迟（Latency）：
    • 仅在最靠近用户的层级告警（如 API 网关）。
    • 若底层组件变慢但整体用户体验未受损，则不告警。
  • 错误率（Error Rate）：
    • 仅告警用户可见的错误（如 HTTP 5xx）。
    • 底层重试成功、内部重定向等“非用户感知错误”不应触发 Pager。

💡 示例：数据库慢 → 但缓存命中率高 → 用户无感知 → 不告警

2. 不同请求类型需分别处理

  • 若某些低流量接口问题会被高流量接口掩盖，应单独设置告警规则。
  • 对具有不同 SLO 的服务路径，应分别监控。

三、特殊场景告警

1. 离线处理系统

  • 关键指标：数据端到端处理延迟
  • 当延迟高到可能影响业务时才告警。

2. 批处理作业

  • 告警条件：最近一次成功运行时间 > 阈值
  • 阈值建议：≥ 2 个完整运行周期
    • 例：作业每 4 小时运行一次，耗时 1 小时 → 阈值设为 10 小时
  • 原则：单次失败不应需人工介入；若不能容忍失败，应提高运行频率。

3. 容量预警（非紧急但重要）

  • 如磁盘使用率 > 80%、内存不足等。
  • 虽不立即影响用户，但需人工介入扩容或清理，应设置告警（可降级为邮件/工单，非 Pager）。

四、监控基础设施自身

  • 必须监控 Prometheus、Alertmanager、Pushgateway 等组件的可用性。
  • 推荐使用黑盒测试（Blackbox Monitoring）：
    • 模拟完整告警链路：Pushgateway → Prometheus → Alertmanager → Email
    • 比单独监控每个组件更可靠，能发现集成问题。

五、告警命名与组织

  • 命名规范：社区普遍采用 驼峰命名法（CamelCase）
    • 示例：HighRequestLatency, DatabaseReplicationLag
  • 告警应包含有用信息：
    • 链接到相关 Grafana 控制台
    • 明确指出受影响的服务或组件
    • 提供初步排查指引（通过 Alertmanager 模板实现）

六、容错与松弛（Allow Slack）

  • 允许短暂波动：设置合理的时间窗口（如 for: 5m），避免因瞬时毛刺触发告警。
  • 避免过度敏感：宁可漏报一次，也不要频繁误报导致信任丧失。

总结：好告警的特征

特征 说明
基于症状 用户能感知的问题
可操作 收到后知道该做什么
极少发生 每天 ≤ 几次有效告警
有上下文 链接控制台、提供诊断信息
经过验证 通过黑盒测试确保告警链路可靠

🌟 终极目标：
让每一次 Pager 响起，都值得工程师放下手头工作立即响应。