【故障定位系列】电商业务系统告警频发，如何快速实现应用接口级故障定位

原文地址：https://www.databuff.com/infoDetail/blog95

摘要

常见的针对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 更多案例交流

关注我，获取更多技术干货~