准备出一系列故障定位的经验分享文章

• RootTalk Sandbox重磅出击
  

• 故障定位系列-1-接口级故障

• 故障定位系列-2-共享连接池故障

• 故障定位系列-3-容器资源故障

• 故障定位系列-4-波动度故障

• 故障定位系列-5-DB 基本故障

• 故障定位系列-6-DB 更新和读取行数的故障

• 故障定位系列-7-DB 连接池故障

• 故障定位系列-8-DB 调用次数故障

1 故障场景

某个时刻，几十个电商服务同时出现告警，如下所示

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

• 定界：服务 G 是根因服务：影响了上游一系列的服务

• 定位：服务 G 的 methodA 接口故障了，故障主要是因为访问 DB 的某个 SQL 耗时突增导致的

2 定位难点

2.1 定界的难点

对该故障的定界主要有如下 2 个难点

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

• 如何确定是自身还是下游服务的问题？

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

• 首先需要拓扑依赖：构建出实时的关系拓扑

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

一旦确定是访问下游服务导致之后，有如下 3 种可能

• 下游服务问题

• 网络问题

• 自身问题

如何才能更好的界定呢？

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

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

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

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

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

2.2 定位的难点

对该故障的定位主要有如下 2 个难点

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

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

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

答案是：指标下钻算法

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

详细见知乎 异常检测中‘根因定位’（root cause analysis）有什么常用的算法？

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

答案是：接口耗时分解

有了耗时分解之后，明显就可以看出是 DB 访问造成的问题，继续对 DB 访问进行下钻即可

3 实战案例

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

3.1 故障注入

注入后等待 2~3 分钟，可直接点击跳转到 Databuff 的故障定位平台

该故障案例有 4 个要素需要定位出来：

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

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

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

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

3.2 故障定位

定界如下：

定位如下：

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

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

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

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

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

定位粒度很细很全面

3.3 故障验证

验证 1 如下：

验证 2 如下：

验证 3 如下：

4 更多案例交流

更多信息请关注 RootTalk 故障定位专场 公众号，关注之后可点击扫码进群