背景

我們有個資料處理平臺，有兩個用 docker 執行的資料處理模組，分別是：data_api, 和 processor_api，故名思義：

data_api：      接受資料；
processor_api： 處理資料；

資料處理簡單架構

1024程式設計師專屬大禮（只限今天），82小節 Python 零基礎視訊，想要的加小助手wechat：17812796384

踩坑經過

一直以來，這兩個模組都是相安無事，穩定得很，然而在九月份因為更新 kafka 連線地址重啟了容器，就出了問題。

只要用過 docker

於是感覺特別的神奇，跑了快兩年都沒這問題，改下連結地址就有這麼多日誌輸出，但是明明容器是正常在工作的。

排查半天一直找不出原因，就先配置了日誌轉儲才免得磁碟告警。

今天看到那一堆日誌時，發現很多 kafka 連結失敗日誌：

...
[W 181011 14:18:24 conn:625] <BrokerConnection node_id=18 host=xxxx/xxxx(馬賽克) port=9093>: close() called on disconnected connection with error: ConnectionError: Unable to connect to any of the names for xxxx/xxxx(馬賽克):9093
[E 181011 14:18:24 conn:289] Unable to connect to any of the names for xxxx/xxxx(馬賽克):9093
....
 

之前以為是kafka架構的問題沒去管，現在還是去谷歌一下，比較幸運地似乎找到一些原因和解決方案，

相關的連結：

1. https://github.com/dpkp/kafka...
2. https://github.com/dpkp/kafka...

大約的意思是因為查詢域名失敗導致這個bug觸發了。

於是事不延遲，找臺機器升級下 kafka-python 版本到 1.4.0 看看，升級完之後發現日誌大幅度減少了。

升級後的日誌大約是升級前的九分之一了，這樣來看很明顯就是 1.3.5 的問題了。本想著這樣就愉快的解決了，然而調整完就有 kafka

直到第二天，累積的延遲量已經觸發了第二級別的閾值了，消費延遲超過 30 萬條了，立馬上監控看看

lag 圖就是延遲條數了，大約 11 號 18點的時候，也就是我們更新版本重啟容器之後，在資料寫入並沒多大改變情況下，lag 數拼命增長，直接去到 80 萬了，而且後面還在持續上漲；

首先排除因素就是 processor_api 消費速度，因為在更新前，一直是不會有延遲這麼多的。

先回滾到舊版本看看，看到延遲立馬消失了。

基本就能定位這個消費延遲的問題是版本導致的。

既然是消費延遲，那就得看消費速度監控了。剛才已經說了，消費速度是絕對夠的，只是不知道為什麼還是有延遲而已。

昨天到今天高延遲時的監控圖圖：

時間太長看不出什麼問題，選小區間再看看：

這次看到消費圖表，是斷斷續續的，而看消費者的日誌，也看到時不時沒有東西列印，彷彿消費完了那樣。但是從延遲來看，資料應該是一直有的，不應該出現沒有日誌列印的情況。

對比下正常時候的消費速率圖：

正常消費是連續的平穩的，不應該是斷斷續續有尖峰的，懷疑是 kafka 消費權重沒有均勻等問題，找了 kafka 的童鞋，看能不能看到當前 kafka 消費者分配情況。

kafka 童鞋給了一個神奇的回覆，說 kafka 正在 rebalance ...

Consumer group `panama_opsys_detect` is rebalancing

當 kafka 在 rebalancing 狀態，是不能夠消費的。這樣看起來的話，應該是 kafka 在頻繁的 rebalance 了。。

既然消費者程序和連結都沒有變化，其實不應該短時間內頻繁 rebalance 的。

因為前面的經驗，所以現在都很大可能是版本問題了。

直接去 kafka-python 官網，找了較新的版本 1.4.2，更新之後，消費和日誌都正常了。
轉載請註明來源:https://segmentfault.com/a/1190000016667454