Arthas排查Kubernetes中應(yīng)用頻繁掛掉重啟異常

更新時(shí)間：2022年02月28日 15:02:52 作者：kl

這篇文章主要為大家介紹了Arthas排查Kubernetes中應(yīng)用頻繁掛掉重啟的異常分析，有需要的朋友可以借鑒參考下，希望能夠有所幫助祝大家多多進(jìn)步

前言

其實(shí)最終定位到的問(wèn)題還是蠻好解決的，但是因?yàn)閼?yīng)用在Kubernetes容器中的特殊性,導(dǎo)致在使用Arthas過(guò)程中出現(xiàn)了各種問(wèn)題，所以單獨(dú)成文和大家分享下。照例先講下問(wèn)題發(fā)生的背景，一個(gè)很老的web系統(tǒng)部署在tomcat容器里。近期打成了鏡像丟到了Kubernetes環(huán)境中運(yùn)行，總是各種掛，在Kubernetes層面定位了很久沒(méi)找到具體問(wèn)題，但是初步定位到是因?yàn)橄到y(tǒng)中的報(bào)表導(dǎo)出接口導(dǎo)致的問(wèn)題，最后使用Arthas找到問(wèn)題并解決。

Kubernetes容器的特殊性

首先說(shuō)下，我們的Kubernetes容器中運(yùn)行的應(yīng)用都是基于自己構(gòu)建的基礎(chǔ)鏡像打包的，如JDK，和tomcat基礎(chǔ)鏡像，為了減小打包后應(yīng)用的體積，我們對(duì)JDK進(jìn)行了大量的刪減，只保留了最小的jre運(yùn)行時(shí)環(huán)境。這樣導(dǎo)致的后果是在應(yīng)用出現(xiàn)問(wèn)題需要使用jdk工具時(shí)，如jinfo、jmap、jstack等都沒(méi)了，沒(méi)了這些工具就相當(dāng)于一個(gè)戰(zhàn)士沒(méi)了武器，束手無(wú)策了，但是最后忽然想到了Arthas，java線上排錯(cuò)利器。

使用到的工具Arthas

Arthas是阿里巴巴開(kāi)源的一款在線診斷java應(yīng)用程序的工具，是greys工具的升級(jí)版本，深受開(kāi)發(fā)者喜愛(ài)。當(dāng)你遇到以下類(lèi)似問(wèn)題而束手無(wú)策時(shí)，Arthas可以幫助你解決：

這個(gè)類(lèi)從哪個(gè) jar 包加載的？為什么會(huì)報(bào)各種類(lèi)相關(guān)的 Exception？
我改的代碼為什么沒(méi)有執(zhí)行到？難道是我沒(méi) commit？分支搞錯(cuò)了？
遇到問(wèn)題無(wú)法在線上 debug，難道只能通過(guò)加日志再重新發(fā)布嗎？
線上遇到某個(gè)用戶(hù)的數(shù)據(jù)處理有問(wèn)題，但線上同樣無(wú)法 debug，線下無(wú)法重現(xiàn)！
是否有一個(gè)全局視角來(lái)查看系統(tǒng)的運(yùn)行狀況？
有什么辦法可以監(jiān)控到JVM的實(shí)時(shí)運(yùn)行狀態(tài)？
Arthas采用命令行交互模式，同時(shí)提供豐富的 Tab 自動(dòng)補(bǔ)全功能，進(jìn)一步方便進(jìn)行問(wè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)行后，并沒(méi)有出現(xiàn)熟悉的java進(jìn)程選擇界面，而是一閃而過(guò)，如下：

/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.

按官方的說(shuō)明文檔描述，假如出現(xiàn)了找不到pid的情況，在當(dāng)前目錄下應(yīng)該會(huì)輸出相關(guān)的log，但是我看了并沒(méi)有日志，那只能?chē)L試是否可以手動(dòng)指定pid來(lái)使用Arthas了。在官網(wǎng)沒(méi)找到類(lèi)似說(shuō)明，只能試試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的第一條顯示出來(lái)了，直接在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ù)異?？梢悦黠@看到說(shuō)找不到tools.jar這個(gè)工具包了，還是回歸到Kubernetes容器環(huán)境中因?yàn)榫?jiǎn)了jre運(yùn)行時(shí)環(huán)境導(dǎo)致jdk很多功能受限了。后面我做了一個(gè)非常規(guī)的事情，就是在完整的jdk中找到了這個(gè)tools.jar，丟到了jre里的lib目錄中，繼續(xù)嘗試，但是還有問(wèn)題，如下：

/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新增功能，通過(guò)attach機(jī)制，可以在jvm運(yùn)行中，通過(guò)pid關(guān)聯(lián)應(yīng)用

instrument：jdk1.5新增功能，通過(guò)instrument俗稱(chēng)javaagent技術(shù)，可以修改jvm加載的字節(jié)碼

然后Arthas和其他診斷工具一樣，都是先通過(guò)attach鏈接上目標(biāo)應(yīng)用，通過(guò)instrument動(dòng)態(tài)修改應(yīng)用程序的字節(jié)碼達(dá)到不重啟應(yīng)用而監(jiān)控應(yīng)用的目的

最后的救命稻草

使用完整的JDK中的java命令。

以上方式都試過(guò)不行之后，最后我把完整的JDK給下載到本地了，然后通過(guò)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

最后定位到的問(wèn)題其實(shí)很簡(jiǎn)單，我記錄了Arthas大盤(pán)中關(guān)于內(nèi)存部分的圖，如下：

上圖從標(biāo)題欄開(kāi)始往下，分別是heap（堆內(nèi)存）、eden_space（伊甸園區(qū)內(nèi)存），survivor_space（幸存者區(qū)內(nèi)存）、tenured_gen（老年代內(nèi)存）。這張圖是觸發(fā)導(dǎo)出操作后的內(nèi)存分布，堆內(nèi)存從一開(kā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)用在容器中頻繁掛掉重啟問(wèn)題的本質(zhì)了。

但是為什么堆內(nèi)存會(huì)這么小呢？

最終查明，有方面的原因：

1、因?yàn)槲覀冞@邊都是spring boot應(yīng)用，只有一個(gè)遺留的tomcat部署的應(yīng)用，所以在鏡像優(yōu)化方面更偏向jdk基礎(chǔ)基礎(chǔ)鏡像，而tomcat鏡像沒(méi)怎么關(guān)注，一開(kāi)始對(duì)堆內(nèi)存這塊并沒(méi)調(diào)優(yōu)設(shè)置。

2、后面出現(xiàn)問(wèn)題后，也確實(shí)想到過(guò)因?yàn)槭菍?dǎo)出報(bào)表導(dǎo)致應(yīng)用掛掉，很可能是內(nèi)存問(wèn)題，設(shè)置過(guò)tomcat鏡像內(nèi)的堆內(nèi)存大小，但是因?yàn)槲覀冎匦麓虬溺R像沒(méi)有使用新的版本號(hào)，而是直接覆蓋之前的版本，又使用Jenkins構(gòu)建的，Jenkins所在主機(jī)拉過(guò)之前的鏡像，導(dǎo)致鏡像更新后，Jenkins打包時(shí)并沒(méi)有去拉最新的調(diào)優(yōu)過(guò)基礎(chǔ)鏡像。

解決問(wèn)題

1、調(diào)優(yōu)過(guò)的鏡像加上新的版本號(hào)，讓?xiě)?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í)，可以通過(guò)id分區(qū)，分別作業(yè)寫(xiě)入同一個(gè)服務(wù)器本地的文件中，然后讓web容器映射下這個(gè)文件所在的目錄，等所有分區(qū)的任務(wù)都結(jié)束后，直接組裝一個(gè)文件下載鏈接返回給前端，讓前端觸發(fā)一次讀文件操作即可。

最后嘗試下jmap

除了使用Arthas外，最后還嘗試了使用jmap工具，但是因?yàn)橹匦孪螺d的JDK版本和主機(jī)jre版本不兼容，所有沒(méi)用上。最后通過(guò)JDK發(fā)行的歸檔頁(yè)面找到了對(duì)應(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歸檔下載頁(yè)：https://www.oracle.com/technetwork/java/javase/downloads

結(jié)語(yǔ)

Arthas是一個(gè)非常不錯(cuò)的工具，我們線上多次使用Arthas定位過(guò)問(wèn)題。不過(guò)像今天的這種Kubernetes容器環(huán)境的話，因?yàn)楸旧磉\(yùn)行時(shí)環(huán)境的缺失，可能使用的時(shí)候會(huì)存在各種問(wèn)題，這里主要還是分享個(gè)思路。希望能給類(lèi)似場(chǎng)景的同學(xué)提供一個(gè)有用的參考。

以上就是Arthas排查Kubernetes中應(yīng)用頻繁掛掉重啟異常的詳細(xì)內(nèi)容，更多關(guān)于Arthas異常排查Kubernetes頻繁重啟的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章:

最新国产好看的视频,伊人天堂AV在线,国产Aaaaaa视频,蜜臀视频在线观看一区,人妻av色图,密臀久久久精品影片,青青视频免费观看毛片,久草在线观看视,国产三级精品色情在线

Arthas排查Kubernetes中應(yīng)用頻繁掛掉重啟異常

目錄

前言

Kubernetes容器的特殊性

使用到的工具Arthas

Arthas的使用

異常解析：

異常解析：

最后的救命稻草

但是為什么堆內(nèi)存會(huì)這么小呢？

解決問(wèn)題

最后嘗試下jmap

結(jié)語(yǔ)

相關(guān)文章

最新評(píng)論

大家感興趣的內(nèi)容

最近更新的內(nèi)容

常用在線小工具

最新国产好看的视频,伊人天堂AV在线,国产Aaaaaa视频,蜜臀视频在线观看一区,人妻av色图,密臀久久久精品影片,青青视频免费观看毛片,久草在线观看视,国产三级精品色情在线

Arthas排查Kubernetes中應(yīng)用頻繁掛掉重啟異常

目錄

前言

Kubernetes容器的特殊性

使用到的工具Arthas

Arthas的使用

異常解析：

異常解析：

最后的救命稻草

但是為什么堆內(nèi)存會(huì)這么小呢？

解決問(wèn)題

最后嘗試下jmap

結(jié)語(yǔ)

相關(guān)文章

最新評(píng)論

大家感興趣的內(nèi)容

最近更新的內(nèi)容

常用在線小工具

但是為什么堆內(nèi)存會(huì)這么小呢？