AIOps应用：告警数据的应用

背景

随着科技的不断发展，软件系统规模愈发庞大，复杂度日益提升，组件和应用间的联系也更加紧密。海恩法则(Heinrich's Law)指出： 每一起严重事故背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。在系统发生故障之前，通过先兆告警通常可以防患于未然，提前的排查事故隐患。而当系统出现问题时，运维人员第一时间收到的也是各类重要告警信息，告警对于维护系统的正常运行至关重要。

通过收集和分析告警数据，运维团队能够实时了解系统的健康程度，迅速发现潜在问题和异常情况，并及时采取必要的措施。在系统出现故障或异常时，由于各组件及各服务之间的关联性质，通过会出现大范围的大量告警，通过AIOps技术，有效的对告警数据进行管理和分析，能够更高效地处置风险，确保系统持续稳定运行。

总而言之，告警数据在运维中不仅是问题发现的关键，更是实现智能运维（AIOps）、提高系统可靠性和效率的重要原材料。在实际场景中，运维团队时常因为各种原因而每天面对大量无效告警，如何通过AIOps从大量告警中挖掘出真正有价值的信息呢？在深入讨论这个问题之前，让我们首先对告警数据本身进行一些基本介绍。

告警介绍

什么是告警

告警是指系统或应用程序监测到的、与正常操作不符或可能表明存在问题的事件或状态的通知。这些通知通常以消息、日志、警报或其他形式呈现给系统管理员、运维人员或其他相关人员。

告警的目的是及时通知相关人员，以便他们能够采取必要的措施来处理潜在的问题、故障或异常情况。告警通常与系统的监控和管理系统集成，可以涉及各种方面的系统状态，如性能、安全、可用性等。

告警数据的特点：

即时性： 告警数据通常是实时生成的，反映了系统当前或近期发生的异常情况。这使得及时采取行动来处理问题成为可能，有助于减少潜在的影响。

关联性： 告警数据通常不是孤立存在的，而是与其他数据和事件相关联的。通过分析告警数据的关联性，可以更好地理解问题的根本原因，并采取更有针对性的解决方案。一条告警有多达十个个乃至几十个字段，而其中很多与告警关联并没有重要联系

频繁性： 一些系统可能会生成大量的告警，而其中的大多数可能是瞬时或不重要的。有效管理和过滤告警数据，以便集中关注于最关键的问题，对于维护人员是很重要的。

冗余多：故障发生时，多个设备可能产生同一种告警，引起的连锁故障也会造成一系列告警，最终形成告警风暴，很多表象告警会导致根源告警不能被及时发现。严重告警会导致故障发生，次要或冗余告警只起到提示或预警的作用。 往往严重告警发生的频率低，而次要或冗余的告警 发生频繁。

告警和事件、故障的关系

故障、告警和事件是在运维监控和系统管理中经常遇到的概念，它们在性质和意义上有所不同。

1. 故障（Fault）：
   • 定义： 故障指的是系统中的错误、缺陷或问题，导致系统的部分或全部功能无法按照设计预期正常运行。
   • 性质： 故障是实际发生的问题，是一个具体的、存在的缺陷或错误。
   • 示例： 服务器硬件故障、应用程序崩溃、网络中断等。
2. 告警（Alert）：
   • 定义： 告警是系统或应用程序监测到的、与正常操作不符或可能表明存在问题的事件或状态的通知。
   • 性质： 告警是一种通知机制，用于即时提醒相关人员系统的某些方面可能存在问题。
   • 示例： CPU使用率超过阈值告警、安全漏洞检测告警、服务不可用告警等。
3. 事件（Event）：
   • 定义： 事件是系统中发生的任何可测量的、记录的事情，可能包括正常操作、警告、异常或故障。
   • 性质： 事件是一个广泛的概念，可以包括正常操作、预定任务、告警和故障等。
   • 示例： 用户登录事件、定时任务启动事件、数据库备份完成事件等。

在实践中，这三个概念之间存在一些重叠。告警通常是对系统中某个事件（如故障）的反应，而事件则是一个更通用的术语，既包括正常的操作和计划任务，也包括异常和故障。因此，故障可以被视为事件的一种特殊类型，而告警则是对特定事件的响应。

总体而言，故障表示系统的不正常状态，告警是一种通知机制，而事件是系统中发生的可测量的事情，包括正常和异常情况。

告警的一般分类

告警可以按照多个维度进行分类，这取决于系统或应用程序监控的方面以及组织的需求。以下是一些常见的告警分类方式：

1. 严重性：
   • 致命告警： 指示系统存在严重问题，可能导致系统崩溃或无法正常运行，需要立即处理。
   • 严重告警： 表明系统存在问题，需要紧急处理，但尚未达到致命程度。
   • 一般告警： 提示系统发生了一般性的问题，需要关注但不太紧急。
   • 信息告警： 提供关于系统状态或事件的一般信息，通常不需要立即干预。
2. 来源：
   • 系统基础设施告警： 由操作系统、网络设备等基础设施生成的告警。
   • 应用程序内部告警： 应用程序自身生成的告警，通常与应用程序内部的问题相关。
   • 第三方服务告警： 与依赖的外部服务或组件相关的告警。
3. 类型：
   • 性能告警： CPU 使用率高告警 内存不足告警 网络带宽超限告警
   • 安全告警：恶意登录尝试告警 病毒检测告警 安全漏洞扫描告警
   • 可用性告警：服务不可用告警 数据库连接失败告警 硬件故障导致的可用性问题告警
4. 业务关联性：
   • 业务关键告警： 直接影响关键业务流程或核心业务功能的告警。
   • 非业务关键告警： 对业务影响较小或可以暂时忽略的告警。
5. 本质：
   • 表象告警：故障造成的结果告警，往往看不出根源，需要运维人员进行进一步分析
   • 冗余告警：同一告警在某一时间段内的重复告警，或者一些不重要的周期性告警
   • 根因告警：往往是造成故障的原因的告警
   • 波动告警：因指标波动造成的一类告警，通常不涉及到故障的发生

告警是运维中非常重要的一部分，它们使得管理员和工程师能够及时发现和解决潜在问题，从而确保系统的正常运行和稳定性。以上分类方式并非相互排斥，而是可以组合使用，根据具体情况来对告警进行更细致的分类。根据实际需求，组织可以制定适合其运维管理的告警分类标准。

AIOps能做哪些事情

在当前复杂的业务系统下，往往一个微小的故障就可能会影响一大片服务所承载的众多业务，进而会产生一系列告警，形成告警风暴。在此背景下，AIOps应用的主流方向一般有两个：告警压缩（收敛），根因告警定位。在很多方法里，这两个场景是同属一个流程的。下面会按照通用的步骤一一讨论。（告警降噪和告警压缩存在效果相同的部分，很多告警策略也可以达成告警降噪的效果，本文只讨论使用AIOps算法进行降噪的方法）

告警数据预处理

告警数据预处理对于AIOps场景而言是必不可少的，对原始告警数据进行一系列的操作和转换，以提高数据的质量、减少冗余信息、降低噪音，而后的数据才可以作为后续场景建设的基础。通常的预处理手段如下：

提取关键字段：一条告警中有多达几十个字段，然而与告警关联有关系的字段并不多，因此需要根据实际业务情况选择有用的字段，通常包括告警发生时间、告警消除时间、告警持续时间、告警源名称、告警源类型、告警标题、端口名称、告警级别等
数据清洗：许多告警存在字段缺失，重复发送等问题，因此需要根据业务理解把明显无用的告警剔除，比如可以剔除同一时间段重复类型的告警，剔除部分不重要的告警（比如一些毛刺、周期性告警，及告警等级低的告警），去除告警时间明显异常的告警，去除或填充字段缺失的告警，也有一些算法会计算告警权重，去除那些低权重的告警
滑动窗口及步长划分：
是 告 警序 列 的 提 取：用 于将 具 有 时 序 特性 的 告 警转换 为 可 以 用 于 序 列 模 式挖掘 算法 的 告 警序 列

告警关联分析

告警是故障和隐患的体现，通过相关性分析，多条相关的告警数据可以被合并为一条，从而提供更准确的信息。告警相关性分析有助于网络管理人员对海量告警信息进行筛选和总结，缩小故障范围。因此，使用告警相关性分析可以从海量告警数据中提取有价值的信息，清除冗余告警，并准确定位故障根源，对故障的诊断与定位具有重要意义。

通常而言，告警的关联分析会将大量经过预处理的告警数据作为输入，下面介绍一下常规的告警关联分析的方法：

基于专家知识构建关联规则：利用特定先验专家知识和规则集合进行分析推理，建立专家规则库，通过推理引擎进行告警关联分析。简单易理解，能够进行实时监控，但对专家知识的依赖较高，缺乏自学习能力，维护规则库困难。

基于特定算法挖掘关联规则：Apriori算法和FP-Growth算法是应用于告警关联的经典方法，二者都是基于频繁模式的挖掘而生成关联关系；无需先验知识，适应性强，能够快速挖掘网络告警的关联关系。

基于拓扑结构图计算关联路径：将告警结合已有的CMDB拓扑、调用链拓扑等拓扑进行关联；定位准确率高，定位时间效率较高，但需要依赖准确的拓扑模型。

基于文本相似度的关联：将文本相似度高于阈值的告警合并为一条，避免告警风暴的困扰。但是相似度评价指标难确定，选择好的度量函数难度较高。

基于社区发现与划分方法：在网络图中，内部连接紧密的节点集合所对应的子图称为社区。一般在告警拓扑生成之后进行的剪枝和划分。

这里对第二种方法（特定算法挖掘关联规则）进行展开讲解，此类方法一般会通过划分滑动时间窗口及步长的方法，得到多个时间片下的告警序列（组合起来就是告警共现矩阵），再通过对共现矩阵的分析，得到告警间的因果关联关系。

告警共现矩阵的定义：给定一个过滤后的历史告警数据集合 D，时间滑动窗口大小Tw，其中包括 n 个告警种类，可生成一个 mxn 大小的共现矩阵Mmxn（如下图）：
关联事务集 Ri： 用一维数组进行表示，其数组长度为n，表示n 个告警种类，表示某个滑动窗口下告警的发生情况。如果在第 i 个滑动窗口内，某种告警的实例发生，我们记为1（忽略发生的次数）；否则记为 0。
其中r ij表示在第 i 个时间窗口内所对应的关联告警事务集Ri 中，第j 个告警元是否出现。其中 r ij的取值范围为0或1，1代表告警发生，0代表告警不发生。

基于告警共现矩阵，我们就可以得到告警之间的拓扑关系了，通常会采用因果发现算法计算得出：如PC、GES、CCDr、LiNGAM等算法。因果边的权重表示条件概率，即因出现后，果出现的概率。这步得到的可能是一个大图，可以配合社区发现与划分方法进行社区划分，形成告警关联子图。

这里对几种告警压缩会用到的拓扑做举例：
告警拓扑：描述各种告警之间因果关系的拓扑，一般通过告警共现矩阵生成
CMDB拓扑：构建物理机、虚拟机、软件及主机组间的对应关系的拓扑
调用链拓扑：构建系统、服务、应用间调用关系的拓扑；调用链数据本身可以和host关联起来
网络设备拓扑：网络设备之间形成的拓扑；也即流量路径

告警压缩与根因告警定位

告警压缩是指将多条告警压缩成少量的几条；根因告警定位是指在多条告警中识别出某条告警，此告警是导致其余告警发生的根因。按照告警关联分析的做法，可以分为两大类：
1.基于文本相似度的压缩：将多条告警根据相似度压缩成一条，本质上只是聚类压缩，没有告警的因果压缩；
2.基于因果关系的压缩：将多条告警根据因果关系压缩成一条根因告警，本质上是因果压缩，也即只输出处于因果链更上游的根因告警。这里的因果关系可以只使用共现矩阵（+社区划分）得到，也可以结合其他拓扑信息合并成知识图谱，再进行推断，这种方法会更有可解释性。

总结

在当前复杂的业务系统环境下，告警数据的处理、关联分析和根因定位成为保障系统稳定性和运维效率的重要环节。通过 AIOps 技术的应用，运维团队能够更加智能地处理大量的告警信息，更加高效地应对复杂系统环境下的各种挑战，保障系统的稳定运行。随着技术的不断发展，AIOps 在运维领域的应用前景将更加广阔。