利用知识图谱诊断PG问题的一个小案例

白鳝的洞穴 2020-12-23

1890

目前用于问题诊断与分析的知识图谱已经从Oracle扩大到了oracle、Mysql、PostgreSQL、SQL SERVER。D-SMART的数据库正好是PostgreSQL 11，于是先用自己的数据库练练手。

首先在监控入口发现这个数据库实例的健康分比较低：

点击进去发现操作系统层面，数据库IO和数据库命中率都存在问题。

角标表示D-SMART的故障模型有报警存在，于是我们先点击进去看看，到底哪个运维场景发生了预警：

原来是操作系统的IO延时严重超标，触发了故障模型报警。这个告警的第一条诊断路径就是“智能指标分析”，这个诊断工具就是通过知识图谱推理可能存在的问题点。我们点击一下看看有什么问题存在：

通过分析发现，当前这个PG数据库的REDO量，TOP-SQL，数据库的并发量，CPU内存的使用率，物理写等方面都存在异常。同时图谱分析推荐了一系列诊断路径给我们，让我们继续点击，进行分析。

通过OSIO诊断路径我们发现后端存储的延时存在问题。同时报警的时间段内，IO吞吐量和IOPS都存在快速上升的趋势，因此可能该时段可能存在一些异常的SQL。通过SQL诊断工具分析，报警时段内的PG SQL的总体统计情况如下：

其中问题较为严重的TOP SQL如下：

我们再来看一个故障模型报警的场景，这个场景下，运维知识图谱推荐的诊断路径如下：

下面我们来看一个通过某个指标异常，运维知识图谱推荐的诊断路径：

看看这个系统的每秒事务数，从目前的数据看，当前是46TX/秒，周平均值是37。点击进入指标显示的界面，选择下面的智能指标分析按钮。

针对每秒事务数过高的问题，知识图谱推荐的诊断工具包括下面的一些内容：

从上述推荐的诊断路径上看，基本上还是靠谱的。有些诊断路径可能就是专家也不一定第一时间想得到，比如主从复制分析，这个分析是每秒事务数过高可能导致的问题，老专家也有可能会忘了去检查一下。

最后我们再来看一个远程诊断的案例，正好12月上旬客户将最近几个月的监控数据发到南京的实验室进行分析，其中有几套PG数据库。

这个系统的健康分在80分左右波动，点击雷达图可以看到索引扫描比例偏低：

看看这回智能指标分析会给我们什么样的推荐：

这回推荐我们去分析TOP SQL，看上去还是比较靠谱的。PG的知识图谱目前还是在初级阶段，虽然已经初步具备了一定的应用效果，提升能力需要有大量的应用实践，只有在实践中磨合，才能不断提升。

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