4.3 监控告警：QPS 与错误率

场景：告警先于客户投诉，是尊严问题

日志基建完成后，下一个痛点是告警时效。某次故障客户先在群里投诉，我们才去看监控——这种感觉非常丢人。监控的目标定得直接：任何影响可用性的异常，告警必须比客户投诉先到；告警要带足够的信息，让值班同学点开就能定位而不是先去猜。

那个丢人的夜晚后来被写进了团队文化：从此每次故障复盘第一句不再是“根因是什么”，而是“告警比客户快了多少”。这个提问顺序的改变，把时效性刻进了每个人的潜意识。

接云监控（文档入口 cloud.tencent.com/document/product/248）是出于复用考虑：CVM 与 Redis 的基础指标是现成的，我们只需要补上业务自定义指标（网关层的 QPS、错误率、限流数、缓存命中率），统一在一个平台看，告警通道也一并解决。自建 Prometheus 的方案被我们推迟了，现阶段够用就好，把精力留给业务指标质量。

定指标时还有一条原则：只监控会改变行动的指标。每个指标都要回答“看到之后做什么”，答不上来的指标先不建。早期我们犯过求全的毛病，面板里堆了四五十个曲线，值班同学看都不看；砍到十几个核心指标后，面板反而真正被用起来了。

方案：两条生命线与三级告警

我们给监控定了两条生命线指标：QPS（承载力）与错误率（健康度）。其余指标都围绕这两条展开。告警分级决定了半夜会不会被叫醒：

告警的生命线是值班同学的表情：告警泛滥，大家会习惯性忽略；告警珍贵，每一条都被认真对待。我们每月统计告警有效性，误报超两成的规则必须调阈值或降级。

值班轮换制度也一并立下：一周一轮，交接时必须口头过一遍当前告警规则的有效性。轮换让每个人都对告警体系有切肤感受，谁值班谁就有改阈值的提案权。制度与工具配合，监控才不会沦为摆设。

告警内容本身也值得定规范。早期告警只有一句错误率超阈值，值班同学收到后第一件事是开电脑查面板，五分钟就这么被消耗掉了。后来我们规定每条告警必须自带四要素：指标名与当前值、触发阈值、受影响的接口或机器、一键跳转的预设面板链接。点开链接直接落到保存好的视图，省掉一切临时查询。告警上每一个多余的点击，都是凌晨三点对值班同学的消耗。

配置：自定义指标上报

指标采集走两条路：计数类（QPS、限流数）从限流与日志模块的 Redis 计数器每 30 秒聚合一次批量上报；耗时类（P50/P99）在日志缓冲层做分桶统计。上报接口遵循云监控自定义指标规范，批量提交降网络开销：

<?php
// 指标上报（骨架）：每 30 秒一次批量推送
$metrics = [
    [
        'MetricName' => 'qps',
        'Value'      => $counter->get('gw:qps', 30),
        'Dimensions' => [['Name' => 'host', 'Value' => $host]],
    ],
    [
        'MetricName' => 'error_rate',
        'Value'      => round($errs / max($total, 1) * 100, 2),
    ],
];
$monitor->put($metrics);

告警面板按 3.4 节的灰度分组出双曲线（beta 组与 stable 组分开看），这是灰度期能发现问题的前提。面板还叠加了限流剩余令牌与缓存命中率两张副图，四图同屏，值班同学一眼掌握全局。

面板设计也有讲究：曲线颜色固定（错误率永远红色、QPS 永远蓝色），变量统一命名，时间默认最近一小时。这些细节看似琐碎，却决定了凌晨三点被叫醒时，值班同学能不能在十秒内看懂面板。面板是监控的用户的界面，值得当成产品来打磨。

面板还有个隐藏功能：给老板看的 exec 视图。同一套指标，值班同学看的是排查细节，管理层看的是可用率与趋势。我们做了一份精简大屏只放四个数字——当日可用率、实时 QPS、错误率、影响客户数，投在研发区墙上。可见度提高之后，资源申请的阻力肉眼可见地变小了。

踩坑：告警风暴与指标口径

第一个坑是告警风暴。熔断与限流叠加触发时，每秒数十条同类告警刷屏，真正的关键告警被淹没在通知海里。修复是告警聚合：同一规则 5 分钟内只发一条摘要（附发生次数与最新值），并给每条告警带 acknowledged 状态，双人确认才算处理完。第二个坑是口径漂移：错误率的分母到底算不算限流拒绝的请求？早期口径没定清，告警阈值时灵时不灵。统一定义为：分母是全部进入网关的请求，分子是网关自身与后端返回 5xx 的和，限流拒绝单独一个指标不算错误率。口径文档化，是监控可靠的地基。

第三个坑是阈值一刀切。小接口流量低，错误率天然波动大（十个请求错一个就百分之十），同套阈值误报连连。修复是按基线动态阈值：历史 7 天同时间段 P99 错误率作为基线，超过基线两倍才告警。这就是 3.4 节提到的监控基线数据的另一处用途。

第四个坑是自定义指标的维度爆炸。初期给每条接口都建维度，指标数量飙升，报表加载慢、费用也上去了。后来收敛为两级维度：主机维度定位故障机器，接口维度只在 TOP 20 接口上保留，其余聚合成总览。维度不是越多越好，够定位到责任方就行。

第五个坑是通知通道本身也会挂。有次凌晨 P0 告警没有打电话叫醒任何人——短信平台自己延迟了四十分钟，等值班同学看到已经错过了最佳处置窗口。这次教训之后，P0 通道做了双备份：电话与短信分属两个服务商，告警系统对通道也有探活，连续两次发送失败自动切到备用通道。监控系统的每一环如果都是单点，那监控系统本身就不可信。

监控与人的闭环

监控的价值最终落在闭环：告警到人、处理留痕、复盘归档。每条 P0/P1 告警必须在工单系统里有个复盘单，写下根因与改进项，改进项进季度计划跟踪到底。告警没有闭环就是噪音，有闭环的告警是组织学习的数据来源。团队的体会是：监控体系建到深处，其实是在建设团队的反应能力——工具能买到，反应能力只能练出来。

复盘单里有个固定字段叫“告警是否先于投诉”。每个月底统计这个比例，是我们衡量监控体系健康度的北极星指标。从最初的四成，到如今稳定在九成五以上，这个数字背后是每一轮故障复盘的累积。

监控的下一步是自动化。告警闭环跑顺之后，我们试探性地把两类动作交给脚本：熔断持续打开超过十分钟自动创建扩容工单，缓存命中率连续走低自动触发预热任务。注意这里是创建工单而不是直接执行变更——自动化可以加快人的决策，但变更权依然留在人手里，这是我们对自动化的克制原则。网关是流量咽喉，任何自动化动作都必须能被一夜回滚。

监控体系建到深处，其实是在建设团队的反应能力——工具能买到，反应能力只能练出来。

一个告警自检清单

• 每条告警都能在十秒内被值班同学读懂
• 每条告警都对应一个明确的处置动作或升级路径
• 误报规则月度复核，超两成即调阈值
• P0 告警必须能电话叫到人，而非只进工作群
• 值班交接时口头过一遍规则有效性

这份清单贴在每个值班工位上，新同学入职第一周必须背下来。监控系统的最终形态不是多少条曲线，而是一支训练有素的响应队伍。

告警质量也要被运营

告警体系上线半年后我们做了一次盘点，发现一个反直觉的事实：告警规则从最初的 12 条涨到了 47 条，但值班同学的响应速度反而变慢了。原因不复杂——规则越多，单条告警被认真阅读的概率越低。我们从那天起把告警也当产品来运营：每条规则有 owner、有明确的处置文档链接、有半年度存废评审。评审会上只问两个问题：这条规则过去三个月触发过吗？触发后有人采取了行动吗？两个都答不上来的规则当场下线。第一次评审砍掉 19 条规则，告警群的清净让所有人眼前一亮。

这四个数字每月在团队例会上过一遍。还有个额外收获：误报率摊到台面上之后，定阈值的同学不再敢拍脑袋设保守值——因为误报的代价会算到规则 owner 头上，指标公开就是最好的相互问责。告警体系的天敌从来不是技术故障，而是习惯性忽略。

小结

监控两条生命线（QPS 与错误率）加三级告警分级加值班闭环，构成网关的可观测中枢。核心做对三件事：接云监控省下自建成本、告警聚合防风暴、口径与基线数据化。记住告警的尊严不在数量而在准确，一条能救命的告警胜过一百条噪音。

最后提醒一句监控自身的盲区：指标上报链路本身就是一套系统，它挂了你毫不知情。我们的做法给上报任务也做了探活——连续两次采集周期没有数据写入，先于业务异常触发一条元告警（告警系统的告警）。听起来套娃，但它堵住了监控系统安静却失明这个最可怕的故障形态。

延伸阅读

• 4.1 调用日志：CLS 全量留痕
• 3.1 限流设计：令牌桶与漏桶
• 5.1 高可用：多机与容灾切换
• 腾讯云架构实践：监控告警体系