背景
我們有個數據處理平臺，有兩個用 docker 運行的數據處理模塊，分別是：data_api, 和 processor_api，故名思義：
data_api： 接受數據；
processor_api： 處理數據；
數據處理簡單架構
踩坑經過
一直以來，這兩個模塊都是相安無事，穩定得很，然而在九月份因為更新 kafka 連接地址重啟了容器，就出了問題。
只要用過 docker 的童鞋，都會對 docker logs 很熟悉，這次問題就是，因為 docker 的日誌狂刷，按照默認的配置，日誌會全部寫入 json.log，大約一小時就能刷出 2G 的日誌；
於是感覺特別的神奇，跑了快兩年都沒這問題，改下鏈接地址就有這麼多日誌輸出，但是明明容器是正常在工作的。
排查半天一直找不出原因，就先配置了日誌轉儲才免得磁盤告警。
今天看到那一堆日誌時，發現很多 kafka 鏈接失敗日誌：
...
[W 181011 14:18:24 conn:625]: 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架構的問題沒去管，現在還是去谷歌一下，比較幸運地似乎找到一些原因和解決方案，
相關的鏈接：
https://github.com/dpkp/kafka-python/issues/1306
https://github.com/dpkp/kafka-python/pull/1312
大約的意思是因為查找域名失敗導致這個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
閱讀更多 Python學習 的文章
