自己部门日均1000+告警?如何减少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自动化处理

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

在这里插入图片描述

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

无休居士

感谢您的支持,我会继续努!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值