如何識別和排除Netty內(nèi)存泄漏

在優(yōu)銳課的學(xué)習(xí)分享中，我們了解有關(guān)識別Netty內(nèi)存泄漏的更多信息。分享給大家參考學(xué)習(xí)。

讓我們快樂的開始到結(jié)束-經(jīng)過漫長的搜索，我們設(shè)法在我們的一個(gè)日志偵聽器中發(fā)現(xiàn)了Netty內(nèi)存泄漏，并能夠在服務(wù)崩潰之前及時(shí)解決并修復(fù)問題。

1、聆聽?Netty

備份一下，讓我們提供一些背景信息。

Logz.io的日志偵聽器充當(dāng)從我們的用戶收集的數(shù)據(jù)的入口，然后被推送到我們的Kafka實(shí)例。 它們是基于Netty的Dockerized Java服務(wù)，旨在處理極高的吞吐量。

網(wǎng)絡(luò)內(nèi)存泄漏并非罕見。 過去，我們分享了從ByteBuf內(nèi)存泄漏中汲取的一些經(jīng)驗(yàn)教訓(xùn)，并且還會出現(xiàn)其他類型的內(nèi)存問題，尤其是在處理大量數(shù)據(jù)時(shí)。 手動(dòng)調(diào)整未使用對象的清理過程非常棘手，并且消耗內(nèi)存的情況是許多傷痕累累的工程團(tuán)隊(duì)遇到的情況（不相信我嗎？

但是，在每天要處理數(shù)百萬條日志消息的生產(chǎn)環(huán)境中，這些事件冒著被忽視的風(fēng)險(xiǎn)，直到災(zāi)難來臨和內(nèi)存用完為止。 然后，他們非常受關(guān)注。

2、識別泄漏

那么，在這種情況下如何識別Netty內(nèi)存泄漏？

答案就是Logz.io的Cognitive Insights，該技術(shù)將機(jī)器學(xué)習(xí)與眾包相結(jié)合，可以準(zhǔn)確地揭示此類事件。 它通過識別日志和技術(shù)論壇中的討論之間的相關(guān)性并將它們標(biāo)記為Kibana中的事件來工作。 然后，它將它們與可操作的信息一起顯示，這些信息可用于調(diào)試并防止將來發(fā)生同一事件。

在相關(guān)日子（即1月15日），我們的系統(tǒng)記錄了超過4億條日志消息。 在這些消息中，Cognitive Insights識別了由偵聽器服務(wù)生成的一條日志消息-NettyBufferLeak。

打開洞察力，揭示了更多細(xì)節(jié)。 事實(shí)證明，該事件在最近一周內(nèi)發(fā)生了四次，并且該特定事件已在Netty的技術(shù)文檔中進(jìn)行了討論。

通過查看消息中包含的實(shí)際堆棧跟蹤，我們的團(tuán)隊(duì)能夠了解泄漏的原因并進(jìn)行修復(fù)。

3、積極主動(dòng)

盡管有針對失敗的偵聽器的故障安全機(jī)制，但Logz.io不能承受這種情況，因此，我們寧愿避免喚醒一位待命的工程師。

為防止將來發(fā)生類似的內(nèi)存泄漏，我們根據(jù)見解中提供給我們的信息執(zhí)行了許多措施。 首先，我們根據(jù)特定的日志消息創(chuàng)建了測試，洞察力浮出水面，然后使用它們來驗(yàn)證我們對漏洞的修復(fù)未生成日志。 其次，如果此確切事件將來發(fā)生，我們將創(chuàng)建警報(bào)以通知我們。

4、結(jié)論

在日志分析領(lǐng)域，工程師面臨的最大挑戰(zhàn)之一是如何在大海撈針中找到針頭并識別出單個(gè)日志消息，這表明環(huán)境中的某些內(nèi)容已損壞并將使我們的服務(wù)崩潰。通常，事件不會在被攝入系統(tǒng)中的大數(shù)據(jù)流中被忽略。

有多種方法可用來克服這一挑戰(zhàn)，一種流行的方法是異常檢測。確定正常行為的基準(zhǔn)，并偏離該基準(zhǔn)觸發(fā)警報(bào)。盡管在某些情況下足夠了，但傳統(tǒng)的異常檢測系統(tǒng)很可能無法識別Netty內(nèi)存泄漏，這是一個(gè)非常緩慢和逐漸的事件，隨著時(shí)間的推移會間歇性地發(fā)生泄漏。

利用特定日志消息和網(wǎng)絡(luò)上大量技術(shù)知識之間的關(guān)聯(lián)性，可以幫助您發(fā)現(xiàn)那些本來不會引起注意的關(guān)鍵事件。我們的許多用戶已經(jīng)為此目的而利用了Cognitive Insights，接下來我將介紹一些我們幫助發(fā)現(xiàn)的事件的示例。

?

文章寫到這里，如有不足之處歡迎補(bǔ)充評論。

抽絲剝繭細(xì)說架構(gòu)那些事--優(yōu)銳課