经典烧脑故障--之山路十八弯

ok!~

没事根据自己的笔记给大家说一下处理过的比较经典的故障过程!~

那么在说明问题前,先看看大概的业务流和基础架构.

涉及本次故障的模块都在上面了哈!~

干扰事件前提:

1、故障发生的前天晚上proxy一侧做了割接切换.

2、当晚凌晨3点做了整体线上环境压力测试.

事件开始:

早上9点左右,接到业务侧同事反馈交易订单无法打开,无法交易,就是我们上面的a服务和b服务!~

那么由于昨天晚上对proxy做了割接,其实这批代理割接名单中并没有故障业务先的服务,但是业务侧却偏偏最初的重点怀疑是割接出现了问题导致的.

好巧不巧大家都在路上,这个情况也延长了处理故障的时间轴.

波哥接到了电话,由于波哥当时骑个自行车在路上实在听不清,只好找个地方靠边停车,然后发现群里已经快要炸了…因为他们就是判定割接代理出了问题,但是又联系不到人.都在等消息…我的天!~

临时找了个阴凉地方坐马路边,翻出电脑,第一时间回复群中,昨晚没有割接故障域名.另外告知组员在家没动身的不要来单位.

开始处理问题.

通过kibana查看涉案域名请求返回大部分是200,其中几个404.

立刻询问运营侧,故障是否为100%?

回答是100%.

这不可能是代理的问题.

立刻反馈给业务测希望立刻协助查看应用日志.

这时技术大群里,大数据业务组反馈有两个kafka的topic消费不正常,lag数已经达到30万+.但是由于不认识这两个topic是哪个业务线的,把问题抛到了大群里.

迅速捕捉到了这个信息,联系大数据业务线进群,协同确认,1分钟,确认这两个topic跟本次故障有关系.

阶段总结:

前端代理反馈客户端请求基本都是200.

运营业务侧反馈故障率100%.这就不符合代理出现问题的现象.

迅速同步信息,应该是业务间关联或者逻辑代码出现了问题之类的.要是类似这样的情况,核心排查力量将有基础运维,变成业务研发.

还没等放松两分钟,业务研发反馈部分业务任务现在无限重启情况,consumer的pod运行失败.

完了!~还得提刀上战场.

因为所有业务服务都在k8s集群上跑着,立刻定位pod运行状态.

故障pod集中在了一个固定的节点.

进一步查看pod失败日志,大部分都跟网络有关系.

立刻排查calico的pod的总体状态

确实该节点的calico的pod出现问题了.

那么我们都了解calico的运行原理,立刻查看该节点的iptables状态

呦呵!~iptable表被锁了…

这里细节的知识点各位自行查找哈!~

我们一定要明白一个原理,节点每新增一个pod,都会在该节点的iptables增加一条规则.

然后calico会调用iptables-restore来更新iptables,这里可以查看calico项目的源码来印证.

阶段总结:

1、kafka大量消息堆积.

2、导致kafka大量堆积的一定是consumer一侧服务出现了问题.

3、consumer服务的pod拉不起来,因为网络出现问题.

4、网络出问题是因为calico的pod不正常.

5、calico的pod不正常是因为iptable 被锁了.

呦西!_行吧!先解决问题,等有空了我再收拾这个问题.

立刻驱逐该节点consumer服务的pod,重新执行部署却发现依然无法拉起,因为这个业务指定了nodeSelector.而其指定的节点只有目前这一个节点还在运行中…

脑中一万匹羊驼奔跑…

不行,还得解决这个节点的问题.

那么能锁iptable的一定是某些服务在频繁更改这个节点的iptables规则.

立刻查看该节点的pod运行情况,发现几个不明job的pod在无限创建.

进一步查看发现是其获取配置出现了问题.

没见过这几个pod,很奇怪,反馈给群中业务,立刻被测试组同学领走了…5分钟左右后台发现该节点job的pod消失.

iptables锁释放

重新拉起consumer正常运行!~

业务恢复正常.

故障处理完毕!~

事后复盘:

1、测试同学做完压测收尾不干净.导致部分job没有被下掉,但是配置却被清除掉了.这些job就在不断的反复尝试创建.因为8点往后是业务高峰,进而引起了这起故障,这个是直接原因.

2、基础环境有几台机器故障被下掉了,正好是该业务所属的几个节点…所以变成了consumer只在这一个节点运行的局面.

3、压测同学选择运行压测运行job的节点名称有误会,内部沟通问题,导致把大量job跑到了这个consumer的节点上.

各种倒霉事遇到了一起,导致的这样的故障.

唉!_{都小心点呀各位老板!}