常见的针对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 更多案例交流
关注我，不定期发送技术干货。
