Fluent Bitとは？読み方・Fluentdとの違い・AWSでの設定例【v5.1対応】

Fluent Bit（フルエントビット）は、ログ・メトリクス・トレースを集めて加工し、CloudWatch LogsやOpenSearch、Grafana Lokiなどへ転送するC言語製のテレメトリエージェントです。表記は「fluentbit」「fluent-bit」と揺れますが、すべて同じソフトウェアを指します。この記事では2026年10月時点の最新版v5.1.5を前提に、仕組みと保守期限、Fluentdとの違い、実行して確かめたYAML設定とParserの落とし穴、ECS・EKSでの構成を扱います。

まとめ｜Fluent Bitの要点と採用判断

• 何をするものか：各サーバーやコンテナの横でログを収集し、Parser・Filterで整えて宛先へ送る常駐エージェントです。公式の比較表ではメモリ約450KB、組み込みプラグインは100種類以上です。
• Fluentdとの関係：同じFluentdエコシステムの一部で、どちらもCNCFのGraduatedプロジェクトです。ノードごとの収集はFluent Bit、複雑な加工と集約はFluentdという分担が基本です。
• 最新版と保守期限：v5.1.5（2026年10月21日）。v5.0系は2026年11月30日まで保守され、v4.2系は2026年7月30日にEOLを迎えました。
• 設定形式：v3.2からYAMLが標準で、従来の.conf形式（classic）は2026年末に非推奨になります。新規はYAMLで書いてください。
• 見落としやすい落とし穴：v5.0.5以降のforward出力は、既定値のままFluentdへ送ると全レコードが捨てられます。また、Parserで数値型にした項目にはgrepやrewrite_tagの正規表現が一致しません。
• AWSで使うなら：aws-for-fluent-bitのlatestとstableはFluent Bit 1.9.10を積んだ2.x系を指します。3.x系をバージョン番号タグで固定して使います（2026年10月22日公開の3.5.4でも同梱はv5.1.2）。

Fluent Bitとは｜ログを収集・加工・転送するC製エージェント

Fluent Bitは、2014年にTreasure DataのFluentdチームが組み込みLinuxやゲートウェイ向けの軽量なログプロセッサとして作り始めたOSSです。コンテナの普及とともに入力・出力の対象が広がり、現在はログに加えてメトリクス・トレース・プロファイルまで扱います。OpenTelemetryのOTLPを入力・出力の両方でネイティブに扱えるため、OpenTelemetry Collectorの代わりに置く構成も取れます。

ライセンスはApache License 2.0で、ソフトウェア自体の費用はかかりません。公式サイトは累計150億回以上デプロイされたと記載しており、AWSのコンテナ向けログ転送（FireLens）やEKSのContainer Insightsでも採用されています。費用として見積もるのは、Fluent Bitを動かすCPU・メモリ（Fargateならログルーターを含めたタスクの割り当て）と、転送先のCloudWatch LogsやS3といった保存・検索サービスの料金です。

現行の保守ライン｜v5.1が現行・v5.0は2026年11月30日まで・v4.2はEOL

Fluent Bitは現行系列と保守系列に並行して修正版を出し、セキュリティ修正の期限をGitHubのSECURITY.mdで公表しています。直近の版と期限は次のとおりです（2026年10月24日時点）。

v5.0系の保守はあと約1か月で切れるため、これから構築するならv5.1系一択です。v5.1ではForward入力などのマルチスレッド受信（workers）、入力ごとの流量上限（rate_gate）、FIPSモード、Google Cloud Storage出力が加わりました。

v5.1系の中でも、ネットワークから受信する入力を開けているならv5.1.4以降に上げてください。v5.1.4ではOTLP gRPC受信時の無制限な伸長とForward入力のmsgpack展開量に上限が入り、v5.1.5ではForward入力のトレース復号の迂回、Loki出力のHTTPヘッダーへのCRLF注入、copytruncate方式でローテーションされたファイルをtailが読み逃す不具合が直っています。

Fluent Bitの仕組み｜Input・Parser・Filter・Buffer・Router・Output

Fluent Bitは受け取ったデータを「レコード（1件のログ）」単位で扱い、次の順に処理します。

1. Input：ファイル末尾の追跡（tail）、systemdジャーナル、Forwardプロトコル、HTTP、OTLPなどからデータを受け取り、レコードにタグを付けます。
2. Parser：JSONや正規表現で、1行の文字列を構造化されたキーと値に分解します。
3. Filter：grepによる除外、modifyによるキー追加、kubernetesによるPod名やラベルの付与などを行います。
4. Buffer：出力できるまでデータをチャンク単位でメモリまたはファイルに保持します。
5. Router：出力側のmatchに書いたパターンとタグを照合し、送り先を決めます。1件を複数の出力へ送ることもできます。
6. Output：CloudWatch Logs・S3・OpenSearch・Lokiなどへ送信し、失敗したら再試行します。

設計で最初に決めるのはタグの命名です。app.web、app.batch、host.syslogのように階層を切っておくと、出力側でapp.*だけをCloudWatch Logsへ、host.*だけをS3へ、と振り分けを書けます。

YAML形式では、入力や出力にprocessorsを直接ぶら下げて加工することもできます。processorsは特定の入力・出力に付属する処理で、ログだけでなくメトリクスやトレースにも使えます。classic形式（.conf）ではprocessorsを書けません。これもYAMLへ移る理由のひとつです。

FluentdとFluent Bitの違い｜比較表と併用時の注意点

公式ドキュメント「Fluentd and Fluent Bit」の比較表から抜粋したものです。

「約450KB」は公式表の値で、実際の使用量は入力の量とバッファ設定で大きく変わります。サイジングの根拠にはせず、実際の流量で計測してください。後述のmem_buf_limit（入力ごとのメモリバッファ）やstorage.max_chunks_up（メモリに載せるチャンク数）はバッファの上限で、プロセス全体のメモリ上限ではありません。コンテナではメモリのlimitも別に設定します。

選び分けの基準｜ノードの収集はFluent Bit、集約はFluentd

Kubernetesのノードごと、ECSのタスクごとに常駐させる収集役は、メモリの小さいFluent Bitが向いています。公式ドキュメントも、クラウド事業者がFluentdからFluent Bitへ移ってきたと書いています。Fluentdを残す理由になるのは、Fluent Bitに無い外部プラグインが必要な場合や、Rubyで書いた独自の加工処理がすでに資産になっている場合です。Fluentd側の設定とfluent-package v6への移行はFluentdとは？設定ファイルの書き方とfluent-package v6移行の判断で扱っています。

v5.0.5以降のforward出力｜Fluentdへ送ると全件破棄される既定値

Fluent Bitで収集してFluentdで集約する2段構成では、Fluent Bitのforward出力を使います。ここでretain_metadata_in_forward_modeの既定値がfalseからtrueに変わりました。公式ドキュメントはv5.0.4からと書いていますが、タグ付きのソースコードではv5.0.4の定義もまだ"false"で、"true"になったのはv5.0.5（PR #11756）からです。v5.1.5のforward.cでも既定値は"true"のままです。

この値がtrueだと、Fluent Bitはイベントのメタデータを拡張形式で埋め込んで送ります。Fluentdはこの形式を解釈できず、skip invalid eventという警告を出してレコードを捨てます。公式のforward出力のドキュメントは、この場合全レコードが破棄されると明記しています。警告は受信側のFluentdのログにしか出ないため、Fluent Bit側だけを監視していると欠損に気づけません。Fluentd側の受け入れ対応（PR #5411）は2026年7月7日にmasterへ取り込まれましたが、2026年10月24日時点の最新リリースであるv1.19.4（9月28日公開）には含まれていません。

Fluentdへ送る出力には、次のように明示的にfalseを書きます。

pipeline:
  outputs:
    - name: forward
      match: '*'
      host: fluentd-aggregator
      port: 24224
      retain_metadata_in_forward_mode: false

受信側もFluent Bitであれば既定値のままで構いません。

設定ファイルの書き方｜YAMLが標準・classicは2026年末に非推奨

公式ドキュメントでは、YAMLがv3.2からの標準形式で、classic形式（拡張子.conf）は2026年末に非推奨になると案内しています。YAMLの基本構造は、全体設定のserviceと、入力・フィルター・出力を並べるpipelineの2つで、独自のParserを使うときはparsersを加えます。

インストール｜Linux・Kubernetes・Docker・macOS

LinuxサーバーとKubernetesには公式の導入手段があります。Dockerなら公式イメージfluent/fluent-bitに設定ファイルをマウントして-cで指定し、macOSならHomebrewで入ります。

# Linux（パッケージリポジトリを登録して導入）
curl https://raw.githubusercontent.com/fluent/fluent-bit/master/install.sh | sh

# Kubernetes（DaemonSetとして導入）
helm repo add fluent https://fluent.github.io/helm-charts
helm upgrade --install fluent-bit fluent/fluent-bit

# macOS
brew install fluent-bit

最小構成の実行例｜dummy入力からstdout出力まで

次の設定は、2件のテストログを生成し、levelがdebugのものを除外し、残りにenvキーを加えて標準出力へJSONで出すものです。外部サービスが要らないため、タグの振り分けやフィルターの効き方をこの形で確かめてから本番の出力先に差し替えると、切り分けが速くなります。

# fluent-bit.yaml
service:
  flush: 1
  log_level: info

pipeline:
  inputs:
    - name: dummy
      tag: app.web
      dummy: '{"level":"info","path":"/api/orders","status":200}'
      samples: 1
    - name: dummy
      tag: app.web
      dummy: '{"level":"debug","path":"/healthz","status":200}'
      samples: 1

  filters:
    - name: grep
      match: 'app.*'
      exclude: level ^debug$
    - name: modify
      match: 'app.*'
      add: env production

  outputs:
    - name: stdout
      match: 'app.*'
      format: json_lines

macOSのHomebrewで入れたFluent Bit 5.1.2でfluent-bit -c fluent-bit.yamlを実行すると（2026年10月24日）、標準出力に届いたのは次の1件だけでした。debugのレコードはgrepで落ち、envが追加されています。

{"date":1792782041.49424,"level":"info","path":"/api/orders","status":200,"env":"production"}

起動前の検証｜dry-runオプションでプロパティ名の誤りを検出

fluent-bit --dry-run -c fluent-bit.yamlは、起動せずに設定だけを検証します。v4.2から構文だけでなくプロパティ名まで検査するようになり、それ以前は実行時まで分からなかった綴りの誤りを事前に拾えます。上の設定のexcludeをexludeと打ち間違えた版で実行した結果が次です（起動バナーと時刻は省略）。

$ fluent-bit --dry-run -c typo.yaml
[error] [config] grep: unknown configuration property 'exlude'. The following properties are allowed: regex, exclude, and logical_op.
[error] [reload] check properties and additonal vaildations for filter plugins is failed
$ echo $?
1

正しい設定ならconfiguration test is successfulと出て終了コード0で終わります。CIでこのコマンドを実行し、終了コードが0以外なら配布を止める仕組みにしておくと、設定ミスでログが止まる事故を防げます。ただし、次の章で扱う「型の不一致」はdry-runでは検出できません。

アクセスログを解析して振り分ける｜tail・Parser・rewrite_tag

実運用で最初に書くのは、ファイルに出ているログをtailで読み、Parserで項目に分け、条件で宛先を変える設定です。nginx形式のアクセスログを例に、ヘルスチェックを捨て、5xxだけを別の宛先へ回します。

regexパーサーの設定例｜5xxレスポンスの別タグへの振り分け

入力には次の3行を使います。200と503のリクエスト、Kubernetesのヘルスチェックです。

192.0.2.10 - - [24/Oct/2026:10:00:01 +0900] "GET /api/orders HTTP/1.1" 200 512 "-" "curl/8.7.1"
192.0.2.11 - - [24/Oct/2026:10:00:02 +0900] "POST /api/orders HTTP/1.1" 503 87 "-" "curl/8.7.1"
192.0.2.12 - - [24/Oct/2026:10:00:03 +0900] "GET /healthz HTTP/1.1" 200 2 "-" "kube-probe/1.34"

service:
  flush: 1
  log_level: info

parsers:
  - name: nginx_access
    format: regex
    regex: '^(?<remote>[^ ]*) [^ ]* [^ ]* \[(?<time>[^\]]*)\] "(?<method>\S+) (?<path>[^ ]*) [^"]*" (?<code>\d{3}) (?<size>\d+) "[^"]*" "(?<agent>[^"]*)"$'
    time_key: time
    time_format: '%d/%b/%Y:%H:%M:%S %z'
    types: size:integer

pipeline:
  inputs:
    - name: tail
      path: /var/log/nginx/access.log
      tag: nginx.access
      read_from_head: true
      parser: nginx_access

  filters:
    - name: grep
      match: 'nginx.*'
      exclude: agent ^kube-probe
    - name: rewrite_tag
      match: 'nginx.access'
      rule: '$code ^5\d\d$ nginx.error false'

  outputs:
    - name: stdout
      match: 'nginx.access'
      format: json_lines
    - name: file
      match: 'nginx.error'
      path: /var/log/fluent-bit
      mkdir: true
      file: errors.log
      format: plain

rewrite_tagのruleは「キー、正規表現、新しいタグ、元のレコードを残すか」の4つを空白区切りで書きます。最後をfalseにすると、5xxのレコードはnginx.errorだけに流れ、nginx.accessからは消えます。read_from_head: trueは既存の行も先頭から読む指定で、本番では読み取り位置を記録するdbと組み合わせます。file出力のmkdirは既定がfalseで、出力先のディレクトリが無いと書き込めません。実行ユーザーには、入力ファイルの読み取り権限と出力先への書き込み権限が要ります。

上の3行を入れたファイルを、入出力のパスだけ検証用のディレクトリに替えてFluent Bit 5.1.2で読ませた結果です。標準出力には200の1件だけが出て、503の行はerrors.logに書かれ、ヘルスチェックはどちらにも出ませんでした。

$ fluent-bit -c nginx.yaml
{"date":1792803601.0,"remote":"192.0.2.10","method":"GET","path":"/api/orders","code":"200","size":512,"agent":"curl/8.7.1"}

$ cat errors.log
{"remote":"192.0.2.11","method":"POST","path":"/api/orders","code":"503","size":87,"agent":"curl/8.7.1"}

数値型にした項目は正規表現に一致しない｜grep・rewrite_tagの落とし穴

上の設定でtypesをcode:integer size:integerにすると、ステータスコードが数値として出力され、集計しやすくなります。ところが同じログで実行すると、503のレコードがnginx.errorへ回らず、200と一緒に標準出力へ出ました。エラーも警告も出ず、--dry-runも成功します。

原因はレコードを照合する共通処理にあります。grepとrewrite_tagはどちらも同じ照合関数を使っており、v5.1.5のsrc/flb_ra_key.cは、値が文字列でなければ照合せずに「一致しない」を返す実装です。数値・真偽値・null・入れ子のオブジェクトには、正規表現が当たりません。

ステータスコードやレイテンシーで振り分けたい項目は、Parserで数値型にしないでください。数値として保存したいなら、振り分けを済ませた後の出力先（OpenSearchのマッピングやCloudWatch Logs Insightsのクエリ）で型を変えるか、Lua（luaフィルター）で数値のまま比較します。JSONで出力するアプリのログも、数値はそのまま数値型になります。{"status":503}をregex: status ^503$のgrepに通すと1件も残らず、値を"503"と文字列にした場合だけ残りました。

ログの欠損を減らすバッファ設計｜mem_buf_limit・filesystem・DLQ

出力先が落ちたり遅くなったりすると、Fluent Bitには送れないデータが溜まります。公式ドキュメントはこれをバックプレッシャと呼び、入力ごとのバッファ方式で対処が変わります。

メモリのみの方式でmem_buf_limitに達すると、Fluent Bitはその入力を一時停止し、ログにpaused (mem buf overlimit)と出します。tail入力は読み取り位置で止まるだけです。ただし停止中にローテーションされ、rotate_wait（既定5秒）を過ぎたファイルは読み残しが出ることがあります。HTTP系の入力（http・splunk・elasticsearch・opentelemetry・prometheus_remote_write）はもっと厳しく、停止中に届いた接続を受け付けてすぐ閉じ、処理中のリクエストも破棄します。送信側が再送しなければ、そのデータは失われたまま。アプリからOTLPで直接受ける構成なら、送信側SDKのリトライ設定まで見直す必要があります。

取りこぼしを許容できないログは、ファイル併用にします。

service:
  storage.path: /var/lib/fluent-bit/storage/
  storage.max_chunks_up: 128
  storage.keep.rejected: on
  storage.rejected.path: rejected
  storage.rejected.limit: 500M

pipeline:
  inputs:
    - name: tail
      path: /var/log/app/*.log
      db: /var/lib/fluent-bit/tail-app.db
      tag: app.file
      storage.type: filesystem
  outputs:
    - name: cloudwatch_logs
      match: 'app.*'
      region: ap-northeast-1
      log_group_name: /app/production
      log_stream_prefix: node-
      storage.total_limit_size: 5G

dbは読み取り位置を記録するファイルで、無いと再起動のたびに位置を引き継げません。ほかに効いている設定は3つです。storage.max_chunks_upは、ファイル併用の全入力で共有する「同時にメモリへ載せるチャンク数」の上限です。storage.total_limit_sizeは出力ごとのキューの上限で、超えると最も古いチャンクから捨てられます。ディスクを守る代わりに古いログを失う設定なので、出力先の障害が何時間続いたら溢れるかをログ量から逆算して決めてください。

storage.keep.rejected: onはデッドレターキュー（DLQ）で、v4.2から使えます。出力先が回復不能なエラーを返したとき、再試行の上限に達したとき、再試行を無効にしているときに、送れなかったチャンクをstorage.path配下のrejectedディレクトリへ保存します。storage.rejected.limitを書かないとDLQの容量は無制限で、保存されたファイルは手で消すまで残ります。上限を書いた場合は、上限に達した後のチャンクはDLQへ保存されず、警告ログが出るだけです。ディスク使用量とこの警告の監視、削除の運用を決めてから有効にしてください。

AWSでFluent Bitを使う構成｜FireLens・EKS・aws-for-fluent-bit

AWSでは、AWSがビルドして配布するコンテナイメージaws-for-fluent-bitを使うのが一般的です。ECSではFireLensのサイドカーとして、EKSではDaemonSetとして動かします。どちらを選ぶかの前提になるECS・EKS・Fargateの違いはAWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順で整理しています。

aws-for-fluent-bitの版｜latestとstableは1.9.10を積んだ2.x系

aws-for-fluent-bitには、Amazon Linux 2ベースの2.x系とAmazon Linux 2023ベースの3.x系があり、同梱されているFluent Bitの版がまったく違います。

注意すべきはタグの意味です。READMEはlatestタグを「2.x系の最新」と定義しており、安定版を示すAWS_FOR_FLUENT_BIT_STABLE_VERSIONファイルも2026年10月24日時点で2.34.3.20261020を指しています。latestやstableを指定すると、Fluent Bit 1.9.10が動きます。1.9.10では、v2.1で入ったprocessorsも、v4.2で入ったDLQ（前述のstorage.keep.rejected）も使えません。

2.x系はサポート終了後もAmazon Linux 2ベースの再ビルドが続いていますが、同梱のFluent Bitは1.9.10のままです。AWS自身も3.x系への移行を勧め、本番ではタグをバージョン番号で固定するよう推奨しています。ただしstable指定はまだ2.x系にしか付いておらず、READMEはstable指定前の版をテスト環境やステージングで使うよう求めています。3.x系はステージングで検証してから、本番の版として固定するのが安全です。latest・stable・3はいずれも中身が入れ替わるタグなので、デプロイの途中で版が混在する原因になります。

もう1つ、AWS版は本家より遅れます。3.5.0で同梱がFluent Bit 5.1.2に上がった後、3.5.1から3.5.4までの4回はベースOSのパッケージ更新だけでした。前述のv5.1.4・v5.1.5の修正は、2026年10月24日時点のaws-for-fluent-bitには入っていません。同梱の版はリポジトリのlinux.versionファイルに書かれているので、イメージを上げる前にここで確かめてください。OTLPやForwardの受信ポートを外部に開けていて修正をすぐ取り込みたい場合は、本家のfluent/fluent-bitイメージを使う選択肢もあります。ただしFireLensで使うGo製プラグイン（後述のcloudwatchなど）は本家イメージに入っていません。

ECS・FargateはFireLensのサイドカー｜awsfirelensドライバーの設定

ECSでは、タスク定義にログルーター用のFluent Bitコンテナを1つ加え、アプリ側のコンテナのログドライバーをawsfirelensにします。optionsに書いたキーと値がFluent BitのOUTPUT設定として生成され、matchはFireLensが自動で付けます。次はタスク定義のうちcontainerDefinitionsだけの抜粋で、Fargateではこのほかにタスク全体のcpu・memory、networkMode: awsvpc、タスクロールなどを書きます。

{
  "containerDefinitions": [
    {
      "name": "log_router",
      "image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3.5.4",
      "essential": true,
      "firelensConfiguration": { "type": "fluentbit" }
    },
    {
      "name": "app",
      "image": "example/app:1.0.0",
      "essential": true,
      "logConfiguration": {
        "logDriver": "awsfirelens",
        "options": {
          "Name": "cloudwatch_logs",
          "region": "ap-northeast-1",
          "log_group_name": "/ecs/app",
          "log_stream_prefix": "app-",
          "auto_create_group": "true",
          "log_retention_days": "30"
        }
      }
    }
  ]
}

CloudWatch Logsへ書き込むIAM権限は、タスク定義のtaskRoleArnに指定するタスクロールに付けます。FireLensにはいくつか制約があります。Windowsコンテナでは使えません。独自の設定ファイルを読ませるconfig-file-typeは、Fargateではfile（イメージ内のファイル）しか指定できず、S3上の設定を使うにはaws-for-fluent-bitのinitタグ付きイメージが必要です。また/fluent-bit/etc/fluent-bit.confはFireLensの予約パスなので、独自の設定は別のパスに置きます。

EKSはDaemonSet｜Container Insightsのロググループ構成

EKSでは、各ノードにFluent BitをDaemonSetで1つずつ置き、/var/log/containers配下のコンテナログをtailで読みます。CloudWatchのContainer Insightsの手順で導入すると、次の3つのロググループが作られます。

• /aws/containerinsights/クラスター名/application：/var/log/containersの全コンテナログ
• /aws/containerinsights/クラスター名/host：/var/log/dmesg・/var/log/secure・/var/log/messages
• /aws/containerinsights/クラスター名/dataplane：kubelet・kube-proxy・dockerのジャーナル

以前のContainer InsightsでFluentdのDaemonSetを入れていた場合、AWSのドキュメントはFluent Bitを入れた直後にFluentdをアンインストールするよう求めています。containerdランタイムでFluentdが正しく動いていない場合は、Fluent Bitより先にFluentdを消します。残しておくと、Fluentdのエラーログを、Fluent Bitが拾い続けます。なお、この手順の公式マニフェストは2026年10月24日時点でもイメージがaws-for-fluent-bit:3.0.1（Fluent Bit v4.1.1、2026年2月28日にEOL）に固定されています。imageの行を現行の3.x系に書き換えてから適用してください。クラスター全体の監視設計はKubernetes監視・モニタリングの設計｜メトリクス・ログ・アラート閾値の実装判断を参照してください。

CloudWatch Logsへの出力｜cloudwatch_logsプラグインとIAM権限

aws-for-fluent-bitには、CloudWatch Logs向けの出力が2つ入っています。初期に作られたGo製のcloudwatchと、Fluent Bit本体に取り込まれたC製のcloudwatch_logsです。AWSは、C製のほうがリソース使用量が少なくスループットも高いと説明しています。新規ならcloudwatch_logsが第一候補です。Go製から切り替えるときは、ロググループ名とストリーム名のテンプレートの書き方が違います。Go製はlog_group_nameに$(ecs_task_id)などのECSメタデータを直接書けますが、C製はlog_group_template・log_stream_templateに$変数記法で書き、埋め込めるのはログのJSONにある値だけです。逆にworkersやauto_retry_requestsはC製でだけ使えます。

公式ドキュメントが挙げるIAM権限はlogs:CreateLogStream・logs:CreateLogGroup・logs:PutLogEvents・logs:PutRetentionPolicyの4つです。v5.1.5のソースでは、CreateLogGroupはauto_create_groupがtrueでロググループが見つからないときに、PutRetentionPolicyはその作成の直後にlog_retention_daysを指定していたときにだけ呼ばれます。ロググループを事前に作る運用なら、残りの2つで足ります。auto_create_groupの既定値はfalseなので、ロググループを事前に作らない運用ならtrueにし、log_retention_daysで保持期間も同時に決めます。保持期間を決めずに自動作成すると、ロググループは無期限保存になり、保存料金が積み上がります。タスクロールやロググループをTerraformなどでまとめて設計する場合は、AWS・Google Cloud・Azureのインフラ構築支援でも相談を受けています。

CloudWatch以外の出力先｜S3・OpenSearch・Loki・Datadog

出力プラグインはnameに指定する名前で選びます。代表的なものは次のとおりです。

1件のレコードは複数の出力にmatchできるため、「全量をS3に安く保管し、エラーだけをOpenSearchやDatadogへ送る」という分け方が取れます。取り込み量課金のSaaSでは、この分け方がそのまま費用の差になります。OpenSearchとElasticsearchのどちらを受け側にするかはElasticsearchとOpenSearchの違い｜ライセンス・API互換・機能差から移行先を決める、Lokiの構成はGrafana Lokiとは？仕組み・Alloyでの導入手順とLogQLの書き方【v3.7】が詳しいです。

ほかのログエージェントとの比較｜Vector・Filebeat・OTel Collector・Alloy

ログ収集エージェントはFluent Bitのほかにも選択肢があります。2026年10月24日時点の最新版と、開発元・実装言語・ライセンスを並べました。

受け側の製品が決まっているなら、その製品の標準エージェントが最短です。Elasticsearchへ送るならFilebeat、Grafana LokiならAlloyです。Lokiの旧エージェントPromtailは、Grafanaの告知どおり2026年3月2日にEOLとなり、以後の開発はAlloyに移りました。Promtailで動いている環境は、Fluent BitかAlloyへの移行が必要です。宛先が複数ある、またはAWSの標準構成に乗せたい場合はFluent Bitが有利です。Vectorは変換用の独自言語（VRL）で複雑な加工を書ける点が強みですが、版は0.x系のままで、2026年8月から10月だけでも0.58・0.59・0.60とマイナー版が3回上がっています。版ごとの変更点を追い続ける運用が要ります。

Fluent Bitを選ばない方がよい場面｜OpenTelemetry Collectorとの分担

トレースとメトリクスをすでにOpenTelemetry Collectorで集めている環境に、ログのためだけにFluent Bitを足すと、エージェントが2種類になり、設定ファイル、版の追従、エージェント自身の監視をそれぞれ2系統持つことになります。Collector（Contrib版）のfilelogレシーバーでファイルのログも読めるので、まずCollectorに寄せられないかを検討します。判断材料はOpenTelemetryのログ実装｜直接送信とfilelog receiverの選び分けにまとめています。

Fluent Bitが優位なのは、ノードあたりのメモリ枠が厳しい場合、ECS FireLensやContainer InsightsのようにAWSの標準構成に乗る場合、syslogやsystemdなど従来型のログ源が混在する場合です。ログ基盤全体でのエージェントの位置づけはログ集約とは？収集・転送・保存・可視化の仕組みとエージェント選定・導入判断を実装目線で解説【2026年版】で比較しています。

よくある質問

Fluent Bitの読み方は？

「フルエントビット」と読みます。表記は「Fluent Bit」が正式で、コマンド名やパッケージ名は「fluent-bit」です。

FluentdとFluent Bitはどちらを選べばよいですか？

各ノードに常駐させる収集役はFluent Bit、外部プラグインやRubyの独自処理が要る集約役はFluentdです。併用時はforward出力のretain_metadata_in_forward_modeをfalseにします。

AWSではどのイメージを使えばよいですか？

aws-for-fluent-bitの3.x系を、3.5.4のようなバージョン番号タグで固定して使ってください。latestとstableは2026年10月時点でFluent Bit 1.9.10を積んだ2.x系を指し、2.x系は2026年6月30日にサポートを終えています。

Fluent BitにEOLはありますか？

系列ごとの保守期限はGitHubのSECURITY.mdで公表されています。2026年10月24日時点では、v5.1系が現行（期限は未定）、v5.0系は2026年11月30日までセキュリティ修正の対象、v4.2系は2026年7月30日にEOLです。v5.0系以前を使っているならv5.1系へ上げてください。設定面では、classic形式（.conf）の設定ファイルが2026年末に非推奨になります。

Fluent BitはWindowsでも動きますか？

動きます。ZIPとEXEのインストーラー（MSIも提供）、Docker HubのWindowsコンテナがあります。ただし全プラグインがWindowsに対応しているわけではなく、ECSのFireLensもWindowsコンテナでは使えません。

関連記事

• Fluentdとは？設定ファイルの書き方とfluent-package v6移行の判断
• ログ集約とは？収集・転送・保存・可視化の仕組みとエージェント選定・導入判断を実装目線で解説【2026年版】
• OpenTelemetryのログ実装｜直接送信とfilelog receiverの選び分け
• Grafana Lokiとは？仕組み・Alloyでの導入手順とLogQLの書き方【v3.7】
• AWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順