1. 日志采集這件事為什么繞不開 Filebeat做后端運維和日志分析的朋友大概率都經(jīng)歷過這樣的場景服務器上跑著七八個服務每個服務往不同的目錄寫日志排查一個線上問題要挨個登錄機器、tail -f翻半天好不容易定位到關(guān)鍵字又發(fā)現(xiàn)日志已經(jīng)被輪轉(zhuǎn)刪掉了。這種痛只要你經(jīng)歷過一次深夜排障就再也不想經(jīng)歷第二次。ElasticSearch 這套技術(shù)棧解決的就是這個問題——把散落在各臺機器上的日志集中收上來統(tǒng)一存儲、統(tǒng)一檢索。但問題來了日志怎么從服務器“搬”到 ElasticSearch 里去你可以自己寫腳本讀文件再調(diào) API 推送也可以用一個專門的采集器。Filebeat 就是干這個的它是 Elastic 官方出品的輕量級日志采集器專門負責把日志文件里的內(nèi)容讀出來轉(zhuǎn)發(fā)到 ElasticSearch 或者 Logstash。這篇文章適合誰看如果你是剛接觸 ELK 技術(shù)棧的運維或后端開發(fā)想快速把 Filebeat 跑起來并接入現(xiàn)有日志體系那這篇就是給你寫的。如果你已經(jīng)用過 Logstash 但覺得它太重、太吃資源想找一個更輕的替代方案那 Filebeat 也值得你花時間了解。我會從它為什么這么設(shè)計講起一直講到配置文件怎么寫、常見坑怎么填盡量讓你看完就能上手。先說一個我自己的判斷Filebeat 最大的價值不在于功能多強而在于它“足夠簡單且足夠穩(wěn)”。它用 Go 語言寫的編譯出來就是一個二進制文件沒有運行時依賴內(nèi)存占用通常在幾十 MB 級別CPU 消耗也極低。這意味著你可以在生產(chǎn)環(huán)境的每一臺業(yè)務機器上都部署一個而不用擔心它把業(yè)務資源搶走。這一點是它和 Logstash 最本質(zhì)的區(qū)別——Logstash 是 JVM 應用啟動就要吃掉幾百 MB 甚至上 G 內(nèi)存你不太可能把它鋪到每一臺業(yè)務機上。2. Filebeat 的核心設(shè)計思路拆解2.1 它到底解決了什么問題要理解 Filebeat 的設(shè)計先得理解日志采集這件事的難點在哪。表面上看無非就是“讀文件、發(fā)出去”但真要做到生產(chǎn)可用你得處理一堆細節(jié)文件被輪轉(zhuǎn)了怎么辦采集進度怎么記錄重啟后會不會重復讀或者漏讀網(wǎng)絡(luò)斷了數(shù)據(jù)發(fā)不出去是丟掉還是緩存多個采集器同時讀一個文件會不會沖突這些問題Filebeat 都替你想好了。Filebeat 的核心抽象叫Harvester收割機和Input輸入源。一個 Input 可以理解為一個日志來源的配置比如“我要采集 /var/log/app/*.log 這些文件”。Filebeat 會為每個被匹配到的文件啟動一個 HarvesterHarvester 負責逐行讀取這個文件的內(nèi)容并把讀到的每一行發(fā)給處理管道。這里有個關(guān)鍵點一個文件同一時刻只會被一個 Harvester 讀取這就避免了重復采集的問題。那進度記錄怎么做的Filebeat 維護了一個叫Registry注冊表的文件默認在數(shù)據(jù)目錄下的registry文件里。它記錄的是每個文件的唯一標識inode device以及已經(jīng)讀到的偏移量offset。每次讀完一批數(shù)據(jù)并成功發(fā)送后它才會更新這個偏移量。所以即使 Filebeat 重啟它也能從上次的位置繼續(xù)讀不會從頭再來。這個機制是 Filebeat 可靠性的基石后面講配置的時候會反復提到它。2.2 為什么選 Filebeat 而不是 Logstash很多人第一次接觸日志采集學的是 Logstash因為它功能全、插件多、能做復雜的過濾和轉(zhuǎn)換。但用著用著就會發(fā)現(xiàn)Logstash 太重了。它基于 JRuby跑在 JVM 上一個進程動輒幾百 MB 內(nèi)存啟動要幾十秒。如果你只是想把日志原樣搬走用 Logstash 就像開卡車去送一封信。Filebeat 的定位就清晰得多只做采集和轉(zhuǎn)發(fā)不做復雜處理。它把“采集”這件事做到極致輕量和穩(wěn)定復雜的過濾、富化、格式轉(zhuǎn)換交給下游的 Logstash 或者 ElasticSearch Ingest Node 去做。這種職責分離的設(shè)計讓整個鏈路更可控。你可以在一百臺機器上部署 Filebeat只在一臺機器上部署 Logstash 做集中處理資源利用效率高得多。當然Filebeat 也不是完全不能處理數(shù)據(jù)。它支持Processors可以在發(fā)送前做一些輕量的字段增刪改比如加個標簽、刪掉敏感字段、解析一下時間戳。但它的處理能力有限復雜的 Grok 正則解析還是建議放到 Logstash 里。我的經(jīng)驗是能用 Filebeat 做的就別上 Logstash能少一層就少一層鏈路越短出問題的概率越小。2.3 數(shù)據(jù)流轉(zhuǎn)的完整鏈路一個典型的 Filebeat 數(shù)據(jù)鏈路是這樣的業(yè)務服務寫日志文件 → Filebeat 的 Input 發(fā)現(xiàn)文件 → Harvester 逐行讀取 → 經(jīng)過 Processors 處理 → 通過 Output 發(fā)送到 ElasticSearch 或 Logstash → 最終存入 ElasticSearch 供 Kibana 查詢。這里有個容易被忽略的細節(jié)Filebeat 讀取文件時默認是按行讀取的每一行作為一條獨立的日志事件。如果你的日志是多行組成的比如 Java 的異常堆棧直接按行讀會把一個異常拆成好幾條查詢的時候就很痛苦。所以 Filebeat 提供了multiline配置可以把符合特定規(guī)則的多行合并成一條事件。這個配置幾乎是 Java 應用日志采集的必備項后面會詳細講怎么寫。另外Filebeat 的 Output 支持 ElasticSearch、Logstash、Kafka、Redis 等多種目標。如果你已經(jīng)有 Kafka 集群可以先發(fā)到 Kafka 做緩沖再由下游消費寫入 ElasticSearch這樣能扛住流量高峰。如果規(guī)模不大直接發(fā) ElasticSearch 也完全夠用。3. 從零開始搭建 Filebeat 采集環(huán)境3.1 安裝與目錄結(jié)構(gòu)說明Filebeat 的安裝方式有好幾種包管理器、二進制包、容器鏡像都行。我一般推薦用官方提供的二進制包或者系統(tǒng)包因為升級和排查都方便。以常見的 Linux 環(huán)境為例用包管理器安裝后它的目錄結(jié)構(gòu)大致是這樣的配置文件目錄/etc/filebeat/主配置是filebeat.yml可執(zhí)行文件/usr/share/filebeat/bin/filebeat數(shù)據(jù)目錄/var/lib/filebeat/registry 文件就在這里日志目錄/var/log/filebeat/Filebeat 自己的運行日志這里要特別提醒一句Filebeat 自己的日志和它采集的業(yè)務日志是兩回事。排查 Filebeat 本身的問題時要看/var/log/filebeat/下的日志而不是你配置采集的那些業(yè)務日志。我見過有同學配置了半天沒數(shù)據(jù)結(jié)果一直在看業(yè)務日志文件完全找錯了方向。安裝完成后先別急著改配置用filebeat version確認一下版本再用filebeat test config -c /etc/filebeat/filebeat.yml測試配置文件語法。這兩個命令是后面每次改配置后都建議跑一遍的能幫你提前發(fā)現(xiàn)大部分低級錯誤。3.2 核心配置文件逐項拆解Filebeat 的配置文件是 YAML 格式結(jié)構(gòu)上主要分幾大塊inputs、processors、output、以及一些全局設(shè)置。下面是一個最基礎(chǔ)的采集配置示例我逐段解釋filebeat.inputs: - type: filestream id: app-log enabled: true paths: - /var/log/myapp/*.log fields: app: myapp env: prod fields_under_root: false這里type: filestream是較新版本推薦的輸入類型老版本用的是type: log。filestream 相比 log 類型在文件輪轉(zhuǎn)處理、狀態(tài)管理上更健壯新項目建議直接用 filestream。id是這個 input 的唯一標識改了 id 會導致 registry 里的狀態(tài)對不上可能觸發(fā)重新采集所以一旦上線就不要隨便改 id。paths支持通配符可以匹配多個文件。fields是給采集到的每條日志附加自定義字段方便后續(xù)在 Kibana 里按應用或環(huán)境過濾。fields_under_root控制這些字段是放在事件根層級還是放在fields子對象下一般保持 false 就行避免和日志本身的字段沖突。接下來是輸出配置以直接發(fā) ElasticSearch 為例output.elasticsearch: hosts: [http://es-node1:9200, http://es-node2:9200] username: filebeat_writer password: your_password index: myapp-%{yyyy.MM.dd}hosts可以寫多個節(jié)點Filebeat 會自動做負載均衡和故障轉(zhuǎn)移。index定義了寫入的索引名用日期做后綴是常見做法方便按天管理索引生命周期。這里有個坑索引名里的日期格式必須用%{yyyy.MM.dd}這種寫法寫成別的格式可能不生效我踩過這個坑排查了半天才發(fā)現(xiàn)是格式問題。3.3 多行日志合并的關(guān)鍵配置前面提到 Java 異常堆棧的問題這里詳細說下 multiline 怎么配。假設(shè)你的日志長這樣2024-01-15 10:23:45 ERROR [main] com.example.Service - 處理請求失敗 java.lang.NullPointerException: null at com.example.Service.handle(Service.java:42) at com.example.Controller.doPost(Controller.java:18)如果不做處理這五行會變成五條獨立事件。我們希望以時間戳開頭的行作為新事件的開始后面不以時間戳開頭的行都追加到上一條。配置如下parsers: - multiline: type: pattern pattern: ^\d{4}-\d{2}-\d{2} negate: true match: afterpattern是正則匹配以日期開頭的行。negate: true表示“不匹配這個正則的行”match: after表示把這些行合并到上一行之后。合起來的意思就是凡是不以日期開頭的行都追加到上一條事件后面。這樣就得到了完整的一條異常日志。注意multiline 配置在 filestream 輸入里是放在parsers下的而在老的 log 輸入里是直接放在 input 下的。版本不同寫法不同升級的時候要特別注意配置寫錯位置不會報錯但就是不生效很隱蔽。4. 實操全流程與關(guān)鍵環(huán)節(jié)實現(xiàn)4.1 采集進度與 Registry 機制實操Registry 是 Filebeat 可靠性的核心但也是最容易出問題的地方。它的工作原理是Filebeat 為每個被采集的文件生成一個唯一標識記錄當前讀到的偏移量。這個標識默認是基于文件的 inode 和設(shè)備號生成的。問題就出在這里——如果文件被刪除后重建inode 變了Filebeat 會認為這是一個新文件從頭開始讀。如果你的日志是按天輪轉(zhuǎn)、每天新建文件的這沒問題但如果是原地清空文件比如 app.loginode 不變但內(nèi)容沒了Filebeat 可能會讀到一堆空內(nèi)容或者行為異常。我的建議是日志輪轉(zhuǎn)一定要用 rename 新建的方式不要用清空的方式。比如用 logrotate 配置create選項輪轉(zhuǎn)時把老文件改名然后創(chuàng)建新文件。這樣 Filebeat 能正確識別文件切換不會漏讀也不會重復讀。另外registry 文件本身如果損壞Filebeat 啟動時會報錯。遇到這種情況可以刪掉 registry 文件讓它重新采集但代價是可能重復采集歷史數(shù)據(jù)。所以生產(chǎn)環(huán)境一定要給 registry 做備份或者至少知道它在哪、怎么恢復。我一般會在 Filebeat 的配置里把path.data指向一個獨立目錄方便單獨備份。4.2 輸出到 ElasticSearch 的完整配置把日志發(fā)到 ElasticSearch 是最常見的用法但配置上有幾個細節(jié)決定了它穩(wěn)不穩(wěn)。首先是認證生產(chǎn)環(huán)境一定要開賬號密碼不要用默認的無認證模式。其次是索引模板Filebeat 首次連接 ElasticSearch 時會自動安裝一個索引模板定義字段的映射類型。如果你的日志里有自定義字段建議提前在模板里定義好類型否則 ElasticSearch 可能會把數(shù)字類型的字段猜成字符串影響后續(xù)聚合查詢。一個相對完整的輸出配置長這樣output.elasticsearch: hosts: [http://es-node1:9200, http://es-node2:9200] username: filebeat_writer password: your_password index: myapp-%{yyyy.MM.dd} bulk_max_size: 1000 worker: 2 backoff.init: 1s backoff.max: 60sbulk_max_size控制每次批量發(fā)送的事件數(shù)默認是 50對于日志量大的場景可以調(diào)大但別太大否則單次請求體過大反而容易失敗。worker是并發(fā)發(fā)送的工作協(xié)程數(shù)適當調(diào)大能提升吞吐。backoff是發(fā)送失敗后的重試退避策略從 1 秒開始最大退到 60 秒避免網(wǎng)絡(luò)抖動時瘋狂重試把 ElasticSearch 打掛。提示如果 ElasticSearch 開了 HTTPS 和證書校驗還需要配置ssl.certificate_authorities指向 CA 證書。自簽證書的場景下要么把 CA 證書配進去要么臨時關(guān)閉校驗不推薦生產(chǎn)用。4.3 用 Processors 做輕量字段處理Filebeat 的 Processors 能在發(fā)送前對事件做處理常用的有 add_fields、drop_fields、rename、decode_json_fields 等。舉個例子如果你的日志是 JSON 格式的可以用 decode_json_fields 把 JSON 里的字段展開成獨立字段processors: - decode_json_fields: fields: [message] target: overwrite_keys: true這樣原本擠在 message 字段里的 JSON 內(nèi)容會被解析出來每個 key 變成獨立字段在 Kibana 里就能直接按這些字段過濾和聚合了。overwrite_keys: true表示如果解析出的字段和已有字段重名用解析出的覆蓋。再比如你想刪掉一些敏感字段可以用 drop_fields- drop_fields: fields: [password, token] ignore_missing: trueignore_missing: true表示字段不存在時不報錯這個一定要加上否則日志里沒有這個字段時 Processor 會報錯導致事件被丟棄。我的經(jīng)驗是Processors 只做輕量處理復雜的解析和轉(zhuǎn)換留給 Logstash。Filebeat 的 Processor 能力有限正則解析、條件分支這些做起來很別扭硬要用只會讓配置變得難以維護。4.4 啟動、驗證與監(jiān)控配置寫好后啟動 Filebeat 并驗證數(shù)據(jù)是否正常流轉(zhuǎn)。啟動命令一般是systemctl start filebeat或者直接跑二進制。啟動后先看 Filebeat 自己的日志確認沒有報錯。然后去 ElasticSearch 里查一下索引有沒有創(chuàng)建、數(shù)據(jù)有沒有進來curl -u user:pass http://es-node1:9200/_cat/indices/myapp-*?v如果索引存在但數(shù)據(jù)為空大概率是采集端的問題回去檢查 paths 是否匹配到了文件、權(quán)限是否足夠。如果索引都不存在那可能是輸出配置有問題看 Filebeat 日志里的連接錯誤。Filebeat 還提供了監(jiān)控接口可以暴露自身的運行指標比如采集了多少事件、發(fā)送失敗多少次、隊列積壓多少。這些指標對于排查“為什么數(shù)據(jù)延遲”特別有用。配置里打開http.enabled: true并設(shè)置端口就能用 curl 拉取指標了。我一般會把這些指標接到監(jiān)控系統(tǒng)里設(shè)置告警一旦發(fā)送失敗率升高就及時介入。5. 常見問題排查與避坑經(jīng)驗實錄5.1 數(shù)據(jù)不采集或采集不全這是最常見的問題排查思路可以按這個順序走先確認 Filebeat 進程在跑、配置加載成功再確認 paths 匹配的文件確實存在且有讀權(quán)限然后看 registry 里有沒有這個文件的記錄偏移量是不是已經(jīng)到文件末尾了。如果偏移量到了末尾但文件還在寫說明 Filebeat 沒檢測到新內(nèi)容可能是文件系統(tǒng)的事件通知機制有問題可以調(diào)大scan_frequency或者改用輪詢模式。權(quán)限問題特別隱蔽。Filebeat 默認以 filebeat 用戶運行如果日志文件的屬主是 root 且權(quán)限是 640filebeat 用戶就讀不了。這種情況要么改文件權(quán)限要么把 Filebeat 配成以 root 運行不推薦要么把 filebeat 用戶加到日志文件的屬組里。我一般用最后一種最安全。5.2 重復采集與數(shù)據(jù)丟失重復采集通常和 registry 有關(guān)。如果 registry 文件被刪或者損壞Filebeat 會從頭采集導致重復。數(shù)據(jù)丟失則可能是發(fā)送失敗后沒有正確重試或者隊列滿了被丟棄。Filebeat 的內(nèi)存隊列默認容量有限如果下游 ElasticSearch 長時間不可用隊列滿了之后新事件會被丟棄。這種情況可以調(diào)大隊列或者配置磁盤隊列queue.spool把事件先寫到磁盤上等下游恢復再發(fā)。注意磁盤隊列雖然能防丟數(shù)據(jù)但會帶來額外的磁盤 IO 和延遲是否啟用要根據(jù)業(yè)務對數(shù)據(jù)完整性的要求來權(quán)衡。日志這種數(shù)據(jù)丟幾條通?？梢越邮艿绻婕皩徲嫽蛴嬞M那就必須開磁盤隊列。5.3 性能調(diào)優(yōu)的幾個關(guān)鍵參數(shù)Filebeat 本身很輕但在日志量極大的場景下默認配置可能扛不住。幾個關(guān)鍵調(diào)優(yōu)參數(shù)harvester_limit控制同時打開的 Harvester 數(shù)量避免文件太多時耗盡文件句柄bulk_max_size和worker影響發(fā)送吞吐scan_frequency影響新文件的發(fā)現(xiàn)速度。調(diào)優(yōu)的原則是先壓測再調(diào)參不要憑感覺改。我見過有人把 bulk_max_size 調(diào)到幾萬結(jié)果單次請求體過大被 ElasticSearch 拒絕反而更慢。下面這張表整理了幾個常見問題和對應的排查方向方便快速對照現(xiàn)象可能原因排查方向完全沒有數(shù)據(jù)配置未加載、路徑不匹配、權(quán)限不足看 Filebeat 日志、檢查 paths 和文件權(quán)限數(shù)據(jù)延遲大隊列積壓、下游慢、批量參數(shù)不合理看監(jiān)控指標、調(diào) bulk_max_size 和 worker數(shù)據(jù)重復registry 丟失或損壞檢查 registry 文件、確認文件輪轉(zhuǎn)方式多行日志被拆散multiline 未配置或正則不對檢查 parsers 配置和正則匹配字段類型錯誤索引模板未定義或自動映射猜錯提前定義模板、檢查字段映射5.4 版本升級的注意事項Filebeat 跨大版本升級時配置格式可能有變化比如前面提到的 log 到 filestream 的遷移。升級前一定要在測試環(huán)境驗證重點檢查輸入類型、multiline 配置位置、以及 registry 的兼容性。有些版本升級后 registry 格式會變回滾時可能讀不了新格式的 registry導致重新采集。所以升級前備份 registry 和配置文件這是保命的操作。另外Filebeat 和 ElasticSearch 的版本最好保持一致或者相近跨太多版本可能出現(xiàn)兼容性問題。官方文檔里有版本兼容性矩陣升級前查一下能省很多事。6. 我在實際使用中總結(jié)的幾條經(jīng)驗Filebeat 這個工具用起來簡單但要用得穩(wěn)還是得理解它背后的機制。我自己踩過的坑里最多的就是 registry 和 multiline 這兩塊。registry 決定了數(shù)據(jù)會不會重復或丟失multiline 決定了日志可讀性這兩個配置一定要在上線前反復驗證。還有一點體會是不要試圖用 Filebeat 做它不擅長的事。它就是個搬運工把日志從 A 搬到 B搬得又快又穩(wěn)就是它的全部價值。復雜的解析、富化、路由交給 Logstash 或者 ElasticSearch Ingest Node。鏈路越簡單出問題時越容易定位維護成本也越低。最后分享一個小技巧如果你不確定 multiline 正則寫得對不對可以先用filebeat test config驗證語法再找一段真實日志用在線正則工具測一下匹配結(jié)果。正則這東西差一個字符結(jié)果就完全不同測過再上線能省掉很多半夜被叫起來排查的時間。