背景
本文涉及的日志系統(tǒng)是文章《dapeng日志的收集處理及查詢應(yīng)用》中詳細(xì)描述的以fluent-bit => fluentd => kafka => fluentd => elasticsearch為結(jié)構(gòu)的日志系統(tǒng)得封。如果有興趣可以詳細(xì)的了解下培廓。
由于公司現(xiàn)有服務(wù)逐步增加让腹，現(xiàn)有日志量相比之前已經(jīng)有了成倍的增加箭昵。近期谤碳，運維小伙伴反應(yīng)線上服務(wù)器的磁盤空間消耗突然增加宛渐，達(dá)到預(yù)警值（90%）牍戚。經(jīng)過排查發(fā)現(xiàn)伦仍，是因為業(yè)務(wù)量的增加導(dǎo)致日志量激增娄蔼，而由于fluentd的處理能力有限怖喻，沒有及時將fluent-bit收集的日志發(fā)送到kafka，導(dǎo)致日志堆積和日志的告警延遲岁诉。
為了解決日志堆積問題锚沸，我們提出了兩種解決方案：
- 第一種是增加fluentd節(jié)點，通過多進(jìn)程來同時處理fluent-bit收集的日志涕癣，但是這個方案會帶來另一個問題哗蜈，就是cpu的開銷會增加，在線上已經(jīng)存在很多fluentd線程的情況下，該方案并不是適用距潘。
- 第二種就是剔除掉fluentd對日志的轉(zhuǎn)發(fā)炼列，直接通過fluent-bit向kafka發(fā)送日志消息。該方案依賴kafka強(qiáng)大的處理能力音比，剔除掉fluentd唯鸭，不僅可以解決日志堆積問題，還可以減小cpu消耗硅确，同時因為環(huán)節(jié)的減少目溉，日志將會更加實時。因此該方案就成了我們的選擇菱农。
因為我們使用的fluent-bit版本太低缭付，并不支持kafka-plugin。因此需要對fluent-bit進(jìn)行升級循未，這次我們直接升級到最新的穩(wěn)定版本v1.2陷猫。這篇文章記錄的就是在升級過程中的踩過的坑。
漫漫升級之路
空歡喜
文章《dapeng日志的收集處理及查詢應(yīng)用》中提到過的妖，我們對原生的fluent-bit進(jìn)行過優(yōu)化绣檬，其中一項就是添加了db_count字段來控制向?qū)懳募屏縪ffset的頻率。在升級v1.2的過程中嫂粟，在tail插件的文檔中娇未，我們發(fā)現(xiàn)了一個新的字段Ignore_Older，如下圖所示星虹。
文檔的描述表明零抬，該字段可以控制fluent-bit只讀取近期（m,h,d時間自定義）修改過的文件。我們希望在新版本使用該字段來替換掉db_count宽涌，如此我們就不需要在修改源碼平夜，升級會更方便。
但是本地測試后卸亮，大失所望忽妒。定義了仍會讀取所有的文件，通過查詢github上的issues發(fā)現(xiàn)兼贸，如下圖所示：
原作者表示該字段生效需要配置Parser段直，同時該字段時基于記錄的，而不是基于文件的寝受。至此坷牛，空歡喜一場，還是老老實實改源碼吧很澄。
痛苦的環(huán)境
Round 1
在升級之前，心想就是改好源碼，然后按照Quick Start所示命令（如下）一頓操作即可甩苛。但是事實并非如此蹂楣。
$ cd build
$ cmake ..
$ make
$ bin/fluent-bit -i cpu -o stdout
改好源碼后，按照如上操作會出現(xiàn)如下的錯誤提示：
會提示沒有相應(yīng)的插件FLEX讯蒲，在安裝了相應(yīng)的插件（還有bison插件）之后痊土，再次編譯。仍然會出現(xiàn)如下錯誤提示：
現(xiàn)在的我是一臉懵逼墨林，完全不知道什么原因（有哪位了解的大神可以解答下么）赁酝。
Round 2
通過上述命令不成功之后，我們嘗試使用Dockerfile文件進(jìn)行編譯旭等，打成鏡像酌呆。首次運行，會因為Dockerfile文件的第56行如下所示搔耕，而無法獲取到資源而失敗隙袁。
FROM gcr.io/distroless/cc
通過對Dockerfile文件的分析，我們發(fā)現(xiàn)文件的第56行之后的命令并不會對產(chǎn)生fluent-bit的可執(zhí)行文件構(gòu)成影響弃榨，可以滿足我們的需求菩收，所以我們將這些命令進(jìn)行了屏蔽，重試構(gòu)建驚醒鲸睛。這次居然成功了娜饵，異常興奮:)。
但是高興還是很太早官辈，我們發(fā)現(xiàn)通過Dockerfile構(gòu)建的鏡像非常大划咐，更重要的是我們將鏡像里面的fluent-bit可執(zhí)行文件cp到我們的服務(wù)鏡像里面，仍然不可用钧萍。心情down到底褐缠。
Round 3
我們又回到Round 1中關(guān)于flex等插件的問題中來，試圖找到原因风瘦。我們在fluent-bit文檔中發(fā)現(xiàn)如下的說明:
Flex和Bison插件僅僅只在開啟了Stream Processor的時候需要队魏，為此，我們嘗試將Stream Processor關(guān)閉在進(jìn)行編譯万搔，修改CMakeLists.text文件:
option(FLB_STREAM_PROCESSOR "Enable Stream Processor" No)
果然胡桨，如預(yù)期的一樣，這次編譯成功了瞬雹！吸取前幾次教訓(xùn)昧谊，這次不能太早高興。果不其然酗捌，這次編譯得到的fluent-bit可執(zhí)行文件并不支持kafka插件呢诬，我*哦涌哲。
Round 4
告訴自己淡定淡定，問題還得解決尚镰。我們再次回到Dockerfile文件阀圾，仔細(xì)分析下。我們嘗試用如下的命令進(jìn)行編譯：
cmake -DFLB_DEBUG=Off \
-DFLB_TRACE=Off \
-DFLB_JEMALLOC=On \
-DFLB_BUFFERING=On \
-DFLB_TLS=On \
-DFLB_SHARED_LIB=Off \
-DFLB_EXAMPLES=Off \
-DFLB_HTTP_SERVER=On \
-DFLB_IN_SYSTEMD=On \
-DFLB_OUT_KAFKA=On ..
這次打算趁環(huán)境不注意狗唉，悄悄編譯初烘。。分俯。肾筐。。我*缸剪，居然成功了吗铐。再進(jìn)行make命令。歐耶橄登，又成功抓歼，看來離成功不遠(yuǎn)了。最后將fluent-bit可執(zhí)行文件cp到我們服務(wù)的容器里面拢锹，執(zhí)行了如下命令：
./fluent-bit -i cpu -o kafka -p Brokers=192.168.*.*:9092 -p Topics=****
得到如下界面：
只想說一句：終于成功了谣妻！
最后我們還測試了我們添加的功能，最后都升級成功卒稳，升級不易蹋半。
總結(jié)
通過正常的Quick Start應(yīng)該是可以成功的，因為我們環(huán)境的原因最終沒有成功（有了解的大神可以成功解決否充坑？）但是通過不斷的嘗試减江，最后找到折中的方法，也是不錯的捻爷。過程比較曲折辈灼，結(jié)果還算滿意！我們使用fluent-bit工具用于基于dapeng-soa架構(gòu)的服務(wù)日志的收集也榄。有興趣的朋友可以通過dapeng文檔了解我們的高可用的微服務(wù)架構(gòu)巡莹。
