目录标题
- 一、告警的类别
- 1.技术告警
- 1.1基础设施告警
- 1.2基本服务告警
- 2.业务告警
- 3.监控大盘告警
- 二、为何需要告警治理?
- 三、治理迫在眉睫
- 1.1告警治理策略
- 1.2核心监控告警点
- 1.3避免告警反模式
- 1.4告警规约制定
- 1.5自动化处理
一、告警的类别
一般的告警分为以下几点:
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自动化处理
- 自动恢复机制:对于已知问题,如短暂的服务不可达,可以设置自动恢复机制,如自动重启服务,减少人为干预。
- 自动化脚本部署:编写自动化脚本,用于处理常见的告警问题,如清理缓存、重启应用等,提高响应速度。
- 告警降噪策略:实施告警降噪策略,合并相似告警,减少重复通知,避免同一问题的多次干扰。