告警该指向 runbook，不是指向图表

一句话总结

能够从 panel 创建告警，与该告警是否有用，是两回事。决定其用途的不是阈值，而是 for 与 runbook_url。

为什么需要它

只要一个请求失败，5xx 比例就会骤升。在流量较少的凌晨，一次失败甚至可能占到百分之几。如果一超过阈值的瞬间就呼叫人员，一天会响好几次，人们最终就会忽略告警。

告警失效的方式总是如此：不是被关闭，而是被忽视。真正的故障也会和它一起埋没在无人理会的告警频道中。

for 正面解决了这个问题。写成“连续超过 10 分钟”后，短暂的尖峰会自然过去。呼叫人员的告警如果没有 for，迟早必然会被忽略。

它如何工作

Grafana 的告警规则由多个片段连接而成。

片段	作用
查询（A）	从数据源获取数值
阈值（B）	判断该数值是否超过标准
condition	指定依据哪个片段的结果进行判断
for	必须持续超过多久才发出呼叫
annotations	供人阅读的内容——摘要与 runbook 地址

只有查询而没有阈值，就不是告警，只是指标，因为没有规定何时触发。

而且，以上内容都可以写入文件。

apiVersion: 1
groups:
  - orgId: 1
    name: shop-api
    folder: Lab
    interval: 1m
    rules:
      - uid: shopapi5xx
        title: ShopApiHighErrorRate
        condition: B
        for: 10m
        annotations:
          summary: 5xx 비율이 10분 넘게 0.5% 를 넘었습니다
          runbook_url: file:///root/graf/runbook.md

在 UI 中创建的告警规则会与 dashboard 遭遇同样的命运——只留在这个 Grafana 实例中。

如果在告警中放置 dashboard 链接

接到呼叫的人点击链接后会看到图表。图表只说明哪里异常，却不告诉人该做什么。凌晨 3 点真正需要的不是图，而是处理顺序。

runbook 可以很短，通常三个章节就足够。

章节	应包含的内容
哪里坏了	用一两行解释此告警的含义，以及用户正遭遇什么
先查看什么	可以实际执行的命令或查询。“确认状态”毫无帮助
如何回退	找到原因之前首先采取的措施，通常是回退最近的部署

**最好先写 runbook，再创建告警。**这样，那些无法回答“告警响起时，人现在该做什么”的告警，从一开始就不会被创建。

常见误解

“告警越多越安全。”每增加一条告警，其余所有告警的可信度都会略微下降。真正的预算不是数量，而是人的注意力。

**“只要划分严重级别就行。”**加上 severity: warning 后发送到无人查看的频道，不是在创建告警，只是在增加一条日志。

实际工作中真正重要的事

创建告警时只需问一个问题：“它响起时，人现在要做什么？”

如果答案是“先观察一下”，那它不是告警，而是 dashboard panel。如果答案明确，就把它写进 runbook，让告警指向该文档。这两行内容会改变接到呼叫者最初五分钟的行动。