准备出一系列故障定位的经验分享文章
-
故障定位系列-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接口的获取连接时间，发现耗时突增，说明连接池中的连接一直在被占用而被迫等待
