arthas-first-parctice

Arthas 在线诊断初体验

Arthas 是一款阿里出品的Java诊断工具,可以实时监控JVM状态,灵活地线上Debug,具体可以看看它的教程。

虽然功能很强大,但是这次需要排查的问题比较简单,使用watch命令就简单搞定了。

工具还是要以实用为主,简单高效才是优雅。

问题背景

我们组开发了一个基于Hadoop生态的数据管理平台,简称X,但是在测试环境中回归测试的时候发现一个很诡异的现象:凡是涉及到Hadoop交互的接口全部都失败,而且报错信息为GSS Init failed,一种很典型的Kerberos登录异常。然而,与此形成鲜明对照的是:我开发的另一个监控工具,定时检查Kerberos与Hadoop的可用状态,却显示他们都是正常的。到底是谁出现了问题?🤔️

排查过程

接到问题的第一反应是:Keytab失效了导致登录异常。因为这部分底层代码已经很久没有动过了,在回归测试过程中这段逻辑却抛出了异常,更大的可能是Keytab数据本身有问题,而不是代码。虽然监控工具表明访问Kerberos和Hadoop都是正常可用的,但是也许监控的定时检查失效了呢?也许监控工具用的是新的正常Keytab,而X获取到旧的无效的Keytab呢?不论怎么样,检查一下Ketab数据的有效都是必要的。

下图是获取Keytab信息的代码逻辑:

code

从代码中可以看出,通过AuthInfo.getKeytab()可以得到Keytab数据。如果是在本地环境,IDE中设置断点我们就能一目了然的看到结果。但是,这次我们的服务运行在K8S容器环境中,也没有对外开放远程调试接口,于是想到了Arthas,正好以前只是看过文档,这次正好实践一下。

debug-watch

通过watch命令,顺利地拿到了Username和Keytab数据以后,在本地测试了一下这个Keytab数据的确是有效的,和监控工具使用的Username/Keytab内容相同。而且也比对过代码,本地代码和容器内的代码是一致的。那么,数据是对的,代码也是一样的,问题会出在哪儿了呢?🤨

我想到了唯一的答案:环境。说到环境,就得提困扰Kerberos部署的两大因素:DNS和Clock。DNS经常是一个大麻烦,因为Kerberos的安全机制要求对双方互相做验证,经常会因为容器内无法将Kerberos服务端域名正确解析到IP而导致验证失败。另一个问题就是时钟了,Kerberos的授权Ticket是有时效性的,如果时间漂移差距过大的话,授权机制就会误认为Ticket过期或者非法。最后,检查了一下物理机的时钟,发现差了1个小时,服务转移到其他机器就没有问题,转移回有问题的物理机以后就复现了。具体细节不表^_^

结语

Arthas作为一个很好的诊断工具,虽然不能打断点,但是通过watch命令就相当于在代码中注入了print语句,也是一个很不错的调试手段。