Arthas排查Kubernetes中的应用频繁挂掉重启问题 #561
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
前言
其实最终定位到的问题还是蛮好解决的，但是因为应用在Kubernetes容器中的特殊性,导致在使用Arthas过程中出现了各种问题，所以单独成文和大家分享下。照例先讲下问题发生的背景，一个很老的web系统部署在tomcat容器里。近期打成了镜像丢到了Kubernetes环境中运行，总是各种挂，在Kubernetes层面定位了很久没找到具体问题，但是初步定位到是因为系统中的报表导出接口导致的问题，最后使用Arthas找到问题并解决。
Kubernetes容器的特殊性
首先说下，我们的Kubernetes容器中运行的应用都是基于自己构建的基础镜像打包的，如JDK，和tomcat基础镜像，为了减小打包后应用的体积，我们对JDK进行了大量的删减，只保留了最小的jre运行时环境。这样导致的后果是在应用出现问题需要使用jdk工具时，如jinfo、jmap、jstack等都没了，没了这些工具就相当于一个战士没了武器，束手无策了，但是最后忽然想到了Arthas，java线上排错利器。
使用到的工具Arthas
Arthas是阿里巴巴开源的一款在线诊断java应用程序的工具，是greys工具的升级版本，深受开发者喜爱。当你遇到以下类似问题而束手无策时，Arthas可以帮助你解决：
项目地址：https://github.com/alibaba/arthas
Arthas的使用
第一步：下载arthas-boot.jar
第二步：运行
运行后，并没有出现熟悉的java进程选择界面，而是一闪而过，如下：
按官方的说明文档描述，假如出现了找不到pid的情况，在当前目录下应该会输出相关的log，但是我看了并没有日志，那只能尝试是否可以手动指定pid来使用Arthas了。在官网没找到类似说明，只能试试java -jar arthas-boot.jar -help看下，输出如下
EXAMPLES的第一条显示出来了，直接在jar后面加上pid即可，执行后，还是不行，输出如下：
异常解析：
根据异常可以明显看到说找不到tools.jar这个工具包了，还是回归到Kubernetes容器环境中因为精简了jre运行时环境导致jdk很多功能受限了。后面我做了一个非常规的事情，就是在完整的jdk中找到了这个tools.jar，丢到了jre里的lib目录中，继续尝试，但是还有问题，如下：
异常解析：
可以看到在补全了tools.jar之后，出现了新的异常信息java.lang.UnsatisfiedLinkError: no attach in java.library.path，表明可能我们缺的东西不是一点半点，我们知道attach功能是Arthas实现原理的两大原理之一。
attach：jdk1.6新增功能，通过attach机制，可以在jvm运行中，通过pid关联应用
instrument：jdk1.5新增功能，通过instrument俗称javaagent技术，可以修改jvm加载的字节码
然后Arthas和其他诊断工具一样，都是先通过attach链接上目标应用，通过instrument动态修改应用程序的字节码达到不重启应用而监控应用的目的
最后的救命稻草
使用完整的JDK中的java命令。
以上方式都试过不行之后，最后我把完整的JDK给下载到本地了，然后通过jdk的bin目录下的java命令启动arthas-boot.jar终于ok了，出现了熟悉的java进程选择界面：
最后定位到的问题其实很简单，我记录了Arthas大盘中关于内存部分的图，如下：
上图从标题栏开始往下，分别是heap（堆内存）、eden_space（伊甸园区内存），survivor_space（幸存者区内存）、tenured_gen（老年代内存）。这张图是触发导出操作后的内存分布，堆内存从一开始的200M左右占用、到400M、到600M、一瞬间就飚升到900多兆了。最后从堆内存指标我们看到，总共989M，使用的内存已经飚升到988M了，这个时候其实应用已经挂了，Kubernetes容器已经在重启这个实例了。到这里基本已经到位到应用在容器中频繁挂掉重启问题的本质了。
但是为什么堆内存会这么小呢？
最终查明，有方面的原因：
1、因为我们这边都是spring boot应用，只有一个遗留的tomcat部署的应用，所以在镜像优化方面更偏向jdk基础基础镜像，而tomcat镜像没怎么关注，一开始对堆内存这块并没调优设置。
2、后面出现问题后，也确实想到过因为是导出报表导致应用挂掉，很可能是内存问题，设置过tomcat镜像内的堆内存大小，但是因为我们重新打包的镜像没有使用新的版本号，而是直接覆盖之前的版本，又使用Jenkins构建的，Jenkins所在主机拉过之前的镜像，导致镜像更新后，Jenkins打包时并没有去拉最新的调优过基础镜像。
解决问题
1、调优过的镜像加上新的版本号，让应用基于新的版本号构建镜像。或者清理下Jenkins所在主机的镜像，这个会导致第一次构建时速度变慢
2、优化导出报表的实现，我给的方案是，在导出大数据报表时，可以通过id分区，分别作业写入同一个服务器本地的文件中，然后让web容器映射下这个文件所在的目录，等所有分区的任务都结束后，直接组装一个文件下载链接返回给前端，让前端触发一次读文件操作即可。
最后尝试下jmap
除了使用Arthas外，最后还尝试了使用jmap工具，但是因为重新下载的JDK版本和主机jre版本不兼容，所有没用上。最后通过JDK发行的归档页面找到了对应的版本，还是成功的使用jmap -heap pid看到了内存情况,。内存分布也蛮清晰的，如：
jdk归档下载页：https://www.oracle.com/technetwork/java/javase/downloads
结语
Arthas是一个非常不错的工具，我们线上多次使用Arthas定位过问题。不过像今天的这种Kubernetes容器环境的话，因为本身运行时环境的缺失，可能使用的时候会存在各种问题，这里主要还是分享个思路。希望能给类似场景的同学提供一个有用的参考。
作者简介：
陈凯玲，2016年5月加入凯京科技。曾任职高级研发和项目经理，现任凯京科技研发中心架构&运维部负责人。pmp项目管理认证，阿里云MVP。热爱开源，先后开源过多个热门项目。热爱分享技术点滴，独立博客KL博客（http://www.kailing.pub）博主。
The text was updated successfully, but these errors were encountered: