Skip to content
Published on

Fluent Bit完全ガイド:軽量ログプロセッサのアーキテクチャ、設定、Kubernetes連携を総まとめ

Authors
  • Name
    Twitter

1. Fluent Bit入門

1.1 Fluent Bitとは?

Fluent BitはC言語で書かれた超軽量テレメトリエージェントであり、様々なソースからログ(Logs)メトリクス(Metrics)トレース(Traces)を収集し、処理した後、目的の宛先に配信する役割を担う。バイナリサイズ約450KB、メモリ使用量1MB未満という極めて軽量なフットプリントを誇り、組み込みシステムから大規模Kubernetesクラスターまで幅広く活用されている。

Fluent BitはCNCF(Cloud Native Computing Foundation)Graduatedプロジェクトであり、Kubernetes、Prometheus、Envoyなどと同レベルの成熟度を認められている。Fluentdプロジェクトの傘下で2019年にGraduatedステータスを獲得し、2024年時点でDockerHubから130億回以上ダウンロードされ、クラウドネイティブのログ収集における事実上の標準として定着している。

2024年3月のKubeCon + CloudNativeCon EUでFluent Bit v3が発表され、同年12月にv3.2、2025年3月にはv4.0がリリースされ、YAML標準設定、Processorサポート、SIMDベースのJSONエンコーディング(2.5倍の性能向上)、OpenTelemetry強化など、継続的に進化を続けている。

1.2 主な特徴

  • 超軽量:Cベース、約450KBバイナリ、1MB未満のメモリ使用
  • 高性能:非同期I/O、マルチスレッドパイプライン、SIMD最適化
  • プラグインアーキテクチャ:100以上のInput/Filter/Outputプラグイン
  • 統合テレメトリ:Logs、Metrics、Tracesを単一エージェントで処理
  • YAMLネイティブ:v3.2からYAMLが標準設定フォーマット
  • Hot Reload:サービス中断なしに設定再読み込み(SIGHUP / HTTP API)
  • クロスプラットフォーム:Linux、macOS、Windows、BSD、組み込みLinuxに対応

1.3 Fluent Bit vs Fluentd比較

項目Fluent BitFluentd
開発言語CRuby + C
バイナリサイズ約450KB約40MB
メモリ使用量約1MB約30-40MB
プラグイン数100以上(内蔵)1,000以上(gem含む)
性能(スループット)非常に高い高い
CPU使用量低いFluent Bitの約4倍
設定形式INI / YAMLRuby DSL
主な用途エッジ/ノードレベルの収集・転送中央集約型ログ集約
KubernetesDaemonSetでノード別デプロイAggregatorとして中央デプロイ
CNCFステータスGraduated(Fluentd傘下)Graduated
適した環境IoT、コンテナ、エッジ大規模集約、複雑なルーティング

一般的な推奨アーキテクチャ:Fluent Bitを各ノードにDaemonSetとしてデプロイしてログを収集し、必要に応じて中央のFluentd Aggregatorに転送するハイブリッドパターンが最も広く使われている。ただし、Fluent Bitの機能が着実に強化されており、Fluentdなしで Fluent Bitのみで全パイプラインを構成するケースも急速に増えている。

1.4 アーキテクチャ概要

+------------------------------------------------------------------+
|                        Fluent Bit Engine                         |
|                                                                  |
|  +--------+   +--------+   +--------+   +--------+   +--------+ |
|  | Input  |-->| Parser |-->| Filter |-->| Buffer |-->| Output | |
|  +--------+   +--------+   +--------+   +--------+   +--------+ |
|  | tail   |   | json   |   | k8s    |   | memory |   | es     | |
|  | systemd|   | regex  |   | grep   |   | filesys|   | loki   | |
|  | forward|   | logfmt |   | modify |   |        |   | s3     | |
|  | http   |   | cri    |   | lua    |   |        |   | kafka  | |
|  | tcp    |   | docker |   | nest   |   |        |   | stdout | |
|  +--------+   +--------+   +--------+   +--------+   +--------+ |
|                                                                  |
|  [Scheduler]  [Router / Tag Matching]  [HTTP Server / Monitoring]|
+------------------------------------------------------------------+

Fluent Bitのデータ処理は**パイプライン(Pipeline)**構造に従い、各段階が明確に分離されている。この構造のおかげで、モジュールごとの独立した拡張と交換が可能となっている。


2. コアアーキテクチャ:パイプライン構造

2.1 パイプライン全体の流れ

Fluent Bitのデータ処理パイプラインは以下の段階で構成されている。

  [Data Source]
       |
       v
  +---------+     +---------+     +---------+     +---------+     +---------+
  |  INPUT  | --> | PARSER  | --> | FILTER  | --> | BUFFER  | --> | OUTPUT  |
  |         |     |         |     |         |     |         |     |         |
  | データ   |     | 非構造化 |     | データ   |     | メモリ/  |     | 最終    |
  | 収集     |     | -> 構造化|     | 加工     |     | ディスク |     | 配信    |
  +---------+     +---------+     +---------+     +---------+     +---------+
       |               |               |               |               |
    Tag付与        構造化変換       enrichment      安定性確保     宛先送信
                                   フィルタリング                  (Tag照合)

2.2 各段階の役割

Input(入力)

データのエントリポイントである。ファイル、システムジャーナル、ネットワークソケット、Kubernetesイベントなど、様々なソースからデータを収集する。すべての入力データにはTagが付与され、このTagは後続のルーティングに使用される。

Parser(パーサー)

非構造化(unstructured)テキストデータを構造化(structured)データに変換する。JSON、正規表現(Regex)、Logfmt、Docker、CRIなど、様々なパーサーを提供しており、Inputプラグインの段階で適用される。

Filter(フィルター)

収集されたデータを加工する段階である。フィールドの追加/削除、Kubernetesメタデータのenrichment、正規表現ベースのフィルタリング、Luaスクリプト変換などを実行する。複数のFilterをチェイニングして複雑な変換ロジックを構成できる。

Buffer(バッファ)

Filterを通過したデータは、Outputへ配信される前にバッファに格納される。メモリバッファファイルシステムバッファの2種類の方式をサポートしており、ファイルシステムバッファを使用すれば障害発生時にもデータ損失を防止できる。

Router(ルーター)

Tag照合ルールに従って、データを適切なOutputにルーティングする。ワイルドカード(*)照合をサポートしており、1つの入力を複数のOutputに同時に配信(fan-out)できる。

Output(出力)

最終的な宛先にデータを送信する。Elasticsearch、Loki、S3、Kafka、CloudWatch、Prometheusなど、様々なバックエンドをサポートする。送信失敗時には自動リトライ(Retry)メカニズムが作動する。

2.3 マルチパイプライン構造

Fluent Bitは単一インスタンスで複数の独立したパイプラインを同時に運用できる。各パイプラインは固有のInput、Filter、Outputの組み合わせを持ち、Tagベースのルーティングで異なるデータフローを分離する。

Pipeline A: [tail: app-*.log] --tag:app--> [filter:k8s] --> [output:elasticsearch]
Pipeline B: [tail: sys-*.log] --tag:sys--> [filter:grep] --> [output:loki]
Pipeline C: [forward:24224]   --tag:fwd--> [filter:lua]  --> [output:s3]

この構造は以下の利点を提供する。

  • 分離性:パイプライン間の独立した動作により障害の伝搬を防止
  • 柔軟性:用途別に異なる処理ロジックと宛先を指定
  • 効率性:単一エージェントで多様なデータフローを処理

3. インストール方法

3.1 Linux(apt/yum)

Ubuntu/Debian(apt)

# GPGキーおよびリポジトリ追加
curl https://raw.githubusercontent.com/fluent/fluent-bit/master/install.sh | sh

# または手動インストール
wget -qO - https://packages.fluentbit.io/fluentbit.key | sudo apt-key add -
echo "deb https://packages.fluentbit.io/ubuntu/$(lsb_release -cs) $(lsb_release -cs) main" | \
  sudo tee /etc/apt/sources.list.d/fluent-bit.list

sudo apt-get update
sudo apt-get install -y fluent-bit

# サービス起動
sudo systemctl start fluent-bit
sudo systemctl enable fluent-bit

CentOS/RHEL(yum)

cat > /etc/yum.repos.d/fluent-bit.repo << 'EOF'
[fluent-bit]
name=Fluent Bit
baseurl=https://packages.fluentbit.io/centos/$releasever/
gpgcheck=1
gpgkey=https://packages.fluentbit.io/fluentbit.key
enabled=1
EOF

sudo yum install -y fluent-bit
sudo systemctl start fluent-bit
sudo systemctl enable fluent-bit

3.2 Docker

# 最新バージョンの実行
docker run -ti cr.fluentbit.io/fluent/fluent-bit:latest

# 設定ファイルのマウント
docker run -ti \
  -v /path/to/fluent-bit.yaml:/fluent-bit/etc/fluent-bit.yaml \
  -v /var/log:/var/log \
  cr.fluentbit.io/fluent/fluent-bit:latest \
  /fluent-bit/bin/fluent-bit -c /fluent-bit/etc/fluent-bit.yaml

# Docker Composeの例
cat > docker-compose.yaml << 'EOF'
version: '3.8'
services:
  fluent-bit:
    image: cr.fluentbit.io/fluent/fluent-bit:latest
    volumes:
      - ./fluent-bit.yaml:/fluent-bit/etc/fluent-bit.yaml
      - /var/log:/var/log:ro
    ports:
      - "2020:2020"   # HTTPモニタリング
      - "24224:24224"  # Forwardプロトコル
EOF

3.3 macOS(Homebrew)

brew install fluent-bit

# 実行
fluent-bit -c /opt/homebrew/etc/fluent-bit/fluent-bit.conf

# またはYAML設定ファイルで実行
fluent-bit -c /path/to/fluent-bit.yaml

3.4 Kubernetes(Helm Chart)

# Helmリポジトリ追加
helm repo add fluent https://fluent.github.io/helm-charts
helm repo update

# 基本インストール
helm install fluent-bit fluent/fluent-bit \
  --namespace logging \
  --create-namespace

# values.yamlカスタマイズでインストール
helm install fluent-bit fluent/fluent-bit \
  --namespace logging \
  --create-namespace \
  -f custom-values.yaml

# アップグレード
helm upgrade fluent-bit fluent/fluent-bit \
  --namespace logging \
  -f custom-values.yaml

3.5 バイナリ直接インストール

# GitHub Releasesからバイナリをダウンロード
FLUENT_BIT_VERSION=3.2.2
wget https://github.com/fluent/fluent-bit/releases/download/v${FLUENT_BIT_VERSION}/fluent-bit-${FLUENT_BIT_VERSION}-linux-x86_64.tar.gz

tar xzf fluent-bit-${FLUENT_BIT_VERSION}-linux-x86_64.tar.gz
cd fluent-bit-${FLUENT_BIT_VERSION}-linux-x86_64/

# 実行
./bin/fluent-bit -c conf/fluent-bit.yaml

# バージョン確認
./bin/fluent-bit --version

4. 設定ファイル構造

Fluent BitはClassicモード(INI形式)YAMLモードの2種類の設定形式をサポートしている。v3.2からYAMLが標準設定フォーマットであり、Classicモードは2025年末にdeprecated予定である。

4.1 Classicモード(fluent-bit.conf)

# fluent-bit.conf - Classic INI形式

[SERVICE]
    Flush         5
    Daemon        Off
    Log_Level     info
    Parsers_File  parsers.conf
    HTTP_Server   On
    HTTP_Listen   0.0.0.0
    HTTP_Port     2020
    Hot_Reload    On

[INPUT]
    Name          tail
    Path          /var/log/containers/*.log
    Parser        cri
    Tag           kube.*
    Mem_Buf_Limit 5MB
    Skip_Long_Lines On
    Refresh_Interval 10
    DB            /var/log/flb_kube.db

[FILTER]
    Name          kubernetes
    Match         kube.*
    Kube_URL      https://kubernetes.default.svc:443
    Kube_CA_File  /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    Kube_Token_File /var/run/secrets/kubernetes.io/serviceaccount/token
    Merge_Log     On
    K8S-Logging.Parser On
    K8S-Logging.Exclude On

[OUTPUT]
    Name          es
    Match         kube.*
    Host          elasticsearch.logging.svc.cluster.local
    Port          9200
    Logstash_Format On
    Logstash_Prefix kube
    Retry_Limit   False

4.2 YAMLモード(fluent-bit.yaml)

# fluent-bit.yaml - YAML形式(v3.2+標準)
service:
  flush: 5
  daemon: off
  log_level: info
  parsers_file: parsers.conf
  http_server: on
  http_listen: 0.0.0.0
  http_port: 2020
  hot_reload: on

pipeline:
  inputs:
    - name: tail
      path: /var/log/containers/*.log
      parser: cri
      tag: kube.*
      mem_buf_limit: 5MB
      skip_long_lines: on
      refresh_interval: 10
      db: /var/log/flb_kube.db

  filters:
    - name: kubernetes
      match: kube.*
      kube_url: https://kubernetes.default.svc:443
      kube_ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      kube_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      merge_log: on
      k8s-logging.parser: on
      k8s-logging.exclude: on

  outputs:
    - name: es
      match: kube.*
      host: elasticsearch.logging.svc.cluster.local
      port: 9200
      logstash_format: on
      logstash_prefix: kube
      retry_limit: false

4.3 2つの形式の比較

項目Classic(INI)YAML
ファイル拡張子.conf.yaml / .yml
ステータスDeprecated予定(2025年末)標準(v3.2+)
Processorサポート未対応対応
可読性普通優秀
ネスト構造制限的完全対応
配列/リスト未対応対応
コメント##

4.4 環境変数の使用

両方の形式とも${ENV_VAR}構文で環境変数を参照できる。

# YAML環境変数の例
pipeline:
  outputs:
    - name: es
      match: '*'
      host: ${ELASTICSEARCH_HOST}
      port: ${ELASTICSEARCH_PORT}
      http_user: ${ES_USER}
      http_passwd: ${ES_PASSWORD}
      tls: ${ES_TLS_ENABLED}
# Classic環境変数の例
[OUTPUT]
    Name          es
    Match         *
    Host          ${ELASTICSEARCH_HOST}
    Port          ${ELASTICSEARCH_PORT}
    HTTP_User     ${ES_USER}
    HTTP_Passwd   ${ES_PASSWORD}

v4.0からはfile://プレフィックスを使用して、ファイルシステムからシークレット値を安全に参照できる。

pipeline:
  outputs:
    - name: es
      http_passwd: file:///run/secrets/es-password

4.5 @INCLUDEディレクティブ

設定ファイルをモジュール化して管理できる。

# fluent-bit.conf(Classic)
[SERVICE]
    Flush 5

@INCLUDE inputs.conf
@INCLUDE filters.conf
@INCLUDE outputs.conf

YAMLではincludesセクションを活用する。

# fluent-bit.yaml
includes:
  - inputs.yaml
  - filters.yaml
  - outputs.yaml

service:
  flush: 5

5. Inputプラグイン詳細

Inputプラグインはデータ収集の起点である。各Inputには固有のTagが付与され、以降のFilterとOutputのマッチング基準となる。

5.1 tail:ファイルログ収集

最も多く使用されるInputプラグインで、tail -fのようにファイルの末尾から新しい行をリアルタイムで読み取る。

pipeline:
  inputs:
    - name: tail
      tag: app.logs
      path: /var/log/app/*.log
      path_key: filename # ファイルパスをレコードに含める
      exclude_path: /var/log/app/debug.log # 特定ファイルを除外
      parser: json # デフォルトパーサー
      db: /var/log/flb_app.db # offset保存DB(再起動時に続きから収集)
      db.sync: normal # DB同期モード
      refresh_interval: 10 # ファイルリスト更新周期(秒)
      read_from_head: false # true: ファイル先頭から読み取り
      skip_long_lines: on # 非常に長い行をスキップ
      mem_buf_limit: 5MB # メモリバッファ上限
      rotate_wait: 5 # ローテーション待ち時間(秒)
      multiline.parser: docker, cri # マルチラインパーサー

主要設定項目の説明

設定デフォルト説明
Path(必須)ログファイルパス(ワイルドカード対応)
Path_Key-ファイルパスをレコードにキーとして追加
Exclude_Path-除外するファイルパス
DB-ファイルoffset保存SQLite DBパス
Refresh_Interval60ファイルリスト更新周期(秒)
Read_from_Headfalseファイル先頭から読むかどうか
Skip_Long_LinesOffBuffer_Max_Sizeを超える行をスキップ
Mem_Buf_Limit-メモリバッファ上限
Rotate_Wait5ログローテーション後の待ち時間

5.2 systemd:systemd journal収集

pipeline:
  inputs:
    - name: systemd
      tag: host.systemd
      systemd_filter: _SYSTEMD_UNIT=docker.service
      systemd_filter: _SYSTEMD_UNIT=kubelet.service
      read_from_tail: on
      strip_underscores: on
      db: /var/log/flb_systemd.db

5.3 forward:Fluentdプロトコル受信

pipeline:
  inputs:
    - name: forward
      tag: forward.incoming
      listen: 0.0.0.0
      port: 24224
      buffer_chunk_size: 1M
      buffer_max_size: 6M

5.4 http / tcp / udp:ネットワーク受信

pipeline:
  inputs:
    # HTTP受信
    - name: http
      tag: http.logs
      listen: 0.0.0.0
      port: 9880
      successful_response_code: 201

    # TCP受信
    - name: tcp
      tag: tcp.logs
      listen: 0.0.0.0
      port: 5170
      format: json

    # UDP受信
    - name: udp
      tag: udp.logs
      listen: 0.0.0.0
      port: 5170
      format: json

5.5 kubernetes_events:K8sイベント収集

pipeline:
  inputs:
    - name: kubernetes_events
      tag: kube.events
      kube_url: https://kubernetes.default.svc:443
      kube_ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      kube_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      interval_sec: 1
      retention_time: 1h

5.6 node_exporter_metrics / prometheus_scrape

pipeline:
  inputs:
    # ノードメトリクス収集
    - name: node_exporter_metrics
      tag: node.metrics
      scrape_interval: 30

    # Prometheusエンドポイントスクレイピング
    - name: prometheus_scrape
      tag: prom.metrics
      host: 127.0.0.1
      port: 9090
      metrics_path: /metrics
      scrape_interval: 10s

5.7 fluentbit_metrics:内部メトリクス

pipeline:
  inputs:
    - name: fluentbit_metrics
      tag: fb.metrics
      scrape_interval: 30
      scrape_on_start: true

6. Parser設定

Parserは非構造化テキストログを構造化データに変換するコアコンポーネントである。別途parsers.confまたはYAMLファイルに定義する。

6.1 内蔵パーサー

Fluent Bitはよく使われるログ形式に対する内蔵パーサーを提供している。

パーサー形式用途
jsonJSONJSON形式のログ
dockerJSON(Docker特化)Dockerコンテナログ
cri正規表現CRI(containerd)ログ
syslog-rfc5424正規表現RFC 5424 Syslog
syslog-rfc3164正規表現RFC 3164 Syslog
apache正規表現Apacheアクセスログ
nginx正規表現Nginxアクセスログ
logfmtLogfmtkey=valueペア形式

6.2 カスタム正規表現パーサーの作成

# parsers.conf

# Nginxエラーログパーサー
[PARSER]
    Name        nginx_error
    Format      regex
    Regex       ^(?<time>\d{4}/\d{2}/\d{2} \d{2}:\d{2}:\d{2}) \[(?<level>\w+)\] (?<pid>\d+).(?<tid>\d+): (?<message>.*)$
    Time_Key    time
    Time_Format %Y/%m/%d %H:%M:%S

# Spring Bootログパーサー
[PARSER]
    Name        spring_boot
    Format      regex
    Regex       ^(?<time>\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d+)\s+(?<level>\w+)\s+(?<pid>\d+)\s+---\s+\[(?<thread>[^\]]+)\]\s+(?<logger>\S+)\s+:\s+(?<message>.*)$
    Time_Key    time
    Time_Format %Y-%m-%dT%H:%M:%S.%L

# Apache Combinedログパーサー
[PARSER]
    Name        apache_combined
    Format      regex
    Regex       ^(?<remote>[^ ]*) (?<host>[^ ]*) (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$
    Time_Key    time
    Time_Format %d/%b/%Y:%H:%M:%S %z

YAML形式でも同様に定義できる。

# parsers.yaml
parsers:
  - name: nginx_error
    format: regex
    regex: '^(?<time>\d{4}/\d{2}/\d{2} \d{2}:\d{2}:\d{2}) \[(?<level>\w+)\] (?<pid>\d+).(?<tid>\d+): (?<message>.*)$'
    time_key: time
    time_format: '%Y/%m/%d %H:%M:%S'

  - name: spring_boot
    format: regex
    regex: '^(?<time>\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d+)\s+(?<level>\w+)\s+(?<pid>\d+)\s+---\s+\[(?<thread>[^\]]+)\]\s+(?<logger>\S+)\s+:\s+(?<message>.*)$'
    time_key: time
    time_format: '%Y-%m-%dT%H:%M:%S.%L'

6.3 マルチラインパーサー

Java Stack Traceのように複数行にまたがるログを1つのレコードに結合する。

# マルチラインパーサー定義
[MULTILINE_PARSER]
    Name          java_stacktrace
    Type          regex
    Flush_Timeout 1000
    # 先頭行パターン:タイムスタンプで開始
    Rule          "start_state"  "/^\d{4}-\d{2}-\d{2}/"  "cont"
    # 継続行パターン:空白またはCaused byで開始
    Rule          "cont"         "/^\s+|^Caused by:/"      "cont"

[MULTILINE_PARSER]
    Name          python_traceback
    Type          regex
    Flush_Timeout 1000
    Rule          "start_state"  "/^Traceback/"            "python_tb"
    Rule          "python_tb"    "/^\s+/"                   "python_tb"
    Rule          "python_tb"    "/^\w+Error/"              "end"

Inputでマルチラインパーサーを適用する方法は以下の通りである。

pipeline:
  inputs:
    - name: tail
      tag: app.java
      path: /var/log/app/application.log
      multiline.parser: java_stacktrace
      read_from_head: true

6.4 Time_KeyとTime_Format

ログメッセージからタイムスタンプを抽出して、レコードの時間として使用する。

[PARSER]
    Name        custom_time
    Format      regex
    Regex       ^(?<time>[^ ]+) (?<message>.*)$
    Time_Key    time
    Time_Format %Y-%m-%dT%H:%M:%S.%LZ
    Time_Keep   On    # 変換後もtimeフィールドを保持
    Time_Offset +0900  # JSTタイムゾーン

6.5 パーサーのテストとデバッグ

パーサーの動作を検証する最も簡単な方法はstdout Outputを使用することである。

# パーサーテスト用設定
service:
  flush: 1
  log_level: debug

pipeline:
  inputs:
    - name: tail
      tag: test
      path: /tmp/test.log
      parser: my_custom_parser

  outputs:
    - name: stdout
      match: test
      format: json_lines
# テストログの作成と確認
echo '2026-03-01T12:00:00.000Z ERROR [main] App - Connection failed' >> /tmp/test.log
fluent-bit -c test.yaml

7. Filterプラグイン詳細

Filterプラグインは、収集されたデータを加工する中間段階である。複数のFilterを順次チェイニングして、複雑な変換パイプラインを構成できる。

7.1 kubernetes:Podメタデータenrichment

Kubernetes環境で最も重要なフィルターで、コンテナログにPod名、Namespace、Labels、Annotationsなどのメタデータを自動的に追加する。

pipeline:
  filters:
    - name: kubernetes
      match: kube.*
      kube_url: https://kubernetes.default.svc:443
      kube_ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      kube_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      merge_log: on # JSONログをトップレベルにマージ
      merge_log_key: log_parsed # マージキー名
      keep_log: off # 元のlogフィールドを削除
      k8s-logging.parser: on # Podアノテーションのパーサー設定を使用
      k8s-logging.exclude: on # Podアノテーションでログ除外
      labels: on # Pod Labelsを含める
      annotations: off # Pod Annotationsを含めるかどうか
      buffer_size: 0 # APIレスポンスバッファ(0=無制限)
      kube_meta_cache_ttl: 300 # メタデータキャッシュTTL(秒)
      use_kubelet: false # kubelet APIを使用するかどうか

enrichment後のレコード構造例は以下の通りである。

{
  "log": "Connection established to database",
  "kubernetes": {
    "pod_name": "api-server-7d4b8c6f5-x2k9j",
    "namespace_name": "production",
    "pod_id": "abc-123-def",
    "container_name": "api-server",
    "container_image": "myregistry/api-server:v2.1.0",
    "labels": {
      "app": "api-server",
      "version": "v2.1.0",
      "team": "backend"
    },
    "host": "node-01"
  }
}

7.2 modify:フィールドの追加/削除/リネーム

pipeline:
  filters:
    - name: modify
      match: "*"
      # フィールド追加
      add: environment production
      add: cluster_name main-cluster
      # フィールドリネーム
      rename: log message
      rename: stream source
      # フィールド削除
      remove: unwanted_field
      # 条件付きフィールド追加(キーが存在しない場合のみ)
      set: default_level INFO
      # ハードコピー
      copy: source source_backup

7.3 grep:正規表現ベースのフィルタリング

特定のパターンにマッチするレコードのみを通過させたり除外できる。

pipeline:
  filters:
    # ERRORまたはWARNレベルのみ通過
    - name: grep
      match: app.*
      regex: level (ERROR|WARN)

    # healthcheckパスを除外
    - name: grep
      match: access.*
      exclude: path /health

    # 特定のNamespaceのみ通過
    - name: grep
      match: kube.*
      regex: $kubernetes['namespace_name'] ^(production|staging)$

    # 複数条件の組み合わせ(AND)
    - name: grep
      match: app.*
      regex: level ERROR
      regex: message .*timeout.*

7.4 record_modifier:レコード変更

pipeline:
  filters:
    - name: record_modifier
      match: "*"
      record: hostname ${HOSTNAME}
      record: service_name my-application
      remove_key: unnecessary_field
      allowlist_key: timestamp
      allowlist_key: level
      allowlist_key: message

7.5 nest:ネスト構造の変換

フラット構造をネスト構造に変換、またはその逆を行う。

pipeline:
  filters:
    # ネスト(Nest):フラット -> ネスト
    - name: nest
      match: '*'
      operation: nest
      wildcard: 'app_*'
      nest_under: application
      # app_name, app_version -> application: { name, version }

    # 解除(Lift):ネスト -> フラット
    - name: nest
      match: '*'
      operation: lift
      nested_under: kubernetes
      # kubernetes: { pod_name, namespace } -> pod_name, namespace

7.6 lua:Luaスクリプトベースのカスタム変換

最も柔軟な変換方法で、Luaスクリプトで複雑なロジックを実装できる。

pipeline:
  filters:
    - name: lua
      match: app.*
      script: /fluent-bit/scripts/transform.lua
      call: process_log
-- /fluent-bit/scripts/transform.lua

function process_log(tag, timestamp, record)
    -- ログレベルの正規化
    if record["level"] then
        record["level"] = string.upper(record["level"])
    end

    -- 機密情報のマスキング
    if record["message"] then
        record["message"] = string.gsub(
            record["message"],
            "%d%d%d%d%-%d%d%d%d%-%d%d%d%d%-%d%d%d%d",
            "****-****-****-****"
        )
    end

    -- レスポンス時間に基づくグレード追加
    if record["response_time"] then
        local rt = tonumber(record["response_time"])
        if rt > 5000 then
            record["performance"] = "critical"
        elseif rt > 1000 then
            record["performance"] = "slow"
        else
            record["performance"] = "normal"
        end
    end

    -- タイムスタンプフィールド追加
    record["processed_at"] = os.date("!%Y-%m-%dT%H:%M:%SZ")

    -- 2 = MODIFIED
    return 2, timestamp, record
end

Luaコールバック関数の戻り値は以下の通りである。

コード意味
-1レコード削除(Drop)
0元を維持(Keep)
1タイムスタンプのみ変更
2レコード変更(Modified)

7.7 rewrite_tag:タグベースのルーティング変更

レコードの内容に応じてTagを動的に変更し、別のOutputにルーティングできる。

pipeline:
  filters:
    - name: rewrite_tag
      match: kube.*
      rule: $kubernetes['namespace_name'] ^(production)$ prod.$TAG false
      rule: $kubernetes['namespace_name'] ^(staging)$    stg.$TAG  false
      rule: $level                        ^(ERROR)$      alert.$TAG false

Rule構文rule: $KEY REGEX NEW_TAG KEEP_ORIGINAL

  • $KEY:マッチ対象のフィールド
  • REGEX:正規表現パターン
  • NEW_TAG:新しいTag
  • KEEP_ORIGINAL:元も維持するかどうか(true/false)

7.8 throttle:ログ速度制限

過度なログ生成を制限してシステムを保護する。

pipeline:
  filters:
    - name: throttle
      match: app.*
      rate: 1000 # ウィンドウあたりの許容量
      window: 5 # ウィンドウサイズ(秒)
      interval: 1s # 評価周期
      print_status: true # ステータス出力

7.9 multiline:マルチラインログの結合

Filter段階でマルチラインログを結合する方式である(Inputのmultiline.parserとは別)。

pipeline:
  filters:
    - name: multiline
      match: app.*
      multiline.parser: java_stacktrace
      multiline.key_content: log

8. Outputプラグイン詳細

Outputプラグインは、処理されたデータを最終的な宛先に送信する。1つのFluent Bitインスタンスで複数のOutputを同時に使用できる。

8.1 elasticsearch / opensearch

pipeline:
  outputs:
    # Elasticsearch
    - name: es
      match: kube.*
      host: ${ES_HOST}
      port: 9200
      index: logs
      type: _doc
      http_user: ${ES_USER}
      http_passwd: ${ES_PASSWORD}
      logstash_format: on
      logstash_prefix: kube-logs
      logstash_dateformat: %Y.%m.%d
      time_key: '@timestamp'
      include_tag_key: true
      tag_key: fluentbit_tag
      generate_id: on # 重複防止ID生成
      buffer_size: 512KB
      tls: on
      tls.verify: on
      tls.ca_file: /certs/ca.pem
      retry_limit: 5
      workers: 2
      suppress_type_name: on # ES 8.x互換

    # OpenSearch
    - name: opensearch
      match: app.*
      host: opensearch.logging.svc
      port: 9200
      index: app-logs
      http_user: admin
      http_passwd: ${OPENSEARCH_PASSWORD}
      tls: on
      suppress_type_name: on
      trace_output: off

主要設定項目

設定デフォルト説明
Host127.0.0.1Elasticsearchホスト
Port9200ポート番号
Indexfluent-bitインデックス名
Logstash_FormatOff日付ベースのインデックスを使用
Logstash_Prefixlogstashインデックスプレフィックス
HTTP_User-Basic Auth ユーザー
HTTP_Passwd-Basic Auth パスワード
TLSOffTLS有効化
Generate_IDOffドキュメントID自動生成
Workers0並列Worker数
Retry_Limit1リトライ回数(False=無限)
Suppress_Type_NameOffES 8.x _type無効化

8.2 loki:Grafana Loki連携

pipeline:
  outputs:
    - name: loki
      match: kube.*
      host: loki-gateway.logging.svc
      port: 3100
      uri: /loki/api/v1/push
      tenant_id: my-tenant
      labels: job=fluent-bit
      label_keys: $kubernetes['namespace_name'],$kubernetes['pod_name'],$kubernetes['container_name']
      label_map_path: /fluent-bit/etc/loki-labelmap.json
      remove_keys: kubernetes,stream
      auto_kubernetes_labels: on
      line_format: json
      drop_single_key: on
      http_user: ${LOKI_USER}
      http_passwd: ${LOKI_PASSWORD}
      tls: on
      tls.verify: on
      workers: 2

Loki Label Mapファイルの例

{
  "kubernetes": {
    "namespace_name": "namespace",
    "pod_name": "pod",
    "container_name": "container",
    "labels": {
      "app": "app"
    }
  },
  "stream": "stream"
}

8.3 s3:AWS S3保存

pipeline:
  outputs:
    - name: s3
      match: archive.*
      region: ap-northeast-2
      bucket: my-log-bucket
      s3_key_format: /logs/$TAG/%Y/%m/%d/%H/$UUID.gz
      s3_key_format_tag_delimiters: .
      total_file_size: 50M # このサイズに到達したらアップロード
      upload_timeout: 10m # サイズ未達でもこの時間後にアップロード
      use_put_object: on
      compression: gzip
      content_type: application/gzip
      store_dir: /tmp/fluent-bit-s3 # ローカルバッファディレクトリ
      store_dir_limit_size: 512M
      retry_limit: 5
      # IAMロール使用時(IRSA / EKS Pod Identity)
      role_arn: arn:aws:iam::123456789012:role/fluent-bit-s3
      # 静的認証情報(非推奨)
      # endpoint:
      # sts_endpoint:

8.4 kafka:Kafka連携

pipeline:
  outputs:
    - name: kafka
      match: app.*
      brokers: kafka-0:9092,kafka-1:9092,kafka-2:9092
      topics: application-logs
      timestamp_key: '@timestamp'
      timestamp_format: iso8601
      format: json
      message_key: log
      queue_full_retries: 10
      rdkafka.request.required.acks: 1
      rdkafka.log.connection.close: false
      rdkafka.compression.codec: snappy

8.5 cloudwatch_logs:AWS CloudWatch

pipeline:
  outputs:
    - name: cloudwatch_logs
      match: kube.*
      region: ap-northeast-2
      log_group_name: /eks/my-cluster/containers
      log_group_template: /eks/my-cluster/$kubernetes['namespace_name']
      log_stream_prefix: from-fluent-bit-
      log_stream_template: $kubernetes['pod_name']
      auto_create_group: on
      extra_user_agent: fluent-bit
      retry_limit: 5
      workers: 1

8.6 stdout:デバッグ用標準出力

pipeline:
  outputs:
    - name: stdout
      match: '*'
      format: json_lines # json_lines | msgpack

8.7 forward:Fluentdへの転送

pipeline:
  outputs:
    - name: forward
      match: '*'
      host: fluentd-aggregator.logging.svc
      port: 24224
      time_as_integer: off
      send_options: true
      require_ack_response: true
      # TLS
      tls: on
      tls.verify: on
      tls.ca_file: /certs/ca.pem
      # 共有キー認証
      shared_key: my-shared-secret
      self_hostname: fluent-bit-node01

8.8 prometheus_exporter:メトリクス公開

pipeline:
  outputs:
    - name: prometheus_exporter
      match: metrics.*
      host: 0.0.0.0
      port: 2021
      add_label: app fluent-bit

9. BufferとBackpressure管理

大規模環境ではログ生成速度が送信速度を超過する場合がある。Fluent BitのBufferとBackpressure管理を適切に設定すれば、データ損失なく安定的に運用できる。

9.1 メモリバッファ vs ファイルシステムバッファ

項目メモリバッファファイルシステムバッファ
保存場所RAMディスク + RAM(ハイブリッド)
速度非常に高速相対的に低速
データ安全性プロセス終了時に損失ディスクに保存
容量上限RAMサイズの制限ディスクサイズまで拡張可能
設定の複雑さシンプル追加設定が必要
適した環境開発/テストプロダクション

9.2 Serviceレベル設定

service:
  flush: 1
  log_level: info
  # ファイルシステムバッファの有効化
  storage.path: /var/log/fluent-bit/buffer/
  storage.sync: normal # normal | full
  storage.checksum: off # データ整合性検証
  storage.max_chunks_up: 128 # メモリに載せる最大チャンク数
  storage.backlog.mem_limit: 5M # バックログメモリ上限
  storage.metrics: on # ストレージメトリクスの有効化

9.3 Inputレベルバッファ設定

pipeline:
  inputs:
    # メモリバッファ使用(デフォルト)
    - name: tail
      tag: app.mem
      path: /var/log/app/*.log
      mem_buf_limit: 10MB # メモリバッファ上限

    # ファイルシステムバッファ使用
    - name: tail
      tag: app.fs
      path: /var/log/app/*.log
      storage.type: filesystem # filesystem | memory
      storage.pause_on_chunks_overlimit: off # 上限超過時もディスクに書き込み続行

9.4 Outputレベルバッファ設定

pipeline:
  outputs:
    - name: es
      match: '*'
      host: elasticsearch
      port: 9200
      storage.total_limit_size: 1G # Output別ファイルシステムバッファ総量制限
      retry_limit: 10 # リトライ回数
      # retry_limit: false          # 無限リトライ

9.5 Backpressureメカニズム

BackpressureはOutputがデータを十分に速く送信できないときに発生する。Fluent Bitは以下のような段階でBackpressureを処理する。

  [Input: データ収集]
         |
         v
  [メモリバッファに格納]
         |
    メモリ上限到達?
    /              \
   No              Yes
   |                |
   v                v
 [収集続行]   storage.type=filesystem?
                /              \
              No               Yes
              |                 |
              v                 v
       [Input一時停止]     [ディスクに書き込み]
       (データ損失リスク)        |
                          ディスク上限到達?
                          /              \
                        No              Yes
                        |                |
                        v                v
                   [書き込み続行]   [Input一時停止]

推奨Backpressure設定(プロダクション)

service:
  storage.path: /var/log/fluent-bit/buffer/
  storage.sync: normal
  storage.max_chunks_up: 128
  storage.backlog.mem_limit: 10M

pipeline:
  inputs:
    - name: tail
      tag: kube.*
      path: /var/log/containers/*.log
      storage.type: filesystem
      storage.pause_on_chunks_overlimit: off

  outputs:
    - name: es
      match: kube.*
      host: elasticsearch
      storage.total_limit_size: 5G
      retry_limit: false
      net.keepalive: on
      net.keepalive_idle_timeout: 30

9.6 Mem_Buf_Limit vs storage.max_chunks_up

設定適用範囲バッファモード動作
Mem_Buf_LimitInput別memoryのみ上限超過時にInput一時停止
storage.max_chunks_upグローバル(SERVICE)filesystemメモリ内チャンク数の制限
storage.total_limit_sizeOutput別filesystemディスクバッファ総量制限

注意storage.type: filesystemを使用するとMem_Buf_Limitは無効になる。代わりにstorage.max_chunks_upがメモリ内チャンク数を制御する。


10. Kubernetes連携完全ガイド

10.1 DaemonSetデプロイアーキテクチャ

+---------------------------------------------------------------------+
|                      Kubernetes Cluster                             |
|                                                                     |
|  +-------------------+  +-------------------+  +-------------------+|
|  |     Node 1        |  |     Node 2        |  |     Node 3        ||
|  |                    |  |                    |  |                    ||
|  | +------+ +------+ |  | +------+ +------+ |  | +------+ +------+ ||
|  | |Pod A | |Pod B | |  | |Pod C | |Pod D | |  | |Pod E | |Pod F | ||
|  | +--+---+ +--+---+ |  | +--+---+ +--+---+ |  | +--+---+ +--+---+ ||
|  |    |        |      |  |    |        |      |  |    |        |      ||
|  |    v        v      |  |    v        v      |  |    v        v      ||
|  | /var/log/containers|  | /var/log/containers|  | /var/log/containers||
|  |         |          |  |         |          |  |         |          ||
|  |    +----+-----+    |  |    +----+-----+    |  |    +----+-----+    ||
|  |    |Fluent Bit|    |  |    |Fluent Bit|    |  |    |Fluent Bit|    ||
|  |    |(DaemonSet)|   |  |    |(DaemonSet)|   |  |    |(DaemonSet)|   ||
|  |    +----+-----+    |  |    +----+-----+    |  |    +----+-----+    ||
|  +---------|----------+  +---------|----------+  +---------|----------+|
|            |                       |                       |           |
|            +----------+------------+----------+------------+           |
|                       |                       |                        |
|               +-------v--------+     +--------v--------+              |
|               | Elasticsearch  |     |  Grafana Loki   |              |
|               +----------------+     +-----------------+              |
+---------------------------------------------------------------------+

10.2 Helm Chartインストール

# リポジトリ追加
helm repo add fluent https://fluent.github.io/helm-charts
helm repo update

# 基本インストール
helm install fluent-bit fluent/fluent-bit \
  --namespace logging \
  --create-namespace

# インストール確認
kubectl get pods -n logging -l app.kubernetes.io/name=fluent-bit
kubectl get ds -n logging

10.3 values.yamlカスタマイズ

# custom-values.yaml
kind: DaemonSet

image:
  repository: cr.fluentbit.io/fluent/fluent-bit
  tag: '3.2.2'
  pullPolicy: IfNotPresent

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

tolerations:
  - operator: Exists # 全ノードにデプロイ(master含む)

serviceAccount:
  create: true
  annotations:
    # IRSA(EKS)
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/fluent-bit

# ボリュームマウント
volumeMounts:
  - name: varlog
    mountPath: /var/log
  - name: varlibdockercontainers
    mountPath: /var/lib/docker/containers
    readOnly: true
  - name: etcmachineid
    mountPath: /etc/machine-id
    readOnly: true

volumes:
  - name: varlog
    hostPath:
      path: /var/log
  - name: varlibdockercontainers
    hostPath:
      path: /var/lib/docker/containers
  - name: etcmachineid
    hostPath:
      path: /etc/machine-id

# 環境変数
env:
  - name: ELASTICSEARCH_HOST
    value: 'elasticsearch-master.logging.svc.cluster.local'
  - name: ELASTICSEARCH_PORT
    value: '9200'

# Fluent Bit設定
config:
  service: |
    [SERVICE]
        Flush         5
        Log_Level     info
        Daemon        off
        Parsers_File  /fluent-bit/etc/parsers.conf
        HTTP_Server   On
        HTTP_Listen   0.0.0.0
        HTTP_Port     2020
        storage.path  /var/log/fluent-bit/buffer/
        storage.sync  normal
        storage.max_chunks_up 128
        Hot_Reload    On

  inputs: |
    [INPUT]
        Name              tail
        Tag               kube.*
        Path              /var/log/containers/*.log
        multiline.parser  docker, cri
        DB                /var/log/flb_kube.db
        Mem_Buf_Limit     5MB
        Skip_Long_Lines   On
        Refresh_Interval  10
        storage.type      filesystem

  filters: |
    [FILTER]
        Name                kubernetes
        Match               kube.*
        Kube_URL            https://kubernetes.default.svc:443
        Kube_CA_File        /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        Kube_Token_File     /var/run/secrets/kubernetes.io/serviceaccount/token
        Kube_Tag_Prefix     kube.var.log.containers.
        Merge_Log           On
        Keep_Log            Off
        K8S-Logging.Parser  On
        K8S-Logging.Exclude On
        Labels              On
        Annotations         Off

  outputs: |
    [OUTPUT]
        Name            es
        Match           kube.*
        Host            ${ELASTICSEARCH_HOST}
        Port            ${ELASTICSEARCH_PORT}
        Logstash_Format On
        Logstash_Prefix kube
        Retry_Limit     False
        Suppress_Type_Name On

# Prometheusメトリクス収集のためのServiceMonitor
serviceMonitor:
  enabled: true
  interval: 30s
  scrapeTimeout: 10s

# Liveness/Readiness Probe
livenessProbe:
  httpGet:
    path: /
    port: http
readinessProbe:
  httpGet:
    path: /api/v1/health
    port: http

10.4 コンテナログパスとCRIパース

Kubernetesではコンテナログは以下のパスに保存される。

/var/log/containers/<pod-name>_<namespace>_<container-name>-<container-id>.log
  -> symlink -> /var/log/pods/<namespace>_<pod-name>_<pod-uid>/<container-name>/0.log

CRIログフォーマット(containerd / CRI-O)

2026-03-01T12:00:00.123456789Z stdout F This is a log message
2026-03-01T12:00:00.123456789Z stderr P This is a partial log line
フィールド説明
2026-03-01T12:00:00.123456789ZRFC 3339ナノ秒タイムスタンプ
stdout / stderrストリームタイプ
F / PFull(完全)/ Partial(部分)ログフラグ
残りログメッセージ本文

Fluent Bitはmultiline.parser: docker, criを指定すると、Docker形式とCRI形式を自動的に検出してパースする。

10.5 Namespace別ログルーティング

# Namespaceに応じて異なるOutputにルーティング
pipeline:
  filters:
    - name: kubernetes
      match: kube.*
      merge_log: on
      labels: on

    # プロダクションNamespaceのタグ変更
    - name: rewrite_tag
      match: kube.*
      rule: $kubernetes['namespace_name'] ^(production)$ prod.$TAG false
      rule: $kubernetes['namespace_name'] ^(staging)$    stg.$TAG  false
      rule: $kubernetes['namespace_name'] ^(monitoring)$ mon.$TAG  false

  outputs:
    # プロダクションログ -> Elasticsearch
    - name: es
      match: prod.*
      host: es-production.logging.svc
      port: 9200
      logstash_format: on
      logstash_prefix: prod-logs

    # ステージングログ -> Loki
    - name: loki
      match: stg.*
      host: loki.logging.svc
      port: 3100
      labels:
        env=staging

    # モニタリングログ -> S3アーカイブ
    - name: s3
      match: mon.*
      bucket: monitoring-logs-archive
      region: ap-northeast-2
      total_file_size: 100M
      upload_timeout: 10m
      compression: gzip

    # その他のログ -> デフォルトElasticsearch
    - name: es
      match: kube.*
      host: es-default.logging.svc
      port: 9200
      logstash_format: on
      logstash_prefix: default-logs

10.6 マルチテナントログ分離

pipeline:
  filters:
    - name: kubernetes
      match: kube.*
      merge_log: on
      labels: on

    # チームLabelベースのタグ書き換え
    - name: rewrite_tag
      match: kube.*
      rule: $kubernetes['labels']['team'] ^(backend)$  team.backend.$TAG  false
      rule: $kubernetes['labels']['team'] ^(frontend)$ team.frontend.$TAG false
      rule: $kubernetes['labels']['team'] ^(data)$     team.data.$TAG     false

  outputs:
    # バックエンドチーム -> 専用Elasticsearchインデックス
    - name: es
      match: team.backend.*
      host: elasticsearch.logging.svc
      logstash_format: on
      logstash_prefix: team-backend

    # フロントエンドチーム -> 専用Loki tenant
    - name: loki
      match: team.frontend.*
      host: loki.logging.svc
      tenant_id: frontend-team
      labels:
        team=frontend

    # データチーム -> S3 + Elasticsearchデュアル
    - name: es
      match: team.data.*
      host: elasticsearch.logging.svc
      logstash_format: on
      logstash_prefix: team-data

    - name: s3
      match: team.data.*
      bucket: data-team-logs
      region: ap-northeast-2
      compression: gzip

10.7 ServiceAccountおよびRBAC設定

# fluent-bit-rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: fluent-bit
  namespace: logging
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: fluent-bit
rules:
  - apiGroups: ['']
    resources:
      - namespaces
      - pods
      - pods/logs
      - nodes
      - nodes/proxy
    verbs: ['get', 'list', 'watch']
  - apiGroups: ['']
    resources:
      - events
    verbs: ['get', 'list', 'watch']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: fluent-bit
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: fluent-bit
subjects:
  - kind: ServiceAccount
    name: fluent-bit
    namespace: logging

11. 実践パイプライン例

11.1 例1:K8sログをElasticsearch + Kibanaへ

最も一般的なEFK(Elasticsearch + Fluent Bit + Kibana)スタック構成である。

# fluent-bit-efk.yaml
service:
  flush: 5
  log_level: info
  parsers_file: /fluent-bit/etc/parsers.conf
  http_server: on
  http_listen: 0.0.0.0
  http_port: 2020
  storage.path: /var/log/fluent-bit/buffer/
  storage.sync: normal
  storage.max_chunks_up: 128

pipeline:
  inputs:
    - name: tail
      tag: kube.*
      path: /var/log/containers/*.log
      multiline.parser: docker, cri
      db: /var/log/flb_kube.db
      mem_buf_limit: 5MB
      skip_long_lines: on
      refresh_interval: 10
      storage.type: filesystem

  filters:
    - name: kubernetes
      match: kube.*
      kube_url: https://kubernetes.default.svc:443
      kube_ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      kube_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      merge_log: on
      keep_log: off
      k8s-logging.parser: on
      k8s-logging.exclude: on
      labels: on

    # kube-system、logging Namespaceのログを除外
    - name: grep
      match: kube.*
      exclude: $kubernetes['namespace_name'] ^(kube-system|logging)$

    # 環境情報の追加
    - name: modify
      match: kube.*
      add: cluster_name my-eks-cluster
      add: environment production

  outputs:
    - name: es
      match: kube.*
      host: elasticsearch-master.logging.svc.cluster.local
      port: 9200
      http_user: elastic
      http_passwd: ${ES_PASSWORD}
      logstash_format: on
      logstash_prefix: kube-logs
      logstash_dateformat: "%Y.%m.%d"
      time_key: "@timestamp"
      include_tag_key: true
      tag_key: fluentbit_tag
      suppress_type_name: on
      generate_id: on
      retry_limit: false
      workers: 2
      tls: on
      tls.verify: on
      tls.ca_file: /certs/es-ca.pem

11.2 例2:K8sログをGrafana Loki + Grafanaへ

# fluent-bit-loki.yaml
service:
  flush: 5
  log_level: info
  http_server: on
  http_listen: 0.0.0.0
  http_port: 2020

pipeline:
  inputs:
    - name: tail
      tag: kube.*
      path: /var/log/containers/*.log
      multiline.parser: docker, cri
      db: /var/log/flb_kube.db
      mem_buf_limit: 5MB
      skip_long_lines: on

  filters:
    - name: kubernetes
      match: kube.*
      merge_log: on
      keep_log: off
      labels: on
      annotations: off

  outputs:
    - name: loki
      match: kube.*
      host: loki-gateway.logging.svc.cluster.local
      port: 3100
      uri: /loki/api/v1/push
      labels: job=fluent-bit,cluster=my-cluster
      label_keys: $kubernetes['namespace_name'],$kubernetes['pod_name'],$kubernetes['container_name']
      auto_kubernetes_labels: on
      line_format: json
      workers: 2
      retry_limit: false

11.3 例3:S3アーカイブ + Elasticsearchデュアル出力

1つの入力を2つのOutputに同時に送信するパターンである。

# fluent-bit-dual.yaml
service:
  flush: 5
  log_level: info
  storage.path: /var/log/fluent-bit/buffer/
  storage.sync: normal
  storage.max_chunks_up: 128

pipeline:
  inputs:
    - name: tail
      tag: kube.*
      path: /var/log/containers/*.log
      multiline.parser: docker, cri
      db: /var/log/flb_kube.db
      storage.type: filesystem

  filters:
    - name: kubernetes
      match: kube.*
      merge_log: on
      keep_log: off
      labels: on

  outputs:
    # リアルタイム検索/分析用Elasticsearch
    - name: es
      match: kube.*
      host: elasticsearch.logging.svc
      port: 9200
      logstash_format: on
      logstash_prefix: kube-logs
      suppress_type_name: on
      retry_limit: false
      workers: 2

    # 長期保管用S3アーカイブ
    - name: s3
      match: kube.*
      region: ap-northeast-2
      bucket: log-archive-bucket
      s3_key_format: /kubernetes/$TAG/%Y/%m/%d/%H/$UUID.gz
      s3_key_format_tag_delimiters: .
      total_file_size: 100M
      upload_timeout: 10m
      compression: gzip
      content_type: application/gzip
      store_dir: /tmp/fluent-bit-s3
      store_dir_limit_size: 1G
      use_put_object: on
      retry_limit: 5
      workers: 1

11.4 例4:Namespace別フィルタリングと多重宛先ルーティング

# fluent-bit-routing.yaml
service:
  flush: 5
  log_level: info
  storage.path: /var/log/fluent-bit/buffer/
  storage.sync: normal

pipeline:
  inputs:
    - name: tail
      tag: kube.*
      path: /var/log/containers/*.log
      multiline.parser: docker, cri
      db: /var/log/flb_kube.db
      storage.type: filesystem

  filters:
    - name: kubernetes
      match: kube.*
      merge_log: on
      labels: on

    # Namespace別タグ書き換え
    - name: rewrite_tag
      match: kube.*
      rule: $kubernetes['namespace_name'] ^(production)$  route.prod.$TAG  false
      rule: $kubernetes['namespace_name'] ^(staging)$     route.stg.$TAG   false
      rule: $kubernetes['namespace_name'] ^(kube-system)$ route.sys.$TAG   false

    # プロダクションからERRORのみ抽出
    - name: rewrite_tag
      match: route.prod.*
      rule: $log ^.*ERROR.*$ alert.prod.$TAG true

  outputs:
    # プロダクション全ログ -> Elasticsearch
    - name: es
      match: route.prod.*
      host: es-prod.logging.svc
      port: 9200
      logstash_format: on
      logstash_prefix: prod-all
      suppress_type_name: on
      workers: 2

    # プロダクションERRORアラート -> 別インデックス
    - name: es
      match: alert.prod.*
      host: es-prod.logging.svc
      port: 9200
      logstash_format: on
      logstash_prefix: prod-alerts
      suppress_type_name: on

    # ステージングログ -> Loki(コスト効率)
    - name: loki
      match: route.stg.*
      host: loki.logging.svc
      port: 3100
      labels:
        env=staging
      auto_kubernetes_labels: on
      line_format: json

    # システムログ -> S3アーカイブ(長期保管)
    - name: s3
      match: route.sys.*
      bucket: system-logs-archive
      region: ap-northeast-2
      total_file_size: 50M
      upload_timeout: 15m
      compression: gzip
      s3_key_format: /kube-system/%Y/%m/%d/$UUID.gz

    # 未分類ログ -> デフォルトElasticsearch
    - name: es
      match: kube.*
      host: es-default.logging.svc
      port: 9200
      logstash_format: on
      logstash_prefix: default-logs
      suppress_type_name: on

12. パフォーマンスチューニング

12.1 Workers設定

OutputプラグインにWorkersパラメータを設定すると並列送信が可能になる。各Workerは独立したスレッドとして動作する。

pipeline:
  outputs:
    - name: es
      match: '*'
      host: elasticsearch
      port: 9200
      workers: 4 # 4つの並列Worker
      net.keepalive: on
      net.keepalive_idle_timeout: 30

Workers設定ガイドライン

状況推奨Workers備考
低スループット0-1デフォルトで十分
中スループット2-4大半のプロダクション環境
高スループット4-8CPUコア数を考慮
非常に高いスループット8以上ネットワーク/宛先のボトルネック確認が必要

12.2 Flush Interval最適化

Flush値は秒単位で、バッファからOutputへデータを送信する周期を決定する。

service:
  flush: 1 # 1秒ごとにフラッシュ(リアルタイム性重視)
  # flush: 5  # 5秒ごとにフラッシュ(スループット重視)
Flush値特性
1秒低レイテンシ、高CPU使用率
5秒バランスの取れた設定(デフォルト推奨)
10秒以上高スループット、大きなバッチサイズ

12.3 Bufferサイズ調整

pipeline:
  inputs:
    - name: tail
      path: /var/log/containers/*.log
      # 高スループット環境
      buffer_chunk_size: 512KB # チャンク単位サイズ(デフォルト32KB)
      buffer_max_size: 5MB # 最大バッファサイズ(デフォルト32KB)
      mem_buf_limit: 50MB # メモリバッファ上限

  outputs:
    - name: es
      match: '*'
      buffer_size: 512KB # HTTPバッファサイズ

12.4 パイプラインの並列化

高スループットが必要な環境では、InputとOutputを分離して並列パイプラインを構成できる。

pipeline:
  inputs:
    # アプリケーションログパイプライン
    - name: tail
      tag: app.*
      path: /var/log/containers/app-*.log
      multiline.parser: docker, cri
      threaded: on # 別スレッドで実行

    # システムログパイプライン
    - name: tail
      tag: sys.*
      path: /var/log/containers/kube-*.log
      multiline.parser: docker, cri
      threaded: on

  outputs:
    - name: es
      match: app.*
      host: elasticsearch
      workers: 4

    - name: es
      match: sys.*
      host: elasticsearch
      workers: 2

12.5 Hot Reload

v2.1からサポートされているHot Reload機能により、サービス中断なしに設定を再読み込みできる。

# Hot Reloadの有効化
service:
  hot_reload: on

リロードをトリガーする方法は3つある。

# 方法1:SIGHUPシグナル
kill -SIGHUP $(pidof fluent-bit)

# 方法2:HTTP API(v4.0+)
curl -X POST http://localhost:2020/api/v2/reload

# 方法3:コマンドラインオプション
fluent-bit -c fluent-bit.yaml -Y   # --enable-hot-reload

Hot Reload時の注意事項

  • バッファ内のデータは保持される
  • ファイルシステムバッファの場合、ディスク上のデータも維持される
  • 新しい設定に構文エラーがある場合、リロードは失敗し既存の設定が維持される
  • SIGHUPはWindowsではサポートされていない

12.6 メモリ使用量モニタリング

# Fluent Bitプロセスのメモリ確認
ps aux | grep fluent-bit

# HTTP APIで内部メトリクス確認
curl -s http://localhost:2020/api/v1/storage | jq .

# Prometheusメトリクスで確認
curl -s http://localhost:2020/api/v2/metrics/prometheus | grep fluentbit_input

12.7 パフォーマンスベンチマーク参考

以下は一般的な環境でのFluent Bitのパフォーマンス参考値である(ハードウェア、ネットワーク、設定によって差異がある)。

シナリオスループットCPU使用率メモリ
単純転送(tail入力、stdout出力)約100K events/s5-10%(1コア)5-10MB
K8s Filter + ES出力約40-60K events/s15-25%(1コア)30-50MB
K8s Filter + Lua変換 + ES出力約20-40K events/s25-40%(1コア)40-80MB
複合パイプライン(Filter多数 + デュアル出力)約15-30K events/s30-50%(1コア)50-100MB

v4.1のSIMD最適化:JSONエンコーディングをSIMD(Single Instruction, Multiple Data)命令で処理し、JSON変換性能が2.5倍向上した。


13. モニタリングとObservability

13.1 内蔵HTTPモニタリングエンドポイント

Fluent Bitは内蔵HTTPサーバーを通じて自身の状態をモニタリングできる。

service:
  http_server: on
  http_listen: 0.0.0.0
  http_port: 2020
  health_check: on
  hc_errors_count: 5 # この数以上のエラー発生時にunhealthy
  hc_retry_failure_count: 5 # この数以上のリトライ失敗時にunhealthy
  hc_period: 60 # ヘルスチェック周期(秒)

利用可能なエンドポイント

エンドポイント説明
/Fluent Bitビルド情報
/api/v1/healthヘルスチェック(200=OK、500=Unhealthy)
/api/v1/metricsJSON形式メトリクス
/api/v1/metrics/prometheusPrometheus形式メトリクス
/api/v2/metricsv2メトリクスエンドポイント
/api/v2/metrics/prometheusv2 Prometheusメトリクス
/api/v1/storageストレージ/バッファ状態
/api/v2/reloadHot Reloadトリガー(POST)
/api/v1/uptime稼働時間
# ヘルスチェック
curl -s http://localhost:2020/api/v1/health
# レスポンス: ok (HTTP 200) または error (HTTP 500)

# ストレージ状態確認
curl -s http://localhost:2020/api/v1/storage | jq .
# {
#   "storage_layer": {
#     "chunks": {
#       "total_chunks": 15,
#       "mem_chunks": 10,
#       "fs_chunks": 5,
#       "fs_chunks_up": 3,
#       "fs_chunks_down": 2
#     }
#   }
# }

# Prometheusメトリクス確認
curl -s http://localhost:2020/api/v2/metrics/prometheus

13.2 Prometheusメトリクス収集構成

Fluent Bitの内部メトリクスをPrometheusで収集し、Grafanaで可視化する構成である。

# Fluent Bit自体のメトリクスをPrometheusに公開
pipeline:
  inputs:
    - name: fluentbit_metrics
      tag: fb.metrics
      scrape_interval: 30

  outputs:
    - name: prometheus_exporter
      match: fb.metrics
      host: 0.0.0.0
      port: 2021

Kubernetes ServiceMonitor設定

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: fluent-bit
  namespace: logging
  labels:
    release: prometheus
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: fluent-bit
  endpoints:
    - port: http
      path: /api/v2/metrics/prometheus
      interval: 30s
      scrapeTimeout: 10s
  namespaceSelector:
    matchNames:
      - logging

主要Prometheusメトリクス

メトリクスタイプ説明
fluentbit_input_records_totalCounterInput別収集レコード数
fluentbit_input_bytes_totalCounterInput別収集バイト数
fluentbit_output_proc_records_totalCounterOutput別処理レコード数
fluentbit_output_proc_bytes_totalCounterOutput別処理バイト数
fluentbit_output_errors_totalCounterOutput別エラー数
fluentbit_output_retries_totalCounterOutput別リトライ数
fluentbit_output_retries_failed_totalCounterOutput別リトライ失敗数
fluentbit_filter_records_totalCounterFilter別処理レコード数
fluentbit_uptimeGauge稼働時間(秒)
fluentbit_storage_chunksGaugeストレージチャンク数

13.3 Grafanaダッシュボード

GrafanaでFluent Bitモニタリングダッシュボードを構成する際に含めるべき重要なパネルは以下の通りである。

ダッシュボードパネル構成

パネルPromQL例用途
Inputスループットrate(fluentbit_input_records_total[5m])秒あたり収集レコード数
Outputスループットrate(fluentbit_output_proc_records_total[5m])秒あたり送信レコード数
Outputエラー率rate(fluentbit_output_errors_total[5m])秒あたりエラー発生数
リトライ比率rate(fluentbit_output_retries_total[5m])リトライ傾向
バッファ使用量fluentbit_storage_chunks現在のバッファチャンク数
稼働時間fluentbit_uptimeプロセス安定性
Input/Output差分rate(input[5m]) - rate(output[5m])Backpressure検知

Grafana Labsコミュニティダッシュボード(ID: 7752)をImportすると、基本的なFluent Bitモニタリングダッシュボードを素早く構成できる。


14. トラブルシューティングガイド

14.1 ログが収集されない場合

チェックリスト

# 1. Fluent Bitプロセス状態確認
kubectl get pods -n logging -l app.kubernetes.io/name=fluent-bit
kubectl logs -n logging <fluent-bit-pod> --tail=50

# 2. 設定ファイルの構文検証
fluent-bit -c fluent-bit.yaml --dry-run

# 3. ログファイルパス確認
kubectl exec -n logging <fluent-bit-pod> -- ls -la /var/log/containers/

# 4. DBファイル(offset)確認
kubectl exec -n logging <fluent-bit-pod> -- ls -la /var/log/flb_kube.db

# 5. 権限確認
kubectl exec -n logging <fluent-bit-pod> -- cat /var/log/containers/<target-log>

一般的な原因と解決方法

原因症状解決方法
ファイルパスエラーInputでレコード数0Pathを確認、ワイルドカードパターンを検証
権限不足Permission deniedエラーSecurityContext、hostPath権限を確認
DBファイル破損offsetがファイル末尾を指すDBファイルを削除して再起動
Parser不一致パース失敗、空レコードstdout Outputで原本を確認
Tagマッチ失敗Filter/Outputに到達しないMatchパターンとTagの一致を確認

14.2 メモリリーク / OOM

# メモリ制限設定
pipeline:
  inputs:
    - name: tail
      path: /var/log/containers/*.log
      mem_buf_limit: 5MB # Inputメモリ上限
      skip_long_lines: on # 長い行をスキップ
      buffer_chunk_size: 32KB # チャンクサイズ制限
      buffer_max_size: 32KB # 最大バッファ

service:
  storage.path: /var/log/fluent-bit/buffer/
  storage.max_chunks_up: 64 # メモリチャンク数制限(デフォルト128)

OOM防止チェックリスト

  1. Mem_Buf_Limitまたはstorage.max_chunks_upが設定されているか確認
  2. Skip_Long_Lines: Onを有効化
  3. 不要なFilterを削除(特にLuaで大きなテーブルを生成する場合)
  4. Kubernetes FilterのBuffer_Sizeを確認(0=無制限)
  5. Kubernetes Resource Limitsを適切に設定

14.3 Backpressureによるログ損失

# Backpressure発生確認
curl -s http://localhost:2020/api/v1/storage | jq .

# メトリクスで確認
curl -s http://localhost:2020/api/v2/metrics/prometheus | grep -E "retries|errors|dropped"

Backpressure発生時の対応手順

  1. OutputのWorkers数を増やして並列送信を強化
  2. Flush周期を短くしてより頻繁に送信(例:5 -> 1)
  3. storage.type: filesystemに切り替えてディスクバッファを活用
  4. storage.total_limit_sizeを十分に設定
  5. 宛先(Elasticsearchなど)の処理能力を確認し増強
# Backpressure対応設定例
service:
  flush: 1
  storage.path: /var/log/fluent-bit/buffer/
  storage.sync: normal
  storage.max_chunks_up: 256

pipeline:
  inputs:
    - name: tail
      tag: kube.*
      path: /var/log/containers/*.log
      storage.type: filesystem
      storage.pause_on_chunks_overlimit: off

  outputs:
    - name: es
      match: kube.*
      host: elasticsearch
      port: 9200
      workers: 4
      storage.total_limit_size: 10G
      retry_limit: false
      net.keepalive: on
      net.keepalive_idle_timeout: 15

14.4 TLS/認証エラー

# TLS接続テスト
kubectl exec -n logging <fluent-bit-pod> -- \
  curl -v --cacert /certs/ca.pem https://elasticsearch:9200

# 証明書の有効期限確認
kubectl exec -n logging <fluent-bit-pod> -- \
  openssl x509 -in /certs/ca.pem -noout -enddate

一般的なTLSエラーと解決方法

エラー原因解決方法
SSL_ERROR_SYSCALL証明書パスエラーtls.ca_fileパスを確認
certificate verify failedCA証明書不一致正しいCA証明書を使用
certificate has expired証明書期限切れ証明書を更新
connection refusedポート/ホストエラーHost、Port、TLSポートを確認
401 Unauthorized認証失敗http_userhttp_passwdを確認

14.5 デバッグ方法

ステップ1:Log Levelをdebugに設定

service:
  log_level: debug # error, warn, info, debug, trace

ステップ2:stdout Outputを追加

pipeline:
  outputs:
    # デバッグ用:すべてのレコードを標準出力へ
    - name: stdout
      match: '*'
      format: json_lines

    # 実際のOutput
    - name: es
      match: '*'
      host: elasticsearch

ステップ3:パイプライン段階別確認

# Inputのみテスト
fluent-bit -i tail -p path=/var/log/test.log -o stdout

# Parserテスト
fluent-bit -i tail -p path=/var/log/test.log -p parser=json -o stdout

# 全設定テスト(dry-run)
fluent-bit -c fluent-bit.yaml --dry-run

ステップ4:Kubernetesでリアルタイムログ確認

# Fluent Bitログストリーミング
kubectl logs -n logging -l app.kubernetes.io/name=fluent-bit -f --tail=100

# 特定Podのログ
kubectl logs -n logging fluent-bit-xxxxx -f

# 前のコンテナのログ(crash時)
kubectl logs -n logging fluent-bit-xxxxx --previous

15. 運用ベストプラクティス

15.1 プロダクションチェックリスト

項目推奨設定理由
storage.typefilesystemデータ損失防止
storage.path別ボリュームマウントディスクI/O分離
storage.total_limit_sizeディスク空き容量の50-70%ディスクフル防止
Retry_Limitfalse(無限)または十分な値一時的な障害からの復旧
Workers2-4並列送信性能
Hot_Reloadon無停止設定変更
HTTP_Serveronモニタリング有効化
health_checkonKubernetes Probe連携
Skip_Long_Lineson異常ログによる障害防止
Resource Limits適切なCPU/MemoryOOM防止

15.2 セキュリティ推奨事項

# Kubernetes Pod Security
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  capabilities:
    drop: ['ALL']

# 必要なボリュームのみマウント
volumes:
  - name: varlog
    hostPath:
      path: /var/log
      type: ''
  - name: buffer
    emptyDir:
      sizeLimit: 2Gi

# TLS強制(Output)
pipeline:
  outputs:
    - name: es
      tls: on
      tls.verify: on
      tls.ca_file: /certs/ca.pem

15.3 ログローテーション対応

Fluent Bitのtail Inputはログローテーションを自動的に検出する。ただし以下の設定を確認する必要がある。

pipeline:
  inputs:
    - name: tail
      path: /var/log/app/*.log
      db: /var/log/flb_app.db # 必須:offset追跡
      rotate_wait: 5 # ローテーション後の待ち時間(秒)
      refresh_interval: 10 # ファイルリスト更新周期

16. 参考資料

公式ドキュメントとリポジトリ

CNCF関連資料

比較と発展的資料