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

• 一款体验故障定位的神器
  

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

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

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

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

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

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

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

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

1 故障背景

前面一期，分享了接口级的故障定位，通过细化到接口级别可以更加精确的过滤一些干扰因素，但是过细的过滤也会导致一些新的问题

• service-b 的 callB 接口->service-p 的 callB 接口->service-h 的 callB 接口

• service-o 的 callO 接口->service-p 的 callO 接口->service-l 的 callO 接口

• 其中 service-p 的 callB 和 callO 接口都使用了同一个 Http 连接池来访问下游不同的服务

在接口级链路拓扑中，上述 2 条链路是没有交集的，即 service-o 是不会去访问 service-h 的，但是如果上述 service-h 的 callB 接口发生故障

• service-h 的 callB 接口故障-》影响到 service-p 的 callB 接口-》影响到 service-b 的 callB 接口

• service-p 的 callB 接口长期占用 http 连接-》共享 Http 连接池中的连接不够用-》service-p 的 callO 接口获取不到连接而等待-》影响到 service-o 的 callIO 接口

service-o 的链路不会去访问 service-h，但是 service-h 故障会导致 service-o 故障，假如我们还按接口级链路去分析（service-o 的 callO 接口->service-p 的 callO 接口->service-l 的 callO 接口）就只能得出如下的结论

• service-p 的 callO 接口有问题（因为 service-l 的 callO 接口是没问题的）

这个结论跟实际 service-h 的 callB 接口故障是不符的

因此按照接口级拓扑进行分析有利有弊

• 优势在于：能很好的过滤干扰

• 劣势在于：有时会误导结论

那到底怎么办呢？

答案是：服务级拓扑和接口级拓扑动态结合，大部分情况下使用接口级拓扑，只有在最后一个服务时才采用服务级拓扑

• 大部分时候能充分发挥接口级拓扑的过滤干扰的能力

• 在最后一个服务时，再避免掉接口级拓扑的误导问题

2 实战案例

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

针对上述故障案例，RootTalk Sandbox 也是支持的

2.1 故障注入

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

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

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

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

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

• 并且 service-p 的故障结论中必须要给出共享连接池导致的 callB 接口影响到 callO 接口

2.2 故障定位

定界如下：

定位如下：

确实定位到了 service-h 的 callB 接口的问题

我们再来详细看下对 service-p 服务的分析结论：

service-p 的 callB 接口和 callO 接口都出现了问题，他们是因为 apache-httpclient_2 这个共享连接池导致的相互影响

可以通过上述给出的地址链接来验证这一结论

针对 callB 接口来说，客户端和服务端的平均响应时间均发生突变，一般则是服务端的问题

再看下 callO 接口，客户端响应时间均发生突变，而服务端没有变化，这种情况可能是客户端或者网络的问题

再查看 callO 接口的获取连接时间，发现耗时突增，说明连接池中的连接一直在被占用而被迫等待