這篇文章將更深入的去介紹 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 的原始資料
  • Wildcards 搜尋
• 透過 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 專用來達到分散流量的效果。