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


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

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

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

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

  • enq TX – row lock contention会话总数

  • enq TM – contention会话总数

  • active redo log count

  • noarchive redo log file coun

  • Redo Allocation Hit Ratio

  • enq CF – contention event wait time

  • Library Cache Hit Ratio

  • Latch hit ratio

  • gcs drm freeze in enter server mode平均等待时间

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

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

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

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

利用运维知识图谱简化故障分析算法》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/70.html