告警风暴来袭，智能运维应如何化解？

云智慧 AIOps 社区是由云智慧发起，针对运维业务场景，提供算法、算力、数据集整体的服务体系及智能运维业务场景的解决方案交流社区。该社区致力于传播 AIOps 技术，旨在与各行业客户、用户、研究者和开发者们共同解决智能运维行业技术难题，推动 AIOps 技术在企业中落地，建设健康共赢的AIOps 开发者生态。

本期我们有幸邀请到了英国巴斯大学硕士生、 云智慧智能研究院 算法研究员卢同学作为主讲人，为我们带来《AIOps 中告警管理方法定义》的分享，下面就让我们一起来学习吧~

引言

随着大数据与AI技术的发展，运维人员在工作中获得了许多高效算法的协助，可以多角度快速梳理海量的信息，加快定位故障的速度。其中，告警消息作为运维人员了解系统运行状况的重要途径，是一种常见的信息来源。通常情况下，一套系统会配备不同的监控中心，它们时时刻刻检测系统的运行状况，并在某个服务器出现故障时，发出对应的告警消息。运维人员通过分析这些告警消息能及时准确的定位故障。基于这一应用场景，本文将从告警消息的特性与挑战出发，介绍智能化告警算法如何在这个过程中发挥作用。

告警管理面临的挑战

告警管理作为运维过程的重要阶段，面临着许多挑战。比如，传统运维场景中的一大难题—如何有效的处理告警风暴。告警风暴是指系统在短 时间 内发出海量告警消息的现象，这通常是由于系统出现了某种故障，导致产生的告警消息数远超运维人员所能处理的最大极限。如何对其进行合理的分析也就成为了运维过程的一大难点。除了上述的例子之外，告警管理中还面临着各式各样的挑战，这些挑战的根本原因可归纳为以下几种：

1. 告警信息多种多样，缺少统一模板标准。 市面上的告警检测系统是由多家厂商基于不同的标准与技术研发的，然而告警消息应包含哪些信息？不同故障的告警描述应包含哪些内容？这些至今都没有统一的模版标准。导致许多重要的故障信息往往被隐藏在告警描述的海量文字中。同时，不同的监控系统中信息并不能有效汇集在一起，也使得故障信息比较分散，加大了运维人员分析故障的难度。
2. 告警信息来源混杂，处理方法存在差异。 大部分告警检测系统收集多种来源的信息，但不同设备与网络应用之间的告警处理方法也有显著差异，实际工作中对应负责的运维人员也不同，这种信息混杂也增加了告警分派处理的难度。
3. 告警触发条件不同，故障通知精准度低。 通常情况下，监控系统会设立不同的告警触发条件，即告警消息的产生并不一定代表系统已经出现故障，也可能是对故障的预警。尽管这种预警机制有其存在的必要性，但不合理的告警触发条件很容易令系统产生大量的无用信息，并频繁通知运维人员，耗费人力物力。
4. 告警原因不明确，故障分析难度大。 绝大部分告警消息只有经历故障的设备名称、发生时间、故障现象等数据，并没有产生故障根本原因的明确说明，甚至可能隐藏在告警风暴中，这进一步加剧了分析故障的难度，需要采用多种方法有效梳理告警。

总而言之，不完备与多类别混杂的海量告警信息显著增加了运维人员的工作量，严重影响了故障定位及修复过程。如何利用智能化算法解决这些问题？该从什么角度选择智能化算法？成为当前告警管理亟待解决的问题。

告警的基本特性

我们通过从数据的角度分析告警的基本特性，以选择恰当的方法分别处理这些问题。经过分析，告警主要具备以下三种基本特性：

1. 相似性

不同的告警信息之间可能存在一定的相似性，这种相似性一方面可能表现在文本描述中，即来自于同一系统的告警消息往往遵循几个特定的模板格式，这使得同一模板下的不同告警信息可能存在一定的文本相似性。另一方面也可能表现在所包含的信息中，比如某些告警信息可能都在描述某个特定程序或机器的运行情况，这些不同告警之间也存在一定的信息相似性。基于这种相似性，我们可以将海量的告警消息合并为多个集合，再分别处理。

2. 相关性

在相似性的基础上，不同模板或所含信息不同的告警之间也可能存在一定关联。比如，假设多个应用程序均使用同一个数据库的数据，这些不同用途的应用又对应多个监控系统。当数据库崩溃时，导致应用也出现故障，令对应的监控系统发出告警。这些告警虽然来源不同并遵循多个模板，但因使用同个数据库的数据导致文本和所含信息可能并不具备相似性，却又都属于应用场景下的告警，具备一定的相关性。基于这种相关性，我们可以将不同的告警消息关联为多个集合，再进一步分析。

3. 因果性

从外部观察告警可能会给人一种印象：一个告警会引起另一个告警。然而，这种印象真的正确吗？

正如上文中所举的例子，假定数据库故障导致了应用层的故障，在数据库发出告警后，应用层也会发出多个告警。这些告警是显然存在因果性的，即数据库告警导致应用告警。但实际情况下，对因果性的分析可能并不这么简单。

这主要是由于告警消息往往只是对故障现象的描述，多个不同故障原因产生的故障现象可能没有区别，所以监控系统发出的告警消息也没有区别。比如，当数据库发出告警时，应用层也发出无法使用的告警。然而，经过运维人员排查，实际上是由于网络连接不畅导致应用层无法使用。同时，在这段 时间 内应用并没有访问数据库，即数据库的故障并没有传递到应用层。这种情况下，尽管应用层和数据库的告警消息看上去存在因果性，但并不合理，因为应用层的故障与数据库的故障之间没有因果关系。

经过以上两个例子可以看出，告警并不具备绝对的因果性，这种因果关系并非存在于告警之间，而是在故障之间，需要经过根因分析的梳理，才能确定这种因果关系是否正确。

智能算法下的告警管理体系

1. 数据来源

作为连接运维人员与故障的重要桥梁，理想的告警应包含足够多的信息。这些信息使我们能够采用多样化算法，帮助运维人员从多角度梳理告警消息，令他们在短时间内排除故障，减少因故障带来的损失。然而实际情况下，监控系统发出的大多数告警并不能满足信息量充足的需求。因此，针对理想的告警消息和必要的告警消息，我们分别提出了如下定义：

• 理想的告警信息： 包含括标识、名称、时间、来源、级别、摘要、描述、持续时间、服务器、IP地址、告警生命周期、告警分派记录、负责的运维人员等等。
• 必要的告警信息: 至少包含告警发生的时间、设备名称、告警描述、告警级别、告警来源等，应尽量满足理想告警信息中的字段需求，当需要类似准确度的评价指标时，需要提供告警修复记录与运维工单等信息。

需要注意的是，告警管理中所需要的数据并不局限于告警信息本身，也需要日志、指标、调用链和拓扑关系、工单等数据协助进行告警管理， 这些数据的具体解释如下所示：

• 指标(Metrics): 是服务管理中的另一种关键数据类型，以固定的时间间隔(例如每分钟)连续收集指标，比如CPU的容量情况，可用于评估告警严重性。
• 调用链和拓扑关系(Tracing and CMDB )： 服务器、应用程序等需要运维监控设备的拓扑架构图，比如网络结构图，可用于基于上下文的告警合并方法。
• 日志(log)： 设备或程序运行时产生的数据，包含了日期、时间、使用者及动作等相关操作的描述，可用于告警定级、事件抽象等情况。
• 工单(Ticket): 工单通常是由告警或故障创建的，当运维人员在处理告警信息的过程中，发现需要进行深入分析的告警时，会创建对应的告警工单，典型的工单比如告警修复记录与故障报告，可用于判断告警关联准确性，也可用于评估告警严重性。

2. 三个阶段

经过对告警数据基本特性的分析，我们可以了解到告警管理的重要性。根据告警信息的相似性和相关性生成告警事件，可以为运维人员提供更简洁的告警信息视图，帮助他们更准确、快速地识别故障源，也可以将生成的告警事件作为智能根因分析的重要依据。 因此，结合告警管理所面临的诸多挑战，我们可以提出以下结论：

告警管理： 合并一定时间范围内的告警信息为多个具有高度相似性的告警集合，再将告警集合关联为多个单一概念的事件。重有代表性的告警事件化，使运维人员能够快速获得告警事件的相关信息。

基于这一定义，告警管理体系一共分为三个阶段，告警富集、告警合并以及告警关联。

1. 告警富集： 对于大部分算法来说，数据量的多少与数据所含信息的多少，都将在很大程度上影响结果的优劣。因此，在采用更智能化的算法之前，需要收集更多相关信息以辅助后续的任务。

• 定义： 告警富集分为信息收集和特征抽取两部分。信息收集是从其他数据源获得告警信息以外的其他数据，比如日志数据、指标数据、调用链和拓扑关系等。特征抽取是采用告警解析与主题抽取等方法，从告警描述中获取告警类型、IP 地址、告警原因等详细告警信息。

2. 告警合并： 告警合并是由告警消息生成警报的过程，每个警报只对应系统中的一个故障，每个故障也只对应一个警报。

• 定义： 将一定时间窗口内的相同来源，相似形式的海量告警信息数据，按照规则聚类，或分类等方法，合并为多个内部特征较一致的告警信息集合，也称之为警报(alert)并进行抽象。
• 警报抽象： 警报抽象主要指为了凸显警报相关信息，或便于运维人员诊断故障而进行的一些后处理工作，比如警报再定级便是综合考虑系统当前健康状态，及告警消息分布情况后对警报优先级的评定。

3. 告警关联： 告警关联是由警报生成事件的过程，事件中所有警报都包含同一个问题的相关信息，事件内警报之间的相关关系应当能够被事件阅览者快速发现，并且即使不具备运维专业知识的人士也能够解释其中的关联点。

• 定义： 综合警报的时间、空间和语意相关性，根据关联场景，将一定时间窗口内的多个警报关联为描述当前场景特定问题的集合，每个集合称为一个事件，并对其进行抽象。
• 对“场景”的解释： 此处的场景可以是基于语意的场景，比如模式一致的警报或类别一致的警报；也可以是基于数据分布的场景，比如经常共现的警报；也可以是基于空间的场景，比如存在一定地理关系的警报，或存在一定拓扑关系的警报。
• 对事件抽象的解释： 在关联完成后，我们也可以根据事件内包含的警报信息重新确定事件的优先级，并为事件描述的问题提供一段简单的摘要，这些处理方法都能够帮助运维人员在短时间内更快速地了解重要事件。

3. 细节描述

在本节中，将针对告警管理体系中的不同阶段给出更详细的说明。

1. 告警富集方法：

• 信息收集： 信息收集是指从外部获取信息，可以按照发生时间，将相同时间段内的指标，日志与调用链数据与告警进行关联。
• 特征提取： 从告警信息内部提取特征的方法有很多，比如正则化与命名实体识别。其中比较简单是正则化方法，即预先人为设定一些匹配规则，当文本中的信息满足匹配要求时，对应的信息会被取出。

2. 告警合并方法：

• 文本相似度合并： 这种方法基于不同告警消息所含的告警描述等文本信息进行分类，将语句相似的告警信息进行合并，并在一定程度上结合已有规则生成警报。

3.告警关联方法：

• 语义关联： 比较典型的关联方法是基于警报类型的的关联方法，则侧重于对同一类型的警报进行关联，类型可以分为系统告警事件、应用告警事件、数据库告警事件、网络告警事件、其他事件等。
• 空间场景关联： 主要指基于警报的host来源/服务器拓扑关系等数据进行关联，将同一个host的警报放入一个事件内，以方便运维人员查看。或者将所有业务类的警报关联为一个事件，方便负责业务层的运维人员处理与自身相关的警报。
• 数据分布关联： 典型的例子是将警报按照时间分布进行关联，将经常一起出现的警报关联为一个事件，这种方法可以有效处理分批次网络入侵中产生的警报消息。

4. 评价指标

5. 降噪比

长期以来，如何评价告警管理的效果都依赖于降噪比，但因为告警问题一直都没有明确的定义，对于什么是降噪比？不同的人有不同的解答。基于本文的定义，我们提出了如下评价指标：

• 合并压缩比(Merge Compression ratio)： 在告警合并阶段，可以通过合并压缩比过进行评价，即合并且经过处理后的警报总数与告警信息总数的比值。
• 关联压缩比(Correlation Compression ratio)： 在告警关联阶段，可以通过关联压缩比进行评价，即关联后的事件总数与警报总数的比值。
• 降噪比(Noise Reduction Ratio)： 对于告警管理体系整体，可以通过降噪比进行评价，即告警分析过程中的合并压缩比乘关联压缩比。

2. 准确性

除了降噪比之外，准确度也是一个重要的评判标准，告警管理产生的事件是否为客户所期望的？

由于不同的客户公司有不同的应用场景，同一个客户公司内不同的人也有不同的想法，所以很难统一的进行评判。在本文中我们认为准确性是客户根据抽查和业务价值评估而评定的一种软定性的指标，算法无法直接给出准确率结果，最终需要客户基于自己的使用情况进行评价。

总结

在本篇文章中，我们说明了告警是故障出现时的一种信息报告，也是运维人员了解故障的信息媒介，并介绍了告警的特性与管理过程中面临的多种挑战。最终，基于告警信息的相似性、相关性和因果性建立了应对这些挑战的告警管理算法体系，并给出了对应阶段的评价标准。在未来的过程中，我们将不断完善这一框架，增加更多有效的算法，帮助大家构建更加智能化的告警管理体系。

开源福利

云智慧已开源数据可视化编排平台 FlyFish 。通过配置数据模型为用户提供上百种可视化图形组件，零编码即可实现符合自己业务需求的炫酷可视化大屏。 同时，飞鱼也提供了灵活的拓展能力，支持组件开发、自定义函数与全局事件等配置， 面向复杂需求场景能够保证高效开发与交付。

点击下方地址链接，欢迎大家给 FlyFish 点赞送 Star。参与组件开发，更有万元现金等你来拿。

GitHub 地址： https://github.com/CloudWise-...

Gitee 地址：https://gitee.com/CloudWise/f...

万元现金活动： http://bbs.aiops.cloudwise.co...

微信扫描识别下方二维码，备注【飞鱼】加入AIOps社区飞鱼开发者交流群，与 FlyFish 项目 PMC 面对面交流～