- Authors
- Name
- 1. Fluent Bit入門
- 2. コアアーキテクチャ:パイプライン構造
- 3. インストール方法
- 4. 設定ファイル構造
- 5. Inputプラグイン詳細
- 6. Parser設定
- 7. Filterプラグイン詳細
- 8. Outputプラグイン詳細
- 9. BufferとBackpressure管理
- 10. Kubernetes連携完全ガイド
- 11. 実践パイプライン例
- 12. パフォーマンスチューニング
- 13. モニタリングとObservability
- 14. トラブルシューティングガイド
- 15. 運用ベストプラクティス
- 16. 参考資料
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 Bit | Fluentd |
|---|---|---|
| 開発言語 | C | Ruby + C |
| バイナリサイズ | 約450KB | 約40MB |
| メモリ使用量 | 約1MB | 約30-40MB |
| プラグイン数 | 100以上(内蔵) | 1,000以上(gem含む) |
| 性能(スループット) | 非常に高い | 高い |
| CPU使用量 | 低い | Fluent Bitの約4倍 |
| 設定形式 | INI / YAML | Ruby DSL |
| 主な用途 | エッジ/ノードレベルの収集・転送 | 中央集約型ログ集約 |
| Kubernetes | DaemonSetでノード別デプロイ | 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_Interval | 60 | ファイルリスト更新周期(秒) |
Read_from_Head | false | ファイル先頭から読むかどうか |
Skip_Long_Lines | Off | Buffer_Max_Sizeを超える行をスキップ |
Mem_Buf_Limit | - | メモリバッファ上限 |
Rotate_Wait | 5 | ログローテーション後の待ち時間 |
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はよく使われるログ形式に対する内蔵パーサーを提供している。
| パーサー | 形式 | 用途 |
|---|---|---|
json | JSON | JSON形式のログ |
docker | JSON(Docker特化) | Dockerコンテナログ |
cri | 正規表現 | CRI(containerd)ログ |
syslog-rfc5424 | 正規表現 | RFC 5424 Syslog |
syslog-rfc3164 | 正規表現 | RFC 3164 Syslog |
apache | 正規表現 | Apacheアクセスログ |
nginx | 正規表現 | Nginxアクセスログ |
logfmt | Logfmt | key=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:新しいTagKEEP_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
主要設定項目
| 設定 | デフォルト | 説明 |
|---|---|---|
Host | 127.0.0.1 | Elasticsearchホスト |
Port | 9200 | ポート番号 |
Index | fluent-bit | インデックス名 |
Logstash_Format | Off | 日付ベースのインデックスを使用 |
Logstash_Prefix | logstash | インデックスプレフィックス |
HTTP_User | - | Basic Auth ユーザー |
HTTP_Passwd | - | Basic Auth パスワード |
TLS | Off | TLS有効化 |
Generate_ID | Off | ドキュメントID自動生成 |
Workers | 0 | 並列Worker数 |
Retry_Limit | 1 | リトライ回数(False=無限) |
Suppress_Type_Name | Off | ES 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_Limit | Input別 | memoryのみ | 上限超過時にInput一時停止 |
storage.max_chunks_up | グローバル(SERVICE) | filesystem | メモリ内チャンク数の制限 |
storage.total_limit_size | Output別 | 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.123456789Z | RFC 3339ナノ秒タイムスタンプ |
stdout / stderr | ストリームタイプ |
F / P | Full(完全)/ 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-8 | CPUコア数を考慮 |
| 非常に高いスループット | 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/s | 5-10%(1コア) | 5-10MB |
| K8s Filter + ES出力 | 約40-60K events/s | 15-25%(1コア) | 30-50MB |
| K8s Filter + Lua変換 + ES出力 | 約20-40K events/s | 25-40%(1コア) | 40-80MB |
| 複合パイプライン(Filter多数 + デュアル出力) | 約15-30K events/s | 30-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/metrics | JSON形式メトリクス |
/api/v1/metrics/prometheus | Prometheus形式メトリクス |
/api/v2/metrics | v2メトリクスエンドポイント |
/api/v2/metrics/prometheus | v2 Prometheusメトリクス |
/api/v1/storage | ストレージ/バッファ状態 |
/api/v2/reload | Hot 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_total | Counter | Input別収集レコード数 |
fluentbit_input_bytes_total | Counter | Input別収集バイト数 |
fluentbit_output_proc_records_total | Counter | Output別処理レコード数 |
fluentbit_output_proc_bytes_total | Counter | Output別処理バイト数 |
fluentbit_output_errors_total | Counter | Output別エラー数 |
fluentbit_output_retries_total | Counter | Output別リトライ数 |
fluentbit_output_retries_failed_total | Counter | Output別リトライ失敗数 |
fluentbit_filter_records_total | Counter | Filter別処理レコード数 |
fluentbit_uptime | Gauge | 稼働時間(秒) |
fluentbit_storage_chunks | Gauge | ストレージチャンク数 |
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でレコード数0 | Pathを確認、ワイルドカードパターンを検証 |
| 権限不足 | 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防止チェックリスト
Mem_Buf_Limitまたはstorage.max_chunks_upが設定されているか確認Skip_Long_Lines: Onを有効化- 不要なFilterを削除(特にLuaで大きなテーブルを生成する場合)
- Kubernetes Filterの
Buffer_Sizeを確認(0=無制限) - 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発生時の対応手順
- Outputの
Workers数を増やして並列送信を強化 Flush周期を短くしてより頻繁に送信(例:5 -> 1)storage.type: filesystemに切り替えてディスクバッファを活用storage.total_limit_sizeを十分に設定- 宛先(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 failed | CA証明書不一致 | 正しいCA証明書を使用 |
certificate has expired | 証明書期限切れ | 証明書を更新 |
connection refused | ポート/ホストエラー | Host、Port、TLSポートを確認 |
401 Unauthorized | 認証失敗 | http_user、http_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.type | filesystem | データ損失防止 |
storage.path | 別ボリュームマウント | ディスクI/O分離 |
storage.total_limit_size | ディスク空き容量の50-70% | ディスクフル防止 |
Retry_Limit | false(無限)または十分な値 | 一時的な障害からの復旧 |
Workers | 2-4 | 並列送信性能 |
Hot_Reload | on | 無停止設定変更 |
HTTP_Server | on | モニタリング有効化 |
health_check | on | Kubernetes Probe連携 |
Skip_Long_Lines | on | 異常ログによる障害防止 |
| Resource Limits | 適切なCPU/Memory | OOM防止 |
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. 参考資料
公式ドキュメントとリポジトリ
- Fluent Bit公式ドキュメント - 完全な設定リファレンスとガイド
- Fluent Bit GitHub - ソースコードとIssueトラッカー
- Fluent Bit Helm Charts - Kubernetesデプロイ用Helm Chart
- Fluent Bit Performance Tools - ベンチマークツール
CNCF関連資料
- CNCF Fluent Bit v3発表
- CNCF Fluent Bit v3.2発表
- CNCF Fluentd to Fluent Bitマイグレーションガイド
- CNCF Parsing 101 with Fluent Bit