背景
- 我們的業(yè)務(wù)共使用11臺(tái)(阿里云)服務(wù)器,使用SpringcloudAlibaba構(gòu)建微服務(wù)集群,共計(jì)60個(gè)微服務(wù)全部注冊(cè)在同一個(gè)Nacos集群
- 流量轉(zhuǎn)發(fā)路徑:Nginxspring-gateway業(yè)務(wù)微服務(wù)
- 使用的版本如下:
spring-boot.version:2.2.5.RELEASE
spring-cloud.version:Hoxton.SR3
spring-cloud-alibaba.version:2.2.1.RELEASE
JAVA.version：1.8
- 春節(jié)放假期間,收到反饋,網(wǎng)頁(yè)報(bào)錯(cuò)服務(wù)未找到(gateway找不到服務(wù)的報(bào)錯(cuò)提示).
- 查看nacos集群列表,發(fā)現(xiàn)個(gè)別服務(wù)丟失(下線).
- 這個(gè)問(wèn)題每幾天出現(xiàn)一次,出現(xiàn)時(shí)間不固定,每次掉線的服務(wù)像是隨機(jī)選的幾個(gè).
- 服務(wù)手動(dòng)kill+restart后能穩(wěn)定運(yùn)行2-3天
1.進(jìn)阿里云控制臺(tái)查看故障機(jī)器近期的各項(xiàng)指標(biāo),但是發(fā)現(xiàn)故障機(jī)器的指標(biāo)有重要的幾項(xiàng)丟失,內(nèi)存使用率,CPU使用率,系統(tǒng)負(fù)載均不顯示
2.控制臺(tái)看不了只好進(jìn)服務(wù)器內(nèi)查看各指標(biāo)
free -m 查看內(nèi)存,無(wú)異常
3.提交阿里工單,授權(quán)阿里工程師幫忙修復(fù)控制臺(tái)顯示問(wèn)題,懷疑這個(gè)問(wèn)題對(duì)業(yè)務(wù)有影響
4.控制臺(tái)修復(fù)后掉線問(wèn)題依然存在
懷疑對(duì)象二:CPU滿載
能感覺(jué)到執(zhí)行命令很流暢,所以感覺(jué)不是這個(gè)原因, top查看后很正常
懷疑對(duì)象三:磁盤滿了
雖然概率很小,但是看一下,du -sh *發(fā)現(xiàn)磁盤容量還能用到公司倒閉
懷疑對(duì)象四:網(wǎng)絡(luò)有問(wèn)題
- 服務(wù)器那三個(gè)基本故障暫時(shí)排除后,最大懷疑對(duì)象就是網(wǎng)絡(luò),畢竟服務(wù)掉線肯定是服務(wù)端一段時(shí)間內(nèi)接收不到客戶端心跳包,所以把客戶端踢下線了.
- 通過(guò)te.NET,mtr -n *.*.*.*,netstat -nat |grep "TIME_WAIT" | wc -l這些命令也只能看個(gè)大概.
- echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse修改內(nèi)核參數(shù),開(kāi)啟TIME_WAIT socket復(fù)用能力，提升實(shí)例的網(wǎng)絡(luò)發(fā)送請(qǐng)求性能.
- 查看nacos客戶端(微服務(wù))的日志,在前面案發(fā)里提到?jīng)]有日志記錄
- 查看nacos集群部署的那幾臺(tái)服務(wù)器,查看服務(wù)器基礎(chǔ)指標(biāo)(內(nèi)存,cpu,磁盤等),未發(fā)現(xiàn)異常(畢竟還有幾十個(gè)微服務(wù)都很正常工作)
- 查看nacos服務(wù)端日志,發(fā)現(xiàn)確實(shí)有主動(dòng)下線服務(wù)操作,那就奇怪了,這個(gè)機(jī)器上的有些服務(wù)還在正常工作,為什么會(huì)隨機(jī)下線幾個(gè)服務(wù)呢?
后來(lái)仔細(xì)想想,這個(gè)懷疑對(duì)象是不是有點(diǎn)離譜了?因?yàn)椴渴鹉_本都是同一個(gè),而且負(fù)載均衡也是一樣的,但其他機(jī)器的這個(gè)服務(wù)都好好的.
1.調(diào)大每個(gè)微服務(wù)的內(nèi)存占用
2.添加堆棧打印
3.等待一段時(shí)間后,異常依然存在,并且,沒(méi)有堆棧打印???因?yàn)檫M(jìn)程好好的并沒(méi)退出!
4.google搜索nacos服務(wù)掉線,找到一篇看起來(lái)極其靠譜的文章!
5.上文提到我使用的springcloud版本,恰好這個(gè)版本的nacos-client版本就是1.4.1,于是立馬測(cè)試升級(jí)
6.觀察幾天后,發(fā)現(xiàn)問(wèn)題依舊,只能將探查方向繼續(xù)轉(zhuǎn)回微服務(wù)本身.
7.使用arthas進(jìn)行勘測(cè)各項(xiàng)指標(biāo),發(fā)現(xiàn)所有正常的服務(wù)各指標(biāo)均正常.
8.想到服務(wù)掉線大概率是因?yàn)?strong>心跳包丟失,懷疑是心跳線程因?yàn)槟承┰虮粴⑺?/strong>了.
9.翻看nacos-client源碼,找到心跳函數(shù)(nacos2.x不是這個(gè)),使用arthas監(jiān)聽(tīng)心跳包,嘗試能找到心跳丟失的證據(jù),貼上當(dāng)時(shí)的記錄
10.當(dāng)異常再次發(fā)生......arthas監(jiān)聽(tīng)卡死,無(wú)任何記錄和響應(yīng)........
11.無(wú)奈更換思路,寫一個(gè)監(jiān)聽(tīng)服務(wù)掉線的程序,期望可以在工作時(shí)間內(nèi)及時(shí)獲取到異常
12.終于在工作時(shí)間捕獲到異常,第一時(shí)間進(jìn)入服務(wù)器內(nèi)查看情況,
13.確認(rèn)服務(wù)器基礎(chǔ)項(xiàng)沒(méi)問(wèn)題后,使用arthas查看服務(wù)進(jìn)程堆棧情況,但是arthas無(wú)法進(jìn)入進(jìn)程!!!
14.用jstat查看GC情況,顯示很正常
15.用jmap/jstack輸出堆棧jstack -l 25944 >heap.txt,但是提示無(wú)法進(jìn)入進(jìn)程,無(wú)奈使用添加-F(這個(gè)參數(shù)的堆棧少了很多信息),jstack -F -l 25944 >heap.txt
16.查看堆棧文件,上萬(wàn)行記錄,眼都看花了,但是沒(méi)有死鎖也沒(méi)有發(fā)現(xiàn)異常
17.此時(shí)發(fā)現(xiàn)監(jiān)聽(tīng)程序提示服務(wù)上線了???!!!檢查后發(fā)現(xiàn)確實(shí)掉線的幾個(gè)微服務(wù)自動(dòng)恢復(fù)了,心想這就難排查了.
18.嘗試復(fù)現(xiàn)BUG,此時(shí)離第一次案發(fā)已經(jīng)過(guò)去一周多,必須盡快處理好這個(gè)BUG,否則可能得被迫離職了...
19.當(dāng)?shù)诙伟l(fā)生異常的時(shí)候,使用同樣的方式,arthas無(wú)法進(jìn)入->...->jstack輸出堆棧,奇跡發(fā)生了,服務(wù)又恢復(fù)正常了
20.思考/猜測(cè):因?yàn)閖vm死了(假死),所以導(dǎo)致進(jìn)程中的一切內(nèi)容,包括心跳線程,日志等,都hold住.
20.Google搜索關(guān)鍵詞jvm停止(假死)排查,終于找到一個(gè)極其靠譜的回答
21.連忙查看對(duì)比使用的幾個(gè)機(jī)器內(nèi)核版本號(hào)uname -r
22.那個(gè)低版本的就是故障機(jī)器,確認(rèn)相關(guān)信息后,聯(lián)系阿里云提交工單
23.升級(jí)完內(nèi)核并重啟后機(jī)器后,觀察兩天至今,這個(gè)問(wèn)題不存在了,誰(shuí)能想到這個(gè)問(wèn)題居然是因?yàn)閘inux內(nèi)核的BUG引起的,不得不佩服第一個(gè)發(fā)現(xiàn)這個(gè)BUG的大佬
完結(jié)感言
這個(gè)問(wèn)題折磨了一周多,每日如鯁在喉!調(diào)試過(guò)程也是苦樂(lè)參半,樂(lè)的是突然有了調(diào)試思路,苦的是思路是一條死胡同,還好最終結(jié)果是滿意的.
作為一名程序員,還是要時(shí)刻保持一顆探索的心,學(xué)海無(wú)涯!
