运维大数据日记：故障根源分析之关联规则挖掘

Posted 2020-10-12

当运维工程师每天面对来自不同监控系统中数量庞大、类型复杂的故障告警时，是否感到心有余而力不足呢？

当这些故障告警来自各个不同的厂家设备且类型不一，需要你对各种异构设备都非常了解且完全凭借个人经验时，你是否变得无所适从？

当你从应用系统预警追查到其所在服务器，从中间件服务追查到数据库集群，再从某个数据库节点的缓存命中指标降低追查到是因为存储磁盘的IOPS指标出现了瓶颈，才导致应用所涉及的设备都产生不同程度告警时，你是否曾经祈祷过——当应用系统因访问过慢预警时，上帝能否直接告诉我，就是存储磁盘的IOPS指标出现了问题呢？

答案是肯定的。ITBA运维大数据分析——“故障根源分析”为你揭开神秘的面纱。

在实际运维过程中，现场各种专业监控工具多达十余种，在每天产生纷繁复杂的告警数据中，存在大量的冗余告警信息，它们之间隐藏着一些具有强关联性的告警规则，也就是说某些设施的某些指标告警是由于别的指标告警引起的。

不同类型的设备与设备之间，设备的指标与指标之间，都存在着这样的关系，我们只有找到产生告警的根本原因，才能快速、有效地排除故障，确保业务系统安全稳定运行。

告警关联分析通过融合并转化多条有联系的告警，将它们转换成一条或少量几条包含更多故障信息的告警，以此达到降低活动告警的种类和数目，减轻运维人员的工作压力，提高故障精确定位效率，使系统运行更快恢复正常。

关联规则挖掘是在给定数据集中搜索反复出现的联系。“故障根源分析”旨在发现“告警事务”中“有趣”的相关联系。什么是“告警事务”？所谓事务就是几乎在同一时刻同时发生的事情，我们把几乎在同一时刻发生的告警集合当作一个告警事务，由于告警的产生以及告警数据的传输都会存在一定的时间滞后或者误差，所以把某一“时间窗”（如10分钟）内产生的告警近似为同一告警事务。何为“有趣”的联系呢？我们主要对那种常常（置信度高）在同一事务中出现，并且在历史事务中出现频率较高（支持度大）的指标告警数据感兴趣，其数学描述如下阐述。

关联规则是形如下图的蕴涵表达式，其中x和y是不相交的项集，即关联规则的强度可以用它的支持度和置信度度量，支持度（s，support）和置信度（c，confidence）这两种度量的形式定义如下：

N为历史时间段内总的事务数，σ(x∪y）为支持度计数，表示x和y在N次事务中同时出现的次数。置信度实际上是一个条件概率，表示事件x已发生的条件下事件y发生的概率。

关联规则的发现，给定事务的集合T，发现满足最小支持度阈值Minsup的所有项集（频繁项集），并从频繁项集中提取所有满足最小置信度阈值Minconf的规则。从大型数据集中挖掘频繁项集的主要挑战是，这种挖掘常常产生大量满足最小支持度（Minsup）阈值的项集，当Minsup设置得很低时尤其如此，一个宽度为100的项集产生可能的频繁项集个数为

频繁项集的复杂度是指数级的。

ITBA关联分析采用的是Apriori算法（Agrawal和R.Srikant于1994年提出），通过限制候选产生发现频繁项集，如果一个项集是频繁的，则它的所有子集也是频繁的（先验原理），若{a,b,c}是频繁项集，那么{a,b}、{a,c}、{b,c}都是频繁项集。Apriori算法的核心思想是根据先验原理的逆否命题（如果一个项集是非频繁项集，那么它的超集也不是频繁项集）来进行候选频繁项集的剪枝。

                                                                   关联指标拓扑图

当我们从所有历史告警数据中挖掘出形如A->B,B->C,C->D这样的强关联规则时，我们可以把这三条规则合并为一条规则，随着时间的推移，告警数据量越来越大，且上述关联规则依然有效时，我们就有充分的理由认为告警D是由告警A引起的，而不必去关心告警B和C，从而大大减轻运维人员的工作量，提高了排查故障的准确率和时效性。

                                                                         关联指标组排查

随着ITBA运维大数据分析平台的广泛推广和深入应用，不同用户、不同业务系统发现的告警关联规则可以逐步提炼为知识，对IT运维具有深远的指导意义。

本文出自 “勤智数码” 博客，转载请与作者联系！