基于知识图谱与异常检测的PG数据库故障定位

PostgreSQL数据库是近年来热度上升最快的关系型数据库之一，近年来大量国内企业都在把系统向PostgreSQL上迁移。目前热度较高的国产数据库中也有一大半的厂商选择了PostgreSQL开源项目作为数据库产品的研发基础。不过PostgreSQL的运维一直是个难点，与Mysql相比，PostgreSQL过于复杂，运维难度远大于Mysql。而与Mysql相比，熟悉PostgreSQL运维与优化的DBA数量又远远不及。再加上开源数据库的文档资料相比Oracle等商用数据库来说更是差距甚大，如何做好PostgreSQL数据库的运维就成为很多企业面临的大问题。

在2020年的第十届中国PG用户大会上，我分享了一个主题-《基于知识图谱的PostgreSQL深度分析》，当时正好是基于PG的知识图谱1.0刚刚具备雏形的时候，正在实验性的用于D-SMART产品中，对PG等数据库进行辅助诊断。

在那个分享里，我介绍了利用团队梳理的知识库和异常检测算法进行PG数据库异常的自动诊断的一些尝试。

当时我们采用在生产系统中采样，并进行专家标注的方法构建分析中最为核心的异常检测算法，结合知识图谱定义的诊断路径，找出与某个故障现象相关的指标集，然后通过异常检测发现其中存在问题的子集，最后通过收敛算法，找到问题的根因。

在那个演讲中，我举了一个实际的案例，在一个电力客户中有一套PG数据库，现场DBA对PG运维完全无感，因此这套系统一直是在盲跑，到底有没有问题，只有老天知道，只要不宕机就啊弥陀佛了。客户反馈系统慢也没有任何办法去做分析，因为运维团队里没有任何针对PG进行优化的知识。

正好客户和我们一起启动了一个智能化运维的课题，于是我们就针对这套数据库进行了一些智能诊断的尝试。在D-SMART 1.9中我们提供了一个智能诊断工具，利用这套知识库可以进行初步的分析，将问题收敛到了几个方面，运维人员根据这些方面的分析结论，结合智能化工具推荐的诊断工具，手动点击这些工具，最终定位了问题。这种智能化辅助的手段可以减轻DBA的工作负担，提高问题定位的正确性。不过也只是能够起到一定的辅助作用。

当时我们分享的这个案例只是一个实验性的案例，我们采用的异常检测算法是依赖于专家人工标注的。

通过离线的数据采集，经过无监督学习（实际上就是暴力计算）找到一些疑似故障点，然后对这些数据进行一定的人工标注，再通过半监督学习构建模型，用于生产系统中的异常检测。为什么要采用这种迂回的方法来构建异常检测模型呢？这是因为暴力计算需要很高的算力，如果用于实时监控，对服务器CPU资源消耗过大，需要一个庞大的集群才能支撑较大规模的数据库运维场景。

这种方法虽然在实验室中获得了一定的效果，但是在实际生产环境中我们遇到了一个巨大的问题，那就是这样构建起来的模型并不通用，换了一个客户，甚至在一个客户的多种不同的应用场景中，模型都不通用。对于一个具有数百个甚至上千个数据库实例的用户来说，都采用如此高成本的模型构建方法是完全行不通的。后来我们又尝试了一系列基于时间序列的无监督算法，比如HTM/LSTM，以及随机森林等方法，最后获得的效果都不理想。

基于上面遇到的问题，在构建2.0版本的知识库的时候，我们放弃了以前的一些设计，针对异常检测，需要找到一种计算量较小的，不依赖于专家标注的算法。于是我们想到了模仿Oracle的统计信息，以一定周期为单位（比如一周，半个月），滚动更新统计数据，采集指标的数据进行采样，构建常规运行的数据模型，然后根据这些数据模型，建立算力要求较低的算法，用于生产环境的指标异常检测。

同时针对知识库的更新也在继续进行。从去年1.0版本的数千个顶点，两万多个关系变为5万个顶点，十几万个关系。

在知识库构建的过程中，1.0版本主要解决了从某个故障场景的诊断路径自动发散，通过发散后的路径来寻找各种问题的可能性。1.0版本并没有解决好问题的收敛，虽然智能诊断可以不断地发散，让DBA抓住所有的蛛丝马迹，但是没办法对问题进行收敛归类。从而较为准确的定位故障点，有时候甚至会出现大量的误判，把一些与这个故障无关的因素分析了出来。这是因为数据库系统是一个十分复杂的系统，当某类问题出现的时候，系统中还存在很多其他方面的问题，这些都可能对智能化分析产生严重的干扰。在数据库专家的辅助下，这些干扰可以比较容易的被裁剪，但是智能分析算法并没有人类的这种智慧，只是一种算法智能，是无法解决这些问题的。因此2.0版本的知识库中重点对诊断路径的收敛做了优化，最后形成比较规范的故障结论。

实际上，智能化诊断是一种算力与算法的诊断，而并不完全是一个真正的人工智能，我们更喜欢称之为“知识自动化”，是一种基于各种传感技术与算力的自动化驾驶。我们来看下面的一张D-SMART中智能化诊断的示意图。

首先是通过各种异常发现的算法与规则引擎，找出异常点，并归纳为某个异常场景。然后通过知识图谱发散思维，合理的扩散诊断路径。第三步是根据诊断路径找到关联指标，形成待分析的指标集。第四步是通过异常检测算法对这个指标集进行检测分析，找出可能的问题路径。最后对问题路径进行收敛，获得分析结果。

下面是D-SMART 2.0的一个诊断案例，我们在进行模拟压测时，D-SMART出现了一个告警，含义是shared buffers中的脏块写盘的状态出现了异常，backend进程承担了过多的脏块写出的工作。

比如上面的这个故障场景，在系统负载比较高的时候，经常会出现backend回写共享缓存的比例过高的问题，这会影响应用的性能，对于一些性能敏感的应用影响较大。针对这个告警，D-SMART提供了一个智能化分析工具和几条标准化的诊断路径。上面是“智能指标分析”工具显示的相关指标情况，在后面，该工具直接给出了诊断结论：

诊断结论还是通俗易懂的，懂一些PostgreSQL运维的人都可以获得如下的信息，首先这个问题出现的原因是系统并发量太大，其次数据库的配置有可优化的地方。另外系统中存在TOP SQL，IO的吞吐量也有点大。

事实是否如此呢？首先并发量大这一点十肯定的，因为出现告警的时间段正好在做压测。系统配置是不是有问题，我们可以直接通过工具去验证。目前2.0的知识库还有一个地方不够完善，那就是针对finding的确认，在2.1版本中，知识库里会带有诊断结果确认的知识，当然这些知识是通过关联相关诊断知识点来实现的。升级到2.1版本的知识库后，在每个发现后面会直接输出自动确认的结果。

对BGWRITER相关参数的分析，提出的建议是不调整相关参数，而去加大shared buffers。从shared buffers的命中率看，确实在问题发生的时间段内的命中率较低。

这也是PostgreSQL数据库常见的问题，当shared buffers不足的时候，大量的数据块需要写出，此时backend就被迫承担了大量的bgwriter的工作了。对于大型的PostgreSQL数据库，要尽可能减少这种情况的出现。

上面的诊断结果和智能诊断的finding中DB CACHE配置不合理是吻合的，根据上面的建议，我们把shared buffers调整为15GB，然后再加载类似的负载。再看看刚才的问题是否缓解了。

从上面的这个数据可以看出，调整shared buffers之后，backend进程写出共享缓存的比例合理多了。和今天上午同样压测的情况相比，也要低了很多。我们再来看shared buffers的命中率情况：

Shared buffers的命中率也没有再出现上午的抖动情况。从压测工具上来看，tpmc也稳定在60多万，比上午增加了15%左右，而且tpmc也不像上午压测那样抖动了。从这个例子来看，知识库2.0很好的帮助DBA完成了一次较为复杂的诊断。

知识库2.0版本在分析能力上必1.0版本有了较大的提升，代价是在D-SMART服务器上需要消耗大量的CPU资源去对已有的监控数据做采样分析，从而获得较为准确的数据，用于指标的异常检测。和传统的监控系统相比，智能化运维工具需要更高的算力来做支撑。随着工具能力的不断提升，D-SMART从一个只需要跑在一台配置很低的虚拟机上，已经变成了一个算力吞金兽了，不过幸运的是，算力在现在已经较为便宜了。