腾讯云服务器监控告警收敛：告警太多等于没有告警
一个客户把告警群截图发给我，一天四百多条消息，最新一条是三天前的磁盘告警，没人点开。他们的腾讯云服务器从八台涨到三十台，监控策略还是当初那几条，一台机器一套，谁也没动过。他问我怎么提高监控覆盖率，我说你们的问题不是覆盖不够，是信号被自己淹了。告警的价值不在数量，在"响起来就一定有人处理"这个确定性上。
告警疲劳是三条流水线一起造出来的
第一条是阈值拍脑袋。CPU 超过百分之八十持续五分钟就告警，这个数字在很多团队里是从上一家公司抄来的。它对四核的机器和三十核的机器含义完全不同，对 web 服务和编译机的含义也完全不同。拍出来的阈值通常偏保守，于是每天都在报，每天都"没事"。
第二条是单指标不聚合。一台机器一条策略，CPU、内存、磁盘各一套，三十台就是九十条策略。任何一次机房级别的网络抖动，都能同时触发几十条超时告警，群里瞬间刷屏，人只会往上滑到底部看有没有别的消息。
第三条是告警直达个人。没有值班表，没有群，通知绑在某一个人的手机上。他一休假，链路就断；他一天被 @ 五十次，就会把群设成免打扰。免打扰这个动作，等于把整套监控关掉了。
三条叠加的结果是可预期的：真故障来的时候，它和另外四十七条噪音混在一起，没人分得出来。团队开始说"告警不准"，于是进一步忽略，最后监控退化成一份没人看的报表。告警系统的第一目标不是发现所有异常，是让每一条发出去的告警都被当真。
三层指标，别混在一个阈值里
基础设施层看机器：CPU、内存、磁盘使用率与 inode、网络带宽、进程存活、云盘性能是否受限。这一层的指标在云服务器 CVM 的控制台里默认就有，最容易采，也最容易滥采。它们的共同点是只能回答"机器累不累"，回答不了"用户有没有感觉"。一台 CPU 百分之九十的机器可能一切正常，一台 CPU 百分之二十的机器可能已经拒绝服务。
中间件层看组件：数据库的连接数、慢查询数量、主从延迟，缓存的命中率与内存淘汰次数，消息队列的消费堆积，反向代理的 5xx 比例与上游超时数。这一层的指标离故障更近，因为它反映的是"请求在这条链路的哪一段卡住了"。我一般要求客户至少把连接数和慢查询这两项做成告警，它们比 CPU 更能提前预警。
业务层看结果：下单成功率、支付回调失败率、登录失败率、核心接口的 P99。这一层数量最少，但每一条都该是 P1。只监控基础设施的团队有个共同特征：永远在用户投诉之后才知道出事，因为机器指标全都正常，问题出在"机器正常但业务逻辑错了"，比如回调验签失败、库存扣减超时。
三层的告警数量应该是个金字塔，业务层最少最准，中间件层中等，基础设施层最多但大部分只进日报。反过来做成倒金字塔，就是现在绝大多数团队的现状。
阈值之前，先把口径统一
CPU 看均值不看瞬时。备份、日志轮转、一次批量任务都会在几秒内把 CPU 顶到满，瞬时峰值告警没有意义。用五分钟均值，并且要求连续若干个周期都超线才触发；同时区分用户态、内核态和 steal，steal 高说明是宿主机层面的争抢，不是你的进程在吃 CPU。
内存看 available 不看 free。Linux 会把空闲内存拿去做页缓存，free 那一列常年只有几百兆，看起来随时要 OOM，实际可用内存充足。正确的口径是 free -m 的 available 列，或者 /proc/meminfo 里的 MemAvailable，它已经把可回收的缓存算进去了。用 free 做阈值，几乎必然天天误报。
磁盘要同时看使用率和 inode。小文件多的场景，比如会话文件、缩略图缓存、邮件队列，容量还有一半，inode 已经用尽，写文件报 "No space left on device"。df -h 看不出来，要用 df -i。这是我在生产环境里见过最多的"莫名其妙的磁盘满"。
网络看利用率也看重传。带宽打满会慢，重传率高同样会慢，而且后者在带宽指标上完全看不出来。netstat -s 里的重传计数、ss -s 的连接状态分布，配合云监控的出入带宽，才能判断是拥塞还是链路质量。
进程存活不要只探端口。端口通不代表服务能用，我见过探针只做 TCP 握手，应用已经进入只读模式还在报健康。应用层探针要带回业务语义，比如查一次数据库、取一个缓存键，成功才返回 200。
最后一项容易被忽略：时间同步。多台机器的时钟漂移几分钟，告警时间线就对不上，复盘时你说 A 先挂他说 B 先挂，争半天发现是 chrony 没配好。
分级不是排优先级，是决定谁被打断
分级唯一的判据是"这条告警该不该让人从床上起来"，不是"这个指标有多吓人"。P1 是业务不可用或者有数据丢失风险，走电话加短信，同时拉值班群；P2 是 SLO 即将被突破、容量逼近上限，走群消息，工作时间内处理；P3 是单机指标越界但业务无感，进日报；P4 是趋势和容量规划，进周报或者直接转工单。
同一条阈值在不同业务下的级别应该不同。磁盘百分之九十，对一台跑着主库的机器是 P1，对一台跑日志归档的机器是 P3。分级如果只按指标定，不按承载的业务定，就一定会出现"每次都电话轰炸，最后被拉黑"的结局。
响应时限要写死。P1 五分钟内认领，三十分钟未恢复升级到技术负责人；P2 十五分钟内认领，两小时内给出处置结论。时限写在群公告里，不要只存在某个人的脑子里。
分级做完会发现一个反直觉的结果：P1 的数量应该很少，一个月超过十来条就说明要么系统真不稳，要么分级没做对。P1 泛滥的组织，通常会把所有 P1 都当 P3 处理，这是人的本能。
把这些级别、时限和收敛手段放在一张表里，值班的人照着执行就够了。
级别 判定依据 通知渠道 首次响应时限 收敛手段
P1 业务不可用或存在数据丢失风险 电话加短信，同时拉值班群 五分钟内认领，三十分钟未恢复升级 抑制同链路衍生告警，只保留根因指标
P2 SLO 即将被突破，容量逼近上限 值班群消息 十五分钟内认领，两小时出结论 按实例组聚合，同一策略合并为一条
P3 单机指标越界但业务无感 日报汇总 次个工作日处理 不进即时通道，只做趋势记录
P4 容量趋势与成本类指标 周报或工单 按迭代排期 转为容量规划输入
事件类 宕机、意外重启、异常登录、安全事件 按影响面选电话或群 五分钟内确认 与指标告警建立抑制关联
聚合、抑制、静默与维护窗口
聚合解决"五十台机器五十条告警"。用腾讯云服务器的标签体系做分组，环境、业务、角色三个维度基本够用，一条策略覆盖一个实例组，告警内容里列出受影响的实例清单，而不是发五十条。手机上一屏能看完的信息，才有可能被处理。
抑制解决"根因和症状一起响"。数据库不可用的时候，上层应用的所有超时告警都是症状，应该被抑制，只留数据库那一条。网络抖动的时候，该可用区的连接超时告警同样应该被压掉。抑制关系要按依赖图画，画不出来说明你还没搞清楚系统怎么连的。
静默是手动挡，必须带到期时间、写清原因和关联工单。永久静默是事故的温床，我见过一条静默设了两年，期间那台机器的磁盘告警一次都没发出去，直到写满宕机。规范很简单：静默最长七天，到期自动失效，续期要重新填原因。
维护窗口用在发布、迁移、压测之前。更靠得住的做法是把它做进流水线：发布任务的第一步开启三十分钟维护窗口，最后一步关闭。靠人记得去点，十次里有三次会忘，忘的那次就是半夜被叫起来的那次。
还有一种收敛是靠收敛周期：同一条告警在 N 分钟内只发一次，恢复时发一条汇总，说明"过去一小时该告警触发过多少次、涉及哪些实例"。噪音变成统计量，信息量反而更高。
事件告警与自定义监控，各管一段
事件类和指标类不是一回事。针对腾讯云服务器的宕机、意外重启、异常登录、暴力破解尝试、云盘性能受限，这些不需要阈值，发生即通知，而且往往比指标更早。安全类事件的告警尤其要单独走一条通道，不能混在业务告警里被刷掉。
自定义监控补的是"云监控不知道的业务事实"。队列积压多少、定时任务有没有跑、昨天对账是否完成，这些都得自己上报。云监控提供自定义指标的写入接口，具体调用方式和字段以官方文档为准，不要照着旧博客抄参数。
定时任务最容易被漏掉，因为它失败的时候什么都不发生，没有指标、没有日志、也没有告警。做法是反向心跳：任务每次成功结束上报一个时间戳，监控判断"超过预期时间没有上报"就告警。用"没发生"作为触发条件，是这套体系里最值钱的一个技巧。
日志告警要克制。关键字匹配的误报率极高，一条正常的错误日志被采集进告警，能让值班的人白熬一晚上。要用结构化日志加频率阈值，比如"同一错误码五分钟内超过五十次"，而不是"出现即告警"。
值班、升级与复盘
值班表按周轮换，交接放在周一上午，交接内容包括未闭环的告警、本周的变更计划、以及正在观察的可疑实例。值班人必须有处置权限：能重启、能扩容、能看账单，只能看不能动的值班等于没有值班。
升级路径要机械。到点没人认领就自动升级，不依赖"他应该看到了"。这条规则的价值在深夜体现，白天大家都醒着，看不出差别。
复盘只对 P1 做，但要做透。每条 P1 必须能回答四个问题：触发原因是什么、影响面多大、当时做了什么处置、怎么避免下一次。答不上来的告警，要么降级，要么删掉，不要留着过年。
每月做一次清理：统计触发次数最多的十条策略，要么改阈值，要么改聚合方式；统计三个月零触发的策略，检查是不是阈值太松或者指标根本没采到。两项加起来半小时，效果比加十个新指标明显。
作为腾讯云代理，我们给客户交付监控方案时，最后一定会留一页"告警台账"，写明每条策略的级别、负责人、上次调整时间。没有这一页，半年后没人说得清哪条策略还有用。
FAQ
Q：告警少了会不会漏掉故障？
A：漏故障的原因通常是没采到关键指标，不是告警太少。把三层指标里的业务成功率、中间件连接数、反向心跳补齐，比多加二十条 CPU 阈值有用得多。收敛掉的是重复和症状，不是覆盖范围。
Q：磁盘告警阈值设多少合适？
A：单看百分比没有意义，要结合增长速率。做法是取最近七天的使用率斜率，算出"按当前速度还有几天写满"，剩余不足三天就告警。这样一台长期停在百分之八十五的机器不会每天吵，一台从百分之六十快速涨到七十的机器会提前被看到。
Q：静默和维护窗口有什么区别？
A：静默是针对单条或一组告警的手动屏蔽，用于已知问题，必须带到期时间和原因；维护窗口是一段时间内对一批资源的统一屏蔽，通常由变更流程触发。两者都不能永久生效，区别只在粒度和触发方式。
Q：小团队没人值夜班，怎么做分级？
A：把 P1 的范围压到极小，只保留"用户完全用不了"和"数据可能丢"两类，其余全部进群和日报。同时用自动处置兜底，比如进程挂了自动拉起、磁盘满了自动清理临时文件，把夜间需要人介入的概率降到可接受的水平。
结语
说个真事。去年冬天凌晨三点，我被一条磁盘使用率百分之八十五的告警电话叫醒，爬起来连上去看，是 nginx 的日志没做轮转，占了十几个 G。删日志五分钟，人醒了两个小时。第二周我们做了两件事：给所有机器加 logrotate，把磁盘告警改成"使用率百分之九十，或者按七天斜率算出二十四小时内会满"，级别从 P1 降到 P2 进群。
今天能做的三步：把现有告警按"会不会叫醒人"重新标一遍级别，标完你会发现至少一半可以进日报；给每条策略补上聚合维度和抑制关系，把五十条压成一条；挑一条最吵的策略，改成按增长速率判断，观察一周。做完这三步，告警数量大概会掉一个数量级，而真正需要你起床的那几条，会第一次变得显眼。
如果需要更深入咨询了解可以联系全球代理上TG:jinniuge 他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。不懂找他们就对了。