12.2 告警与诊断界面：从信号到行动

告警系统的产物不是通知，而是及时、正确的人类行动。一个表达式即使数学正确，如果接收者不知道影响、紧迫度和下一步，它仍是失败的告警设计。

Page 由用户风险驱动

第 9 章已经用 burn rate 判断错误预算消耗。这里补上操作契约。每条会叫醒人的告警至少应满足：

1. 正在发生或即将发生显著用户影响；
2. 人现在采取行动能改善结果；
3. 接收者明确且拥有处理权限；
4. 注释中能定位 dashboard、runbook 和变更上下文；
5. 数据缺失与正常值不会混淆。

CPU 80% 本身通常不满足这些条件。若 CPU 饱和会导致延迟 SLO 快速燃烧，page 用户影响，CPU 作为诊断信号；若只是长期容量趋势，创建工作时间 ticket。

for 延迟触发，keep_firing_for 缓冲恢复

groups:
  - name: atlas-slo
    rules:
      - alert: AtlasApiFastBudgetBurn
        expr: service:slo_errors_per_request:ratio_rate5m > 0.0144
        for: 5m
        keep_firing_for: 10m
        labels:
          severity: page
          service: atlas-api
        annotations:
          summary: "atlas-api 正在快速消耗错误预算"
          impact: "结算 API 的有效请求失败或超时"
          dashboard: "https://grafana.example/d/atlas-api"
          runbook: "https://runbooks.example/atlas-api/budget-burn"

for 要求条件持续一段时间后才 firing，适合过滤短暂抖动；它不是任意降噪按钮，设置过长会吞掉真正的快速故障。keep_firing_for 可在信号短暂恢复时维持 firing，减少反复通知。具体阈值应由 SLO 窗口和 burn-rate 设计推导，不能照抄示例数字。

规则还需要单元测试：正常、阈值边界、持续触发、数据缺失和恢复序列都要覆盖。

Alertmanager 处理通知拓扑

Prometheus 决定“什么条件正在告警”，Alertmanager 负责去重、分组、路由、静默和抑制。

route:
  receiver: default-ticket
  group_by: [alertname, service, cluster]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers:
        - severity="page"
      receiver: primary-oncall

group_by 太细会让一次故障产生数百条通知，太粗又会把不同责任人的事件塞在一起。分组键应保留责任域和故障域，而不是把 pod、instance 等易变化维度默认带进去。

Inhibition 表达“根因告警存在时，抑制同范围的症状告警”，例如集群网络中断时抑制大量单服务不可达。Silence 是有期限、带创建者和原因的人工匹配规则，适合计划维护；它不是删除坏告警的长期仓库。

高可用 Alertmanager 部署还要验证通知链路本身。仅监控每个组件进程存活，不足以证明告警能从规则一路送达值班终端，应定期运行端到端 canary 通知。

Dashboard 按问题分层

一个服务诊断界面可分三层：

第 1 层：用户是否受影响？
  SLO、请求量、错误比例、延迟分布

第 2 层：影响在哪里？
  region、version、route、dependency、tenant tier

第 3 层：为什么？
  饱和度、队列、连接池、GC、下游延迟、trace/log 跳转

首屏不要堆满 CPU、内存和几十条节点曲线。先给出范围、时间、单位、目标线和发布注释，让值班者在一分钟内判断影响。然后允许从稳定的低基数维度下钻。

面板标题应写成它回答的问题，例如“过去 30 分钟哪些区域正在消耗预算”，而不是“Error Graph 7”。百分比统一 0–1 或 0–100 的显示约定，延迟使用秒或毫秒时要在标题和轴上明确。

把变更放进同一时间轴

大量事故与发布、配置、扩容和依赖变更相关。Dashboard 应能叠加 deployment revision、feature flag、schema migration 和 incident annotation，并从异常点链接到：

• 当前运行的 image digest；
• 对应 Git commit 和发布审批；
• 代表性 trace；
• 限定 service、region、version 的日志查询。

这比继续增加十个资源面板更接近根因。

告警评审是持续工作

每次事件后记录：哪些告警率先提供有效信号，哪些重复、迟到或缺少上下文，哪些本应触发却沉默。对每条 page 统计频率、确认时间、是否可操作和自动恢复比例；长期无人行动的 page 应降级、合并或删除。

下一课补上服务端遥测看不到的部分：真实用户体验、合成探测、版本化配置和遥测成本控制。

参考资料

• Prometheus, Alerting practices
• Prometheus, Alerting rules
• Prometheus, Alertmanager
• Prometheus, Alertmanager configuration