基于TBDS的flume異常問題怎么排查

這篇文章主要講解了“基于TBDS的flume異常問題怎么排查”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“基于TBDS的flume異常問題怎么排查”吧！

現(xiàn)象

長期運營中發(fā)現(xiàn)部署了flume集群的磁盤滿，經(jīng)過排查發(fā)現(xiàn)flume的日志目錄導致。

具體問題

具體看flume的大文件日志發(fā)現(xiàn)，某個MySQL相關的sink持續(xù)拋出異常，打印了大量的日志

分析過程

根據(jù)這個異常信息（exception）即：
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after statement closed
字面意思為MySQL服務的狀態(tài)（連接）已經(jīng)關閉的狀態(tài)下，仍然有提交事務操作，拋出了異常，但這個異常持續(xù)拋出，仍需要深入分析。

配置分析

既然是flume拋出的，且與MySQL有關，那縮小問題范圍，查找flume里誰在寫MySQL。（flume的配置一般位于/etc/flume/conf/agent/flume.conf）





關閉階段僅僅檢查連接是否存在。

可能的原因

從sink的邏輯看，只有在空連接的情況下，sink狀態(tài)才會是BACKOFF，其他情況下狀態(tài)都是READY，且在向MySQL提交事務前后，不會檢查連接狀態(tài)，即使在SQL拋出異常的情況下也沒有修改sink狀態(tài)，導致提交拋出異常后，sink循環(huán)執(zhí)行，循環(huán)拋出異常。這里就是不斷拋出異常的根本。那么連接到底是什么時候關閉的呢？這里的原因猜測有2個：(1)sink長時間與MySQL沒有交互，超過連接自動關閉時間；(2)MySQL的異常關閉。

問題確認

是否sink長時間與MySQL無交互
查詢MySQL的超時配置如下：

可見，sink與MySQL之間的斷開并非二者長期無交互。

是否人為斷開服務
查詢人為啟動MySQL的時間如下：

時間吻合。

結論
MySQL服務異常導致flume提交事務時連接中斷，且flume沒有處理這種異常，引發(fā)死循環(huán)提交事務，并在這種異常情況下，flume已無法正常工作。

問題重現(xiàn)

根據(jù)以上的推論，可進行如下驗證這個異常：

HiveServer產(chǎn)生日志

在HUE里執(zhí)行多次HiveSQL

手動強制關閉MySQL

手動重啟flume寫入的MySQL實例。

查看flume表現(xiàn)

flume進入無限循環(huán)的拋出異常狀態(tài)，驗證成功。

感謝各位的閱讀，以上就是“基于TBDS的flume異常問題怎么排查”的內容了，經(jīng)過本文的學習后，相信大家對基于TBDS的flume異常問題怎么排查這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！