云联信息：告警配得太吵，等于没有告警

2026-11-04 4次浏览

一、先分级再设阈值

告警分三级：紧急（服务不可用）、重要（性能显著下降）、提示（趋势异常）。紧急告警走电话和短信，重要告警走企业微信，提示只进日报。全部走同一条通道，重要信息会被淹没。

默认的CPU超过百分之八十告警，对计算密集型业务来说天天响。阈值要按业务基线设：观察两周的真实分布，取九十五分位再加一点余量。有基线的告警才有意义。

CPU瞬时冲到百分百很正常，持续五分钟才有问题。告警规则里加上持续时长条件，能过滤掉绝大部分噪音。这一条改动往往能把告警量降一半。

单看内存使用率高会误报，因为系统缓存也占内存。结合可用内存、swap使用率一起判断，准确率高得多。多个指标同时满足才告警，是降噪的有效手段。

告警内容里带上实例名称、地域、当前值、关联的服务，收到就能判断严重程度。只发一句“CPU过高”，还得先去查是哪台机器，响应时间全耗在定位上。

每月看一次告警统计：哪些告警从未被处理、哪些重复出现、哪些是误报。长期无人处理的告警，要么规则有问题，要么这项监控没人在意，两种都该调整。

每条告警都应该对应一个处理动作或者一份处置手册。收到告警不知道干什么，说明监控和流程脱节了。把常见告警的处置步骤写成文档，值班的人照着做就行。

只靠一个通道可能会漏。短信加企业微信双通道，重要告警两边都发。通道本身也可能故障，这点要有心理准备，不能把全部希望押在告警上。

没有明确的值班安排，告警发了没人应。按周排班，交接时说明当前有哪些未闭环的问题。责任清楚了，响应速度才会快。

告警是异常通知，不是日常观察工具。养成每天看一次监控面板的习惯，趋势变化比单次告警更能说明问题。

促销期流量翻几倍，原来合适的阈值会疯狂告警。节前临时调整阈值，节后恢复，是务实做法。更规范的方式是按时间段设置不同阈值，避免人工反复调整。

一台机器故障会连带触发十几条告警，看不过来。设置依赖抑制：核心服务不可用时，抑制下游的连带告警，只保留根因那条。收到的信息少了，判断反而更快。

谁处理的、怎么判断的、最后怎么解决的，简单记三行。积累三个月，就形成了一份本地的故障处置手册，新同事接手也能照着做。

长期响不停的告警，最后所有人都会无视。宁可少设几条，也要保证每一条都有人看、有人管。告警的价值在于被响应，不在于数量。

云联信息【资深云服务专家微信：cloud7591】提醒：任何一次变更都要能在十分钟内回滚，否则不要挑业务高峰动手。