智能运维系列专题简介：智能运维（AIOps），根据Gartner的最新阐释，意指整合大数据和机器学习能力，通过松耦合、可扩展方式去提取和分析数据量（volume）、种类（variety）和速度（velocity）这三个维度不断增长的IT数据，进而为IT运维管理产品提供支撑。在此，微众银行智能运维团队根据一线工作的实践经验与心得体会，特别撰写了《智能运维系列》文章，本公众号后期将陆续发布，敬请持续关注。
点击回顾：智能运维系列（三）| 浅析智能异常检测——“慧识图”核心算法
点击回顾：智能运维系列（四）| 曝光交易路径
点击回顾：智能运维系列（五）| 浅析基于知识图谱的根因分析系统
点击回顾：智能运维系列（六）| 根因分析过程中的运维管理实践
点击回顾：智能运维系列（七）| 化繁为简–业务异常的根因定位方法概述
点击回顾：智能运维系列（八）| 事件指纹库：构建异常案例的“博物馆”
点击回顾：智能运维AIOps系列（九）| 基于交易树的根因告警定位方法
随着分布式技术的快速发展及广泛应用，系统之间的调用不断增多，各服务之间的依赖错综复杂，现实场景中也经常出现一次交易中包含十余次系统间服务调用的情况。当交易发生异常时，多个系统的运维人员往往同时排查各自的系统，然后汇总分析结果，按照调用顺序分析，最终确定异常系统。
然而，这样的常规操作在面对海量交易的时候，复杂性将指数级上升。在大规模的分布式架构下，依赖传统的运维方式无法实现快速的根因定位。因此我们设计了一种自动化、智能化的根因定位方法。本文中将介绍在异常时，告警风暴发生后，如何进行根因告警分析。根因告警分析主要包括原始证据收集、证据分类分析、证据强度分析、构建分析图谱、根因告警推理这五个步骤。
原始证据收集
收集原始证据是根因告警分析的第一步。异常事件发生时，系统立即启动证据收集任务，从告警列表中搜集异常开始前一段时间内(当前为5分钟)的记录，以保证告警与异常有充分的时间相关性。此外，为了降低告警噪音，我们只选取较严重的minor级别及以上(告警级别由低到高分别为info、warning、minor、major、critical)的告警作为原始证据。除告警外，通常还会有其他数据源中的数据作为告警的补充，目前主要是一些变更操作记录。原始告警经常会将关键信息展示在告警描述或告警标题中，便于运维人员阅读，但对于系统来说，结构化数据显然更适合分析。具体的证据收集流程如下图：
图 1 证据收集流程
证据分类分析
在收集了原始数据之后，需要对原始证据进行分类分析，目的是解析不同类型的告警，输出统一的格式化证据用于后续的根因分析。通常将异常事件的根因分为网络、主机、DB（数据库）、WEMQ（消息总线）等若干个类别。每个类别都会实现一个该领域的根因证据子收集器。子收集器利用各自领域的知识构建，同时通过回溯历史案例，挖掘并归纳出一些规律和特征。子收集器的主要作用是从原始证据集中找出属于该类别的原始证据。分类的过程中会以告警中的部分字段（见表1）作为特征，通过这些特征的组合判断出告警所属的类别及对应的具体组件。例如: ci类型=主机，告警对象=10.1.1.100，告警标题包含关键字“CPU”，可以判断该告警是主机10.1.1.100的性能异常。
表 1 告警特征字段
原始证据分类之后，还需要补充每个证据的影响范围。证据的影响范围是根因分析中最重要的信息之一，是基础组件和异常业务指标之间的主要联系，是告警分析的基础。各类型证据的影响的维度是不同的，主要包括子系统、DCN（网络区域）、主机IP、IDC（机房）等。影响范围的提取主要依赖CMDB中的配置数据，各类证据影响范围的提取方式也不同（见表2），需要从CMDB的各个数据视图中获取。
表 2 证据类别及影响维度
证据强度分析
证据的强弱也会影响对根因的判断，弱证据通常影响较小，不会轻易被推举为根因，需要更多辅助信息的支持，例如异常交易在某个IP、DCN或IDC上聚集性。相反，强证据则表示该组件发生较严重的故障，导致业务指标异常的可能性就越大。如何区分强弱证据呢？目前我们主要从告警频率和告警级别2个维度进行判断。
告警频率主要判断某个告警是否是高频的，可以分为短期内频繁告警和周期性告警：短期内频繁告警通常指在异常开始之前的一段时间(参考值为24小时)内频繁重复触发的告警；周期性告警更容易理解，是指该告警每天（或某个特定周期）都被触发。这两类告警出现频率高，与突发的异常事件相关性较小，会被判定为弱证据。偶然出现的告警更能够代表该设备或组件的异常状况，会被判定为强证据。
告警级别代表了告警的严重性。通常情况下，运维人员会定义相对较低的告警阈值，用来做异常的预警，而不是在故障非常严重时才触发告警，这类告警也会被判定为弱证据，级别较高的告警则被视为强证据。
接下来，将我们将收集并分析后的证据缓存到证据池中准备在后续的根因定位时使用。目前我们选择neo4j中作为证据池，neo4j是一款高性能的开源NOSQL图数据库，它将结构化的数据存储在网络上而不是表中，便于在节点之间灵活地建立关联关系，无需设计复杂的表结构。例如，我们在前面收集到的证据可以作为网络中的顶点(Vertex)，影响范围作为边(Edge)，形成一张有向图。neo4j还能够支持事务，确保每次异常事件产生的数据完整写入。
构建分析图谱
证据收集之后，证据池(neo4j)中已经保存了统一格式的结构化证据，主要包含证据分类、影响范围(含多个维度)、证据强度、证据描述以及一些附加信息。除证据之外，neo4j中还会写入异常事件相关的交易链路信息。通常会选取异常时段的若干笔异常交易，将交易链路上的每一次调用作为一个节点，节点上包含了子系统、IP、调用状态(是否失败)、响应时间等信息。这些节点信息和证据的影响范围在neo4j中可以建立起一定的关联关系，将原本孤立存在的证据与异常事件连接起来，构成一张用于根因分析的图谱。
根因告警推理
根因推理的前提是交易中断分析。中断分析是分析每笔交易路径上的中断点(或高耗时点)并利用统计的方法找到异常交易的中断点共性(高度聚集的子系统、DCN或IP等)。异常交易的中断分析是根因分析中最重要的环节，决定着根因定位的方向。
在已构建的分析图谱中，存在着一定的层次关系。推理时从异常事件出发，再到异常指标，找出失败或高耗时交易，统计异常调用汇聚的子系统、DCN或IP，最后再定位到根因证据。例如图2所示，异常交易的交易日志可以汇聚到一个子系统，该子系统又与证据相关联，则可以推理出根因。
图2 异常交易关联告警证据
实际生产案例中，不同维度的中断信息可能关联到不同的证据。因此我们还要对证据的优先级进行排序。通常情况下，异常子系统是我们首选的维度，因为它承载着具体的服务接口，通过分析业务日志或交易路径可以比较准确的定位。为了避免遗漏证据，也会用上游和下游的子系统关联的证据作为备选。其次是IP和DCN，它们会承载多个服务，关联关系相对较弱，如果聚集性很高，也可以用来关联证据作为备选。当然，如果有几个维度同时关联到某个证据，那么它是根因的概率也更大，排名也会更靠前。最终会选取n个排名最靠前的证据作为根因。
总结
以上是我们目前所采用的根因告警分析方法，整合了告警、变更等原始证据，分析证据影响和证据强度，再结合异常交易的中断分析，最终实现根因的定位。目前，异常事件根因定位速度通常在30s内，分析效率远远高于人工。不仅如此，80%以上的异常可以被准确定位。此外，根因定位过程的每一步的推导都有比较明确的方向，整个过程也有迹可寻，也便于接下来实现根因定位过程的可视化。
目前，我们仍在对分析进行优化和改进。首先，随着案例的不断积累，利用关联规则挖掘算法可以提取更多潜在的有效告警证据，丰富证据池，也可以发现证据之间的关联关系，可以形成一些辅助的推理模型，类似于运维人员积累经验，这是个长期的过程。其次是数据质量的提升。一方面是告警的细化，直接影响业务的告警与其他类型的告警需要增加区分度；另一方面证据的影响范围大多取自CMDB的配置数据，那么，底层组件的作用范围和服务对象的准确性，直接影响分析图谱数据的准确性。最后，分析效率还会持续提升，以确保在业务系统大面积异常的极端情况下能够在短时间内定位根因。
如果希望了解我们在智能运维中使用的机器学习算法以及支持根因分析的具体方法，请参阅该系列其他文章。
（作者系微众银行智能运维系统核心开发者 刘超）
该文章转自公众号：金融科技微洞察
转载请注明出处
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/notes/293988.html