监控系统中怎么定义“故障”的概念

快猫运营团队 2024-12-03 11:57:07

在日常运维工作中，我们经常会听到“故障”这个词，比如：

基础网络故障：比如某个光纤被挖断了
云平台故障：比如认证体系不工作了
业务系统故障：比如订单系统不可用了
数据库故障：比如 MySQL 挂了不再提供服务

用大白话来讲，就是生产环境的 IT 系统出现了问题，影响了其他服务或客户。

在监控系统中，只有监控指标、原始的告警事件，并没有“故障”这个东西。不同的数据虽然相互之间有些关联，但是仅就告警事件、指标数据而言，监控系统难以从中直接识别出“故障”这个实体（虽然这是我们努力的方向）。但是我们要处理故障，总得基于一个实体来推进，这个实体就是系统里的“故障”。我们该怎么抽象这个故障呢？

FlashDuty 中的故障

以 FlashDuty 举例，来看系统中的一些考虑。FlashDuty 作为一个告警事件 OnCall 中心，会接收各类监控系统推过来的告警事件。当 Flashduty 接收到告警事件（比如Zabbix的一条告警通知），系统会自动触发一条告警，而这条告警将会触发一条故障。多条相似的活跃告警，可能会被聚合到同一条故障中，一起分派、通知和处理。我们可以简单的理解为：故障，是相似告警的组合，在没有降噪的情况下，故障等同于告警。反过来，降噪的场景下，故障等同于其关联的多条告警。

FlashDuty 是 Flashcat 旗下的一款告警事件 OnCall 中心，提供告警事件的自动分派、收敛降噪、排班、认领升级等功能。助力企业快速响应故障，降低故障对业务的影响。

我们自然很想把某个故障关联的所有告警都汇聚在一起，但从技术上基本是不可能的。比如某个网络故障是光纤被挖断了，产生了很多告警，有的告警是机器失联，有的是 mysql 连不上了，有的是服务请求超时，这些告警的标题、描述、标签都不一样，基本很难自动聚合在一起。

但是，告警的颗粒度通常比较细，我们在处理告警的时候，不想一次只处理一条，比如我要认领告警，是希望能够批量认领的，所以有很强的需求是把一批告警聚合在一起，至少让我方便的批量处理，即便这个告警集合和真正的故障并非一一对应，但是也有很大的价值。

所以，在 FlashDuty 这种 OnCall 平台里，把一批告警聚合成一个故障，也就很容易理解了。但是一堆告警，其严重程度、状态、处理进度都不同，和故障的对应关系是什么呢？

故障严重程度、状态和进度

严重程度

Info：轻微，服务本身仍然正常运行，仅做服务状态提醒，无需立即处理。
Warning：警告，服务可能出错或者即将发生问题，应尽早介入避免问题升级。
Critical：严重，服务大面积出错甚至中断，用户受到影响，必须理解介入处理。

故障、告警和事件，均使用以上三种严重程度。严重程度首字母大写，您在使用 api 时需要特别注意。三者的严重程度生成规则如下：

事件的严重程度：不同集成来源（如Zabbix和夜莺）的告警事件有不同的严重程度枚举值，Flashduty会按照一定规则映射为以上三种标准严重程度。具体映射关系，请您参阅具体集成的接入文档。
告警的严重程度：等于所关联的事件中最高级别的严重程度。
故障的严重程度：等于所关联的告警中最高级别的严重程度。

处理进度

待处理：故障触发后，处理进度默认为”待处理“，系统会发起自动分派，设置处理人员并进行通知。
处理中：任意人员点击认领故障，处理进度将立即变为”处理中“。在此情况下，故障的处理人员可能处于已认领或未认领的状态，但至少有一个人处于”已认领“状态。当所有处理人都取消认领，故障处理进度将回退到“待处理”。
已关闭：任意人员点击关闭故障或故障自动恢复，处理进度将立即变为“已关闭”。