降噪通知告警治理的7种方法( 二 ) _告警

文章插图
例如：系统巡检CPU、内存、磁盘都正常的话，可以以日报或者周报、月报的形式推动。而小时级的巡检数据正常情况下落库到系统中。需要了解的人员可以去系统中查询。异常情况，比如CPU超过阈值则以告警的形式推送。这样，系统运行正常的话，通知和报警都很少。
（四）聚合压缩
同类报警需要聚合压缩，这方面业界相关的资料就很多了。为了找到同类信息，算法、人工智能都可以用上。
（五）告警闭环
告警触发-->告警确认--->告警处理-->恢复信息
看到一些公司在初期设计的告警就是有问题的时候把报警发出来。其他事情都是手工来做。更好的一种做法举例是这样：
【P0业务告警】5分钟XX业务失败1000笔，成功率0%
对应的监控大盘链接为：链接名
对于监控链接为：链接名
点我确认接收到告警点我确认你在处理告警
这样，有人点击了：确认接收到告警，其他人就知道可以快速联系到谁，节省系统恢复的时间。有人点击了：点我确认你在处理告警，则可以暂停此告警的发送，避免告警风暴。
告警恢复后要有恢复通知：
【P0业务告警恢复】5分钟XX业务失败1000笔，成功率0% -- 已恢复，目前5分钟XX业务失败1笔，成功率99.99%
（六）告警控制
告警控制的手段有自动或手动关闭报警、未处理告警频率递减等。例如：系统如果在发布时由于机器数量降低有1%的CPU使用率上升，则可以在发布时手动或者发布操作关联降级CPU使用率报警。
再比如：在确实出现故障的时候，故障一直没有恢复，本来5分钟报警一次，已经报警了三次了。再连续的报警已经意义不大，可降级成1个小时1次。
（七）明确责任人，以治降噪
告警降噪最好的办法是有问题就处理，问题解决了，告警就消失了。可实际上大家经常面临的问题是：报警大家都收到了，谁也不去解决。所以需要在告警中就明确处理人员：比如当日值班人员或者模块负责人。

降噪 通知告警治理的7种方法( 二 )

降噪通知告警治理的7种方法( 二 )