告警平台设计及告警收敛通用解决方案
先有监控,后有告警。如果说监控是一瓶红酒,那么告警就是开瓶器,不然只能望酒兴叹「哈哈,想了半天没有找到合适的比喻,刚好有喝酒撸文的习惯,一口下肚觉得很应景,特此做的借喻」。
告警很重要,想想「三体」中人类星际舰队被水滴攻击,人工智能系统却无法发现攻击源,这实在太可怕了。结合日常工作,我抛以下几个问题,作为文章的开始:
- 问题
告警平台正常运行,因紧急变更、人为失误等异常情况导致告警风暴和连锁故障,那么如下:
- 在风暴告警中,如何分辨有效告警和误告警「告警收敛反而会屏蔽运维视野」,如何精准发现问题根源?
- 针对连锁故障,在服务治理实现前,有什么推荐解决方案?
一、告警平台的数据链条
告警,讲究:
- 有效性
- 及时性
- 精准性
看似简单,却和Consistency(一致性)、Avaliability(可用性)、Partition tolerance(分区容错性)「CAP原则」一样,通常只能三选二!
告警处理流程
如图,为告警处理逻辑,分三段:
- 事件输入
- 事件决策
- 事件处理
事件输入:通常遇到的问题是事件太多;
事件决策:通常遇到的问题是决策名存实亡,狼来了的故事太多;
事件处理:未知因素太多,绝大多数公司都做不好,停留在表层,效果好坏,全看老板是否关注,NOC团队是比较好的解决方案之一;
所以,如下情况很常见:
告警太慢被老板骂,告警太多被同事骂。出了问题,开发比运维先知道,还老在群里喊。这谁受的了!
人人都觉得监控工作很LOW B,但却没几个做的好的!
二、告警平台究竟要解决哪些问题?
- 输入端
数据精准、详实、全面、及时。为决策层夯实基础
- 决策端
策略有效、可自动执行、有收敛、有自愈。一句话,就是去人化!
- 处理层
有告警必处理! 看起来简单,但实际几乎做不到。
三、通用告警平台功能集
告警平台功能集
通知告警平台最少需要具备如下功能:
- 多通道告警接口
邮件、短信、电话、企微/钉钉/飞书。短信,电话必备
- 告警渠道健康检测
告警来源号码被屏蔽,标记为广告常见。虽厂商有自动换号机制,但健康检测不可少
- 级联告警
为告警收敛打基础,减少告警信息,避免告警风暴
- 告警收敛
特别重要,依次要有告警自愈、级联告警、告警收敛
- 告警权重
针对不同告警权重,做对应告警策略。
- 告警分层
分业务、分模块、分团队、分时段,必不可少
- 告警升级
包括告警通道告警和告警职级升级
四、告警收敛通用解决方案
告警收敛首先要解决的问题是告警风暴! 回到文首的问题,假设告警平台正常,如何在海量告警中定位到问题根源,或罪魁祸首!
- 告警分组
分业务、分模块、分团队,简单的如DB类的告警通知DBA团队,Nginx的告警通知业务运维。精细化的案例,如:A业务模块告警只通知A运维,而非通知GROUP组。但没有解决Leader
要接受所有告警的场景。
- 告警抑制
有告警自动抑制功能,需事先做告警级联。上游告警屏蔽下流告警。但不容易解决跨团队信息同步的问题。如路由器挂了,如不通知业务侧,会造成重大生产事故无法及时处理。如DB Master挂了,如果不通知 Replication 同步失败,会容易遗漏处理主从失败问题。
- 告警静默
有手动入口设置告警静默,如常规发布窗口,需有入口关闭告警。如明知A告警会引发B类告警,可以提前关闭B类告警。但不容易解决告警遗忘的问题。如维护期结束,告警静默却没有关闭导致告警无法发出。定时告警静默的功能,也不能覆盖全场景。且已经了出来的告警,再静默无效。
- 告警收敛
收敛有很多方式,常见的如:同属性维度收敛、时间维度收敛、次数收敛。但和告警及时性冲突,收敛做的越好,越容易造成告警不及时。导致开发比运维先发现问题,容易造成部门间关系紧张。
同属性维度收敛:zabbix相同事件名、相同主机名、相同业务名称、告警统一ID,等可以做为唯一标识的字段,做频次收敛,或告警合并
时间维度收敛:判断单位时间内告警条数,做告警合并。时间单位通常以秒为单位,和业务属性强相关。通常也会结合属性维度。
最后,总结如下:
- 找共性问题!! 但依然无法解决降维打击的问题!!;
- 级联分析!标注重要程度和关联关系! 交换机坏了必然会产生大量网络不通的问题;
- 权重算法,同类型问题高权重收敛低权限;
- 智能(相似性)算法,绝大多数公司无法实现,有误判情况;