基于运维知识图谱的指标分析

白鳝的洞穴 2020-11-13

4335

以前我们讨论过通过运维知识图谱可以发现一个运维故障相关的指标集，这对于基于图数据库的运维知识库来说是十分容易实现的事情。

上面的图谱是针对活跃REDO量过大这个故障的图谱数据，这是基于我们1.0的运维知识库，这个库中各个节点之间的关系还不是很完善，即使是这样，我们仍然能够看到，和这个运维故障相关的指标数量仍然很多。不过比起运维知识库中的数千个指标来说，数量还是大大的收敛了。这个图谱在实际的运维中能起到什么作用呢？我们来看D-SMART中的一个诊断工具，这个工具是最近我们根据运维知识图谱开发的一个自动分析工具，目前只是一个雏形，主要用来验证知识图谱与专家分析能力上的差异。

通过这个图谱对指标进行初步分析的结果我们发现，当前系统的问题主要集中在数据文件IO、事务数异常、数据库等待事件异常、REDO量过大、SQL负载过大这几个方面。

对比专家诊断工具的结果：

专家系统给出的分析建议包括行锁方面的等待较多，这一点是包含在等待事件中，1.0的知识库没有做这方面的细分，在近期准备发布的1.1的知识库中，这方面的知识做了细分，应该可以识别出行锁问题了。

数据库IO问题、操作系统IO问题，这一点和图谱分析结果类似。

日志等待方面的问题，这一点图谱也分析出来了。

热块争用问题，这一点图谱分析也是包含在等待事件中了，下一代的图谱将能够提供细分的结论。

似乎图谱分析的结果还算及格吧，不过目前专家系统的诊断结果还有更为深入的分析：

这是因为专家系统的数据集比知识图谱的数据集更为丰富，采用了离线与在线数据两种数据进行分析，而图谱分析完全基于离线数据，因此在分析的深入程度方面还是存在一定的差距。不过构建这种专家分析工具是十分困难的，需要做大量的针对性的定制。而基于运维知识图谱的智能分析系统完全是自动的，只要分析框架确定后，分析能力的提升就依靠图数据库的完善了，因此随着运维需求的不断扩大，依托运维知识图谱来进行分析是可持续发展的道路，而专家诊断工具的瓶颈十分明显。利用智能分析先框定问题的范围，再利用现有的专家诊断工具或者开发对应的诊断工具进行深度诊断，这种模式可以在运维自动化工作中发挥更大的作用。对于D-SMART来说，首先我们通过智能指标分析发现问题的范围，然后再根据这个提示进一步选择系统中的各种工具进行深度分析，定位问题的能力肯定会得到提升。

以前我们的有些用户在做问题诊断的时候，总是问我们，我该使用哪个工具来诊断呢？因为我只懂一点点数据库。有了问题范围的定位，这个问题就变得更简单一些了。

数据库

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

基于运维知识图谱的指标分析

评论