告警平台设计及告警收敛通用解决方案

告警平台设计及告警收敛通用解决方案

先有监控，后有告警。如果说监控是一瓶红酒，那么告警就是开瓶器，不然只能望酒兴叹「哈哈，想了半天没有找到合适的比喻，刚好有喝酒撸文的习惯，一口下肚觉得很应景，特此做的借喻」。

告警很重要，想想「三体」中人类星际舰队被水滴攻击，人工智能系统却无法发现攻击源，这实在太可怕了。结合日常工作，我抛以下几个问题，作为文章的开始：

• 问题

告警平台正常运行，因紧急变更、人为失误等异常情况导致告警风暴和连锁故障，那么如下：

1. 在风暴告警中，如何分辨有效告警和误告警「告警收敛反而会屏蔽运维视野」，如何精准发现问题根源？
2. 针对连锁故障，在服务治理实现前，有什么推荐解决方案？

一、告警平台的数据链条

告警，讲究：

• 有效性
• 及时性
• 精准性

看似简单，却和Consistency(一致性)、Avaliability(可用性)、Partition tolerance(分区容错性)「CAP原则」一样，通常只能三选二！

 

告警处理流程

如图，为告警处理逻辑，分三段：

• 事件输入
• 事件决策
• 事件处理

事件输入：通常遇到的问题是事件太多；

事件决策：通常遇到的问题是决策名存实亡，狼来了的故事太多；

事件处理：未知因素太多，绝大多数公司都做不好，停留在表层，效果好坏，全看老板是否关注，NOC团队是比较好的解决方案之一；

所以，如下情况很常见：

告警太慢被老板骂，告警太多被同事骂。出了问题，开发比运维先知道，还老在群里喊。这谁受的了！

人人都觉得监控工作很LOW B,但却没几个做的好的！

二、告警平台究竟要解决哪些问题？

• 输入端

数据精准、详实、全面、及时。为决策层夯实基础

• 决策端

策略有效、可自动执行、有收敛、有自愈。一句话，就是去人化！

• 处理层

有告警必处理！ 看起来简单，但实际几乎做不到。

三、通用告警平台功能集

 

告警平台功能集

通知告警平台最少需要具备如下功能：

• 多通道告警接口

邮件、短信、电话、企微/钉钉/飞书。短信，电话必备

• 告警渠道健康检测

告警来源号码被屏蔽，标记为广告常见。虽厂商有自动换号机制，但健康检测不可少

• 级联告警

为告警收敛打基础，减少告警信息，避免告警风暴

• 告警收敛

特别重要，依次要有告警自愈、级联告警、告警收敛

• 告警权重

针对不同告警权重，做对应告警策略。

• 告警分层

分业务、分模块、分团队、分时段，必不可少

• 告警升级

包括告警通道告警和告警职级升级

四、告警收敛通用解决方案

告警收敛首先要解决的问题是告警风暴！ 回到文首的问题，假设告警平台正常，如何在海量告警中定位到问题根源，或罪魁祸首！

• 告警分组

分业务、分模块、分团队，简单的如DB类的告警通知DBA团队，Nginx的告警通知业务运维。精细化的案例，如：A业务模块告警只通知A运维，而非通知GROUP组。但没有解决Leader要接受所有告警的场景。

• 告警抑制

有告警自动抑制功能，需事先做告警级联。上游告警屏蔽下流告警。但不容易解决跨团队信息同步的问题。如路由器挂了，如不通知业务侧，会造成重大生产事故无法及时处理。如DB Master挂了，如果不通知 Replication 同步失败，会容易遗漏处理主从失败问题。

• 告警静默

有手动入口设置告警静默，如常规发布窗口，需有入口关闭告警。如明知A告警会引发B类告警，可以提前关闭B类告警。但不容易解决告警遗忘的问题。如维护期结束，告警静默却没有关闭导致告警无法发出。定时告警静默的功能，也不能覆盖全场景。且已经了出来的告警，再静默无效。

• 告警收敛

收敛有很多方式，常见的如：同属性维度收敛、时间维度收敛、次数收敛。但和告警及时性冲突，收敛做的越好，越容易造成告警不及时。导致开发比运维先发现问题，容易造成部门间关系紧张。

同属性维度收敛：zabbix相同事件名、相同主机名、相同业务名称、告警统一ID，等可以做为唯一标识的字段，做频次收敛，或告警合并

时间维度收敛：判断单位时间内告警条数，做告警合并。时间单位通常以秒为单位，和业务属性强相关。通常也会结合属性维度。

---

最后，总结如下：

1. 找共性问题！！ 但依然无法解决降维打击的问题！！；
2. 级联分析！标注重要程度和关联关系！ 交换机坏了必然会产生大量网络不通的问题；
3. 权重算法，同类型问题高权重收敛低权限；
4. 智能(相似性)算法，绝大多数公司无法实现，有误判情况；