自己部门日均1000+告警？如何减少90%无效告警？

自己部门日均1000+告警？如何减少90%无效告警？

引用

CSDN

1.

https://blog.csdn.net/Larry_794204525/article/details/142003432

在IT运维中，告警是保障系统稳定运行的重要手段。然而，过多的无效告警不仅会分散运维人员的注意力，还会导致真正的紧急问题被忽视。本文将探讨告警的分类、告警治理的必要性，并提出具体的治理策略，帮助运维团队减少90%的无效告警。

一、告警的类别

一般的告警可以分为以下几类：

1.技术告警

1.1基础设施告警

• CPU利用率过高告警
• 内存使用率过高告警
• 物理机异常告警
• 磁盘使用率过高告警
• ...

1.2基本服务告警

• 中间件告警：比如MQ积压、重试；Mysql异常；Redis异常等等
• RPC服务：下游可用率告警、SLA不符合告警、熔断告警
• 自定义的可用率、TP99等告警
• 流量监控，比如QPS异常波动告警
• ...

2.业务告警

• 资损监控告警
• 核心业务的稳定性告警
• 业务波动告警
• 自定义业务异常通知告警，比如非正常的情况打个业务通知监控
• ...

3.监控大盘告警

此类告警时针对全链路的，一般在压测或者大型活动中使用！

二、为何需要告警治理？

需求繁重，发布频繁，如何保障发布的稳定性保障？比如：

• 新功能上线，新监控告警没有配置，导致流量预期不明，全量发布之后造成故障；
• 老功能改造，核心模块/领域已有监控告警失准，导致异常未识别，全量发布之后造成故障；
• 新老迭代，对外/对内核心监控指标不够聚焦，导致全局健康度失真，造成业务资损。

不同人对告警的配置理解各不相同，导致告警杂乱无章，告警颗粒度不够，告警不准确，看到告警也不知道是什么问题，线上常见告警问题无法快速识别。

告警配置过多，就比如我们部门日均1000+告警，大部分是各种告警阈值不合理等等问题导致，假如每个告警花5分钟来看，一天就是5000分钟的浪费，谁不觉得难受？天天这样的话很多人就会对告警麻木，就好像“狼来了”，真的有严重的线上事故的时候后知后觉，被一线业务倒推问题！

三、治理迫在眉睫

告警治理的核心在于提高告警的质量，减少无效告警的数量，确保关键告警能够得到及时响应。这不仅有助于提升运维效率，还能改善团队的工作环境，减少因无效告警带来的疲劳感。

1.1告警治理策略

为了进一步细化告警治理技巧，并具体化告警质量优化的内容，我们可以从以下几个方面进行深入探讨：

1.2核心监控告警点

• 灰度发布时的核心监控：在新功能灰度发布时，应特别关注流量变化趋势，设置流量预警监控点，如QPS异常波动，确保一旦流量超出预期，可以及时收到通知并采取措施。
• 业务关键点监控：在业务逻辑的关键环节，如数据库交互、消息队列通信、远程调用等，设置异常监控点，当这些环节出现问题时，能迅速定位并解决。
• 全链路综合指标监控：跨服务调用时，设置响应时间、请求成功率等综合指标监控，一旦偏离正常范围，立即触发告警。

1.3避免告警反模式

• 告警描述标准化：确保每个告警都有清晰、详细的描述，包括告警源、告警级别、影响范围等信息，便于快速理解问题所在。
• 告警阈值个性化：根据不同业务场景调整告警阈值，例如对于交易系统，响应时间稍微延长即可能影响用户体验，因此阈值设置应更为严格。
• 告警策略智能调整：利用机器学习模型分析历史数据，动态调整告警策略，减少误报的同时确保重要告警不被忽略。

1.4告警规约制定

• 监控对象选择：只监控那些直接影响用户体验或服务稳定性的关键指标，如系统负载、数据库连接数、网络延迟等。
• 告警触发时机：设置合理的延迟时间，避免因短期波动引发不必要的告警。例如，CPU使用率超过阈值时，可以设置一定时间窗口观察是否持续超过该阈值。
• 告警信息完善：告警信息应包含尽可能多的诊断信息，如发生告警的时间、位置、影响范围以及可能的原因分析。

1.5自动化处理

• 自动恢复机制：对于已知问题，如短暂的服务不可达，可以设置自动恢复机制，如自动重启服务，减少人为干预。
• 自动化脚本部署：编写自动化脚本，用于处理常见的告警问题，如清理缓存、重启应用等，提高响应速度。
• 告警降噪策略：实施告警降噪策略，合并相似告警，减少重复通知，避免同一问题的多次干扰。