Alluxio實戰手冊之異常排查篇

05-13

Alluxio集群運行過程中, 可能會因為硬體軟體故障, 系統設置錯誤, 系統環境變更等原因導致集群運行出現異常. 本篇記錄了我在平時工作中總結的一些故障排查的經驗. 希望能幫到大家. 同時也建議大家碰到問題在我們的郵件列表(鏈接, 牆內鏡像) 上提問之前, 可以先參照本文列出的考察點, 先自我排查一遍. 很可能就發現了問題的原因.

常用鏈接

Alluxio項目官網
Alluxio Inc網站
Alluxio在各大廠用例
關注Alluxio微信公眾號

master和worker進程是否正常

通常碰到問題後, 首先來確定當前的Alluxio集群的master和worker都在正常工作.

最簡單直接的方法是連接並查看Alluxio的WebUI, 其默認地址為http://MasterHost:19999. 如果WebUI不響應, 則多半master節點出現了問題. 此外也可以運行一些簡單的Alluxio shell 命令來確認master正常響應客戶端的請求. 比如運行

bin/alluxio fs ls /

從WebUI中還可以可以看到很多有用的信息: 比如總worker數目, 是否有worker掉線, 以及每一個worker距上一次和master心跳的時間(如果是幾分鐘前上一次心跳, 多半worker出了問題). 在Alluxio 1.8當中將會添加一個fsadmin report命令讓大家可以從命令行來監視集群的健康狀況.

如果出現WebUI進程停止服務或shell命令超時, 以及如果有worker被判掉線, 下一步就是登錄到這些機器上, 查看master或者worker其工作日誌.

master和worker節點的工作日誌

在每台運行master以及worker進程的節點上, ${ALLUXIO_HOME}/conf目錄下的master.log以及worker.log文件分別是master 進程還有worker進程的工作日誌. 登錄這些節點查看工作日誌內是否有有Exception被記錄. 常見錯誤包括但不局限於下列這些:

UFS連接中斷(比如HDFS的namenode宕機或負載過大), 導致一些Alluxio UFS 操作超時;
UFS操作許可權不夠被拒絕;
UFS端數據源被繞過Alluxio的操作改動, 導致Alluxio與UFS層失去同步;
高負載下Master線程池耗盡, 無法響應新的客戶端請求.

從工作日誌當中, 能夠發掘出很多有用的系統報錯信息. 毫不誇張的說, master以及worker進程的工作日誌是debug的主要來源.

Alluxio文件系統日誌(Journal)

與存儲在每台伺服器節點本地上的master或者worker工作日誌不同, Alluxio文件系統日誌(Journal)通常是保存在一個外部的存儲系統比如HDFS上. 具體地址可見alluxio.master.journal.folder設置.

Alluxio Journal中保存了所有對Alluxio文件系統元數據層面的操作, 所以當Alluxio服務重新啟動, 或者HA(高可用)模式下leader master更迭的時候, 整個Alluxio文件系統依然最新狀態. 如果當Journal所處的存儲系統出現連接問題的時候(比如namenode宕機, 或者具體存儲Journal文件的datanode掉線)的時候, 可能會導致Alluxio系統對元數據寫操作的失敗, 導致Alluxio文件系統拒絕新的文件操作.

所以檢查存儲Alluxio Journal的存儲系統的健康也是排查工作的一部分.

是否有頻繁的JVM GC

Master以及worker進程頻繁及長時間的JVM GC可能會引起master或worker節點的服務中斷或連接超時, 節點連接心跳超時, 表現為Alluxio服務的不穩定. 通常高GC壓力會表現為JVM進程的CPU佔用率飆升. 為了排查這種可能, 可以在alluxio-env.sh當中, 為master或者worker進程的JVM參數添加GC相關的參數, 比如

ALLUXIO_JAVA_OPTS=" -XX:+PrintGCDetails -XX:+PrintTenuringDistribution -XX:+PrintGCTimestamps"

這樣在"${ALLUXIO_HOME}/conf"目錄下的master.out 或者worker.out當中, 會有系統的GC記錄.

如果只要檢測master(或者worker)的GC歷史, 替換ALLUXIO_JAVA_OPTS為ALLUXIO_MASTER_JAVA_OPTS(或者ALLUXIO_WORKER_JAVA_OPTS)

是否有死鎖(查看jstack)

master或者worker服務中斷的另一種可能是程序bug導致的死鎖. 如果master或者worker進程出現了長時間的不響應及高CPU佔用率, 但並沒有頻繁或者超長GC伴隨, 難么有可能是出現了死鎖. 在這種情況系啊, 可以先用jps列出進程得到pid, 再用jstack <pid>輸出這些進程的分線程callstack狀態以供分析.

實時啟用DEBUG級別的日誌

默認情況下, Alluxio master以及worker進程的工作日誌僅僅包括INFO和ERROR級別的日誌, 不包括DEBUG level的消息(通常帶有更豐富的信息, 比如master端RPC執行錯誤的callstack). 如下命令可以動態調整master的logging level 至DEBUG, 這樣我們可以看到master端執行RPC時候報錯的callstack 而不用重啟整個服務.

$ bin/alluxio logLevel --logName=alluxio.master.file.FileSystemMasterClientServiceHandler --target=master --level=DEBUG

也可以指定多個目標, 比如不僅包括master, 也包括192.168.100.100這台worker: "--target=master,192.168.100.100:30000".

更多詳情可以參閱 Logging Conventions And Tips - Docs | Alluxio Open Source

總結

發現異常時首先排查是否所有進程都在正常工作
工作日誌非常非常有用, 基本是debug依據的主要來源
有時候默認的logging level不夠具體, Alluxio提供動態的調整某一個類的logging級別, 非常方別