Posted inMonitoring

LinuxでのFluent Bit導入・設定ガイド：高パフォーマンスなログ収集、フィルタリング、LokiおよびElasticsearchへの転送

Monitoring tutorial - IT technology blog
Monitoring tutorial - IT technology blog

クイックスタート：5分で始めるFluent Bitによるログ転送

小難しい理論は後回しにして、まずは実際に手を動かし、マシン上で軽快に動作するログコレクターを立ち上げてみましょう。

1. Ubuntu / DebianへのFluent Bitのインストール

ターミナルを開き、Fluent Bit公式のインストールスクリプトを実行してリポジトリを追加し、最新パッケージをインストールします：

curl https://raw.githubusercontent.com/fluent/fluent-bit/master/install.sh | sh
sudo systemctl daemon-reload
sudo systemctl enable fluent-bit

RHEL、Rocky Linux、AlmaLinuxの場合は、以下のコマンドを実行します：

curl https://raw.githubusercontent.com/fluent/fluent-bit/master/install.sh | sh
sudo systemctl enable --now fluent-bit

2. コンソールにメトリクスを出力する最小構成の作成

デフォルトの設定ファイルは /etc/fluent-bit/fluent-bit.conf に配置されています。パイプラインの動作を素早く検証するため、以下のサンプル設定を作成します：

sudo tee /etc/fluent-bit/fluent-bit.conf << 'EOF'
[SERVICE]
    Flush         1
    Log_Level     info
    Daemon        off

[INPUT]
    Name          cpu
    Tag           my_cpu
    Interval_Sec  2

[OUTPUT]
    Name          stdout
    Match         *
EOF

3. スタンドアロンでの動作テスト

バイナリを直接実行して、ターミナルに出力されるログデータを確認します：

/opt/fluent-bit/bin/fluent-bit -c /etc/fluent-bit/fluent-bit.conf

CPUメトリクスを含むJSONデータが2秒ごとに出力されれば成功です。パイプラインは正常に開通しています。

Fluent Bitのアーキテクチャ：なぜこれほど軽量なのか？

「なぜ広く使われているLogstashやFluentdではないのか？」と疑問に思う方もいるでしょう。その決定的な違いはリソース消費量にあります。LogstashはJVM上で動作するため500MB〜1GBのRAMを消費し、Ruby製のFluentdも50〜100MB程度を必要とします。一方、純粋なC言語で書かれたFluent Bitは、毎秒数千行のログを処理しても消費メモリはわずか15〜30MB、CPU使用率も1%未満に収まります。1 vCPU・1GB RAMの格安VPSや、数千ノード規模のKubernetesクラスタにおいて、この差は致命的な優位性となります。

ログ処理パイプラインは、以下の5つのフェーズで構成されています：

  • INPUT: ログファイル（tail）、syslog、systemd journal、または各種メトリクスからデータを取得。
  • PARSER: 生テキスト（Nginx、Apacheなど）をパースし、構造化されたJSONに変換。
  • FILTER: フィールドの追加・削除、IPアドレスの抽出、不要行の除外、ホストメタデータの付与などを実行。
  • BUFFER: 転送先の一時的なダウンに備え、ログをメモリまたはディスク（ファイルシステムバッファ）に一時退避。
  • OUTPUT: Grafana Loki、Elasticsearch、OpenSearch、Kafkaなどの指定先へログを転送。

データの正確なルーティングは、TagとMatchのペアによって制御されます。INPUTブロックでTag web.nginx.accessを指定し、OUTPUTブロックでMatch web.nginx.*を定義することで、Fluent Bitがプレフィックスを自動照合して適切な宛先へ振り分けます。

実践構成：LokiとElasticsearchへの並行ルーティング

運用現場でよく採用されるのは、用途に応じたログの分岐です。リアルタイムなTail確認やGrafanaダッシュボードでの可視化にはLokiを用い、セキュリティ調査やデータ分析チームによる全文検索にはElasticsearchを活用します。

NginxアクセスログとシステムSyslogの収集

以下は、Linuxサーバーの本番運用に適した標準的な /etc/fluent-bit/fluent-bit.conf の設定例です：

[SERVICE]
    Flush         1
    Log_Level     info
    Parsers_File  parsers.conf
    Storage.path  /var/log/fluent-bit/buffer
    Storage.sync  normal
    Storage.checksum off
    Storage.backlog.mem_limit 10M

# 1. INPUT: Nginxログの読み込み
[INPUT]
    Name              tail
    Tag               web.nginx.access
    Path              /var/log/nginx/access.log
    Parser            nginx
    DB                /var/log/fluent-bit/nginx.db
    Mem_Buf_Limit     15MB
    Storage.type      filesystem

# 2. INPUT: Systemd Journal (Syslog) の読み込み
[INPUT]
    Name              systemd
    Tag               host.systemd
    Read_From_Tail    On
    Storage.type      filesystem

# 3. FILTER: ホストメタデータの付与
[FILTER]
    Name              record_modifier
    Match             *
    Record env        production
    Record cluster    vps-sg-01

# 4. OUTPUT 1: Grafana Lokiへの転送
[OUTPUT]
    Name              loki
    Match             web.nginx.*
    Host              loki-server.internal
    Port              3100
    Labels            job=fluent-bit, app=nginx, env=$env
    Auto_Kubernetes_Labels off

# 5. OUTPUT 2: Elasticsearchへの転送
[OUTPUT]
    Name              es
    Match             host.*
    Host              es-cluster.internal
    Port              9200
    Index             linux-systemd-logs
    Type              _doc
    HTTP_User         elastic
    HTTP_Passwd       SecretPassword123
    TLS               On
    TLS.verify        Off
    Retry_Limit       5

押さえておくべき3つの重要パラメータ：

  • DB /var/log/fluent-bit/nginx.db: 読み込み済みのログオフセットを軽量なSQLiteファイルに記録します。サービス再起動やOSリブート時にも前回の停止位置から再開できるため、ログの欠損や二重取り込みを防止できます。
  • Storage.type filesystem: ディスクバッファを有効化します。万が一Elasticsearchとの接続が15分間途絶えても、ログはディスクへ安全に退避され、メモリ枯渇を防ぎます。
  • Retry_Limit 5: ネットワークエラー時のリトライ上限回数を設定し、ワーカースレッドのスタックやハングアップを回避します。

本番運用で得られた最適化ノウハウ

モニタリング基盤の安定性は、適切なチューニングにかかっています。初期の運用では、Lokiバックエンドのわずか5分間のメンテナンスによりメモリバッファが溢れ、複数のサーバーでOOMアラートが多発するトラブルも経験しました。即座に適用すべき3つの実践的教訓を紹介します：

1. メモリ依存を脱却し、ディスクバッファを必須で有効化する

Fluent Bitはデフォルトでメモリ上にログをバッファリングします。転送先でネットワーク遅延が発生したりHTTP 429/503エラーが返されたりすると、メモリ消費量は瞬く間にMem_Buf_Limitの上限に達します。その結果、ログのドロップが発生するか、最悪の場合はOOM KillerによってWebサーバープロセスごと強制終了されかねません。重要なINPUTブロックでは、必ずStorage.type filesystemを設定してください。

2. ネットワーク転送前に不要なノイズログを除外する

すべてのログを無差別に送信してはいけません。AWS ALBからのヘルスチェックやKubernetesのliveness probeによる2秒ごとの/healthzリクエストは、ストレージ容量を急速に圧迫します。grepフィルタを使用して、送信元で即座に除外しましょう：

[FILTER]
    Name    grep
    Match   web.nginx.access
    Exclude log ^.*"GET /healthz.*200.*$

このシンプルなルールを適用するだけでも、クラスタへ送信される無駄なログトラフィックを毎日40〜60%削減できます。

3. リロード前にドライランで構文チェックを実施する

設定ファイルを更新した直後にsystemctl restart fluent-bitを実行するのは危険です。まずは-d（ドライラン）フラグを使って構文エラーがないかを検証します：

/opt/fluent-bit/bin/fluent-bit -c /etc/fluent-bit/fluent-bit.conf --dry-run

ターミナルにconfiguration syntax okと表示されたことを確認してから、安全にサービスをリロードしましょう：

sudo systemctl restart fluent-bit
sudo journalctl -u fluent-bit -f

パイプラインの構造とディスクバッファの仕組みを正しく理解すれば、極めて堅牢でリソース効率に優れたログシッパーを安定運用できます。

Share:
Tags: