Arthas 在线诊断初体验

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

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

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

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

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

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

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

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

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

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

本文链接 http://yexingzhe54.github.io/passages/arthas-first-parctice/