前言
首先描述下問題的背景，博主有個習慣，每天上下班的時候看下skywalking的trace頁面的error情況。但是某天突然發現生產環境skywalking頁面沒有任何數據了，頁面也沒有顯示任何的異常，有點慌，我們線上雖然沒有全面鋪開對接skywalking，但是也有十多個應用。看了應用agent端日志后，其實也不用太擔心，對應用毫無影響。大概情況就是這樣，但是問題還是要解決，下面就開始排查skywalking不可用的問題。
使用到的工具arthas
Arthas是阿里巴巴開源的一款在線診斷java應用程序的工具，是greys工具的升級版本，深受開發者喜愛。當你遇到以下類似問題而束手無策時，Arthas可以幫助你解決：
- 這個類從哪個 jar 包加載的？為什么會報各種類相關的 Exception？
- 我改的代碼為什么沒有執行到？難道是我沒 commit？分支搞錯了？
- 遇到問題無法在線上 debug，難道只能通過加日志再重新發布嗎？
- 線上遇到某個用戶的數據處理有問題，但線上同樣無法 debug，線下無法重現！
- 是否有一個全局視角來查看系統的運行狀況？
- 有什么辦法可以監控到JVM的實時運行狀態？
- Arthas采用命令行交互模式，同時提供豐富的 Tab 自動補全功能，進一步方便進行問題的定位和診斷。
項目地址：https://github.com/alibaba/arthas
先定位問題一
skywalking數據存儲使用了elasticsearch，頁面沒有數據，很有可能是elasticsearch出問題了。查看elasticsearch日志后，發現elasticsearch正在瘋狂的GC，日志如：
: 139939K->3479K(153344K), 0.0285655 secs] 473293K->336991K(5225856K), 0.0286918 secs] [Times: user=0.05 sys=0.00, real=0.03 secs] 2019-02-28T20:05:38.276+0800: 3216940.387: Total time for which application threads were stopped: 0.0301495 seconds, Stopping threads took: 0.0001549 seconds 2019-02-28T20:05:38.535+0800: 3216940.646: [GC (Allocation Failure) 2019-02-28T20:05:38.535+0800: 3216940.646: [ParNew Desired survivor size 8716288 bytes, new threshold 6 (max 6) - age 1: 1220136 bytes, 1220136 total - age 2: 158496 bytes, 1378632 total - age 3: 88200 bytes, 1466832 total - age 4: 46240 bytes, 1513072 total - age 5: 126584 bytes, 1639656 total - age 6: 159224 bytes, 1798880 total : 139799K->3295K(153344K), 0.0261667 secs] 473311K->336837K(5225856K), 0.0263158 secs] [Times: user=0.06 sys=0.00, real=0.03 secs] 2019-02-28T20:05:38.562+0800: 3216940.673: Total time for which application threads were stopped: 0.0276971 seconds, Stopping threads took: 0.0001030 seconds 2019-02-28T20:05:38.901+0800: 3216941.012: [GC (Allocation Failure) 2019-02-28T20:05:38.901+0800: 3216941.012: [ParNew Desired survivor size 8716288 bytes, new threshold 6 (max 6)
問題二：
查詢后得知，elasticsearch的內存配置偏大了，GC時間太長，導致elasticsearch脫離服務了。elasticsearch所在主機的內存是8G的實際內存7.6G,剛開始配置了5G的堆內存大小，可能Full GC的時候耗時太久了。查詢elasticsearch官方文檔后，得到如下的jvm優化建議：
- 將最小堆大小（
Xms）和最大堆大小（Xmx）設置為彼此相等。 - Elasticsearch可用的堆越多，它可用於緩存的內存就越多。但請注意，過多的堆可能會使您陷入長時間的垃圾收集暫停。
- 設置
Xmx為不超過物理RAM的50％，以確保有足夠的物理RAM用於內核文件系統緩存。 -
不要設置
Xmx為JVM用於壓縮對象指針（壓縮oops）的截止值之上; 確切的截止值變化但接近32 GB。
詳情見：https://www.elastic.co/guide/en/elasticsearch/reference/6.5/heap-size.html
問題解決：
根據Xmx不超過物理RAM的50％上面的jvm優化建議。后面將Xms和Xmx都設置成了3G。然后先停掉skywalking（由於skywalking中會緩存部分數據，如果直接先停ES，會報索引找不到的類似異常，這個大部分skywalking用戶應該有遇到過），清空skywalking緩存目錄下的內容，如：
在重啟elasticsearch，接着啟動skywalking后頁面終於恢復了
結語
整個問題排查到解決大概花了半天時間，幸好一點也不影響線上應用的使用，這個要得益於skywalking的設計，不然就是大災難了。然后要感謝下Arthas的技術團隊，寫了這么好用的一款產品並且開源了，如果沒有Arthas，這個問題真的不好定位，甚至一度想到了換掉elasticsearch，采用mysql來解決索引id過長的問題。Arthas真的是線上找問題的利器，博主在Arthas剛面世的時候就關注了，並且一直在公司推廣使用，在這里再硬推一波。