filebeat實踐-記憶體佔用-最大記憶體佔用

filebeat作為日誌採集agent, 是需要部署到生產伺服器上的.不理解filebeat的工作機制,不瞭解filebeat在實際生產使用中的記憶體使用將會給你帶來意想不到的麻煩.

有些文章說filebeat記憶體消耗很少,不會超過100M, 這簡直是不負責任的胡說,假如帶著這樣的認識把filebeat部署到生產伺服器上就等著哭吧.

filebeat在空載情況(沒有日誌可採集)下的確不會有大的記憶體開銷,但在有大量的日誌需要採集時,filebeat的記憶體佔用是沒有固定值的, 那有沒有理論值呢?答案是有, 為啥這麼說,看下面公式:

                              bytes_each_log * spool_size * M + a*N

其中, bytes_each_log是單條日誌大小, spool_size是配置檔案裡配置項,  M是單條日誌在記憶體裡的溢價係數(>1), N表示採集的檔案個數,a為常數.

spool_size的預設值是2048, 好多人估計都不會配置這個項,也會因此埋下禍根(OOM):

10MB為filebeat支援的單條日誌最大長度,超過的將會被截斷丟棄

假設忽略a*N部分的記憶體開銷, 單條日誌的記憶體溢價為3, 一旦出現單條日誌大於50KB且有瞬間爆發量的時候, filebeat的記憶體佔用將大於300MB,是不是有點嚇人!如果出現了極端情況,單條日誌>10M,即使filebeat會截斷到10M那也是20GB!!是不是腿都軟了!!!

filebeat在實際使用過程中記憶體>300M,甚至15GB的情況浣熊都遇到過, 記憶體超過300M幾乎經常遇到,基本都是因為客戶沒有按照吩咐的去做導致的; 15GB的那次有點意外和驚喜, 客戶在自己的日誌檔案裡打了大量的二進位制檔案(後來知道真相的我眼淚掉下來...), 大量的二進位制檔案觸發了10MB規則,還好吃掉15GB記憶體後filebeat因OOM退出了,沒有帶來嚴重的損失.

那怎麼樣才能避免以上記憶體災難呢?劃重點了,快快拿出小本本記錄:

(1)每個日誌生產環境生產的日誌大小,爆發量都不一樣, 要根據自己的日誌特點設定合適的spool_size值;什麼叫合適,至少能避免記憶體>200MB的災難;

(2)在不知道日誌實際情況(單條大小,爆發量), 務必把spool_size設定上,建議128或者256;

最後分享張實踐圖片:

        單條日誌為45KB, spool_size為2048的記憶體開銷,陡坡下是spool_size調整為128的效果.