关于数据处理:高效实践|频繁项集挖掘算法在告警关联中的应用

36次阅读

共计 4051 个字符,预计需要花费 11 分钟才能阅读完成。

本篇咱们将次要围绕频繁项集开掘算法的理论利用,即当该算法利用到告警关联场景中时,咱们遇到了哪些问题,如何解决这些问题,以及咱们如何在原始 FP-Growth 算法的根底上进行改良,从而研发了专用于告警关联场景下的 CW-FP-Growth 算法。为了展现该算法的实际效果,咱们在文末给出了这一算法在脱敏数据中的案例。

一、频繁项集开掘与告警关联如何联合?

在前文中,咱们介绍了频繁项集开掘问题以及两种典型的算法,然而如何将频繁项集开掘算法利用到告警关联及降噪中?为了答复这一问题,咱们能够先简要剖析一些运维的典型场景。在理论运维过程中常常会呈现如下状况,零碎短时间内产生了大量的告警,其中局部告警的内容具备较高的重复性,或这些告警之间彼此存在肯定的关联关系,如果每条告警都告诉,那么用户可能会收到大量的信息,然而并非每一条信息都具备很高的剖析价值,这些反复或无意义的告诉并不能帮忙运维人员减速定位故障,反而很大水平上消耗了他们的精力,令他们不能专一于那些真正须要解决的故障。那么如何解决这一问题?

产生这一问题的次要起因在于告警之间不足剖析,如果可能在告诉运维人员之前,对告警进行一些初步的关联剖析与降噪,则能给缩小运维人员承受到的反复告诉,因而咱们尝试了从工夫相关性的角度找出须要剖析的指标告警的相干告警,这些相干告警与指标告警可能属于同一根因,或可能为查找指标告警的根因提供更多的信息,从而帮忙运维人员剖析故障之间的关联关系,使运维人员可能减速根因定位的过程。基于这一指标,咱们采纳频繁项集开掘算法从故障的产生工夫动手,开掘故障之间的关联规定,从而将这些关联规定中可信水平比拟高的局部用于告警降噪中。而在利用这一算法的过程中,咱们也常常被问到一些算法逻辑的相干问题,在这里咱们将简略的介绍这些问题的解决办法。

问题一:如何在数据中开掘尽可能多的关联规定?

在商品举荐的场景中,原始的数据库由多个项集组成,每个项集是消费者购买商品的记录,也就是说这些记录彼此之间的界线十分明确,而在告警关联的场景中,告警是连续不断生成的,因而如何将这些告警宰割为项集成为了咱们在开掘关联规定中面临的第一个问题。

咱们试验的第一种办法是采纳滑动的工夫窗口解决这一问题,将固定工夫的窗口依照 1 分钟的步长进行滑动,则上午 10:00-10:05 内的告警被划分为第一个汇合,10:01-10:06 内的告警被划分为第二个汇合,以此类推。这尽管实现了跨窗口开掘规定,但这一构想引发了新的问题,假如存在规定呈现在 10:04-10:05 这段时间内,那么即便这一规定只呈现了一次,但却呈现在了 4 个不同的告警项集中,这将使得频繁项集算法开掘算法产生大量的错误判断。

为了防止这种数据反复呈现带来的影响,咱们决定采纳一种变通的办法,即采纳了多个固定窗口组合的形式解决这种问题,通过将多个不同起始工夫和切分工夫的窗口的后果加以组合,以挖掘出同一份数据所有可能的关联规定,接着采纳邻接矩阵记录多个项之间的关联度用于筛选并合并屡次开掘产生的反复或抵触的规定。

问题二:如何设计能力更不便用户了解并调整算法的相干参数?

在对频繁项集开掘这一问题的介绍中,咱们引出了反对度这一概念,然而传统的反对度计算方法并不适用于告警关联场景中,或者说不合乎用户的调参直觉。同样一批数据在不同的工夫窗口下产生的告警项集个数并不相同,这导致用户很难依据心田的冀望精确的评估反对度阈值的大小,导致体验变差。

针对这一问题,咱们采纳了告警呈现在几个项集中作为以后项的反对度,比方对于项集 [A, B, C],[B, C, D],[D, F, A],因为告警类别 B 呈现在了项集[A, B, C] 和[B, C, D]中,因而反对度为 2。这近似于将某类告警中的告警个数作为此类告警的反对度,这种形式相比于传统的计算反对度的办法更加合乎用户的主观感知,便于用户依照本人的冀望应用算法。

问题三:如何解决项集中的反复项,解决办法是否正当?

在多个不同的用户场景中,咱们常常被问到这个问题,为解决反复项的问题,咱们最终抉择了保留其中之一的形式。因为项集 [A,B,C] 和项集 [A,A,B,C] 在计算项 A 的反对度时的贡献度是统一的,都会使项 A 的反对度加 1。而如果不去重,则反复项将会烦扰 FP 树的构建过程,比方对于项集 [A, B, C] 和项集 [A, A, B, C],这两个不同的项集将构建出一个长度为 3 的分支和一个长度为 4 的分支,但他们仅具备一个公共节点 A,图示如下,这导致 FP 树产生了不必要的分支,并可能会挖掘出相似于[A,A] 这种无用的关联规定。而保留其中之一的办法可能在不影响后果的前提下解决这一问题,尽管简略然而具备合理性。

问题四:如何抉择聚类维度?

在实现数据的预处理后,咱们依然面临一个重要问题,即该以什么维度聚合告警?在介绍频繁项集开掘的基本概念时,咱们能够发现啤酒不论是哪种牌子,什么规格,他们都属于啤酒,不可能呈现一瓶啤酒被误认为是鸡蛋的状况,也就是说,商品自身具备类别属性,而在告警关联场景中,告警又该如何被划分类别呢?

一种常见的办法是采纳 IP 进行划分,将告警依照 IP 聚类后,采纳该算法的确能够找出零碎中常常同时呈现故障的 IP。但这一办法也存在两个问题,首先不是所有告警都具备 IP 信息,这使得此类办法的应用存在肯定的限度条件,其次这些主机并不一定每次都呈现同样的故障,这使得该办法失去的关联规定并不精确。以上的两个问题使得采纳 IP 作为聚类维度尽管可行但并不总能失去好的后果,是否存在更适宜的维度呢?

通过试验验证,咱们更心愿从故障的维度聚类告警,行将形容同一故障的告警聚合为一类,并通过频繁项集开掘类算法找出哪些常常一起呈现的故障。依据咱们的定义,警报与故障该当具备一一对应关系,因而理论应用过程中,咱们更加举荐用户抉择警报 ID 作为告警聚合的维度。

问题五:如何抉择生成关联规定的评估指标?

通过理论调研,咱们发现用户更加关怀的是哪些规定经常出现,哪些规定在利用到告警降噪过程时不会产生谬误压缩的状况,也就是说用户更加关注规定的反对度与置信度,而对于规定之间的关联关系的强度则须要运维人员亲自判断,并非单纯的通过计算取得。

在试验过程中咱们发现晋升度很难被间接利用在理论场景下,晋升度的计算很容易受反对度计算形式的影响,艰深来说,如果依照原始的反对度计算方法,当项集数较大时,X 和 Y 的反对度都将呈现显著的降落,这将极大的影响晋升度这一指标的理论计算结果,因而理论场景中晋升度的后果并不像料想中那么精确。

综上所述,最终能够抉择置信度和反对度作为关联规定的评估指标,并在计算某个关联规定的相信水平时,计算这一规定对所有子规定的可信水平,并抉择最低值作为以后规定的最终置信度。

二、ACorFrepm 算法的实际效果

基于上述在将频繁项集开掘算法利用于告警关联这一场景中的各种问题,咱们在原始 FP-Growth 算法的根底上进行改良,从而研发了专用于告警关联场景下的 ACorFrepm 算法,为了验证这一算法是否满足理论运维场景的性能和成果要求,咱们做了如下试验。

  1. 算法性能

为了测试算法的性能,咱们利用大批量的模仿数据测试了算法的计算时长,其中项的个数用于模仿理论应用过程中的警报个数,单个项集最大长度用于模仿警报的最多呈现次数,工夫管制在 1 小时内,工夫窗口选为 5 分钟,则共计 12 个项。

工夫性能

通过上述试验后果,咱们能够看出,真正影响这一算法计算效率的是划分后项集的均匀长度以及频繁项的个数,数据总量的影响并不显著。因为理论数据中频繁项数目较少,因而通过屡次理论场景测验,对于一小时内的上万条告警数据的计算均匀工夫不超过 10 秒,但这一数值依据理论数据中频繁项的个数呈现稳定。

空间性能:

上述试验表明算法可能在短时间内挖掘出一百万关联规定,远超理论数据中可能呈现的关联规定数,空间占用较小,即空间性能简直可能满足任何理论数据的需要。

  1. 算法成果

为了验证算法的实际效果,咱们在电网,运营商,银行等多个理论业务场景中测验了该算法,其中的局部关联规定案例如下。

在某网的理论业务脱敏数据中,咱们找出了由成员端口状态 down 产生的告警与聚合接口告警之间的关联规定。从文本形容中能够显著的看出,当接口收回告警时,对应的聚合接口也会在同一时刻收回告警,这些告警具备较强的工夫共现个性,同时文本具备显著的关联,倡议合并剖析。

在某农商行的理论业务脱敏数据中,咱们找出了当队列阻塞并触发自愈脚本产生的告警与零碎恢复正常给出的告警之间的关联规定。当程序阻塞并距离一段时间后恢复正常,从文本内容中能够看出两条形容具备高度关联性,从工夫上也均为 10 分钟以内固定一起呈现的警报,因而能够合并剖析。

三、总结

在本篇文章中,咱们介绍了频繁项集开掘这一问题,并解说了根底算法 Apriori 和目前较为先进的算法 FP-Growth,并详细描述这类问题的相干概念及实现步骤,同时解说了如何将这一算法利用到告警关联场景中,进而实现告警降噪的性能。并介绍了咱们对 FP-Growth 算法作出的改良,以使它可能更好的利用到告警关联场景中,文末咱们给出了改良后算法的实际效果案例和性能阐明,感谢您的浏览。

开源福利

云智慧已开源数据可视化编排平台 FlyFish。通过配置数据模型为用户提供上百种可视化图形组件,零编码即可实现合乎本人业务需要的炫酷可视化大屏。同时,飞鱼也提供了灵便的拓展能力,反对组件开发、自定义函数与全局事件等配置,面向简单需要场景可能保障高效开发与交付。

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

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

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

万元现金流动: http://bbs.aiops.cloudwise.co…

微信扫描辨认下方二维码,备注【飞鱼】退出 AIOps 社区飞鱼开发者交换群,与 FlyFish 我的项目 PMC 面对面交换~

正文完
 0