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

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

• 一款体验故障定位的神器
• 故障定位系列-1-接口级故障
• 故障定位系列-2-共享连接池故障
• 故障定位系列-3-容器资源故障
• 故障定位系列-4-波动度故障
• 故障定位系列-5-DB基本故障
• 故障定位系列-6-DB更新和读取行数的故障
• 故障定位系列-7-DB连接池故障
• 故障定位系列-8-DB调用次数故障
• 故障定位系列-9-网络延迟类故障

1 故障场景

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

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

• 定界：服务J是根因服务：影响了上游一系列的服务
• 定位：服务J的CPU使用率非常高

2 定位难点

2.1 定界的难点

这个之前的故障案例中已经详细分析过了，见 故障定位系列-1-接口级故障

2.2 定位的难点

当我们发现当前服务是根因服务时（即下游服务并未发现问题），我们就需要分析当前服务自身的问题

当前服务自身的问题包含如下：

• GC问题
• 资源问题
• 变更问题
• 等等

那就只能一一检测上述问题，并且上述问题也只能作为辅助因素，因为没有严谨的数据能证明GC超过XXXms跟当前故障是否一定强相关

当我们要查看该服务或者实例的资源指标，这里就涉及到非常重要的数据关联操作

不同环境下的数据如何跟APM的服务和服务实例建立关联呢？

不同环境下的数据来源	APM数据（包含serviceName、ip、pid、containerId、podName、主机host、k8s clusterId）
主机采集的进程数据（包含主机host、pid等）	和APM关联方案：主机host+pid
docker采集的容器数据 （包含主机host、containerId等）	关联方案：主机host+containerId
k8s采集的container数据（包含k8s clusterId、containerId、podName等）	关联方案：k8s clusterId+containerId

本质上就是定义一套资源标准，将不同环境下的数据指标映射到这套标准上

• APM数据要采集足够多的关联字段，才能跟其他各种环境的资源数据进行关联

做到了上述几点，就建立起了服务实例跟各种资源指标的关联，然后就进行异常检测

CPU异常检测的难点：

异常检测为了适应各种服务的波动，通常是突变检测，即产生突变即会认为是异常，对于CPU来说，很容易被突变检测认为是异常，因此还需要一些其他的一些抗干扰的检测能力

• 最低的CPU阈值：低于此则不认是异常
• 波动率：比如至少波动30%才可能认为造成响应时间的波动

同时对CPU波动度进行打分，波动度越高得分高，根因排序的优先级就高，因此同一个服务内的各个根因都要有打分机制，通过打分机制来决定到底哪个更适合作为根因

3 实战案例

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

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

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

3.1 故障注入

如上图所示进行操作，对拓扑图中的service-j::k8s这个服务的所有实例容器CPU满载的故障。

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

3.2 故障定位

登录Databuff后可以看到完整故障树，如下图。

点击根因节点

一旦是CPU问题会导致许多的组件访问都会出现问题，这时候CPU的优先级会更高一些

点击服务实例-CPU问题的地址链接，可以直接验证是否真的是CPU抖动上升了