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