原文出处：微信公众号 RootTalk 故障定位专场原文地址：https://mp.weixin.qq.com/s/AdfyKvx9hURI4Dvpzlg2OA

常见的针对 Web 应用的故障定位方案，大多只能定位到服务级别，然而很多情况下我们需要知道对应的应用接口的情况，才能更有效的解决问题。如何才能实现更加细化的接口级别的根因定位？本文以某个电商业务为例，来解答这个问题。

1 故障场景

某一日，某电商业务系统中几十个服务同时出现告警，如下所示

经过几十分钟的排查，最终确定了如下故障结论

• 定界到服务：根因节点定位到服务 G，该服务影响了上游一系列的服务

• 定位到接口：服务 G 的 methodA 接口存在故障，原因是访问 DB 的某个 SQL 耗时突增

2 定位难点和解决方案

2.1 故障根因服务节点定位

如何确定是自身、访问组件、访问下游服务的问题？

• 首先，构建出实时的拓扑依赖关系

• 然后，对下游组件或者服务进行异常检测，挑出符合当前服务的故障范围

• 一旦确定是故障根因在下游服务时，还会有如下 3 种情况

• 下游服务问题

• 网络问题

• 自身问题

如何才能更好的界定呢？

答案是：客户端响应时间和服务端响应时间的基准对比

• 如果服务端的耗时也波动了，大概率是服务端的问题

• 如果服务端的耗时没有波动，大概率是网络问题或者客户端的问题

• 通过网络丢包、重传来确定是否有网络问题

• 如果 GC 严重则大概率是客户端问题

2.2 故障根因接口定位

当服务整体响应时间突增时，如何定位到具体哪个接口呢？

答案是：指标下钻算法

目前主要有几个实现：Adtributor、iDice、HotSpot、Squeeze

当接口响应时间突增，如何继续往下定位呢？

答案是：接口耗时分解

耗时分解功能可以让你清晰地看到 DB 访问请求出现耗时突增（上图中右侧下方），点击该请求可以继续下钻分析。

3 实战案例

RootTalk Sandbox是一个故障演练和定位的系统，可以进行上述故障场景的复现。目前开放注册，可自主演练体验几十种故障场景。

3.1 故障注入

如上图，对拓扑图中的 service-g::k8s 服务的所有实例的 CallDB 接口注入某个 SQL 出现耗时突增的故障。

这里面的几个要素，会在下一步故障定位中被定位到。

3.2 故障定位

定界到服务：

定位到接口：

上面给出的定位信息，完整给出了前面说的 4 个要素：

• 故障服务是 service-g::k8s

• 故障接口是 callDB 接口，而非所有接口

• 故障是某个 SQL 导致的，而非所有 SQL

• 故障是耗时突增导致的，而非错误导致的

定位粒度很细、很全面。

3.3 故障验证

验证 1 如下：

验证 2 如下：

验证 3 如下：

4 更多案例交流

更多信息请关注 RootTalk 故障定位专场 公众号，关注之后可点击扫码进群，即可参与专家技术讨论。