利用运维知识图谱简化故障分析算法

网友投稿 1061 2022-10-04

本站部分文章、图片属于网络上可搜索到的公开信息,均用于学习和交流用途,不能代表睿象云的观点、立场或意见。我们接受网民的监督,如发现任何违法内容或侵犯了您的权益,请第一时间联系小编邮箱jiasou666@gmail.com 处理。

利用运维知识图谱简化故障分析算法

当某个复杂的运维故障发生时,快速了解如何进行诊断,并尽快定位问题是十分关键的能力。而在我们的运维工作中,这个能力的培养往往是十分困难的,甚至有些分析能力是专家才具备的,这是企业信息系统运维中普遍的痛点。

企业构建这种复杂分析的能力往往依靠的是内部专家或者外部团队,这些能力能够稳定的积累,成为企业的核心资产是所有企业的期望,不过这种资产积累是十分困难的这是因为缺乏正确的方法论与工具作为支撑。在企业的传统模式的知识库积累中,知识或者经验往往以一些方案、预案、报告等形式存在。以老白的经验,这种积累往往是工作量巨大,效率极低,并且成效几乎为0的,这些东西往往用不了一年半载就失效了。很多企业经过了十年的类似积累,知识库积累也十分庞大,不过知识库的使用率却极低,大量的活着的运维经验还是存在于运维人员的脑子里。

通过着这种失败,可能有些用户也意识到了,只有活着的知识才是能够传承的,能够积累的知识。于是也有一些企业尝试着用知识图谱来处理这些资料,希望让这些知识积累使用起来更有效,查找更方便。甚至一些企业想把这些知识和运维流程、监控体系融合起来。这些工作当然还是能够发挥一定的作用的,但是老白认为这种方法从根本上还是没法解决如何让知识真正的活起来的问题。隐藏在某个预案、方案和报告里的知识虽然已经经过了整理提升,但是还是没有把知识最为核心的价值挖掘清楚,因此在使用过程中仍然无法达到很好的效果。

另外一方面,我们积累下来的知识就一定是对的吗?老白在2004年左右写的《ORACLE dba优化日记》里面有些案例和方法,当时觉得还是挺不错的,十年过去了,老白偶尔翻起来,发现里面很多方案还是存在不少缺陷的。有时候专家也不可能对每个故障都分析的十分透彻,更何况在不同的用户,不同的生产环境中,存在大量的变数。因此知识积累不仅仅是一个积累的过程,还包含知识梳理和知识提升的工作。传统的文案形式的知识积累是无法承担这个作用的。

运维知识图谱是有效的解决这个问题的十分有效的工具,比如我提个问题:“在Oracle数据库中,如果出现blocking session较为严重的现象,可能和哪些指标有关?”似乎这个问题很好回答,不过仔细一想也确实不好回答,因为我们很少会把这个问题直接与某个指标去关联。而且在不同的运行环境中,这个答案还存在很大的不确定性。不同能力层次的人回答这个问题的答案也是千差万别的,经验不是十分丰富的技术人员可能只能够想到一些较为浅层次的指标,而专家可能会看到更多深层次的问题,甚至同一个专家在不同的时间能够想到的指标集也会不同,因为某些知识的内部关系是盘根错节的一张大网,很难一下子想清楚。

今天老白和大家分享的这个案例是通过运维知识图谱来解决这个问题的。看下面的图谱:

我们的专家在知识库中并没有直接给出blocking session 故障对应的指标,不过从图数据库的二级推理可以发现,在当前的生产环境中,和这个现象有关的指标包括:

enq TX - row lock contention会话总数enq TM - contention会话总数active redo log countnoarchive redo log file counRedo Allocation Hit Ratioenq CF - contention event wait timeLibrary Cache Hit RatioLatch hit ratiogcs drm freeze in enter server mode平均等待时间

如果你是一个较为资深的DBA,看到上面这个指标列表,是不是感到十分亲切。上面的大多数指标都是我们以前遇到过的和blocking session有关的指标。甚至还包含一些可能你以前没遇到过的场景,不过你仔细想想,确实这些指标异常,也是有可能导致blocking session产生的。通过这个图谱,你还可以学上一小招。

指标分析是在运维自动化系统中比较容易实现的,因此我们可以把blocking session这么一个复杂的比较难以分析问题通过维度转换,转变为分析某些指标是否异常的问题,从而让一个比较复杂的分析从不可能完成的任务变成了可轻松完成的工作。这是运维知识图谱能够对我们的运维工作提供的最大帮助。我们再通过log file sync延时过高的故障来看一个案例,大家知道这个等待事件延时异常可能导致日志数据同步缓慢,影响数据库的总体性能。

从图谱检索的结果我们可以看出,这个故障类型对应的指标比较多,有29个,总结一下可以分为几组,第一组是和数据库读IO总量相关的;第二组是和IO延时有关的;第三组只有一个指标,就是log file parallel write的延时;第四组是和数据库负载有关的;第五组只有一个,是和闩锁命中率有关的。图谱把专家能想到的问题都总结出来了,甚至有些专家可能忽略的问题都没有落下。是不是很神奇,这回运维知识图谱又给出了比专家还专业的分析。

上一篇:新一代运维平台BigOps社区版5.0.3发布
下一篇:【运维面试】金山科技 12 月份最新面试题-自动化运维岗位
相关文章

 发表评论

暂时没有评论,来抢沙发吧~