专栏名称: talkwithtrend
中国企业IT人交流的技术社区
目录
相关文章推荐
科普中国  ·  我,一个成年人,成了儿童精神科的病人 ·  昨天  
科普中国  ·  我国首条!自主设计建造,投运 ·  4 天前  
51好读  ›  专栏  ›  talkwithtrend

运维实战:基于频繁项集的告警关联分析系统的研究与实现

talkwithtrend  · 公众号  ·  · 2024-07-30 07:35

正文

【摘要】

近年来,随着应用系统规模的不断扩大,以及主机下移X86平台、小机下移X86平台的快速进行,使得X86平台的分区数急速上涨;不仅如此,随着应用系统复杂性的不断提高和新技术的不断演进,中间件的种类也在不断增长。根据一体化监控平台显示,团队每日需要处理的三级以上的告警条数高达约3000条,面对每日如此庞大的、种类繁多的告警, 7*24运维人员如何在第一时间准确地处理告警对于提升应急运维能力有着重要的意义;同时,由于同类告警的文本内容存在着相似性,如何利用文本相似性提高运维效率也有着重要的意义。

针对大规模网络频繁告警造成的运维压力和核心报警延迟甚至遗漏的问题,改进了Apriori算法用于告警合并,以适应运维场景的实际情况,并且实现了时序关联关系数据挖掘装置。 该装置通过历史告警数据抓取、模型训练和数据验证测试三个步骤完成对告警数据的合并。与传统 Apriori算法不同的是,针对时序告警序列规则一对一串行的特点,该优化算法省去了迭代过程并提出了一种新的置信度计算方式,解决了频繁告警项引起的置信度计算失真的问题,提高了关联规则的可信度。 实验结果表明,该装置有效合并了告警信息,减轻了运维的压力,为海量告警信息故障的根因定位起到了积极的作用。

【作者】 杨梦伦, 中国银行信息科技运营中心工程师,负责系统运维,擅长开源软件、大数据、容器平台相关技术。喜欢开源,曾经做过开发,接触过安全,擅长研究。

1.引言

随着互联网公司业务规模的快速增长,运维正面临着更为频繁的故障告警 [1] 。在大规模网络的运维工作中,每周海量的接警信息对运维工作人员而言工作量过大且难以及时查看,也会给运维带来较大压力,进一步影响故障的根因定位 [2] ,致使核心告警延迟甚至遗漏,造成重大损失 [3] 。因此,需要对海量告警信息进行告警收敛,以获取真正有价值的告警信息 [4]

目前,国内工业界针对以上问题,多采用的是告警合并策略 [5] 。首先,对告警进行分类,通常分为对业务有直接影响的告警 [6] (如在线下降、服务器 ping 不通、业务进程崩溃、业务进程日志中出现致命字符串等)和预警(如在线波动、CPU和内存异常等) [7] ,其次,完成告警的去重、合并和聚合,最后,通过规则库过滤进行告警收敛 [8] ,对于误报、连锁告警、大量告警等现象,会进行根因定位分析等,并做可视化数据呈现 [9] 。然而,采用简单的时间窗口合并、服务组织合并等方式的告警合并策略无法实现大量告警精准归类的目标,且合并效率较低 [10]

从历史告警数据中看,一个故障往往会引发很多相关策略的告警,这些告警在时序上存在一定的关联,所以可以从历史数据中挖掘不同策略间的时序关联关系,从而确定哪些规则是可以合并的,在告警的时候将关联策略合并展示,可以有效的减少告警条数、更清晰的接收故障信息 [11] 。本文从实际运维场景的需求出发,对Apriori算法作出相应改进,并在运维告警的时序信息场景中进行了实际应用,结果表明在告警合并的结果和效率上均获得了显著的改善效果。

2.问题定义

传统的关联关系挖掘方法使用支持度挖掘频繁项集,然后从频繁项集中产生规则,根据各规则置信度,给出关联规则。研究的就是对大量告警进行压缩折叠,从而提取根源告警,减少告警风暴,缩短服务恢复时间。

定义1 告警序列

告警序列 S 是由告警类型集合 E 上的多个有序的告警组成,表示为 S=(s,Ts ,Te),s为序列,Ts为序列起始时间,Te 为序列终止时间。例如在图1中,Ts = 0,Te = 600,告警序列 s由多个有序的告警向量(A,t)组成(其中A为告警监控项,t为告警发生的时间,A∈E)。告警序列实例如图1所示。

图1 告警序列实例

定义2 时间窗口

告警序列S=(s,Ts ,Te)上的一个告警子项,可以表示成 W=(w,ts ,te),ts < t < te ,其中 w = te - ts称为时间窗口。

定义3 告警串行关系

则 Ai ,Aj 之间是串行关系。告警情景 a 由告警事件 A 和 B 组成,且告警 A会导致告警B出现,则A与B为串行关系。


3.背景介绍

假设多个系统通过 RPC 进行服务调用,调用关系如下:D 系统->C 系统-> B 系统-> A 系统。

当 A 系统查询数据库出现查询超时后,告警会层层往前推进,导致 B、C、D 系统均有 N 个超时告警在同一个时间窗口内产生。此时,ROOT 分析可以将告警进行收敛,直接分析出根源告警为 A 系统访问数据库异常,导致 A、B、C、D 多个系统异常。此时,告警关联分析可以挖掘出关联规则,进而可以找到告警根因。

这样,就避免了处理人员和每个系统开发人员沟通,辅助处理人员快速定位问题根源、提高了平均解决时间。

根源告警分析主要分为强关联分析与机器学习两类。

3.1 强关联数据分析

强关联指的是已知确定的关联关系。如:

  • 应用之间的调用链关系

  • 数据库与应用服务器

  • 网络设备与网络设备、网络设备与应用服务器

  • 宿主机与虚拟机关系等

若在同一个时间窗内,有多个强关联的设备或应用服务器同时告警,则大概率认为告警之间存在关联关系。

在权重算法中,有一个重要的规则,链路上存在连续的告警可能存在关联,越靠后的应用越可能是根源。根据例子,分别计算各类根源告警。

继续使用上面的例子,D 应用->C 应用->B 应用->A 应用->数据库异常的情况。

首先是计算数据库根源告警。根据数据库关联关系,会派生数据库类型的数据库告警、A 应用告警。还会派生一条应用类型的 A 应用数据库异常告警。根据数据库派生告警以及数据库与应用的关联关系及权重,可以得出数据库异常导致 A 应用查询超时。

接下来是计算应用根源告警。根据调用关系,先计算出连续多个应用告警的链路。当前 D->C->B->A 四个应用都有派生告警,满足此规则。

然后,找到最靠后的告警应用,也就是 A 应用。列举时间窗口内所有 A 应用的派生告警(可能存在多种派生告警,根据权重计算根源),将权重最高的派生告警标记为根源告警。比如:A 系统内部有 2 种类型派生告警,分别是数据库告警、GC 告警。

根据权重计算规则,数据库告警为 90,GC 告警 10,也就是说数据库异常告警权重最高。这时由于数据库根源告警和调用链根源告警一致,会将两种类型的告警合并。最后得出结论:数据库异常导致 A、B、C、D 系统告警。

3.2 机器学习根源分析

强关联数据分析是对已知告警的关联关系,直接进行根源告警分析。但是有些时候,关联关系是未知的。这时就需要通过机器学习算法,找到告警之间的隐含联系,再进行根源告警预测。

关联规则算法主要进行了 Apriori 算法和 FPGrowth 两类算法的实践。这两类功能相似,都可以发现频繁项集。

按一定的时间间隔划分时间窗,计算每个时间窗内,各种告警一起出现的频率,找出各类告警之间的关联。最终可按分析出的关联关系,生成根源告警。

关联规则算法的优点在于理解和实现起来比较简单。缺点是效率比较低,灵活度也不够高。

4.系统总览

将告警历史数据和资源拓扑数据作为原始数据,这些数据首先经过预处理模块进行清洗、数据抽取、数据加工、数据转换后进行聚类和分类,在这部分合并相似的告警,自动对数据打标,使用聚类数据训练分类器为后续关联分析做准备。在关联分析部分中,对告警进行频繁项集挖掘,找出相关联告警。最后生成根源告警和解决方案。

4.1 数据集与预处理

生产系统的一条告警由12个字段构成,具体数据格式如表1所示。一条告警实例如图2所示。本文采集了时间范围从2023年1月18日至2023年7月5日的489662条告警(约50万条),对其中状态为已关闭的且告警等级为橙色和红色的告警412195(约41万条)进行分析。

表1 告警结构

字段

含义

id

告警ID

log_sys

告警所属系统

log_host

告警主机名

log_ip

告警IP

log_class

告警类别

log_severity

告警级别

log_history

告警来源

log_repeat

告警重复次数

log_message

告警文本内容

log_status

告警状态

start_time

告警开始时间

modify_time

告警修改时间

图2 告警实例

4.2 系统详细介绍

本文设计的基于内容的告警解决方案推荐系统ARS(Alert Reference Solution)系统由告警特征权重构建器、告警聚类器和告警分类器三个模块组成,具体详情如图3所示。告警特征权重构建器模块基于TFIDF方法,实现了一种基于告警内容的特征构建方法以适用于特征化X86平台上的分区所产生的各类告警;告警聚类器模块对特征化后的无标签告警数据集进行聚类,提取类别关键字作为每一类的标签,并对每一类基于专家知识进行人工标记解决方案;告警分类器模块对打标签后的告警数据集训练分类器,并将训练好的模型保存。

ARS系统的操作流程如下所示:

(1)对数据集中的每一条告警基于TFIDF构建告警特征权重向量,生成告警特征权重矩阵;

(2)对所有告警特征权重矩阵训练聚类器,并根据提取的类别关键字进行自动打标,生成打标后的数据集;

(3)人工根据专家知识对每一个类别录入解决方案;

(4)基于打标后的数据集训练分类器,并保存模型;

(5)分类器模块调用特征权重构建器模块处理打标后的数据集;

(6)返回打标后的告警特征权重矩阵训练分类器;

(7)发送请求,获取相应告警的推荐的解决方案;

(8)请求告警基于告警特征权重构建器模块构建特征并作为分类器模块的入模数据;

(9)返回请求告警所属的告警类别,或返回与请求告警最相似的Top N条告警类别;

(10)返回请求告警所属告警类别的解决方案,或返回与请求告警最相似的Top N条告警类别的解决方案。

图3 告警解决方案推荐系统模块

ARS系统操作界面如图4所示。可以看到请求返回了与请求告警最相似的告警解决方案。每个解决方案对应一类告警,该类告警与请求告警的相似度越高,则说明该类告警的解决方案越能为请求告警提供决策依据。

图4 告警解决方案推荐页面展示

4.3 告警特征权重构建器模块

告警特征权重构建器模块基于TFIDF方法,对每一条分词后的告警的log_message构建该告警的特征权重向量。分词使用JIEBA分词器,会对常见的停用词和自定义停用词进行过滤,自定义停用词比如有remedy等中心一体化监控平台专用词汇且该类词汇不具有区分告警的功能。在分词阶段,会有如下5处过滤策略:

(1)保留以中英文开头和结尾的词;

(2)如果是现有生产系统名称或简称,予以去除;

(3)如果是英文词,对于比如mq、qdepth、mysql这类对于告警文本区分度很大的词予以保留;

(4)如果是英文词,且不是正常的英文单词,予以去除;

(5)如果是告警区分度很大的词(经过第三步留下的词),且属于告警强调词,突出该关键词,即增加TF。比如down、ping、tcp、port、space等词汇属于告警强调词,若某一条告警包含该类词汇,则说明这条告警更需要值得关注,即增加该类词汇的权重。

4.4 告警聚类器模块

告警聚类器模块的输入是无标签的数据集经过告警特征权重构建器模块输出的告警TFIDF特征向量矩阵,聚类使用KMeans++算法。KMeans算法的K值的选择对最终结果的影响很大,常常依据先验知识而定,或者根据SSE与K的曲线图的拐点来确定。选择拐点作为K值的原因是在拐点出现以前,SSE下降非常明显,说明继续划分类簇效果会更好,在拐点出现以后,SSE下降缓慢,说明继续划分类簇带来的收益已经变小,结合图5所示,本文最终选择K=230。

图5 K-Means SSE与cluster number关系

4.5 告警关联模块

在挖掘频繁项集,采取移动窗口处理数据的方法提高数据的精确度,使用宽列矩阵转化为稀疏OneHot编码矩阵优化算法提高计算速度和算法通用性,以最小支持度=0.1为阈值,找出所有相关联的告警进行研究压缩合并,实现减少告警风暴,缩短服务恢复时间的目的。

A. 移动窗口处理

将每60s时间窗口内发生的告警视为apriori算法中的一个”购物车”,每个告警的类别为购物车的一个商品类别,即找出经常一起出现的商品组合。

例如:

1、【内存使用率超过80%】和【Swap空间不足】经常一起出现;

B. 宽列矩阵转化为稀疏OneHot编码矩阵

1、告警类别共有500类,告警数量50w条,则dataframe.shape=[50w, 1]

2、OneHot编码后:dataframe.shape=[50w, 500]

稀疏OneHot编码:MultiLabelBinarizer

C. Apriori算法

1、最小支持度=0.1

2、产生频繁项集:时间窗口内经常一起出现的告警类别;

3、关联规则:不同告警类别产生的关联顺序;

4.6 告警分类器模块

对于实时产生的告警,同步推送该告警的解决方案既可以在第一时间提高 7*24 运维人员解决问题的能力和决策能力,以此来保障生产系统的稳定可靠;也可以减少二线运维人员的重复性工作,以此来提高高整个团队的运维效率。

分析历史告警信息的文本相似性,提出了一种基于告警内容的特征构建方法以适用于X86平台上的分区所产生的各类告警,并设计并实现了一种基于内容的告警解决方案推荐模型。分析历史同一时间窗口内频繁出现的告警数据的特征,设计并实现了一种告警关联分析模型,可以为后续的告警压缩、告警根因分析、告警与事件的有效关联提供坚实的技术支撑,具有前瞻性。

告警分类器模块的输入是经过聚类器模块打标和人工专家知识打标后的数据集,该数据集需要经过告警特征权重构建器模块构建出数据集的特征权重向量作为入模的训练数据,模型使用sklearn模块的naive_bayes.MultinomialNB算法训练,本文设定的训练集与验证集的比例为8:2。

4.7 结果与评价

下图展示了告警关联分析结果,以第12组为例,通过聚类算法得出前5条告警为同一类型告警,后55条告警为同一类型告警,这两类告警经过关联分析算法得出他们会经常同时发生,专家系统给出此类告警根因为“负载所连机器没有相应”,解决方案是检查机器进程。

在测试过程中,告警关联规则挖掘平台总共学习了100万告警数据,生成230个类型,生成85条关联规则,其中设置的参数时间窗宽度为1min,支持度为0.1。通过算法挖掘,结合人工分析提取有效的规则,解决了人工梳理告警关联规则成本高、效率低、场景低覆盖问题,为实现告警自动压缩、根告警定位提供技术了支撑,经过测试,在告警压缩、根因分析处理方面有较大提升:

通过告警关联分析,告警数量压缩比13%,减少告警风暴的产生。

提升故障定界定位/根因分析能力,缩短服务恢复时间17%。

分析出的规则通过人工审核,告警在配置的时间窗内关联的准确率达到95%。

5.总结与展望

5.1 总结

本文通过对 Apriori算法的改进和置信度公式的优化,设计并实现了时序关联关系数据挖掘装置,并将其用于大规模网络告警合并场景,从而减少了冗余告警数量,减轻了运维的压力,为海量告警信息故障的根因定位起到了积极的作用,减少了核心告警延迟和遗漏的情况。根据告警场景的实际情况,改进后的Apriori算法能更好地挖掘出关联关系规则,进而提高了该算法的实用性。本文的方法对已发生的告警起到了有效的合并作用,下一步的工作是对告警数量进行预测,对未来预期时间的告警数量进行预测,当超过该预测值的时候,则认为疑似出现大规模告警,然后利用本文的方法对告警信息进行合并展示。

5.2 展望

虽然目前的研究已经能够应用于告警解决方案的推荐,但是还有一些问题需要进一步考虑与研究:

(1)本文目前只针对告警数据中的log_message进行文本分析,提取特征,该告警的其他重要字段并没有有效利用;

(2)在告警特征权重构建器模块中,过滤策略中过滤了一些有着重要区分度的关键字,比如中英文组合的词汇,如J2CA0045E,其表示WAS的jdbc连接错误;

针对上述问题,本课题尚需进一步调研和完善的工作如下:

(1)更细粒度地构建特征权重矩阵;

(2)更细粒度地对关键词进行过滤。

参考文献

[1]Dattatraya V K,Shaila D A. A Universal Object Oriented Expert System Frame Work for Fault Diagnosis[J]. International Journal of Intelligence Science,2012,2(3):63-70.






请到「今天看啥」查看全文