如何選擇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就更為適合。