云联信息观察：云监控告警，配得太多等于没配

上云第一件事是配监控，于是 CPU、内存、磁盘、网络全配上，阈值都设百分之八十。上线一周，每天两百条告警，运维直接把通知静音。三个月后数据库连接数爆了，没人发现。

告警要分级

致命（业务不可用）、严重（性能明显下降）、提示（资源使用偏高）。致命类打电话，严重类发消息，提示类进日报。分级之后，人才知道哪条要立刻处理。

阈值不要一刀切

CPU 百分之八十对计算型实例算正常，对通用型就是异常。按规格族和业务类型设不同阈值，告警才有意义。

用持续时间过滤抖动

瞬时峰值不构成问题。设成连续五分钟超过阈值才告警，能过滤掉八成噪音。

业务指标比资源指标更重要

CPU 高但业务正常，不用管；CPU 不高但接口响应慢，必须查。接口成功率、响应时间、队列积压，这些才是业务视角的告警。

告警要有处置指引

每条告警配一句处置建议：先看什么、常见原因、找谁。半夜收到告警的人，需要的是操作步骤而不是一个数字。

避免告警风暴

一台宿主机故障，上面二十个实例同时告警。用告警收敛和分组，把同源告警合并成一条，避免刷屏。

定期清理无效告警

每月看一次告警统计：哪些告警从来没被处理过，哪些重复率最高。删掉无效的，调整不准的阈值。

值班与升级机制

谁值班、多久响应、多久没处理升级给谁。没有升级机制的告警，最后都变成未读消息。

监控看板给不同人看

运维看资源和错误率，研发看接口和日志，老板看业务可用性和成本。一个看板给所有人看，谁都看不明白。

告警的静默机制

计划内维护期间，把相关告警静默掉，避免误报。静默要有到期时间，别设成永久，否则真故障也不响。

监控数据的保留

监控指标保留多久，决定了能不能做同比分析。至少保留一年，否则明年想看去年同期数据都没有。

告警的复盘机制

每月看一次告警复盘：哪些是真故障、哪些是误报、哪些是漏报。三类都统计，规则才越调越准。

值守的责任边界

值班人有权做哪些处置，要写清。只能上报不能处置，故障恢复时间会被流程拖长。

指标口径的统一

同一个指标，不同团队算法不同，对比时就会吵架。监控指标的计算方式写进文档，全员统一。

告警的价值在于被响应，不在于数量。分级、按规格设阈值、加持续时间、配处置指引，这四步做完，告警量能降八成，有效告警的处理率反而上升。每月清理一次无效规则，保持清单干净。云联信息【资深云服务专家微信：cloud7591】可以协助设计告警分级和处置手册。