storm worker異常重啓原因排查彙總

此時此刻，正在等到6.18的到來，趁着沒事寫個博客，，，

 

storm集羣在worker down掉以後會自動啓動新的woker，但是有很多情況下是感覺不應該重啓的時候，woker重啓了，因此就走上了排查woker重啓的道路上~

 

一、排查思路

經過排查，主要總結有以下幾種問題，會導致woker重啓：

1. 代碼有未捕獲的異常

如下例子，因爲處理的數據有異常，並且在代碼中沒有捕獲異常，這樣Exception被拋給了JVM，導致woker down掉。

對於這樣的異常，可以在storm UI界面看到相應的異常信息，因此，排查問題時，可以首先看UI中是否有異常拋出。

 

java.lang.RuntimeException: java.lang.NumberFormatException: For input string: "贈品"
    at backtype.storm.utils.DisruptorQueue.consumeBatchToCursor(DisruptorQueue.java:90)
    at backtype.storm.utils.DisruptorQueue.consumeBatchWhenAvailable(DisruptorQueue.java:61)
    at backtype.storm.disruptor$consume_batch_when_available.invoke(disruptor.clj:62)
    at backtype.storm.daemon.executor$fn__3498$fn__3510$fn__3557.invoke(executor.clj:730)
    at backtype.storm.util$async_loop$fn__444.invoke(util.clj:403)
    at clojure.lang.AFn.run(AFn.java:24)
    at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NumberFormatException: For input string: "贈品"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
    at java.lang.Long.parseLong(Long.java:410)
    at java.lang.Long.parseLong(Long.java:468)
    at com.jd.ad.user.service.impl.UserOrderEntireUpdateServiceImpl.processUserOrderEntireData(UserOrderEntireUpdateServiceImpl.java:96)
    at com.jd.a

 

2、JVM 內存溢出

關於這個問題，沒有保留下來當初的現場，主要是由於各種原因導致JVM的垃圾回收機制有問題，最終導致內存溢出，這個問題，也會導致woker退出。

對於此類異常，跟1中的一樣，也可以在UI界面中看到的，這個需要具體排查JVM內存溢出的原因。

 

3、woker 無問題，supervisor重啓woker

對於1和2中的問題，拋出來的異常信息都可以在UI界面中以及woker的日誌文件中查找到，但是，我們還遇到了另一種情況，就是在woker中找不到任何的異常信息，但是總是隨機的會有woker重啓。

 

因爲woker中找不到異常信息，這時候就需要查看supervisor中的log信息了，因爲supervisor會對本機上的woker中的狀態信息進行監控,並且woker的重啓也是由supervisor操作的。

 

此時，查看supervisor中的日誌信息可以看到以下內容：

2017-06-17 23:36:08 b.s.d.supervisor [INFO] Shutting down and clearing state for id 867ed61b-a9d5-423e-bb0b-b2e428369140. 
Current supervisor time: 1497713767. State: :timed-out, 
Heartbeat: #backtype.storm.daemon.common.WorkerHeartbeat{:time-secs 1497713735, :storm-id "data_process_1-170-1497518898", 
:executors #{[578 578] [868 868] [1158 1158] [1448 1448] [1738 1738] [-1 -1] [288 288]}, :port 6716}

 因此，可以判斷爲是由於supervisor獲取狀態信息timeout超時（其實supervisor是獲取誰的狀態信息，這點還不明確，因爲woker的狀態信息是在本地文件系統中的，難道是獲取executor的狀態？這點希望大家拍磚吐槽），導致把woker shut down 了，然後重啓了woker。並且此時查看機器的狀態，發現zookeeper的機器的CPU負載，會偶爾出現不穩定的狀態。如下圖：

 

 

因此，可以斷定是由於supervisor獲取狀態信息超時導致的。

 

跟運維溝通，zookeeper的3臺機器是跟supervisor部署在同一臺機器上面的，因此會造成機器不穩定的情況出現。

 

平穩度過618，準備回家了。