智能运维探索（二） | 如何利用人工智能实现告警关联分析

文章来自公众号——布博士（擎创科技资深产品专家）

上次我们讲到了AIOps新趋势，以及在运维领域的一些应用，（戳↓↓↓，一键了解上期精彩内容）智能运维探索 | 2022年值得关注的三个AIOps新趋势https://www.toutiao.com/i7155726725777719811/后台有收到一些朋友的提问，想了解人工智能在运维领域的价值是怎样的。所以此次文章将从告警角度出发，探索人工智能技术是如何应用于告警关联分析问题的。即：发现告警指标的频繁模式（如在某个时段A指标的异常引起来了B和C指标的异常告警），最终将相同问题引起的多个告警关联到一起进行处理。

▶本文主要包括如下内容：

• 什么是告警的关联分析？

• 告警关联分析的意义是什么？

• 如何利用历史告警数据来完成告警的关联分析？

一、什么是告警的关联分析？

在进入正文之前首先要明白什么是告警的关联分析，我们进行告警关联分析的意义是什么？

做IT的人都非常清楚应用系统是由非常多的技术组件组成，底层数据库数据读写缓慢会直接影响前端用户处理告警的效率，这时我们看到数据库存在告警、告警服务也存在告警、分布式流处理组件也在告警、kafka待处理的原始告警量也在积压等问题。

擎创告警辨析中心的技术架构，由数据库、大数据处理组件、kafka等多个技术组件组成

告警的关联分析，就是通过某种技术手段（数据挖掘技术中的频繁项集）发现应用系统范围内各组件的告警相互影响，从而指导运维经理、SRE工程师去建立关联规则形成关联场景，将同一问题所引发的告警关联到一起进行处理。

二、告警关联分析的意义是什么？

​

告警关联分析的定位是“将同一个问题所引发的多个相关联的告警合并生成一个关联的场景进行处理”，其带来的业务价值，包括：

• 进一步降噪，提高处理问题效率：由于将问题和表象的告警关联到一起进行处理了，我们只需要关注问题告警，其它的表象告警我们可以将其理解为噪音，不必过多浪费精力进行分析和调查，只要问题告警得到解决即可。

• 解决信息混杂，方便数据管理：在数据中心中一旦各种告警到来所有的告警都来到了告警工作台，这些告警是混杂的，通过告警关联可以将无序的告警按不同的问起进行分类管理。

• 更完善的告警上下文，便于因果分析：将多个相关联的告警放到一起进行处理，为告警的处理过程提供了更完善的上下文信息，便于进行因果关系分析。

• 减少告警的处理量：将多个相关联的告警放到一起进行处理，进一步降低了要处理的告警量。

• 加速排障：通过对告警的关联分析，可以加速排障的过程。

通过告警的关联分析，最终目标是在告警发生后，能够更快速恢复业务、恢复生产。

三、如何利用历史告警数据进行关联分析，从而找到有意义的模式？

关联分析是一种无监督的数据挖掘方法，如今它有一个更流行的叫法——人工智能或机器学习。它能够从无lable标签的数据中发现频繁项模式，一个非常典型的例子就是购物篮分析，分析哪些商品是人们经常一起购买的。这样的模式发现之后对人们有一定的启发作用，并通过人的审核（发现有业务解析意义的结果）确认该模式是否应用到生产环境。

在运维领域，我们可以通过对告警对象产生的真实告警数据进行统计分析，发现同一业务系统下不同技术组件及指标之间的相互影响关系，从而生成相应的频繁项集，当再次遇到类似的告警组合满足某个频繁项集的模式后，将这些组合成不同的告警关联场景，从而提高处置告警的效率。

在本场景中频繁项集是基于真实的历史告警数据而进行统计的一种结果，既然是基于真实数据的统计产生结果，那它一定是可以帮助我们的运维工程师、SRE工程师发现这些可用的的有特定运维业务意义的模式，进而使用到告警的关联场景中。

下面我们来看一下在购物行为中（这个例子更容易理解）频繁项集分析场景所需要的数据：

​从这些数据中，我们肉眼可以发现{尿布、啤酒}是一种频繁出现的模式。

而在运维领域，数据就不像购物行为中的数据那么简单，我们先来认识一下运维中的数据：

• 每套不同业务系统由不同的技术组件组成（如：hadoop大数据处理组件、flink流处理组件、WEBLOIGC应用服务器、ORACLE数据库服务器、均衡负载设备、存储设备等）

• A系统的数据库故障不可能影响B系统的应用故障（除非两套系统之间有API调用关系，这种调用关系在本例中我们排障不考虑，API之间的调用分析我们更习惯用调用链路分析）

• 告警示例数据

​购物篮分析是每一个订单为一个独立的购物篮，来分析所有购物篮之间的频繁项集模式。而我们做运维场景的分析，就需要了解如何将这些告警转换为类似购物篮的问题来进行分析。

带着这个问题，我们再来确认一下我们用频繁项集算法在运维领域解决的问题场景： “找到同一个业务系统范围内，不同技术组件之间指标的相互影响模式，进而找到同一问题影响的一组告警”，问题明确之后，我们来看告警如何转换为购物篮问题：

• 01.交易订单号：在告警事件中，我们可以将独立的业务系统按20分钟或您认为合适的时间窗口，切分为不同的时间窗口（类似购物篮中的交易订单号）。

• 02.商品：在告警事件中，我们发现指标之间是相互影响的，因此，这里面的商品即是“告警指标”。下表为“AAA业务系统”按20分钟时间窗口切分之后的结果列表：

​我们做了这样的业务数据转换之后，后续大家就可以利用历史告警数据去做频繁模式的挖掘，具体的实现大家在网上可以找到非常多的算法和使用介绍，在这里不再详述。

在项目中要注意：

• 时间窗口确认：在这里时间窗口的切分，需要在实际的项目中通过不断的实验来发现什么样的时间窗口取得的效果是最好的。

• 业务系统切分：一定要将不同的业务系统分开来进行处理，不同业务系统的影响分析在没有实际的调用关系情况下分析是完全没有意义的。

• 关于指标：现实的生产环境，有很多的系统在产生告警时没有在告警中指定指标的信息，这时候建议您可以使用擎创的文本挖掘工具对告警内容进行模板的提取，不同的模板代表一类问题（如CPU使用率和内存使用率在发生告警时其文本的描述模式是不同的），这样我们在频繁项集模式挖掘时，可以更通用一些。

四、擎创告警辨析中心

擎创告警辨析中心已经将关联分析算法封装在产品中，该能力目前已经在部分客户中得到验证和使用，期待更多有需求的客户可以同我们一起优化和打磨我们的算法结果。

与此同时，它能通过智能化引擎的分析处理，结合过滤、分类、压缩等多个步骤，帮助客户有效地将降噪能力提升到95%以上，实现降本增效的目标。

​

---

​擎创科技，Gartner连续推荐的AIOps领域标杆供应商。公司致力于协助企业客户提升对运维数据的洞见能力，优化运维效率，充分体现科技运维对业务运营的影响力。

▶行业龙头客户的共同选择