告警这东西，写查询的人从来不被叫醒，被叫醒的是那个查询本身
最典型的一次：同事给文件处理管道加了个「消息处理数」告警，逻辑听着挺顺——吞吐量嘛，数消息不就行了。结果半夜触发，一看队列里躺着 5 条消息，实际却要下载 26 个 PDF。原来一条消息里能打包 10 个 URL，这细节写规则的人根本不知道，更谈不上什么「权衡成本用消息数做代理指标」。阈值、SLO、几个月积攒的「这数值正不正常」的直觉，全建立在错的单位上。
这不是个例，是所有告警坑的通用形状：指标本身没毛病，指标到意图的映射才是裂缝所在。
一、吞吐别看速率地板，看最老消息年龄
最直觉的吞吐告警是「N 分钟少于 M 条报警」。夜跑批量作业这招天天误报——地板分不清「卡死」和「真没活」。
改用「最老队列消息年龄」：
- 队列空则无老消息，闲时自动静默
- 有活不跑，年龄就涨；消费端挂了、或活着但不消费，都能逮住
- 不用拍脑门定「40 条/分钟算不算正常」，改问「有东西躺超 6 小时没动静吗」——这数字能在复盘会上站得住脚
同一天同一次卡顿，速率地板报了 17 小时，年龄告警只响一次。
二、抓长尾，别光看队列年龄
队列年龄只告诉你「排不出去」，不告诉你为什么。两种可能：
1. 整条链路窒息
2. 主流跑得飞快，就几个烂作业拖后腿
加个单作业截止时间告警——「有没有单个作业跑超 N 分钟」。关键不在它响没响，而在响了几次：
- 几百次超时，吞吐告警也在响 → 主流挂了，尾部告警只是同一次故障的第二视角
- 十来次超时，吞吐正常 → 真就是几个病态输入，去查那个域名、那个超大文件
我们 API 侧的真实数据：两周约 10 次孤立超时，全是个别大文件。同一个告警规则，计数一出，定性立判。
三、别让「成功率」掩盖「部分降级」
99.9% 成功率看起来美，但如果那 0.1% 全是付费用户的核心写入路径，业务早炸了。把成功率拆成「关键路径成功率」和「非关键路径成功率」，前者阈值拉到 99.99%，后者 99% 甚至 95% 都能接受。告警是给人看的，得按业务痛感分级，别让平均值把致命伤抹平。
四、告警规则也要版本控制、也要 Code Review
曾有个规则把 sum(rate(http_requests_total[5m])) 写成 sum(rate(http_requests_total[1m]))，窗口一缩，抖动直接把值抬高三倍，半夜群里全是「误报」。把 PrometheusRule 当代码管：PR 审查、单元测试跑 promtool test rules、变更记录进 CHANGELOG。半夜被吵醒时，你会感谢那个强迫你写测试的自己。
告警治理没有终点，只有不断把「指标到意图的映射」修补得更准。下次加规则前，先问自己：这查询真代表我以为的那个业务含义吗？
