RocketMQ進程自動退出排查的示例分析

1、背景

一個 RocketMQ 集群由4主4從組成，突然其中3臺服務(wù)器“竟然”在同一時間下線，其監(jiān)控顯示如下：

 

2、故障分析

出現(xiàn)問題，先二話不說，馬上重啟各服務(wù)器，盡快恢復(fù)集群，降低對業(yè)務(wù)的影響，接下來開始對日志進行分析。

Java 進程自動退出(rocketmq 本身就是一個java進程)，一種最常見的問題是由于內(nèi)存溢出或由于內(nèi)存泄漏導(dǎo)致進程發(fā)送Crash等。由于我們的啟動參數(shù)中未配置

• -XX:+HeapDumpOnOutOfMemoryError

• -XX:HeapDumpPath=/opt/jvmdump

這兩個參數(shù)，不能直接根據(jù) 是否生成 dump 文件，那退而求其次去查看其GC日志，將GC日志下載到本地，然后可以使用一個在線gc日志分析工具：https://gceasy.io/ ，將 gc 日志上傳后會給出圖形化的展示，其圖如下：

 

 

既然 Java 進程不是由于內(nèi)存溢出等問題導(dǎo)致的退出，那又會是什么原因呢？那我們來看一下那個點的broker的日志，其關(guān)鍵日志截圖如下：

 

但我始終相信，肯定是執(zhí)行了手動執(zhí)行了 kill 命令導(dǎo)致進程退出的，經(jīng)過網(wǎng)上查找查，得知可以通過查閱系統(tǒng)日志/var/log/messages 來查看系統(tǒng)命令的調(diào)用，于是乎把日志文件下載到本地，開始搜索 kill 關(guān)鍵字，發(fā)現(xiàn)如下日志：

 

這個命令是有問題的，沒有使用 nohup ，如果會話失效，該進程就會被退出，為了驗證，我們再查一下進程退出時的日志：

 

故障原因基本分析到位了，運維在啟動的時候沒有使用 nohup 來啟動，故馬上排查剛啟動的集群的方式，重新重啟剛啟動的 Broker。

RocketMQ優(yōu)雅重啟小建議：

1. 首先將 broker 的寫權(quán)限關(guān)閉，命令如下：

   bin/mqadmin updateBrokerConfig -b 192.168.x.x:10911 -n 192.168.x.x:9876 -k brokerPermission -v 4
   

2. 通過 rocketmq-console 查看該broker的寫入TPS，當(dāng)寫入TPS降為0后，再使用 kill pid 關(guān)閉 rocketmq 進程。溫馨提示：將broker的寫權(quán)限關(guān)閉后，非順序消息不會立馬拒絕，而是需要等客戶端路由信息更新后，不會在往該broker上發(fā)送消息，故這個過程需要等待。

3. 啟動 rocketmq

   nohup bin/mqbroker -c conf/broker-a.conf  /dev/null  2>&1 &
   

4. 恢復(fù)該節(jié)點的寫權(quán)限

   bin/mqadmin updateBrokerConfig -b 192.168.x.x:10911 -n 192.168.x.x:9876 -k brokerPermission -v 6