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

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

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

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

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

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

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

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

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

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

• 故障定位系列 - 9 - 网络延迟类故障

1 故障场景

如下 2 个同样类型的故障

• 故障 A：某个 SQL 的耗时故障（耗时更长，造成的影响大）

• 故障 B：某个 SQL 的耗时故障（耗时相对短，造成的影响小）

其中某个服务在 2 个故障中的表现如下：

可以明显看出，这 2 次故障造成的耗时波动是不一样的，那这里就引出一个定位难点：如何能自适应不同程度的故障呢？

2 定位难点

要想适应不同程度的故障，需要做到如下 2 点：

• 异常检测需要自适应不同的波动度

• 上下游根因的界定如何适应不同的波动度

2.1 异常检测需要自适应不同的波动度

要想做到自适应，就必须先做到自学习，即对当前曲线的正常时间段的曲线波动进行学习

学习正常区间内的一些特征值：最大值、最小值、中位数、平均值、方差、标准差动态等计算出波动幅度，一旦响应时间波动大计算出的波动幅度也大，响应时间的波动小计算出的波动幅度也小，这样就容易适配不同的波动幅度了

再对异常区间进行异常检测：是否超过波动幅度，如果超过则认为异常，同时标记出异常范围

这里又引出了一个难点：如何界定出一段正常区间

一般通过告警来触发定位，因此可以将告警前几十分钟作为一个正常区间

2.2 上下游根因的界定如何适应不同的波动度

通常大家认为：客户端的响应时间上升了

• 如果服务端的响应时间也上升了：则认为是服务端的问题

• 如果服务端的响应时间没变化：则认为是客户端自身或者网络的问题

上述逻辑其实也涉及到一个波动度的问题，上图看起来是服务端造成了客户端的波动，但是如果服务端波动度再小一些，这时再去界定客户端还是服务端的问题就很难了

有什么解决办法呢：

• 可以配置一定的比例关系，如果 2 者响应时间的比例关系超过一定的比例再认为他们不相关，即并不是服务端造成了客户端的问题

• 这时候可能没法仅仅从这个点来判定到底是服务端还是客户端的问题，还是需要一个更综合的判断

3 实战案例

我们到 RootTalk Sandbox 上进行上述故障场景的复现。

RootTalk Sandbox 是一个故障演练和定位的系统，可以进行多种故障场景的复现，目前开放注册。

地址：https://sandbox.databuff.com/

3.1 故障注入

注入一个中度的故障

然后再按照上述操作注入一个轻微的故障

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

3.2 故障定位

登录 Databuff 后可以看到 2 次都能准确定位到故障

并且 2 次故障的波动幅度确实不一样

但是最终都能准确定位到是某个 SQL 的故障