Elastic Logging X Filebeat 深入理解 Filebeat 實際運用的細節、基礎概念及相關配置教學

Lin Yen-Cheng on 2020-09-09 9 min. read

這篇文章將更深入的去介紹 Log 與 Filebeat 在實際運用上的細節、基礎概念及相關配置教學,本篇文章將著重在 Filebeat 在收集 Log 上的運用。

  • 實體的 Log 檔提供了許多大祕寶讓我們去尋找人生的問題
  • 一筆 Log 由 timestamp 還有相關訊息組成
  • 透過 Filebeat 可以監控某個資料夾或是某個檔案
  • Filebeat 模組簡化了蒐集、解析、協助處理 Log 的格式與視覺化的難題

Log 的重要性

Log 就像是我們的好隊友,首先當然要了解隊友!!! 接下來才能夠跟隊友互相扶持共同成長,首先我們要

  • 了解隊友能協助我們解決了哪些屬性的難題
  • 能夠提供怎麼樣的解決方案
  • 透過什麼方式去解決和優化

Log 解決了商業面的問題

  • 每天有多少使用者來用教學網站?
  • Node.js 的服務慢在哪裡?
  • 上次實體活動有多少人註冊並登入?
  • 什麼時候停機升級系統比較適合?

Log 的收集與解析

Elastic Stack 能夠處理不同的系統與服務的 Log,提供了兩種收集 Log 的工具

  • filebeat: client 端處理實體 Log 檔
  • logstash: server 端才進行資料的處理

解析 Log 常見問題

  • 一致性
    • 每個程式的格式都不同,透過不同模組定義 Pattern,解析成一致的格式
  • 時間格式
    • ISO 8601 可到毫秒 (2018-10-05T14:30:00Z)
  • 分散在不同地方: Server 很多台查詢困難
    • Elastic Search 方便檢索
  • 需要負責人可能才知道位置在哪 (SSH)
    • Kibana、App Search 降低門檻

Log 在 Elastic Stack 中的生命週期

  • 資料的產生
  • Filebeat 傳送
  • 處理與儲存
    • Hot data: 常讀寫
    • Warm data: read-only 少用
  • 搜尋與分析
  • 封存資料成 Warm data
  • Purge 清除不在使用的資料

Multi-Line Processing

Log 中每筆 event 可能會有包含多行的情境,Filebeat 也有提供相關配置,透過 regular expression patterns 來找出每筆 Log 開始的地方,搭配 negate 和 match 去找出整段,這裡有線上解析器來檢查我們寫的表達式。

  • multiline.pattern: 找出每筆 Log 開始的地方
  • negate: true/false
  • match: before/after
  • multiline.flush_pattern: 標示結束
multiline.pattern: 'test'
negate: true
match: before
multiline.flush_pattern: 'test end'

[2020] test start
oxox
xoxo
oxox
[2020] test end

Filebeat 深入理解

Filebeat 提供很多預設的模組,讓實體 Log 檔無痛存到 Elasticsearch,預設的模組也提供了預設的 dashboards 非常方便,如何使用 Filebeat:

  • 下載 Filebeat 到需要監控 log 的主機
  • 配置並啟動 Filebeat
  • 用 kibana 介面看資料是否進入 Elasticsearch

Filebeat 在安裝後 module 大部分預設都是 disabled 的,需要自行啟用

  • ./filebeat modules list 可以看目前 module 的狀態
  • ./filebeat modules enable nginx 透過指令開啟模組,這裡是開啟 nginx

配置 Filebeat 需要修改 filebeat.yml

  • You can edit the yaml file to define different paths to logs
  • input 要抓哪些 log
    • ignore_older: ignore_older: 24h 預設是 0 代表 disable
    • include_lines: include_lines: ['^WARN']
    • exclude_lines: include_lines: ['^INFO']
    • exclude_files: exclude_files: ['\.gz$']
  • output 則是要要放到哪台 Elasticsearch
  • 也可以在配置中啟用模組
filebeat.modules:
  - module: nginx
  - module: mysql

接著在開始配置前,先透過指令測試我們的配置檔

./filebeat test config
./filebeat test output
./filebeat test -c custom.yml output

執行以下指令配置 Filebeat,目的是確認 Elasticsearch 跟 kibana 是否可以連線,只需要跑一次即可

./filebeat setup

不幸需要 debug 的話
./filebeat -e -d "publish"

Filebeat Resilience and Recovery

Filebeat 會自動幫我們確認新檔案,並且在傳送資料時會使用偵測背壓 (backpressure) 的協定,當 Logstash 或是 Elasticsearch 告知壓力過大,Filebeat 會自動減速,也有相關配置可以依照系統效能和需求去設定:

  • scan_frequency: 預設掃描新檔案頻率是十秒一次,最低建議不要低於一秒
  • back_off: 預設是一秒後再掃一次,如果 Filebeat 過於忙碌就會減少頻率
    • 達到 EOF 時 back_off 就照 backoff_factor 的值 (預設 2 倍) 去增加 back_off 時間
    • 直到達到 max_backoff 就是長的等待秒數
    • 只要有偵測到文件有新的變化就會重置

Filebeat 所有的資訊都透過 registry 來儲存現在的狀態,如果當機也會從這裡儲存的狀態恢復,存放的位置會在:

  • var/lib/filebeat/registry
  • C:\ProgramData\filebeat\registry

如果發現 registry 檔案太大可以透過以下配置來改善:

clean_inactive
clean_removed

Log X Elasticsearch

Elasticsearch 都是用 Index 來儲存的,Filebeat 預設是使用 ILM (Index Lifecycle Management),ILM 的概念如下

  • ‒{type}beat-{agent.version}-{yyyy-MM-dd}-000001
  • 當硬碟空間或資料數量達到設定上限時,用新的取代最舊的
  • 可以用天、周、月當單位來創建 Index 並封存前一個
  • 方便刪掉過舊的資料

確認資料是不是有進到 Elasticsearch:

  • 用 Dev Tool Console 透過 REST API 去看進入 Elasticsearch 的原始資料
  • 透過 Kibana 分析資料,需定義 index pattern 讓 kibana 能夠視覺化 (ILM)
    • filebeat-*

透過 Kibana 查看 dashboards

  • 確認 Elasticsearch 及 Kibana 正在運行
  • Filebeat 配置確認:
    • Elasticsearch 位置有設定在 output
    • 確認 Kibana URL
  • 執行指令 ./filebeat setup --dashboards
  • 內建模組 Kibana 可以直接查看內建的 dashboards

Log 如果搭配 Metrics、APM 會更容易評估系統和服務,但很可能因此資料量過大,這時 Elasticsearch 可以無痛的按照用途分成不同的 cluster,像是分成監控專用、APM 專用來達到分散流量的效果。


喜歡這篇文章,請幫忙拍拍手喔 🤣

share