技术分析：如何选择java诊断工具

现在市面上的java诊断工具繁多。大家可以说的上来的，有jdk自带的jstack(获取java线程栈和检测死锁)，jconsole(图形化的jmx工具)，jstat(查看内存信息变化以及gccause)。还有例如pinpoint这种大而全的诊断工具，一体化的apm系统。还有zipkin这种分布式调用链的工具。

如何做出选择呢

工具的繁多，带来的选择的困难，尤其是这么多的工具。我们可以接下来可以谈谈这些工具的区别。方便在合适的时候选择合适的方式。

jdk自带系列

jstack，jconsole，jstat，jcmd等等。

优点

他们使用的好处是和jvm高度的集成，非常适合当前版本的jvm的诊断。你装好jdk以后，这些就自带了，信息也比较多。

准确性高。其他的工具基本都是基于这些做的，所以信息的准确性基本是不需要太纠结的。当然也是有bug的。只不过相对比较少。

缺点

可视化欠缺，大部分工具都是cmd执行的，数据可视化力度不高。

不可持久化，目前没有提供这些信息的存储，当时看到的如果不自己保存下来，那么就无法回溯。

需要提前开启或者登陆cmd。这个可以说是他的优点，也是缺点，他的好处就是登陆机器上就可以看，缺点也是这样，例如生产的系统一般是不允许登陆上去的。或者是一个view账户登陆(jps这种是无法跨账户的)。

场景

非常适合在没有全面的诊断信息的情况，jdk自带的工具可以提供一个可以看的数据。这个已经是方便诊断问题了。不过需要自己保存数据，否则的话，你看到了，给别人讲的时候，无法完全可信。

prometheus系列

prometheus提供了一整套的抓取方案。开源非常的友好。

优点

开源友好。prometheus提供了一套抓取方案。grafana提供了一套可视化方案，jvm_exporter提供了一套指标暴露方案，alertmanager提供了一套告警方案，thanos提供了一套高可用的存储，压缩等方案。

可以快速支持不同的产品线。prometheus算是一套方案可以提供多个进程的抓取，做数据的对比，相比原来的单机的诊断，已经可以站在更高的视角，而且还有存储方案。是可以回溯问题的。

高度集成的程序，可以说诊断先下一个prometheus的介质就结束了，剩下的缺什么，补什么。

可扩展能力强，可以自定义指标。

缺点

exporter需要事先安装。开源的版本是这样的，虽说这个可以进行修改，利用jvm的attach方案去解决这个问题，但是需要承担宕机的风险。

过于零散化，组件得一个一个安装，如果一般来说，监控系统是需要告警等的，他的便于接收也导致了不是一体化的工具

场景

prometheus非常适合定制化强，信息可视化强，但是非链路跟踪的系统。数据是以时序指标呈现的。

apm系列

apm的产品就特别多了。例如pinpoint等等。

优点

非常产品化，无论采集还是展示，都是产品话的东西，可以说是开箱即用。

采集的信息非常全。不单单是指标的数据，调用链等也是有的。从物理机到jvm到进程信息，可以说是极大的满足诊断所需要的信息。

缺点

定制化低。由于非常的产品化，所以定制化的程度比较低了，并不是一个可接入的平台。(opentracing是定义了一个规范，他自己并不是一个具体的产品)。

需要的资源更多，存储等是非常完善的方案，所以一旦使用就是长期用户。

场景

非常适合做一个长期的诊断方案，短期应急或者资源不够就不是很适合。

总结

上面从资源，使用，定制化的角度说明了选择的方式。我们需要根据自己的需求来做选择。没有监控jdk自带的很好，想定制化，prometheus是个不错的选择。想直接现成的使用apm就更为适合。