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的节点上.
各种倒霉事遇到了一起,导致的这样的故障.
唉!~都小心点呀各位老板!~
