資訊專欄INFORMATION COLUMN
摘要：升級后的日志大約是升級前的九分之一了，這樣來看很明顯就是的問題了。基本就能定位這個消費延遲的問題是版本導致的。既然消費者進程和鏈接都沒有變化，其實不應該短時間內頻繁的。因為前面的經(jīng)驗，所以現(xiàn)在都很大可能是版本問題了。
背景
我們有個數(shù)據(jù)處理平臺，有兩個用 docker 運行的數(shù)據(jù)處理模塊，分別是：data_api, 和 processor_api，故名思義：
data_api： 接受數(shù)據(jù)； processor_api： 處理數(shù)據(jù)；
一直以來，這兩個模塊都是相安無事，穩(wěn)定得很，然而在九月份因為更新 kafka 連接地址重啟了容器，就出了問題。
只要用過 docker 的童鞋，都會對 docker logs 很熟悉，這次問題就是，因為 docker 的日志狂刷，按照默認的配置，日志會全部寫入 json.log，大約一小時就能刷出 2G 的日志；
于是感覺特別的神奇，跑了快兩年都沒這問題，改下鏈接地址就有這么多日志輸出，但是明明容器是正常在工作的。
排查半天一直找不出原因，就先配置了日志轉儲才免得磁盤告警。
今天看到那一堆日志時，發(fā)現(xiàn)很多 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架構的問題沒去管，現(xiàn)在還是去谷歌一下，比較幸運地似乎找到一些原因和解決方案，
相關的鏈接：
https://github.com/dpkp/kafka...
https://github.com/dpkp/kafka...
大約的意思是因為查找域名失敗導致這個bug觸發(fā)了。
于是事不延遲，找臺機器升級下 kafka-python 版本到 1.4.0 看看，升級完之后發(fā)現(xiàn)日志大幅度減少了。
升級后的日志大約是升級前的九分之一了，這樣來看很明顯就是 1.3.5 的問題了。本想著這樣就愉快的解決了，然而調整完就有 kafka 消費延遲的告警了，因為一直時不時有少量的消費延遲，所以也沒在意。
直到第二天，累積的延遲量已經(jīng)觸發(fā)了第二級別的閾值了，消費延遲超過 30 萬條了，立馬上監(jiān)控看看
lag 圖就是延遲條數(shù)了，大約 11 號 18點的時候，也就是我們更新版本重啟容器之后，在數(shù)據(jù)寫入并沒多大改變情況下，lag 數(shù)拼命增長，直接去到 80 萬了，而且后面還在持續(xù)上漲；
首先排除因素就是 processor_api 消費速度，因為在更新前，一直是不會有延遲這么多的。
先回滾到舊版本看看，看到延遲立馬消失了。
基本就能定位這個消費延遲的問題是版本導致的。
既然是消費延遲，那就得看消費速度監(jiān)控了。剛才已經(jīng)說了，消費速度是絕對夠的，只是不知道為什么還是有延遲而已。
昨天到今天高延遲時的監(jiān)控圖圖：
時間太長看不出什么問題，選小區(qū)間再看看：
這次看到消費圖表，是斷斷續(xù)續(xù)的，而看消費者的日志，也看到時不時沒有東西打印，仿佛消費完了那樣。但是從延遲來看，數(shù)據(jù)應該是一直有的，不應該出現(xiàn)沒有日志打印的情況。
對比下正常時候的消費速率圖：
正常消費是連續(xù)的平穩(wěn)的，不應該是斷斷續(xù)續(xù)有尖峰的，懷疑是 kafka 消費權重沒有均勻等問題，找了 kafka 的童鞋，看能不能看到當前 kafka 消費者分配情況。
kafka 童鞋給了一個神奇的回復，說 kafka 正在 rebalance ...
Consumer group `panama_opsys_detect` is rebalancing
當 kafka 在 rebalancing 狀態(tài)，是不能夠消費的。這樣看起來的話，應該是 kafka 在頻繁的 rebalance 了。。
既然消費者進程和鏈接都沒有變化，其實不應該短時間內頻繁 rebalance 的。
因為前面的經(jīng)驗，所以現(xiàn)在都很大可能是版本問題了。
直接去 kafka-python 官網(wǎng)，找了較新的版本 1.4.2，更新之后，消費和日志都正常了。
歡迎各位大神指點交流, QQ討論群: 258498217
轉載請注明來源: https://segmentfault.com/a/11...
我的博客即將同步至騰訊云+社區(qū)，邀請大家一同入駐：https://cloud.tencent.com/dev...
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/44779.html
摘要：確定分流方案使用各類平臺分配流量。備擇假設與零假設相反，即實驗者希望證實的假設。雖然該數(shù)據(jù)集的統(tǒng)計結果與支付寶的實際規(guī)模有偏差，但不影響解決方案的適用性。選定統(tǒng)計方法由于樣本較大，故采用檢驗。 ...
摘要：將開發(fā)環(huán)境和生產(chǎn)環(huán)境的差異降至最低，并使用持續(xù)交付實施敏捷開發(fā)。可以在工具架構和開發(fā)流程不發(fā)生明顯變化的前提下實現(xiàn)擴展。我們的初衷是分享在現(xiàn)代軟件開發(fā)過程中發(fā)現(xiàn)的一些系統(tǒng)性問題，并加深對這些問題的認識。 簡介 如今，軟件通常會作為一種服務來交付，它們被稱為網(wǎng)絡應用程序，或軟件即服務（SaaS）。12-Factor 為構建如下的 SaaS 應用提供了方法論： 使用標準化流程自動配置，從...
摘要：使用或機器語言的外部功能包處理時間敏感任務，可以有效提高應用的運行效率。關鍵在于，優(yōu)化循環(huán)方案是提高應用程序運行速度的上佳選擇。此外，關于交叉編譯是否為提高運行效率的最佳方法還存在討論的空間。在使用交叉編譯器時，記得確保它支持你所用的版本。 Python 是一門優(yōu)秀的語言，它能讓你在短時間內通過極少量代碼就能完成許多操作。不僅如此，它還輕松支持多任務處理，比如多進程。 不喜歡 Pyt...
閱讀 1206·2021-11-24 09:39
閱讀 2129·2021-11-22 13:54
閱讀 2111·2021-09-08 10:45
閱讀 1443·2021-08-09 13:43
閱讀 2985·2019-08-30 15:52
閱讀 3083·2019-08-29 15:38
閱讀 2848·2019-08-26 13:44
閱讀 3055·2019-08-26 13:30
