概览
普米
grafana
什么是根因分析
https://originx.kindlingx.com/blog/%E4%BB%80%E4%B9%88%E6%98%AF%E6%A0%B9%E5%9B%A0%E5%88%86%E6%9E%90/
根因分析（Root Cause Analysis，RCA）是一种问题解决方法，用于识别问题的根本原因，然后通过解决这些原因来防止问题再次发生。
它是一种回溯性过程，旨在发现问题的深层原因，而不仅仅是处理表面的症状或后果。
在可观测领域和IT领域内，根因分析是指在软件工程和系统管理中，当服务或应用出现故障时，通过监控和日志数据来识别导致问题的基本原因的过程。
可观测性通常涉及三个主要的数据源：日志（记录事件的详细信息）、指标（系统性能的定量数据）和跟踪（记录请求流程的路径）。
不同人眼中的根因分析
运维工程师眼中的根因分析
在运维工程师或SRE部门承担着业务稳定的职责，所以出现问题之后，第一职责是确认到底该如何操作才能恢复业务。那么这里面需要根因分析吗？可能会有部分人认为运维不需要对故障做根因分析，只需关注进程是否存在，机器是否正常就好了，如果没有问题，就无脑重启业务就应该恢复业务了。 在一些IT架构不复杂，问题故障原因单一的情况下，很多时候是可以通过重启、回滚等手段恢复，但是IT架构一旦庞大起来，或问题根因比较复杂，特别是以微服务架构运行在云原生环境中时，重启能够恢复业务的几率就大大降低了，往往重启也只是一种无目的的猜测手段了。 在云原生环境中，运维工程师需要通过根因分析来达到恢复业务的目的。所谓根因就是运维工程师在故障发生时能够依据的结论，其后依靠这些结论来指导业务的恢复和故障的处置。 在这里例举下运维工程师可以采取的恢复手段，即使同类故障仍旧会在不久的将来再次发生。
识别是代码缺陷，例如内存泄露、GC频率过高等，重启恢复业务。 识别是代码缺陷导致CPU飙升、数据库QPS过高，在允许代码回滚的情况下通过回滚恢复业务。 识别是流量过大的问题，如果确认是流量过大超过系统设计负载能力，在不变更架构设计的情况下，只能通过扩容或者限流措施来快速恢复业务。 识别是共享资源的问题，取得明确的证据，减少跨公司跨团队的协作沟通成本，提交工单提供数据或相关日志，协助公有云或者云供应商更快的解决故障，恢复业务。 识别是第三方软件依赖的问题，取得明确的证据，减少跨公司跨团队的协作沟通成本，督促第三方软件依赖快速解决故障，恢复业务。 运维工程师不可能在不了解故障根因的情况下，依靠穷举猜测试验的方式恢复故障，所以运维工程师非常需要了解到底发生了什么故障，该故障的根因是什么，才能真正的快速恢复业务，做到快速止血。所以针对运维工程师，故障根因结论是以下几种：
位于哪个微服务节点的内存泄露、代码死锁——重启能够解决，确认是否能够重启还是扩容机器，减少风险。 位于哪个服务节点的CPU飙升——确认是否能够回滚，或者扩容机器，减少风险。 访问量激增——确认是扩容哪些节点还是限流某些节点来恢复业务。 共享资源的问题 如果是网络问题，确定哪个节点与节点之间的网络有问题，还是整个网段都有网络问题，提取证据，提交给公有云或者云供应商。 如果是存储问题，确定是何种存储，提取证据，提交给供应商解决。 如果是节点硬件或者配置故障，迁移机器。 第三方依赖的问题，提交证据，交于第三方依赖厂商解决问题。 开发工程师眼中的根因分析 开发工程师往往承担业务实现的职责，但在系统故障时常需协助运维工程师定位运维中的根本原因。同时，开发工程师还需要承担软件缺陷和架构设计问题所致故障的复盘工作，以避免未来类似故障再次发生，并确保对系统及时进行优化。
因此，开发工程师视角下的根因分析需要有效指导故障复盘，能更好地还原故障现场，帮助开发人员理解故障发生的代码层或配置层原因，并及早发现业务架构设计层面的潜在风险。
常见的开发人员视角下的根因包括：
代码死锁现象——开发工程师想知道的根因是锁住的代码块是哪些，代码分别持有锁的时间长度是多久。 CPU飙升——开发工程师想知道哪段代码导致的CPU飙升。 内存泄露——开发工程师想知道哪些函数申请的内存具体多少。 网络问题——开发工程师想知道具体访问哪些请求，做了哪些操作从而提取优化思路。 存储问题——开发工程师想知道具体访问了什么文件，I/O是多少，访问频度如何，从而提前设计优化方案。
故障根因分析实践中的困境
虽然在现代IT系统中，各环境参与人员都急需合适的根因分析工具介入来提高效率，优化故障处置流程，但是目前根因分析在真正落地实施时面临多种挑战和困境：
复杂性 现代系统的分布式和微服务架构增加了系统的复杂性，特别是云原生环境下资源服务的动态变化和基础设施故障也会对定位造成干扰，这些都使得故障的定位和根因分析难以实现。
信噪比 系统可能会产生大量的日志和各类指标数据，特别是发生故障时尤为突出，但并非所有数据都与问题相关。过滤出有用信息并从中识别和定位出故障根因非常具有挑战性。
文化和流程 组织文化和相关流程需要能够有所支持，一方面组织内部必须能够切实有效的认识到根因分析对于提高系统可靠性和发生故障时真正快速止血的必要性，另一方面团队内部也需要有适宜的协作机制和流程，促进各团队间能够快速修复问题，并且深入挖掘其根本原因，能够做到快速止血的同时也能够彻底解除隐患，落地实践 1-5-10 等高效的故障处置流程。
根因分析
智能运维是如何抑制告警风暴的？
通常智能运维中的告警收敛场景，以机器学习算法为驱动，对海量的告警事件进行降噪和关联分析，辅助根因定位并可沉淀故障处理的知识，从而提升企业的运维效率，降低运维成本。
告警产生后，AIOps系统通过算法甄别 内容相关性（重复性、相似性）、时序相关性和拓扑相关性 事件来进行告警事件的自动化抑制。
这类收敛抑制，往往能得到99%的告警压缩率，极大地提高了告警有效性。
在一个完整的智能运维告警产品里，除了告警收敛，还可以
基于故障传播链及拓扑信息 ( 可选 ), 智能发现突发故障场景；基于告警“熵值”算法，实现告警的动态优先级推荐；通过时序以及拓扑关系定位故障场景根因，并进行根因标记。
当这些都可以完成时，由告警事件一步步引导的根因定位和排障，才是真正智能运维发挥了作用。
相比传统运维工具，AIOps的优势在哪里
所谓的AIOps运维告警根因分析，简单理解就是基于自动化运维，将AI和运维很好的结合起来。
AIOps的落地在多方面直击传统运维的痛点，AI算法承担起分析海量运维数据的重任，能够自动、准确地发现和定位问题，从决策层面提高运营效率，为企业运营和运维工作在成本、质量和效率方面的优化提供了重要支持。
可见，AIOps 在企业中的作用正在进一步放大。但事实上，很多企业对于AIOps 能解决什么问题并不清晰，今天我们就以博睿数据的AIOps 的三大场景和算法说起。
博睿数据的AIOps 实践
作为中国领先的智能可观测平台，在AIOps实践方面，多年来博睿数据积极拥抱人工智能、机器学习等新技术变革的浪潮，并基于AI和机器学习技术，自主研发了“数据接入、处理、存储与分析技术”核心技术体系，全面布局智能基线、异常检测、智能告警、关联分析、根因分析等丰富且广泛的智能运维功能，并将AIOps能力融入端到端全栈监控产品线，可为传统企业提供强大的数据处理、存储和分析的软件工具，帮助客户整合各类IT运维监控数据，实现数据的统一存储和关联分析，打破数据孤岛，构建统一的IT运维管理平台，让企业的IT运维更加智能化、自动化。
在此基础上，博睿数据还依托完整的IT运维监控能力，利用大数据和机器学习技术持续构建先进的智能运维监控产品，2021年先后推出了搭载了AI能力的新一代APM产品Server7.0和新版的统一智能运维平台Dataview，不断落地智能异常检测、根因分析、故障预测等场景。
基于人工智能的能力实现运维监控场景的信息整合、特征关联和业务洞察，帮助企业确保数字化业务平稳运行，并保障良好的数字化体验。
目前，博睿数据在AIOps 技术方面主要落地了三大场景。
即智能基线预测、异常检测及告警收敛。
随着企业业务规模扩大，云原生与微服务的兴起，企业IT架构复杂性呈现指数级增长。而传统的IT运维手段面临故障发生后，查找故障原因困难，故障平均修复时间周期长，已无法满足新的运维要求。因此运用人工智能赋能运维，去取代缓慢易错的人力决策，快速给出运维决策建议，降低问题的影响并提前预警问题就成为了必然。AIOps作为目前运维发展的最高阶目标，未来将会赋能运维带给用户全新的体验。
但需要注意的是，当前智能运维的很多产品和项目在企业侧落地效果并不理想，究其原因可归类为三点：
一是数据采集与AI平台割裂，多源数据之间的关联关系缺失导致AI平台缺乏高质量的数据，进而导致模型训练效果不佳运维告警根因分析；
二是数据采集以metric和log为主，导致应用场景较窄且存在数据孤岛问题；
三是AI平台能力尚有提升空间。
当前落地的场景多以异常检测与智能告警为主，未来需要进一步提升根因分析与故障预测的能力。
因此，未来企业首先要建设一体化监控运维平台，一体化是智能化的基础。基于一体化监控运维平台采集的高质量的可观测数据数据以及数据之间的关联关系，进一步将AIOps的能力落地到一体化监控运维平台中，从而实现问题精准定位与见解能力。
此外，在实际应用中，依据信通院的相关调查，其受访企业中只有不足20%的企业具有智能化监控和运维决策能力，超过70%的企业在应用系统出现故障的10分钟内一筹莫展。
各行业的数字化转型正在改变这一现状，不仅互联网企业，更多传统企业的数字化转型为智能运维开拓了更广阔的市场，智能运维有着巨大的发展空间，这也是博睿数据等行业领先企业发力的大好时机。
提升创新能力，推广智能运维不仅是相关服务商自身发展的要求，也是提升我国企业应用管理和运维水平的使命。
中国企业数字化转型加速，无论是前端的应用服务迭代更新，还是后端IT运维架构的复杂度提升，都在加速培育智能运维的成长。
运维监控工具太多，根因定位不够智能和快速，如何解决？
常规的运维监控工具，基本都是监控某一种设备或某种应用的数据，并且通过阈值的设置来进行故障告警。
这样虽然也达到了监控的目的，但在实际使用中，常遇到一个个设置阈值特别麻烦、阈值设置不合理造成告警过少或过多、不同监控数据之间没有关联，出一个故障各系统都在告警，难以判断根因的情况。
智能运维AIOps系统，能通过“数字运维中台”，将原有的分散的运维监控数据统一采集、存储、归档到中台内，并且利用“统一监控平台”对这些数据进行分析管理，如果原来有CMDB数据，还能建立关联并生成拓扑图。
当故障发生、系统告警时，告警辨析中心能利用规则和算法，锁定最重要的那些告警信息，并根据统一监控平台梳理的数据关系，协助查询日志及其他故障数据，更快定位根因。
AIOps平台架构和各数据层关系
IT运维平台算法背后的两大“神助攻”
智能运维(AIops)是目前 IT 运维领域最火热的词汇，全称是 Algorithmic IT operations platforms，正规翻译是『基于算法的 IT 运维平台』，直观可见算法是智能运维的核心要素之一。
本文主要谈算法对运维的作用，涉及异常检测和归因分析两方面，围绕运维系统Kale 中 skyline、Oculus 模块、Opprentice 系统、Granger causality（格兰杰因果关系）、FastDTW 算法等细节展开。
一、异常检测
异常检测，是运维工程师们最先可能接触的地方了。毕竟监控告警是所有运维工作的基础。
设定告警阈值是一项耗时耗力的工作，需要运维人员在充分了解业务的前提下才能进行，还得考虑业务是不是平稳发展状态，否则一两周改动一次，运维工程师绝对是要发疯的。
如果能将这部分工作交给算法来解决，无疑是推翻一座大山。
这件事情，机器学习当然可以做到。但是不用机器学习，基于数学统计的算法，同样可以，而且效果也不差。
异常检测之Skyline异常检测模块
2013年，Etsy 开源了一个内部的运维系统，叫 Kale。其中的 skyline 部分，就是做异常检测的模块， 它提供了 9 种异常检测算法 ：
first_hour_average、 simple_stddev_from_moving_average、 stddev_from_moving_average、 mean_subtraction_cumulation、 least_squares histogram_bins、 grubbs、 median_absolute_deviation、 Kolmogorov-Smirnov_test
简要的概括来说，这9种算法分为两类：
从正态分布入手：假设数据服从高斯分布，可以通过标准差来确定绝大多数数据点的区间；或者根据分布的直方图，落在过少直方里的数据就是异常；或者根据箱体图分析来避免造成长尾影响。
从样本校验入手：采用 Kolmogorov-Smirnov、Shapiro-Wilk、Lilliefor 等非参数校验方法。
这些都是统计学上的算法，而不是机器学习的事情。
当然，Etsy 这个 Skyline 项目并不是异常检测的全部。
首先，这里只考虑了一个指标自己的状态，从纵向的时序角度做异常检测。而没有考虑业务的复杂性导致的横向异常。其次，提供了这么多种算法，到底一个指标在哪种算法下判断的更准？这又是一个很难判断的事情。
问题一： 实现上的抉择。同样的样本校验算法，可以用来对比一个指标的当前和历史情况，也可以用来对比多个指标里哪个跟别的指标不一样。
问题二： Skyline 其实自己采用了一种特别朴实和简单的办法来做补充——9 个算法每人一票，投票达到阈值就算数。至于这个阈值，一般算 6 或者 7 这样，即占到大多数即可。
异常检测之Opprentice系统
作为对比，面对相同的问题，百度 SRE 的智能运维是怎么处理的。
在去年的 APMcon 上，百度工程师描述 Opprentice 系统的主要思想时，用了这么一张图：
Opprentice 系统的主体流程为：
KPI 数据经过各式 detector 计算得到每个点的诸多 feature；
通过专门的交互工具，由运维人员标记 KPI 数据的异常时间段；
采用随机森林算法做异常分类。
其中 detector 有14种异常检测算法，如下图：
我们可以看到其中很多算法在 Etsy 的 Skyline 里同样存在。
不过，为避免给这么多算法调配参数，直接采用的办法是：每个参数的取值范围均等分一下——反正随机森林不要求什么特征工程。
如，用 holt-winters 做为一类 detector。holt-winters 有α，β，γ 三个参数，取值范围都是 [0, 1]。那么它就采样为 (0.2, 0.4, 0.6, 0.8)，也就是 4 ** 3 = 64 个可能。那么每个点就此得到 64 个特征值。
异常检测之
Opprentice 系统与 Skyline 很相似
Opprentice 系统整个流程跟 skyline 的思想相似之处在于先通过不同的统计学上的算法来尝试发现异常，然后通过一个多数同意的方式/算法来确定最终的判定结果。
只不过这里百度采用了一个随机森林的算法，来更靠谱一点的投票。而 Etsy 呢？在 skyline 开源几个月后，他们内部又实现了新版本，叫 Thyme。利用了小波分解、傅里叶变换、Mann-whitney 检测等等技术。
另外，社区在 Skyline 上同样做了后续更新，Earthgecko 利用 Tsfresh 模块来提取时序数据的特征值，以此做多时序之间的异常检测。我们可以看到，后续发展的两种 Skyline，依然都没有使用机器学习，而是进一步深度挖掘和调整时序相关的统计学算法。
开源社区除了 Etsy，还有诸多巨头也开源过各式其他的时序异常检测算法库，大多是在 2015 年开始的。列举如下：
Yahoo! 在去年开源的 egads 库。(Java)
Twitter 在去年开源的 anomalydetection 库。(R)
Netflix 在 2015 年开源的 Surus 库。(Pig，基于PCA)
其中 Twitter 这个库还被 port 到 Python 社区，有兴趣的读者也可以试试。
二、归因分析
归因分析是运维工作的下一大块内容，就是收到报警以后的排障。
对于简单故障，应对方案一般也很简单，采用 service restart engineering~ 但是在大规模 IT 环境下，通常一个故障会触发或导致大面积的告警发生。
如果能从大面积的告警中，找到最紧迫最要紧的那个，肯定能大大的缩短故障恢复时间(MTTR)。
这个故障定位的需求，通常被归类为根因分析（RCA，Root Cause Analysis）。
当然，RCA 可不止故障定位一个用途，性能优化的过程通常也是 RCA 的一种。
归因分析之 Oculus 模块
和异常检测一样，做 RCA 同样是可以统计学和机器学习方法并行的~我们还是从统计学的角度开始。
依然是 Etsy 的 kale 系统，其中除了做异常检测的 skyline 以外，还有另外一部分，叫 Oculus。
而且在 Etsy 重构 kale 2.0 的时候，Oculus 被认为是1.0 最成功的部分，完整保留下来了。
Oculus 的思路，用一句话描述，就是：
如果一个监控指标的时间趋势图走势，跟另一个监控指标的趋势图长得比较像，那它们很可能是被同一个根因影响的。
那么，如果整体 IT 环境内的时间同步是可靠的，且监控指标的颗粒度比较细的情况下，我们就可能近似的推断：跟一个告警比较像的最早的那个监控指标，应该就是需要重点关注的根因了。
Oculus 截图如下：
这部分使用的 计算方式有两种：
欧式距离，就是不同时序数据，在相同时刻做对比。假如0分0秒，a和b相差1000，0分5秒，也相差1000，依次类推。
FastDTW，则加了一层偏移量，0分0秒的a和0分5秒的b相差1000，0分5秒的a和0分10秒的b也相差1000，依次类推。
当然，算法在这个简单假设背后，是有很多降低计算复杂度的具体实现的，这里就不谈了。
唯一可惜的是 Etsy 当初实现 Oculus 是基于 ES 的 0.20 版本，后来该版本一直没有更新。现在停留在这么老版本的 ES 用户应该很少了。
除了 Oculus，还有很多其他产品，采用不同的统计学原理，达到类似的效果。
归因分析之 Granger causality
Granger causality（格兰杰因果关系）是一种算法，简单来说它通过比较“已知上一时刻所有信息，这一时刻 X 的概率分布情况”和“已知上一时刻除 Y 以外的所有信息，这一时刻 X 的概率分布情况”，来判断 Y 对 X 是否存在因果关系。
可能有了解过一点机器学习信息的读者会很诧异了：不是说机器只能反应相关性，不能反应因果性的么？
需要说明一下，这里的因果，是统计学意义上的因果，不是我们通常哲学意义上的因果。
统计学上的因果定义是：『在宇宙中所有其他事件的发生情况固定不变的条件下，如果一个事件 A 的发生与不发生对于另一个事件 B 的发生的概率有影响，并且这两个事件在时间上有先后顺序（A 前 B 后），那么我们便可以说 A 是 B 的原因。』
归因分析之皮尔逊系数
另一个常用的算法是皮尔逊系数。
下图是某 ITOM 软件的实现：
我们可以看到，其主要元素和采用 FastDTW 算法的 Oculus 类似：correlation 表示相关性的评分、lead/lag 表示不同时序数据在时间轴上的偏移量。
皮尔逊系数在 R 语言里可以特别简单的做到。比如我们拿到同时间段的访问量和服务器 CPU 使用率：
然后运行如下命令：
acc_count<-scale(acc$acc_count,center=T,scale=T)
cpu<-scale(acc$cpuload5,center=T,scale=T)
cor.test(acc_count,cpu)
可以看到如下结果输出：
对应的可视化图形如下：
这就说明网站数据访问量和 CPU 存在弱相关，同时从散点图上看两者为非线性关系。因此访问量上升不一定会真正影响 CPU 消耗。
其实 R 语言不太适合嵌入到现有的运维系统中。那这时候使用 Elasticsearch 的工程师就有福了。
ES 在大家常用的 metric aggregation、bucket aggregation、pipeline aggregation 之外，还提供了一种 matrix aggregation，目前唯一支持的 matrix_stats 就是采用了皮尔逊系数的计算，接口文档见：
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-matrix-stats-aggregation.html
唯一需要注意的就是，要求计算相关性的两个字段必须同时存在于一个 event 里。所以没法直接从现成的 ES 数据中请求不同的 date_histogram，然后计算，需要自己手动整理一遍，转储回 ES 再计算。
饶琛琳，目前就职日志易，有十年运维工作经验。在微博担任系统架构师期间，负责带领11人的SRE团队。
著有《网站运维技术与实践》、《ELKstack权威指南》，合译有《Puppet 3 Cookbook》、《Learning Puppet 4》。在众多技术大会上分享过自动化运维与数据分析相关主题。
企业智能化运维该如何展开？
随着企业业务规模扩大，云原生与微服务的兴起，企业IT架构复杂性呈现指数级增长。
而传统的IT运维手段面临故障发生后，查找故障原因困难，故障平均修复时间周期长，已无法满足新的运维要求。因此运用人工智能赋能运维，去取代缓慢易错的人力决策，快速给出运维决策建议，降低问题的影响并提前预警问题就成为了必然。AIOps作为目前运维发展的最高阶目标，未来将会赋能运维带给用户全新的体验。
但需要注意的是，当前智能运维的很多产品和项目在企业侧落地效果并不理想，究其原因可归类为三点：一是数据采集与AI平台割裂，多源数据之间的关联关系缺失导致AI平台缺乏高质量的数据，进而导致模型训练效果不佳；二是数据采集以metric和log为主，导致应用场景较窄且存在数据孤岛问题；三是AI平台能力尚有提升空间。当前落地的场景多以异常检测与智能告警为主，未来需要进一步提升根因分析与故障预测的能力。
因此，未来企业首先要建设一体化监控运维平台，一体化是智能化的基础。基于一体化监控运维平台采集的高质量的可观测数据数据以及数据之间的关联关系，进一步将AIOps的能力落地到一体化监控运维平台中，从而实现问题精准定位与见解能力。
此外，在实际应用中，依据信通院的相关调查，其受访企业中只有不足20%的企业具有智能化监控和运维决策能力，超过70%的企业在应用系统出现故障的10分钟内一筹莫展。
各行业的数字化转型正在改变这一现状，不仅互联网企业，更多传统企业的数字化转型为智能运维开拓了更广阔的市场，智能运维有着巨大的发展空间，这也是博睿数据等行业领先企业发力的大好时机。
提升创新能力，推广智能运维不仅是相关服务商自身发展的要求，也是提升我国企业应用管理和运维水平的使命。
中国企业数字化转型加速，无论是前端的应用服务迭代更新，还是后端IT运维架构的复杂度提升，都在加速培育智能运维的成长。
运维告警根因分析（运维故障根因分析）
关于运维告警根因分析和运维故障根因分析的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？
如果你还想了解更多这方面的信息，记得收藏关注本站。
运维告警根因分析的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于运维故障根因分析、运维告警根因分析的信息别忘了在本站进行查找喔。
一、背景
随着去哪儿网业务的发展和微服务架构的普及，公司内微服务的拆分粒度越来越细，导致服务间的调用错综复杂。
比如机票和酒店的下单场景，就会涉及到成百上千个应用的调用，而当此类场景出现异常产生报警甚至产生故障时，对开学同学来说查找并定位问题是个很大的挑战。
去哪儿网构建了自己的 APM 系统，包括监控(metric)、日志(logging)和调用链路(Tracing)，帮助开发同学定位问题。
但在实际排查问题的过程中，开发同学需要排查是报警的应用本身还是下游依赖的问题，需要逐层去排查调用链路、异常日志、监控指标等，这样就会导致有时定位问题的时间比较长。而对于影响业务的故障而言，导致的后果便是恢复时间较长，造成的损失较大。
我们对2022年上半年公司主要技术团队的99个故障进行分析，发现处理超时故障占比48.5%(30分钟内未恢复的故障，认为是超时故障)。
并将故障处理超时的原因，归纳为以下7类：
由上图可以看出，在故障处理超时的原因中，链路分析不清晰、未定位到 DB 问题、未定位到单机问题、未关注到异常增长等占比57.57%。
如果能够在报警或者故障时，自动的分析相关指标的调用链路、异常日志、DB 等问题，并依据权重对分析结果进行汇总和剪枝，最终将分析结果推送给开发同学，那么将大大减少开发同学排查问题的时间，有效的降低故障超时率。
基于此，去哪儿网根因分析系统-horus 应用而生。
二、实践框架
1.基础能力建设
去哪儿网一直在构建并完善企业级的 apm 系统，包括链路追踪系统 qtracer、监控系统 watcher、异常统计分析系统 heimdall 以及公司事件平台。
其中qtracer是公司自研的链路追踪系统，可以用来快速获取系统间的调用信息。
为了能够在监控报警时，快速检索出指标相关联的trace，我们进行了metric和trace的结合。
如下图所示，不同于业界常用的label标签关联，我们使用了trace的context进行关联，达到的效果是在某个时间点，一个带着trace信息的请求从入口进来，经过了方法foo()，而foo()中记录了指标foo.access.time，那么通过指标foo.access.time以及对应时间段，便能够查询到此条trace信息。
并且在报警发生时，qtracer系统会自动提高trace的采样率。
watcher 是公司的一站式监控平台，可以很容易的获取报警信息、指标数据和指标单机数据、以及基础监控数据(CPU、网络等)、DB 数据等。
heimdall 是公司的异常统计分析系统，能够支持分钟级别的异常统计以及某个时间段内的同比环比。
公司事件平台收集了全司应用的各种类型事件和变更，比如发布、配置、压测、k8s 事件等。
公司 apm 系统的构建和完善，为根因分析系统的数据获取提供了坚实的保障。
2.整体框架设计
根因问题定位，业界有许多优秀的探索，比如eBay链路分析、腾讯决策树方法等思路。
下面我们进行简单介绍。
eBay 链路分析
链路分析，是通过分析 Trace 数据中的断链和错链问题，以定位出故障根因的方法。
如上图所示，通过对图上面部分3个核心链路的归并，可以很清晰的看到，在 userCheckout 这个链路中 calculateMoney 的调用接口由”coupon” -> “couponV2”后，对于 createOrder 来说，调用量上升了20%，延迟降低了5%，因此，倾向于定位是 coupon 结点的问题。
腾讯决策树方法
决策树是具有强解释性的有监督分类模型，其本质是一颗由多个判断节点组成的树，如下图所示，就是一个典型的两层结构：基于天气判断是否要出去玩。
策树的生成，就是将一个数据集基于某个特征将其分成 N 类，循环划分子集，直到满足一定条件（子集数），或者子集中数据无法再继续拆分。决策树本质就是 if-else，也就是说，我们根据一定的条件来对数据集做了分类，当一个数据落入某个节点时，它是有原因的，其原因就是它的生成路径。决策树来做根因分析的大体流程：
特征工程：选择合适的数据，并将数据数值化
模型训练：利用sklearn等工具训练决策树模型
基于训练结果做根因分析，或做新数据预测分析
针对分析的结果做校验和优化
以上两种方法，对于根因分析有很好的借鉴意义。
但根因分析系统的实现，必须要结合公司的具体实际，包括基建、技术栈、业务场景等，以打造出符合去哪儿网自身的根因分析平台。
去哪儿网根因分析的构建思路，主要是模拟人的思维。
如下图所示，通过调研机票、酒店、公共和服务的开发同学在问题排查时的经验，我们发现大多开发同学在收到报警时，会通过报警查看trace调用链路，以获取当前应用以及调用的下游应用，然后结合自身的经验，判定大概是哪几个应用的问题，然后针对这些应用，去查看日志、事件等，最终定位问题。
们基于调研结果，并结合业界的实践，抽象出了去哪儿网根因分析系统分析定位的核心思路，即是：
定位范围 → 异常断言 → 关联挖掘 → 剪枝排序 → 结果输出。
在具体实现上，是以报警/指标为入口，通过分析关联trace，获取异常应用，并对异常应用进行多维度分析，对结果汇总、剪枝、排序后输出。
上图为根因分析系统的整体架构图，主要包括以下6个模块：
-
api/listener：服务入口层，支持api触发分析以及listener监听报警消息触发分析
-
orchestration：分析编排控制层，负责控制整个分析过程以及控制整合分析结果
-
analyzer：具体的分析器，包括链路trace、运行时runtime、事件event、日志log、中间件middleware、以及可扩展的extender
-
data processor：分析结果处理模块，对分析结果进行聚合、权重判定、剪枝、排序
-
feedback/learning：反馈及学习模块
-
base data：基础数据层，负责获取及聚合分析模块所需的各种数据，比如event事件、日志信息、报警信息、指标数据等
3.核心模块介绍
3.1 trace分析模块
Trace 模块的作用是根据报警或者指标，查询出对应时间段内的 trace 信息，并根据 trace 是否异常、T 值(T 值是去哪儿网大客户端的一个概念，是为了区分各业务线服务的，在请求的时候，会带一个参数 qrt 称之为 T 值。
不同的 T 值，对应的业务也不同)、相似度等筛选策略进行漏斗式过滤，获得一定数目的 trace，之后根据筛选得到的 trace 定位出异常应用。
Trace模块是整个根因分析系统的核心，也是分析结果能否准确的前提。
难点分析：
1.时间段的确定：
对于监听报警所触发的分析，trace 时间段的选择是个需要首先考虑的问题。时间段过短，有可能导致相关 trace 未查询到；时间段过长，就会包含过多的无用 trace。 我们的开发同学在配置报警时，都是对一段时间内指标数值进行阈值判定，比如3m>4(连续3分钟大于4)，2%5m>7(5分钟内有2个点大于7)。因此我们会根据当前报警所设报警规则的时间段，再加一个特定的时间窗口(比如3分钟，在第一个点满足报警阈值时，异常便已经产生了，向前推一小段时间，以防止 trace 遗漏)，作为查询时间段。
2.trace的筛选：
在前文我们提到过，在报警发生时，qtracer 会提高 trace 的采样率。因此即使我们选定的时间段比较短，仍会查询到大量的 trace(几千甚至数万条)。而如果每次根因分析都对如此规模的trace数据逐条进行拓扑构建并详细分析，会造成巨大的计算成本浪费，并且会极大延长分析耗时，因此需要对查询到的 trace 进行筛选。
trace 筛选的核心思想是漏斗式的筛选，首先根据 trace 是否异常进行分类。qtracer 在记录链路的过程中，如果某次调用判断为超时，或者 http/dubbo 返回状态码异常，便会将此次调用标记为异常，并将 trace 标记为异常 trace。若筛选出的异常 trace 量级仍然很大(比如大于500)，那么我们继续根据 trace 的相似度进行进一步的筛选。
对于非异常 trace，首先根据T值进行筛选，因为不同的 T 值，对应的业务场景也不同，调用链路也不同。对T值相同的 trace，根据相似度筛选出 n 条数据，为了提升相似度的判定速度，我们将图进行降维，根据特定的规则将图构建为字符串，转换为字符串的相似度算法。
3.异常应用的判定：
在排查问题的过程中，异常 trace 要比非异常 trace 的作用大的多。对于筛选到的异常 trace，首先进行拓扑构建并标记异常应用，之后对构建的 trace 拓扑进行归并，某个异常应用出现次数越多，则越倾向于是此应用导致的此次问题，其权重也就越高。如下图所示，在 traceA、traceB、traceC 三条调用链路中，应用 C 都出现了异常，那么我们倾向于认为是应用 C 导致的此次问题。
但 qtracer 当前只能标记出调用超时、调用状态码等异常，对于调用的返回结果中的业务状态码并不会进行判断。
因此某些无异常的应用，也是有可能导致此次问题。
我们在重点关注异常 trace 的同时，也会以非异常 trace 作为辅助。对于非异常 trace，我们对当前报警所属应用节点下钻 n 层拓扑，拿到拓扑应用后，根据应用的报警浓度等策略进行异常应用判定。
3.2 应用纬度分析模块
race 分析模块负责定位出异常应用，而应用纬度分析模块则是对异常应用进行多维度分析。
我们通过对业务线开发同学定位问题的过程以及公司故障数据进行调研分析，抽象出了应用分析的四个维度，分别是
runtime：运行时分析，主要包括应用的单机实例(kvm、容器、宿主机)分析、业务指标单实例分析、JVM 分析如 full gc 等
middleware：中间件分析，目前主要是应用相关的 mysql 和 redis 分析
event：事件/变更分析，目前主要分析的是发布、配置变更、压测等，事件分析支持按部门配置，每个部门都可以单独配置自己关注的事件类型
log：日志分析，通过 heimdall 的异常日志统计能力，筛选出一段时间内的同比环比超过配置阈值的异常类型；并以筛选出的 trace id，从 es 查询出的异常日志作为补充
下面我们将挑选 runtime 和 middleware 两个较复杂的模块进行介绍。
runtime
runtime 是应用的运行时异常分析模块，目前主要分析单机实例、jvm 指标、单机业务指标三个部分。
其中单机实例包括单机基础指标和宿主机指标两个部分，单机基础指标对于应用不同的实例类型会分析不同的指标，宿主机的健康状况也会影响到单机实例，因此我们找到应用的实例对应的宿主机，并分析宿主机的健康状态。
JVM 指标目前主要分析是 full gc 和 young gc 数据，我们根据专家经验，会对每个 java 应用添加 gc 报警，并支持应用 owner 修改阈值。
当分析过程中发现有相关报警时，便会将报警汇总到分析结果。业务线很多应用有大量的实例，很多达到了500以上。
某些报警或者故障是应用某个或者某几个实例导致的，我们报警系统配置的指标是所有实例聚合得到的一个总指标，因此我们会根据配置的业务指标，获取对应时间段内的单机指标数，纵向对比，使用离散度算法比如3西格玛算法，尝试定位出异常单机实例。
如下图所示，应用有五个实例，而实例4在对应时间段内都偏离其余四个实例，那么我们倾向于认为实例4有问题。
middleware
middleware 是应用的中间件分析模块，目前主要分析应用的 mysql 和 redis 实例运行状况。如上图所示，模块首先根据应用名，调用 tc 同学提供的接口，获取对应的 mysql 和 redis 的 namespace 及宿主信息，然后进行异常分析。
在 DBA 同学的帮助下，我们分别确认了 mysql 和 redis 相关的核心报警。
mysql：
pmp-check-mysql-status-pc：pxc 节点状态，告警说明 pxc 不可用
pmp-check-mysql-status-size：pxc 集群没有可用节点，业务无法访问
pmp-check-mysql-status-fc：pxc 集群触发流控，整个集群变慢甚至不可用
pmp-check-mysql-status-threads-running：mysql 线程异常，实例负载过高或者有慢查询导致堵塞
pmp-check-mysql-processlist：mysql 线程异常， 实例负载过高或者有慢查询导致堵塞
pmp-check-mysql-replication-delay：主从同步延迟
pmp-check-mysql-replication-running：主从同步失败
pmp-check-mysql-status-connect：连接数已满，无法连接
check_mmm：集群状态有问题，节点下线
pmp-check-mmm-vip：mmm 集群的 vip 连通性，告警说明 mmm 集群 vip 不通，业务无法访问数据库
redis：
q-check-redis-cpu-usage：redis cpu 告警
q-check-redis-memory-usage：redis 内存告警
q-check-redis-latency-port：redis 延迟告警，比如 redis 大 key 时有可能导致此报警
检测到对应的 mysql/redis 的 namespace 或者宿主有以上核心报警时，则直接将报警汇总到分析结果；
若无报警，则分析慢查询指标数量，若增长趋势异常，则将异常信息汇总到分析结果。
3.3 权重体系模块
权重体系在整个根因分析过程的剪枝排序环节非常重要，直接决定最终推送结果的准确性。
目前根因分析系统主要抽象出了四类权重，以对分析模块分析出的结果进行综合计算。主要包括应用权重、静态权重、动态权重和强弱依赖权重。
下面我们将从what(是什么)、why(为什么)、how(怎么做)。
三个方面来阐述四类权重。
应用权重：
what：应用权重表示在整个调用链路中，当前异常应用影响报警/故障的概率的大小。
why：比如我们对多条异常trace进行分析，发现应用B多次被标记为异常应用，那么我们倾向于认为，是应用B大概率导致此次问题，计算得到的应用B的权重就会很高。又或者对于一条调用链路A->B->C→D，如果当前报警的是应用A，那么根据专家经验，应用B对A的影响要比应用C对A的影响要大，因此我们认为应用B的权重要比应用C要高。
how：目前应用异常权重分两部分计算，异常trace的应用权重通过trace归并计算，比如每重复出现一次，权重增加0.1等，并且异常应用也要综合考虑和当前报警应用的拓扑联通性以及连通层级。而对于非异常trace，主要是根据应用距离当前报警应用的距离计算，类似于欧几里德距离，距离报警应用越近，权重越高。
静态权重：
what：静态权重也就是经验权重，我们总结了2022年上半年的故障原因分布占比，来设置根因分析每个维度的权重比。
why：其实这种静态权重代表了去哪儿网自身的业务特点，比如因发布或者配置变更导致的故障占比50%，说明在去哪儿网发布或配置变更是一个相对比较危险的动作，如果再次发生故障，且我们在事件分析中定位到了异常应用有发布或者变更，那么我们就会倾向于认为这次问题大概率是此次发布或者变更导致的。
how：人为统计故障原因分布占比，并配置到应用配置中。需要注意的是，这个静态权重不是一成不变的，需要每隔一段时间，就根据新的数据调整一次。我们的反馈和学习模块，也会自动根据故障原因分布和用户反馈结果，进行静态权重的调整。
动态权重：
what：动态权重，我们也称为root case权重，根据各个原因的严重级别来对自身进行升级，以避免真正的根因被淹没掉。
why：静态权重只能是一个大概的推测，并且已经归一化了，起到的更多是default设置的作用，提供一些参考意义。比如一个报警或故障，我们分析出链路中某个异常应用有一些调用超时日志，且同时有mysql/redis实例连接失败，那么按照专家经验来看，mysql/redis实例连接失败是一个严重级别很高的原因，因此mysql/redis实例连接失败这个case，便可以自身升权。
how：目前动态权重主要是依靠专家经验，以及case的严重程度，比如磁盘使用率100%，IO使用率100%，DB/redis挂掉，CPU使用率超过90%等，都可以动态升权。
强弱依赖权重：
what：强弱依赖权重其实有些类似应用权重，强弱依赖里明确标明了，A应用的 m1接口依赖B应用的 m2接口是强依赖还是弱依赖，根据此信息可以断定，B应用的异常尤其是m2接口的异常对A应用尤其是A应用的m1接口影响的概率。去哪儿网强弱依赖关系，是通过混沌工程进行强弱依赖演练得到的。
why：强弱依赖是已经人为或系统标记了 A 应用到B应用是否是强依赖或若依赖，这是一个非常重要的信息，比如 A 同时依赖 B、C两个应用，但是根据强弱依赖信息，我们知道B应用对A应用是强依赖关系，而C应用对A应用则是弱依赖关系，那么当A故障时，我们同时发现了B和C两个应用此时都有异常信息，那么此时可以倾向认为B的异常导致了A故障，B的权重大于C。
how：目前强弱依赖标记的是接口维度，在根因分析过程中，根据trace分析拿到当前异常的接口，则可以根据API搜索当前应用的此API的强依赖，如果没有被标记，那么可以回归聚合，将接口维度的强弱收敛到应用维度的强弱，比如A依赖了B的3个接口，2个弱依赖接口一个强依赖接口，那么我们就可以认为B是A的强依赖，按照这种该逻辑来收敛应用级的强弱依赖，强依赖的权重大于弱依赖。
总结展望
当前根因分析系统已经涵盖了机票、酒店、公共、服务四个部门的所有核心报警，每周自动分析报警量在千次以上；对于非核心报警，业务线开发同学很多每周手动触发次数在百次左右。
很多开发同学已经养成了在线上有异常报警时，查看根因分析报告的习惯。在根因分析系统上线的第一季度内，故障责任部门是业务研发所有故障共18个，处理超时故障个数7个，故障处理超时率由22年下半年60.9%降低至38.8%。
目前根因分析系统对应用的分析维度只有runtime、log、middleware、event四种，自根因分析系统上线以来，我们收到了业务线同学的大量建议，后续准备扩展更多的分析纬度，涵盖更广的范围，包括死锁分析、gc详情分析、线程池分析等。
随着去哪儿网业务的恢复和增长，未来根因分析将会发挥更大的价值。
我们也会加大根因分析的领域覆盖范围和使用推广，进一步提升分析准确率，优化使用体验，为助力业务故障的快速恢复提供更大的助力。
聚类算法
可观测 AIOps 的智能监控和诊断实践丨QCon 全球软件开发大会总结
智能运维系列（七）| 化繁为简：业务异常的根因定位方法概述
根因定位分析（RCA）是智能化运维 (AIOPS) 一个重要且难于实现的领域，涉及到归纳分析和演绎推理的相互结合，是从大数定理到逻辑性完备链条推理的综合应用。
分布式架构的海量数据为相关分析奠定了基础，但业务异常案例相比于庞大的指标 / 日志数据却显得凤毛麟角，因此需要具备从相关性到因果性的强 AI 能力：基于运维领域知识进行演绎推理，同时因果推导的过程和结论要具有可解释性便于复盘分析和不断优化。
RCA 的前提是具备了高质量的可观测数据，这些数据包含大家熟知的链路 (Trace)、指标 (Metric) 和日志 (Log)，也包括运维关注的告警（Alarm）、变更（Change）等信息。
微众银行的监控系统（IMS）实现了系统应用、平台组件和基础架构的指标监控和告警集中，同时也具备了交易和应用日志的监控能力。
智能化平台（KNOWING）实现了业务黄金指标的异常检测以及基于消息总线数据的业务链路绘制。
配置管理数据库（CMDB）实现了从基础架构到业务产品的配置项自动管理，提供了实时准确的配置及其关系数据。
自动化运维系统（AOMP）实现了应用变更版本发布的统一管理。
RCA 基于这些系统平台开展建设，分为异常交易分析、异常相关性分析和根因推导等几部分：
一、异常交易分析
业务黄金指标是直接反应业务异常且影响客户使用金融服务的指标，我们选定产品入口子系统的关键接口交易统计指标作为业务黄金指标，包括交易量、成功率和耗时等。业务黄金指标异常是由异常交易引起的，准确识别本次事件的异常交易并针对这些交易做全路径排查和关联指标 / 日志的聚类分析可以确定根因方向。其原理类似于控制新冠疫情的过程，即找到确诊病人（异常交易）并进行流行病学追踪（全路径排查）和聚集地分析（聚类分析），从而定位传染源头进而控制扩散（定位故障）。
指标异常时间段内，异常交易判定为下面两种情况：交易返回码标记为失败的交易和高于平日耗时基线的交易。通过交易流水（交易唯一标识）从 KNOWING 获取每笔交易的系统调用路径 (TRACE)，从 IMS 中获取交易路径上每个系统接口的指标数据（METRICS）和日志（LOG）信息，依据下游影响上游的原则并排除常见错误干扰，针对异常交易做聚类分析归纳出导致众多交易链条出错的异常子系统和接口、相关出错信息和聚集 IP，从而确定根因的大致方向。
- 图 2 Metrics, tracing 和 logging 的关系（引自：Peter Bourgon 《Metrics, tracing, and logging》）
二、异常相关性分析
针对异常时间段的运维数据通过交易链路路径信息、CMDB 关系数据、历史数据模型等进行相关分析提取有效信息用于最终根因的推导。
这些运维数据包括告警（含指标异常）、日志和变更操作等，具体的分析过程如下：
1. 告警分析
IMS 日均 2000 条告警，每月不经过收敛的原始告警约 14 万条，每条告警均有压缩策略，如果按照指标越限来统计的告警次数则更加庞大。由于分布式架构的高可用性以及告警定义的差异性，每条告警需要运维人员去处理和关注但不一定会影响业务和黄金指标，因此在业务异常发生时甄别出根因告警显得尤为困难，我们采用了下面一些方法：
（1）影响业务的告警筛选，应用关联分析算法挖掘历史告警的频繁项集并提取关联规则, 归纳引起业务异常的并发告警类型集合。例如主机的磁盘只读会立即引起业务异常，空间使用率越限则不会马上影响业务。
（2）告警相关性分析，结合交易路径信息和 CMDB 关系数据生成本次异常相关的应用实例和基础节点信息，异常窗口新增告警的对象信息与这些数据进行匹配生成相关告警集合。交易路径经过的节点信息认为是强相关，例如异常交易聚集的主机告警；交易路径上未经过通过 CMDB 关联到的节点信息认为是弱相关，例如核心网络、消息总线节点告警。针对弱相关告警需要结合业务影响面、异常范围匹配度、并发特征和历史告警频度等进行加权评分，依据强弱相关告警统一评分结果生成告警根因的概率排名。例如弱相关的核心网络抖动告警很多时候不影响业务，但如果伴随高频产品场景和多个业务集群异常，并发数据库网关不可达、应用超时日志，则抖动告警很可能是根因。
2. 日志分析
应用日志是异常分析和问题定位的主要抓手，运维人员尝尝利用异常交易流水上下文的出错日志来定位问题。IMS-LOGM 统计到全行应用系统累计应用日志 291T/ 天、业务交易日志 13T/ 天（截止 2019 年底），这么大量的日志既是宝藏也是挑战。RCA 主要针对关键系统的应用日志进行实时采集和分析。应用 NLP 技术实现文本的聚类分析和异常检测，聚类分析把大量的日志信息进行分类，减少同类日志的干扰；异常检测针对日志中的错误进行主动发现和归类，传统日志监控依赖人工配置错误关键字来识别异常，定义标准和使用目的的不同导致错误种类繁多，而且多数和业务影响不相关。RCA 日志检测采用统一标准对错误日志进行识别和分类，基于历史出现频度进行常见错误的排除，提取 OOM/DB 异常等影响业务的错误类别作为根因分析参考。
3. 发布变更和业务操作修改
应用版本发布、基础架构变更、业务操作和配置修改等都会引起业务异常。应用版本和变更信息关联类似于告警关联分析，变更实际操做时间与异常时间相符、发布单元在异常场景的交易路径或者 CMDB 关系链路上；基础架构变更需要结合历史影响面以及并发特征来组合判断；业务操作和配置修改依据时间相关性、产品场景关联性和影响指标匹配性来进行分析。
三、根因推导
传统根因推导过程是运维工程师通过对软件架构和调用关系的理解将异常发生时的告警、日志等信息联系在一起，应用运维知识经验来排查推导异常根因，相当于在大脑中存储和训练了一个知识图谱。
其中最大的挑战在于，运维工程师的知识经验存在差异而且往往仅精通本领域知识，同时人脑存储的信息量也相对有限。
然而，RCA 应用图形数据库（图形数据库是一种非关系型数据库，应用图形理论存储实体之间的关系信息），可以针对每个异常事件创建一个覆盖多应用域及基础架构的全专业图谱，沉淀运维知识进行因果推导。相比于专家规则引擎系统，基于图数据库的知识图谱更利于开发维护，并且具备结合机器学习实现复杂推理和新知识发现的扩展性，可视化的推导链路也具有较好的可解释性易于复盘和优化。
针对异常事件建立的知识图谱包含每笔异常交易的路径信息、CMDB 关联的数据库等基础架构信息、相关性分析得出的告警 / 日志 / 变更信息，针对这些数据基于基础组件影响上层应用等运维知识进行因果推导得出根因，如果存在多种结论则依据加权评分进行可能性排名。
RCA 对基础数据质量有非常高的要求，告警对象信息记录不标准、日志采集的延迟等均会导致最终结果错误。在开展 RCA 建设的时候很多方法也不是一撮而就，无不经过反复验证、不断复盘、持续迭代优化才最终落地建成工程化的应用系统。RCA 涉及到机器学习 / 深度学习、NLP 和知识图谱等众多 AI 技术的综合应用, 但也不能简单的把数据丢给算法来解决问题，例如 RCA 需要业务场景对应的所有接口指标来进行分析定位，曾尝试应用聚类算法在海量指标数据中寻找相似曲线进而确定业务场景关联的同类指标，但结果无法满足要求，最终通过日志中交易流水来关联接口信息的工程化做法确定了相关的指标集合。
微众银行的 RCA 经过前期建设已初显成效，目前定位准确率达到 80% 以上。
未来
进一步提升定位准确率以及缩短定位时效到秒级、让 RCA 具有自学习能力是接下来的建设目标，对未来有如下展望：
-
交易链路是业务异常定位的基石，链路信息越丰富、经过的节点数据越完整则定位问题越容易。结合 APM（应用性能监控系统）的建设丰富链路上的应用程序内部调用信息，补充链路经过的消息总线、域名服务等更多基础节点信息，实现应用代码方法及 SQL 语句级的异常定位。
-
告警是异常定位的首选参考，实时准确的告警可以让 RCA 事半功倍，一个引起业务异常的重要指标异动如果不能及时检测出来，就要通过大量其他相关辅助信息来弥补论证。针对主机 / 容器、数据库 / 网络等重要基础设施性能指标开展异常检测和无阈值标准化告警，提升基础指标异常发现的实效和准确性。
-
希望 RCA 具有自学习能力。尝试建立异常信息的全量大规模图谱，包含完整的 CMDB 关系和告警信息，应用图谱技术进行实体连接和相关规则的知识挖掘来不断补充完善现有知识；尝试建立基于向量的知识图谱，通过数值计算与深度学习模型集成来发现新知识和隐性知识。
如果希望了解我们在智能运维中使用的机器学习算法以及支持根因分析的具体方法，请参阅该系列其他文章。
参考资料
https://www.tingyun.com/blog/11860.html
百度在故障定位场景下的监控数据可视化探索: https://www.ucloud.cn/yun/3955.html
智能运维相关算法总结: https://blog.csdn.net/yamgyutou/article/details/134850892
