Arthas排查Kubernetes中應(yīng)用頻繁掛掉重啟異常
前言
其實(shí)最終定位到的問題還是蠻好解決的,但是因?yàn)閼?yīng)用在Kubernetes容器中的特殊性,導(dǎo)致在使用Arthas過程中出現(xiàn)了各種問題,所以單獨(dú)成文和大家分享下。照例先講下問題發(fā)生的背景,一個(gè)很老的web系統(tǒng)部署在tomcat容器里。近期打成了鏡像丟到了Kubernetes環(huán)境中運(yùn)行,總是各種掛,在Kubernetes層面定位了很久沒找到具體問題,但是初步定位到是因?yàn)橄到y(tǒng)中的報(bào)表導(dǎo)出接口導(dǎo)致的問題,最后使用Arthas找到問題并解決。
Kubernetes容器的特殊性
首先說下,我們的Kubernetes容器中運(yùn)行的應(yīng)用都是基于自己構(gòu)建的基礎(chǔ)鏡像打包的,如JDK,和tomcat基礎(chǔ)鏡像,為了減小打包后應(yīng)用的體積,我們對JDK進(jìn)行了大量的刪減,只保留了最小的jre運(yùn)行時(shí)環(huán)境。這樣導(dǎo)致的后果是在應(yīng)用出現(xiàn)問題需要使用jdk工具時(shí),如jinfo、jmap、jstack等都沒了,沒了這些工具就相當(dāng)于一個(gè)戰(zhàn)士沒了武器,束手無策了,但是最后忽然想到了Arthas,java線上排錯(cuò)利器。
使用到的工具Arthas
Arthas是阿里巴巴開源的一款在線診斷java應(yīng)用程序的工具,是greys工具的升級版本,深受開發(fā)者喜愛。當(dāng)你遇到以下類似問題而束手無策時(shí),Arthas可以幫助你解決:
- 這個(gè)類從哪個(gè) jar 包加載的?為什么會(huì)報(bào)各種類相關(guān)的 Exception?
- 我改的代碼為什么沒有執(zhí)行到?難道是我沒 commit?分支搞錯(cuò)了?
- 遇到問題無法在線上 debug,難道只能通過加日志再重新發(fā)布嗎?
- 線上遇到某個(gè)用戶的數(shù)據(jù)處理有問題,但線上同樣無法 debug,線下無法重現(xiàn)!
- 是否有一個(gè)全局視角來查看系統(tǒng)的運(yùn)行狀況?
- 有什么辦法可以監(jiān)控到JVM的實(shí)時(shí)運(yùn)行狀態(tài)?
- Arthas采用命令行交互模式,同時(shí)提供豐富的 Tab 自動(dòng)補(bǔ)全功能,進(jìn)一步方便進(jìn)行問題的定位和診斷。
項(xiàng)目地址:https://github.com/alibaba/arthas
Arthas的使用
第一步:下載arthas-boot.jar
wget https://alibaba.github.io/arthas/arthas-boot.jar
第二步:運(yùn)行
java -jar arthas-boot.jar
運(yùn)行后,并沒有出現(xiàn)熟悉的java進(jìn)程選擇界面,而是一閃而過,如下:
/opt/kl # java -jar arthas-boot.jar [INFO] arthas-boot version: 3.1.0 [INFO] Can not find java process. Try to pass <pid> in command line. Please select an available pid.
按官方的說明文檔描述,假如出現(xiàn)了找不到pid的情況,在當(dāng)前目錄下應(yīng)該會(huì)輸出相關(guān)的log,但是我看了并沒有日志,那只能嘗試是否可以手動(dòng)指定pid來使用Arthas了。在官網(wǎng)沒找到類似說明,只能試試java -jar arthas-boot.jar -help看下,輸出如下
/opt/kl # java -jar arthas-boot.jar -help [INFO] arthas-boot version: 3.1.0 Usage: arthas-boot [-h] [--target-ip <value>] [--telnet-port <value>] [--http-port <value>] [--session-timeout <value>] [--arthas-home <value>] [--use-version <value>] [--repo-mirror <value>] [--versions] [--use-http] [--attach-only] [-c <value>] [-f <value>] [--height <value>] [--width <value>] [-v] [pid] Bootstrap Arthas EXAMPLES: java -jar arthas-boot.jar <pid> java -jar arthas-boot.jar --target-ip 0.0.0.0 java -jar arthas-boot.jar --telnet-port 9999 --http-port -1 java -jar arthas-boot.jar -c 'sysprop; thread' <pid> java -jar arthas-boot.jar -f batch.as <pid> java -jar arthas-boot.jar --use-version 3.0.5 java -jar arthas-boot.jar --versions java -jar arthas-boot.jar --session-timeout 3600 java -jar arthas-boot.jar --attach-only java -jar arthas-boot.jar --repo-mirror aliyun --use-http
EXAMPLES的第一條顯示出來了,直接在jar后面加上pid即可,執(zhí)行后,還是不行,輸出如下:
/opt/kl # java -jar arthas-boot.jar 1 [INFO] arthas-boot version: 3.1.0 [INFO] Start download arthas from remote server: https://maven.aliyun.com/repository/public/com/taobao/arthas/arthas-packaging/3.1.0/arthas-packaging-3.1.0-bin.zip [INFO] Download arthas success. [INFO] arthas home: /root/.arthas/lib/3.1.0/arthas [INFO] Try to attach process 1 Exception in thread "main" java.lang.IllegalArgumentException: Can not find tools.jar under java home: /usr/java/jdk/jre1.8.0_191, please try to start arthas-boot with full path java. Such as /opt/jdk/bin/java -jar arthas-boot.jar at com.taobao.arthas.boot.ProcessUtils.findJavaHome(ProcessUtils.java:195) at com.taobao.arthas.boot.ProcessUtils.startArthasCore(ProcessUtils.java:206) at com.taobao.arthas.boot.Bootstrap.main(Bootstrap.java:441)
異常解析:
根據(jù)異??梢悦黠@看到說找不到tools.jar這個(gè)工具包了,還是回歸到Kubernetes容器環(huán)境中因?yàn)榫喠薺re運(yùn)行時(shí)環(huán)境導(dǎo)致jdk很多功能受限了。后面我做了一個(gè)非常規(guī)的事情,就是在完整的jdk中找到了這個(gè)tools.jar,丟到了jre里的lib目錄中,繼續(xù)嘗試,但是還有問題,如下:
/opt/kl # java -jar arthas-boot.jar 1 [INFO] arthas-boot version: 3.1.0 [INFO] arthas home: /root/.arthas/lib/3.1.0/arthas [INFO] Try to attach process 1 [ERROR] Start arthas failed, exception stack trace: java.lang.UnsatisfiedLinkError: no attach in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1122) at sun.tools.attach.LinuxVirtualMachine.<clinit>(LinuxVirtualMachine.java:342) at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:78) at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:250) at com.taobao.arthas.core.Arthas.attachAgent(Arthas.java:73) at com.taobao.arthas.core.Arthas.<init>(Arthas.java:26) at com.taobao.arthas.core.Arthas.main(Arthas.java:100) [ERROR] attach fail, targetPid: 1
異常解析:
可以看到在補(bǔ)全了tools.jar之后,出現(xiàn)了新的異常信息java.lang.UnsatisfiedLinkError: no attach in java.library.path,表明可能我們?nèi)钡臇|西不是一點(diǎn)半點(diǎn),我們知道attach功能是Arthas實(shí)現(xiàn)原理的兩大原理之一。
attach
:jdk1.6新增功能,通過attach機(jī)制,可以在jvm運(yùn)行中,通過pid關(guān)聯(lián)應(yīng)用
instrument
:jdk1.5新增功能,通過instrument俗稱javaagent技術(shù),可以修改jvm加載的字節(jié)碼
然后Arthas和其他診斷工具一樣,都是先通過attach鏈接上目標(biāo)應(yīng)用,通過instrument動(dòng)態(tài)修改應(yīng)用程序的字節(jié)碼達(dá)到不重啟應(yīng)用而監(jiān)控應(yīng)用的目的
最后的救命稻草
使用完整的JDK中的java命令。
以上方式都試過不行之后,最后我把完整的JDK給下載到本地了,然后通過jdk的bin目錄下的java命令啟動(dòng)arthas-boot.jar終于ok了,出現(xiàn)了熟悉的java進(jìn)程選擇界面:
/opt/kl/jdk1.8.0_191/bin # ./java -jar arthas-boot.jar [INFO] arthas-boot version: 3.1.0 [INFO] Found existing java process, please choose one and hit RETURN. * [1]: 1 org.apache.catalina.startup.Bootstrap
最后定位到的問題其實(shí)很簡單,我記錄了Arthas大盤中關(guān)于內(nèi)存部分的圖,如下:
上圖從標(biāo)題欄開始往下,分別是heap(堆內(nèi)存)、eden_space(伊甸園區(qū)內(nèi)存),survivor_space(幸存者區(qū)內(nèi)存)、tenured_gen(老年代內(nèi)存)。這張圖是觸發(fā)導(dǎo)出操作后的內(nèi)存分布,堆內(nèi)存從一開始的200M左右占用、到400M、到600M、一瞬間就飚升到900多兆了。最后從堆內(nèi)存指標(biāo)我們看到,總共989M,使用的內(nèi)存已經(jīng)飚升到988M了,這個(gè)時(shí)候其實(shí)應(yīng)用已經(jīng)掛了,Kubernetes容器已經(jīng)在重啟這個(gè)實(shí)例了。到這里基本已經(jīng)到位到應(yīng)用在容器中頻繁掛掉重啟問題的本質(zhì)了。
但是為什么堆內(nèi)存會(huì)這么小呢?
最終查明,有方面的原因:
1、因?yàn)槲覀冞@邊都是spring boot應(yīng)用,只有一個(gè)遺留的tomcat部署的應(yīng)用,所以在鏡像優(yōu)化方面更偏向jdk基礎(chǔ)基礎(chǔ)鏡像,而tomcat鏡像沒怎么關(guān)注,一開始對堆內(nèi)存這塊并沒調(diào)優(yōu)設(shè)置。
2、后面出現(xiàn)問題后,也確實(shí)想到過因?yàn)槭菍?dǎo)出報(bào)表導(dǎo)致應(yīng)用掛掉,很可能是內(nèi)存問題,設(shè)置過tomcat鏡像內(nèi)的堆內(nèi)存大小,但是因?yàn)槲覀冎匦麓虬溺R像沒有使用新的版本號(hào),而是直接覆蓋之前的版本,又使用Jenkins構(gòu)建的,Jenkins所在主機(jī)拉過之前的鏡像,導(dǎo)致鏡像更新后,Jenkins打包時(shí)并沒有去拉最新的調(diào)優(yōu)過基礎(chǔ)鏡像。
解決問題
1、調(diào)優(yōu)過的鏡像加上新的版本號(hào),讓應(yīng)用基于新的版本號(hào)構(gòu)建鏡像。或者清理下Jenkins所在主機(jī)的鏡像,這個(gè)會(huì)導(dǎo)致第一次構(gòu)建時(shí)速度變慢
2、優(yōu)化導(dǎo)出報(bào)表的實(shí)現(xiàn),我給的方案是,在導(dǎo)出大數(shù)據(jù)報(bào)表時(shí),可以通過id分區(qū),分別作業(yè)寫入同一個(gè)服務(wù)器本地的文件中,然后讓web容器映射下這個(gè)文件所在的目錄,等所有分區(qū)的任務(wù)都結(jié)束后,直接組裝一個(gè)文件下載鏈接返回給前端,讓前端觸發(fā)一次讀文件操作即可。
最后嘗試下jmap
除了使用Arthas外,最后還嘗試了使用jmap工具,但是因?yàn)橹匦孪螺d的JDK版本和主機(jī)jre版本不兼容,所有沒用上。最后通過JDK發(fā)行的歸檔頁面找到了對應(yīng)的版本,還是成功的使用jmap -heap pid看到了內(nèi)存情況,。內(nèi)存分布也蠻清晰的,如:
/opt/kl/jdk1.8.0_191/bin # ./jmap -heap 1 Attaching to process ID 1, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.191-b12 using thread-local object allocation. Mark Sweep Compact GC Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 3221225472 (3072.0MB) NewSize = 1073741824 (1024.0MB) MaxNewSize = 1073741824 (1024.0MB) OldSize = 2147483648 (2048.0MB) NewRatio = 2 SurvivorRatio = 8 MetaspaceSize = 21807104 (20.796875MB) CompressedClassSpaceSize = 1073741824 (1024.0MB) MaxMetaspaceSize = 17592186044415 MB G1HeapRegionSize = 0 (0.0MB) Heap Usage: New Generation (Eden + 1 Survivor Space): capacity = 966393856 (921.625MB) used = 856023096 (816.3672409057617MB) free = 110370760 (105.25775909423828MB) 88.57911199302988% used Eden Space: capacity = 859045888 (819.25MB) used = 787314712 (750.8418197631836MB) free = 71731176 (68.4081802368164MB) 91.6499017104893% used From Space: capacity = 107347968 (102.375MB) used = 68708384 (65.52542114257812MB) free = 38639584 (36.849578857421875MB) 64.00529537736568% used To Space: capacity = 107347968 (102.375MB) used = 0 (0.0MB) free = 107347968 (102.375MB) 0.0% used tenured generation: capacity = 2147483648 (2048.0MB) used = 1521987528 (1451.4804153442383MB) free = 625496120 (596.5195846557617MB) 70.87306715548038% used
jdk歸檔下載頁:https://www.oracle.com/technetwork/java/javase/downloads
結(jié)語
Arthas是一個(gè)非常不錯(cuò)的工具,我們線上多次使用Arthas定位過問題。不過像今天的這種Kubernetes容器環(huán)境的話,因?yàn)楸旧磉\(yùn)行時(shí)環(huán)境的缺失,可能使用的時(shí)候會(huì)存在各種問題,這里主要還是分享個(gè)思路。希望能給類似場景的同學(xué)提供一個(gè)有用的參考。
以上就是Arthas排查Kubernetes中應(yīng)用頻繁掛掉重啟異常的詳細(xì)內(nèi)容,更多關(guān)于Arthas異常排查Kubernetes頻繁重啟的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Java實(shí)現(xiàn)掃雷游戲詳細(xì)代碼講解
windows自帶的游戲《掃雷》是陪伴了無數(shù)人的經(jīng)典游戲,本文將利用Java語言實(shí)現(xiàn)這一經(jīng)典的游戲,文中的示例代碼講解詳細(xì),感興趣的可以學(xué)習(xí)一下2022-05-05Java多線程局域網(wǎng)聊天室的實(shí)現(xiàn)
在學(xué)習(xí)了一個(gè)學(xué)期的java以后,搞了一個(gè)多線程的聊天室,熟悉了一下服務(wù)器和客戶機(jī)的操作。感興趣的小伙伴們可以參考一下2021-06-06springboot使用@Slf4j進(jìn)行日志的記錄步驟詳解
這篇文章主要介紹了springboot使用@Slf4j進(jìn)行日志的記錄,使用@Slf4j的注解進(jìn)行日志記錄非常方便,本文給大家分享操作步驟,需要的朋友可以參考下2023-08-08springboot啟動(dòng)后卡住無日志的幾種情況小結(jié)
這篇文章主要介紹了springboot啟動(dòng)后卡住無日志的幾種情況小結(jié),具有很好的參考價(jià)值,希望對大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2021-12-12Spring Security實(shí)現(xiàn)驗(yàn)證碼登錄功能
這篇文章主要介紹了Spring Security實(shí)現(xiàn)驗(yàn)證碼登錄功能,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-01-01