共计 7345 个字符，预计需要花费 19 分钟才能阅读完成。
汤泳，苏宁科技团体智能监控与运维产研核心总监，中国商业联合会智库参谋，致力于海量数据分析、基于深度学习的工夫序列剖析与预测、自然语言解决和图神经网络的钻研。在利用实际中，通过基于 AI 的形式不断完善智能监控体系的建设，对日常和大促提供稳定性保障。
概述
常识图谱有较强的常识表达能力、直观的信息出现能力和较好的推理可解释性，因而常识图谱在举荐零碎、问答零碎、搜索引擎、医疗衰弱、生物制药等畛域有着宽泛的利用。运维常识图谱构建绝对于其余畛域的常识图谱构建而言，具备人造的劣势，网络设备固有的拓扑构造、零碎利用的调用关系能够疾速的形成软硬件常识图谱中的实体和关系。历史的告警数据蕴含着大量的相干、因果关系，应用因果发现算法，也能够无效的构建告警常识图谱。基于常识图谱上的权重进行门路搜寻，能够给出根因的流传门路，便于运维人员疾速的做出干涉决策。
苏宁通过 CMDB、调用链等数据构建软硬件常识图谱，在此基础上通过历史告警数据构建告警常识图谱，并最终利用常识图谱进行告警收敛和根因定位。本文次要包含运维常识图谱构建、常识图谱存储、告警收敛及根因定位等内容。
痛点及产品对策演进
痛点
- 苏宁外部零碎和服务的复杂性:
6000+ 零碎，数量还在减少;
零碎间调用形式简单: 大部分应用 RSF，也有 HTTP、HESSIAN 等;
苏宁业务的简单: 既有线上新业务又有线下老业务，这些业务零碎之间会有大量的关联。
- 根底环境的复杂性:
多数据中心，每个数据中心会划分多个逻辑机房和部署环境;
服务器规模 30w+，例如，缓存服务器就有可能有上千台服务器;
设施复杂性: 多品牌的交换机，路由器，负载平衡，OpenStack, KVM, k8s 下 docker，swarm 下的 docker 等。
基础设施的复杂性导致每天均匀产生 10w+ 的告警事件，峰值可达到 20w+ / 天。面对海量的运维监控数据，零碎和指标间关联关系越来越简单，一个节点呈现故障，极易引发告警风暴，波及更广的范畴，导致定位问题费时费力。此时，单纯依附人肉和教训剖析，越来越难以为继。迫切需要一个工具，能够辅助咱们剖析零碎和指标间关联关系，可视化展现告警的流传门路和影响范畴等。
产品对策演进
针对上述痛点，咱们采纳畛域常识联合 AI 的办法对告警进行收敛，以缓解告 警风暴。此外，为便于一线运维人员疾速的作出干涉决策，咱们同时对告警的流传门路和影响范畴进行剖析。
- 基于穿插熵的告警聚类 (1.0 版本)
依照告警的场景和规定，利用穿插熵对告警信息进行聚类，实现告警的收敛。借鉴 moogsoft 的思维，将告警聚类后果生成 situation，同一个 situation 中蕴含同场景、有关联的告警。
毛病:
- 收敛成果无限，该办法只能缩小 30% 左右的告警，无奈无效解决告警风暴问题;
- 无奈提供根告警以及根因链路
- 弱解释性
- 无奈解决告警的根因问题。
- 基于 GRANO 算法的根因定位 (2.0 版本)
根因定位是在告警收敛的根底上进行的，采纳 GRANO[2] 算法，基于告警收敛后果生成 situation，计算 situation 中每个告警节点的得分，而后排序来确定根因。
毛病:
- 这种办法的毛病是不会给出一条残缺的根因链路，因而根因的可解释性不强。
- 基于运维常识图谱的告警收敛和根因定位 (3.0 版本)
包含全局视角下的软硬件常识图谱和告警常识图谱，利用 NLP 技术对告警文 本信息进行分类，而后将告警收敛到软硬件常识图谱的相干节点上，再联合具 有因果关系的告警常识图谱，得出一条“A –> B –> C –> D”的根因链路。
长处:
- 因为联合了畛域相干常识，该办法收敛成果更好，而且提供了一条残缺的根因链路，所以解释性更强，能够更好的为 SRE / 运维人员提供指引。
思路与架构
分层建设思路
流程架构
运维常识图谱构建
4.1 软硬件常识图谱构建
软硬件常识图谱是以全局的视角展现零碎内各利用、软件、虚拟机、物理机间 的外在逻辑，零碎间的调用关系，网络设备的物理连贯关系。图谱中的节点包 括零碎、DU(部署单元)、group(主机实例组)、软件、虚拟机、物理机、接入交 换机、外围交换机、汇聚交换机、路由器等。关系包含 constitute(形成)、call (调用)、logical(逻辑连贯)、cluster(汇聚)、ship(承载)、host(宿主)、connect(物 理连贯)等。软硬件常识图谱的原型如下:
软硬件常识图谱构建的数据源次要有 CMDB 数据、调用链数据和物理设施网络连接数据。实际中首先基于离线数据初始化软硬件常识图谱，随着业务的变动和拓展会呈现旧零碎的下线和新零碎的上线，而后依据变动定时或定期更新软硬件常识图谱。
4.1.1 CMDB 数据构建流程
通过 CMDB 数据能够构建 HOST->VM->SOFTWARE->GROUP 及 GROUP (WildFly) -> GROUP(Nginx)的关系图谱。
4.1.2 调用链 / 物理设施网络连接数据
调用链数据次要用于获取 DU 间调用关系、零碎间调用关系、DU / IP 映射关系、中间件间的逻辑连贯关系等，数据次要通过外部的一些 API 接口获取。
物理设施次要包含物理机、交换机、路由器等，数据次要通过运维平台获取。
4.1.3 合并图谱
将后面失去的 CMDB、调用链和物理设施图谱通过 networkx 合并，而后存入图数据库 NebulaGraph 中，最终失去的单零碎和零碎间图谱别离如下(NebulaGraph Studio 可视化出现):
其中蓝色节点为零碎，浅蓝色节点为 DU，绿色节点为 group，红色节点为软件，橙色节点为虚拟机，深蓝色节点为物理机，黄色节点为接入交换机，淡黄色节点为汇聚交换机。
NebulaGraph Studio: [https://github.com/vesoft-inc…]()
4.2 告警常识图谱构建
4.2.1 告警数据分类
原来的告警分类采纳是穿插熵办法: 告警信息、分词、统计词频、计算与各类别的类似度(穿插熵)，若类似度大于阈值，抉择类似度最高的那一类归到该类，若类似度均小于阈值，则新增一个类别。
这样做的毛病:
- 无法控制分类的数量，比方如果阈值设的较大，就会呈现好多类别；如果设置的较小，很多告警又会归到一类。
- 无法控制类别的具体含意，分类依赖于穿插熵的计算结果以及阈值的设置，无奈确切晓得每个类别的真正含意。
上述这种办法无奈满足咱们构建因果图的须要。
为了让构建的因果图有更好的说服力和可解释性，咱们须要对各种告警信息进行人工分类，比方有的告警是对应于基础设施，比方网卡流量，cpu 利用率，
有的告警对应于具体软件，比方 mysql 提早，wildfly 无奈获取连贯。这样，每个告警类别都有本人明确的含意。在此基础上构建的因果图才是有意义的。
咱们首先对 zabbix 六个月全量告警信息进行了整顿，将所有告警分为了 183 类，而后应用有监督的办法，训练分类模型。这样新来的告警信息也能够依照 咱们事后设定的类别进行分类。
分类模型咱们应用的是自然语言解决办法，先对告警信息进行分词，而后计算词向量，而后将词向量作为输出训练模型。咱们别离训练的 cnn 和 bow(ngr ams)分类模型，整体而言，分类准确率都很高，能满足咱们的要求。其中 cnn 成果好一点，然而预测工夫也会比 bow 耗时长一点。
• cnn 模型(modelcnn20e__0813):
- ————– train_list
predict total time= 12.386132
总告警数量: 20620 谬误个数: 0 准确率 = 1.0
- ————– test_list
predict total time= 1.452978
总告警数量: 3620 谬误个数: 0 准确率 = 1.0
- ————– 全副六个月告警信息
总告警数量: 733637 预测谬误数量: 9 准确率: 0.99998
• n bow 模型(model__bow__20e__0813)
- ————– train_list
predict total time= 1.687823
总告警数量: 20620 谬误个数: 1 准确率 = 0.999952
- ————– test_list
predict total time= 0.272725
总告警数量: 3620 谬误个数: 1 准确率 = 0.999724
- ————– 全副六个月告警信息
总告警数量: 733637 预测谬误数量: 12 准确率: 0.99998
4.2.2 因果节点选取
因果节点不具体指一个物理机或虚拟机 IP 上的告警，而是对所有告警类型的一个形象总结，目前蕴含三层(构造如下): 物理机层面的告警、虚拟机层面 的告警、软件层面的告警。比方: 任何一台物理机上的宕机告警都归类于因果图上【物理机 - 宕机】节点。
通过告警数据分类，咱们初步将所有的告警分类都作为因果节点，在通过因果算法输入因果边并人工筛查确认之后，选取最终的因果节点。
4.2.3 构建因果发现样本
基于 6 个月的 zabbix 告警数据 (如上图，共 781288 条告警) 构建样本。
构建指标:
依据告警分类，已将每一条告警记录归类为一种告警类型 (告警类型: 物理机 - xx 告警、虚拟机 -xx 告警、软件 -xx 告警)。以每条虚拟机告警记录为核心，给定一个告警工夫切片(1min、2min 等)，寻找每条虚拟机告警工夫切片内的相干告警记录(相干告警包含: 该虚拟机附属的物理机上的告警，同附属该台物理机上的其余虚拟机上的告警) 汇合作为一个因果发现样本。
举例说明:
上面是一台虚拟机在某一个工夫点的告警，以该告警构建样本。
给定工夫切片为 1 分钟，以下面一条虚拟机上的告警为例，寻找 1 分钟内与该虚拟机相干的物理机和虚拟机上的告警，所有告警如下图所示为一个因果样本。
最终转置每一个样本，将告警类型作为列名，汇合所有的样本，若产生告警记为 1，不产生记为 0，生成最终的因果发现样本(因果算法的输出)，如下所示:
4.2.4 因果算法
采纳已有的因果发现算法工具包:CausalDiscoveryToolbox，其中蕴含的算法有: PC、GES、CCDr、LiNGAM 等。
PC：是因果发现中最驰名的基于分数的办法，该算法对变量和变量集的进行 条件测试，以取得可能的因果边。
GES:Greedy Equivalence Search algorithm(贪心干预等价搜索算法), 是一种 基于分数的贝叶斯算法，通过在数据上计算似然分数最小化来启发式地搜寻 图，以取得因果边。
CCDr: Concave penalized Coordinate Descent with reparametrization(参数化的凹点惩办坐标降落法)，这是一种基于分数的用来学习贝叶斯网络的疾速构造学习算法，该办法应用稠密正则化和块循环坐标降落。
指标:
采纳多种因果发现算法训练告警数据，基于各个算法输入的因果边再联合人工审查筛选确定最终的因果边(蕴含因果节点)，边确定了，相应的因果节点也确定了。
举例说明:
以 PC 和 GES 两个算法为例:
PC 算法输入的可能因果节点和边:
GES 算法输入的可能因果节点和边:
两个算法都发现了【host- 服务器宕机】导致【vm- 服务器宕机】和【host- 服务 器宕机】导致【software- 网页拜访失败】等雷同的因果边，经人工确认物理机宕机的确会导致其对应的虚拟机宕机和服务器上的软件拜访失败，所以确定这两条边为因果边。
4.2.5 因果边的权重计算
因果边的权重采纳条件概率计算，即: 基于因果发现样本数据和因果发现算法给出的因果边(包含两个因果节点)，【因节点产生告警的条件下果节点产生告警的次数】与【因节点总共产生的告警次数】的比值作为该因果边的权重。
举例:
截取局部的因果边及其权重:【host- 服务器宕机】导致【vm- 服务器宕机】的因果边权重为 0.99。
4.2.6 构建告警常识图谱
通过【告警的分类】–>【构建因果发现样本】–>【因果算法发现因果边】–>【因果边权重计算】，最终生成所有的因果边及其权重。
基于 zabbix 的 781288 条告警数据，最终确定了 213 条因果边(如上图所 示)，依据 213 条因果边的指向和权重，构建告警常识图谱(局部构造如下图所示)，并将告警常识图谱写入图数据库以便长久化读取，后续的根因定位需从图数据库读取所构建的告警常识图谱进行剖析。
常识图谱存储
5.1 图数据库引入
图数据库是以图数据结构存储和查问数据，图蕴含节点和边。构建运维常识图谱做根因告警剖析等场景时，为了实时查问常识图谱，咱们引入了图数据库，并将常识图谱长久化存储到图数据库中。另外，引入图数据库还有以下劣势:
(1) 图数据库在解决关联数据时的速度快，而关系型数据库在解决反向查问以及多层次关系查问的时候通常开销较大，无奈满足咱们的要求。
(2) 图数据库可解释性好。图数据库基于节点和边，以一种直观的形式示意这些关系，具备人造可解释性。
(3) 图数据库查问语句表白性好，比方查问一跳，两跳数据，不须要像关系型数据库那样做简单的表关联。
(4) 图数据库更灵便。图这种通用构造能够对各种场景进行建模，如社交网络、路线零碎等。不论有什么新的数据须要存储，都只须要思考节点属性和边属性。不像关系型数据库中，须要更新表构造，还要思考和其余表的关联关系 等。
5.2 图数据库选型
Neo4j 开源版本不反对分布式，无奈满足咱们对多正本的需要; ArangoDB 是 多模态数据库，反对 graph, document, key/value 和 search，反对分布式部署，查问速度快; NebulaGraph 一款是国产的开源图数据库，反对分布式部署且部署形式比 ArangoDB 更轻便，查问速度快，腾讯、京东等公司外部也在应用。
在充沛比拟了以上图数据库的性能，以及社区的活跃性以及开放性后，咱们最终抉择 NebulaGraph。针对上述的三个图数据库，咱们做了一个具体的性能 Benchmark 比照: [https://discuss.nebula-graph….]()
告警收敛及根因定位
6.1 流程
针对告警数据的收敛和根因定位，能够分为以下次要几个步骤。
多模态数据库
设置工夫切片粒度: 实时获取工夫切片内 (1min、5min 等) 的告警数 据;
告警分类: 针对原始的告警数据，联合具体的告警信息和监控项等信息，依据训练好的分类模型对原始的告警数据从 HOST、VM、SOFTW ARE 三个方面进行分类，例如: vm_网卡流量大、host_磁盘使用率过高、software_网页拜访失败等。
告警收敛: 查问软硬件常识图谱将告警以零碎为单位进行收敛，收敛格局如下，格局如下:
零碎 1: {软硬件常识图谱节点 1:[告警类型 1，告警类型 2…]，软硬件常识图谱节点 2:[告警类型 1，告警类型 2…]
告警因果图构建: 基于告警收敛后果，在图数据库中依照零碎级别查问每个零碎下的所有节点之间的连接子图，并将失去的后果输出到 networkx 中，失去某个零碎下的各节点之间的最终连贯关系，即告警因果图。
根因门路: 基于上述生成的告警因果图，以及权重来计算疑似门路，排序给出根因门路。
6.2 告警收敛
基于上述的次要流程，咱们现以工夫粒度为前后 5min 内的告警数据创立工夫切片样本，并取告警数量最多的前 100 个工夫片的样本作为次要剖析的内容，其中第一个工夫切片中的各个系统下各节点的告警收敛后果如下:
6.3 根因定位
对于上述第一个工夫切片中的某个零碎，在图数据库中查问该零碎下的所有节点形成的子图，以“苏宁 XXX 零碎”这个零碎为例，查问失去在“一跳”范畴内与该零碎下的所有节点之间有关联的节点的关系大抵如下(红色示意物理机节点，棕色示意虚拟机节点，绿色示意软件节点):
上图中呈现的所有节点中，既包含有告警信息的，也包含没有告警音讯的，因而将上述因果图输出到 netwokx 后，能够失去最终通过精简后的有告警音讯收回的各节点的因果图，其中一部分的因果图展现如下:
能够解释为:“192.168.xxx.xxx-host- 服务器宕机”导致“10.104.xxx.xxx-vm- 服 务器宕机”，进而导致“software- 网页拜访失败”。
进一步的，根据上述生成的因果图，再联合因果图中每条边的权重，就能够计算出该工夫切片下的单个零碎层面上的所有疑似根因门路，通过排序后即可失去最终的根因门路。本例中最终失去的几条根因门路如下:
从上图能够看出，程序最终给出了几条疑似的根因门路，其中包含最长的一 条，能够解释为: ip 为 192.168.xxx.xxx 这台物理机因为网卡 overruns 的
起因，导致了这台物理机的宕机，从而使得这台物理机上的 ip 为 10.104.xx x.xxx 的虚拟机宕机，最终导致这台虚拟机上的相干的网页拜访失败。
成果及优化方向
在告警收敛方面，通过验证，基于运维常识图谱可缩减至多 50% 的告警量，最高可达到 60% 以上，有效率的缓解了告警风暴的压力; 另外，在时效性方面，基于 1、2、5min 不同长度的工夫切片进行告警收敛，耗时能够管制在 6 s 以内，满足告警告诉的时效性要求。
在根因定位方面，经一线运维人员验证，每个告警时间段提供的可能根因流传门路汇合根本蕴含了实在的根因，无效缩短了运维人员的干涉工夫; 另外在耗时上，根因定位能够管制在 3s 以内，速度较快，满足时效性要求。
但目前通过因果发现算法主动构建的告警常识图谱准确率有待进一步晋升，持续调研评估其余告警常识图谱构建形式。持续欠缺软硬件和调用链告警常识图谱，以后仅是基于 CMDB 和 Zabbix 告警数据构建运维常识图谱进行告警收 敛和根因定位，基础设施层面的告警数据更简略、标准，后续还要扩大到更简单的非基础设施层面的告警数据中。以后还没有利用常识图谱对异样检测 (工夫序列数据) 后果做根因定位的利用实际，这须要对工夫序列做因果关系的发现，构建工夫序列之间的因果图，从而买通常识图谱与异样检测的壁垒，这也是常识图谱后续应用的扩大方向之一。
谢谢你读完本文 (///▽///)
要来近距离体验一把图数据库吗？NebulaGraph 阿里云计算巢现 30 天收费应用中，点击链接 节俭大量的部署安装时间来搞定业务吧~
想看源码的小伙伴能够返回 GitHub 浏览、应用、(^з^)-☆ star 它 -> GitHub；和其余的 NebulaGraph 用户一起交换图数据库技术和利用技能，留下「你的名片」一起游玩呢~
