聊点技术 | AI 赋能：根因定位如何深入到 SQL 级别

作者信息

背  景

在当今数字化时代，企业对 IT 系统的依赖日益加深，系统故障的影响也愈发严重。因此，快速准确地定位故障根因成为了 IT 运维领域的重要课题。传统的故障排查方法往往只能触及表面，无法深入到最核心的 SQL 级别，方法级别或错误级别的具体执行层面。人工智能（AI）技术的发展为故障根因定位带来了新的机遇。本文将重点介绍如何利用 AI 技术进行故障根因分析，并达到 SQL 级别，方法级别，错误类型级的定位精度。

1. 用业务入口的关键指标来确定真正的故障

在故障根因分析的过程中，首先需要准确地识别出真正的故障。这需要建立一个非常明确的故障定义，以便在复杂的系统环境中区分真正的故障与正常的系统波动或误报。基于以往的多种排障经验和云原生架构的部署经验，我们引入了“业务入口”的概念，并将真正的故障与业务入口的多个关键指标关联起来。

业务入口是指用户或外部系统与 IT 系统交互的入口点，如某个网页上的具体操作、某个页面上的提交功能，后端服务或系统提供的关键接口等。业务入口的关键指标通常包括响应时间、吞吐量、错误率，失败请求次数，阻塞操作占比等，这些指标直接反映了业务服务的可用性和实际性能。

对这些多指标联合进行 AI 异常检测，可以采用的 AI 算法非常多，比如可以通过对多指标进行聚类的方式，如 K-Means、DBSCAN 等，由于指标数据属于典型的时间序列数据，所以还可以通过时间序列算法，如 ARIMA（自回归积分滑动平均模型）、Holt-Winters 等，可以用来检测时间序列中的异常点。再比如，可以通过机器学习算法如决策树、随机森林、支持向量机（SVM）等，可以通过训练数据集来学习正常行为模式，从而识别异常。深度学习算法如自编码器（Auto Encoders）、长短期记忆网络（LSTM）等，能够学习复杂数据的潜在表示，并在重构过程中识别异常。当这些关键指标超出正常范围时，可以认为业务服务出现了故障。

2. 在调用链知识图谱上做“合纵连横”分析

使用 AI 算法确定某个系统发生故障后，就需要针对该故障进行根因定位分析，试图快速精准地定位到引发该故障的根本原因。

故障发生前一段时间的调用链数据是故障分析的关键。首先，我们收集并汇总这段时间内的所有错误或缓慢的异常调用链数据。这些数据通常包括服务之间的调用关系、调用时间、调用结果，也包括从页面上的某个操作调用某个具体的网络请求的链路，同时还包括网络请求调用后端多个服务的链路数据等。

知识图谱是一种结构化的语义知识库，用图形的方式表达实体之间的关系。在故障根因分析中，我们将调用节点抽取为知识图谱的节点，将调用链的关系抽取为知识图谱的边。如下图所示：在进行实体识别时，每个调用节点都可以视为一个实体，例如一个页面，页面上的某个操作，一个网络请求，一个服务，一个接口或一个数据库等等，这些实体在知识图谱中作为节点表示。而调用链中的关系，如服务 A 调用服务 B，在知识图谱中表示为从节点 A 到节点 B 的边，接口 1 属于服务 A，则在知识图谱上表现为服务 A 包含接口 1.

在知识图谱构建完成后，就可以基于该图谱“按图索骥”地进行根因分析。在进行知识图谱的根因定位算法选型上，考虑到故障数据难以获取，人工打标难度较大等原因，我们采用了无监督知识图谱结合“合纵连横”的技术方案。

在定位最可能的根因时，遵循“先横后纵，横纵结合”的原则，先在横向调用关系上采用深度（或广度）优先遍历算法，从源头开始逐级下钻，逐级判断每个实体点是否发生了错误或缓慢，直到链路的最终节点。然后再使用告警数据，提取出告警发生的实体对象，使用知识图谱中的最短路径算法，查找到告警实体对象与前面最终节点之间的最短路径，最后将横向遍历得到的路径和纵向的最短路径结合起来，绘制成最终根因分析拓扑图。

下图是横向定位时使用深度优先遍历算法得到最深层次的根因实体点。

在纵向定位上，我们使用知识图谱的最短路径算法，该算法在实现上有多种，其中最著名的是 Dijkstra 算法和 Floyd-Warshall 算法。

下图是纵向定位时使用知识图谱的最短路径算法进一步下钻查找根因。Dijkstra 算法是一种贪心算法，用于在加权图中找到单源最短路径。它适用于有向图和无向图。其基本原理是，首先进行初始化，选择一个起始节点（源节点）并设置其距离为 0，其他所有节点的距离设置为无穷大。然后创建一个优先队列（通常使用最小堆实现），将所有节点按照距离排序。当优先队列非空时，取出距离最小的节点，并对其每个邻接节点进行松弛操作（更新更短的路径）。重复上面的步骤，直到到达目标节点或优先队列为空。

Floyd-Warshall 算法是一种动态规划算法，用于在加权图中找到所有节点对之间的最短路径。其基本原理是，首先初始化一个二维数组，表示图中所有节点对之间的直接距离。然后对于图中的每个节点，检查通过该节点作为中间节点是否会缩短其他节点对之间的距离。然后更新数组中的距离值，直到所有节点对的最短路径都被找到。

如下是基于“先横后纵，横纵结合”的原则，得到的真实场景下的根因定位拓扑图。

在下面的真实根因定位拓扑图中，首先，我们将某页面的某个操作当作业务入口，使用 AI 多指标异常检测算法实时分析该操作是否发生缓慢或错误的故障，如下图，当该业务入口的操作发生缓慢/错误故障时，我们根据调用链知识图谱可以得到：该操作属于某个页面，且该页面属于某个终端应用，故而在拓扑图上可以补充从终端应用到操作的节点和边。然后在横向调用关系上采用深度/广度优先遍历算法，查找到该操作包含有某个网络请求，且该网络请求调用了 A 服务的接口 a，同时该接口 a 又调用了 B 服务的接口 b,如此不断下钻，最终找到最深层次的实体点是 D 服务的接口 d。如此便完成了横向上的根因下钻分析。

然后开始进行纵向上的分析，当有某个主机或网卡发生告警时，我们会抽取出该告警的实体对象，使用知识图谱的最短路径算法，查找从该 D 服务实体点到主机或网卡实体点的最短路径，如果找到，则将其路径补充到下方的知识图谱中。如此便完成了纵向分析，在最终结果上进行横纵向融合，最终得到如下根因定位拓扑图，且显示出最终根因节点是最下方的网卡。

对于 AI 算法而言，不管是传统机器学习算法，深度学习算法，还是最近火遍全球的 ChatGPT 类 AI 大模型，数据的准确性和全面性一直是至关重要的，所以在 AI 算法圈里有一句家喻户晓的名言：Garbage In, Garbage Out，简称 GIGO，即"垃圾进，垃圾出"。同样的，对故障的根因分析而言，调用链数据，告警数据的全面性和准确性也至关重要，只有首先确保了底层数据的精准性，然后才能确保上层 AI 应用的精准性。

得益于博睿数据在 APM 领域，RUM 领域和智能告警领域长达十几年的经验积累，我们的调用链数据，告警数据在采集全面性，精准性，时效性方面，在全国来说都是屈指可数的，故而站在如此精准全面的底层数据的“巨人”肩膀上，AI 算法才能在故障根因分析方面做到更加精准。

3. 深度分析--深入到 SQL 级别的根因定位

前面的“合纵连横”分析可以认为是初步分析，可以得到引起该入口业务发生异常的根因实体点，但有了实体点就代表找到了真正的根因吗？

根据我们在运维领域的实际排障经验，根因定位要做到可以直接给出具有可操作性价值的信息才有意义。比如某个页面的某个操作发生了缓慢的故障，我们初步分析得到是因为某个关系型数据库缓慢导致的。这样看并没有错，但是不够具体，定位的根因粒度还不够，运维人员只知道数据库缓慢并不能明确知道要操作什么才能恢复。

通过对以上排障场景的思考，我们提出了“初步分析”+“深度分析”的二级火箭思路，即在初步分析得到具体根因实体点的基础上，还要继续往下挖掘出更细粒度的原因，这样才能让运维人员更明确的知道后续操作的内容。

下图展示了初步分析得到的根因实体类型和深度分析给出的最细粒度根因的对应关系。

如下是真实场景下，多个服务的多个接口都出现了缓慢的异常故障，经过初步分析后，发现是底层的调用数据 Redis 出现异常，然后通过深度分析，给出了调用最慢的几个 Redis 命令（相当于 SQL）。

4.具体案例展示

案例 1：多个服务的多个接口缓慢，最终定位到根因是几个不合理的 SQL

针对该故障场景的复盘：在某一个时刻，多个上游服务的多个接口耗时非常长，服务响应太慢，首先通过我们 AI 的初因分析，算法自动发现哪几个服务的哪几个接口耗时太长，进而下钻分析这些接口调用下游其他哪些服务的哪些接口，通过不断下钻，最终发现是某调用数据库存在响应太慢的情况。

故而，通过上述第一级 AI 初因分析，得到了故障节点是该调用数据库。但为什么该数据库响应慢了？

我们继续通过第二级的深度分析，发现是短时间内多频次的调用某不合理 SQL 导致，最终在页面上给出这些不合理 SQL 语句，并给出其平均调用耗时，调用次数，总调用耗时等关键信息。同时，基于该不合理 SQL 语句，我们也给出修改建议：请关注上述慢 sql 以及调用服务是否有优化空间。

案例 2：一个服务下的多个接口缓慢，最终定位到根因是某个方法运行缓慢

针对该故障场景的复盘：某个服务下多个接口都出现缓慢的情况，通过初步分析，发现是该服务下的某个服务实例出现异常。继续通过深度分析，定位到是该服务实例下运行的某个方法太慢导致。如下图所示，该方法的执行耗时达到了 29s，严重拖累了整个服务下的多个接口的响应速度。

案例 3：某个服务的接口报错，最终定位到根因是下游接口发生了多次 HTTP ERROR 和 Exception

针对该故障场景的复盘：某个服务的接口报错次数太多，错误率太高，通过初步分析，发现该接口调用了下游接口，下游接口接连报错导致该接口报错。故而初步分析定位到下游服务的下游接口。然后针对该接口进行深度分析，最终定位到该接口产生了大量的 HTTP ERROR 和 Exception 导致了一系列问题，而且界面上还给出了每一种错误的调用服务名称，错误次数，错误占比，错误类型，以及对应的日志和调用链数据。方便用户进一步查看分析引起该故障的整个传播链路。

2024 年秋季，博睿数据重磅发布了一体化智能可观测平台 Bonree ONE 3.0，Bonree ONE 3.0 凭借其在数据采集、数据模型、数据中台及数据分析等方面的全面升级，再次引领了市场对可观测性的需求。Bonree ONE 3.0 通过领先的全域可观测数据模型，实现了更全面的数据采集和更智能的数据分析，帮助企业轻松应对复杂的 IT 运维挑战，将运维效率提升至全新高度。