Fluentd には、より軽量な兄弟がいます。Fluent Bit は、Fluentd チームのメンバーが、Fluentd のフットプリントが重すぎる環境のために特別に作ったものです。どちらも同じ Fluent の傘下にある CNCF の graduated プロジェクトで、このシリーズの他の場所で説明している、同じ入力/フィルター/出力のタグベースのアーキテクチャに従っています。このガイドでは、両者の実際の違いと、両方を一緒に使うアーキテクチャを説明します。

根本的なトレードオフ：フットプリントとエコシステム

	Fluentd	Fluent Bit
言語	Ruby（パフォーマンスに敏感な部分は C）	C
一般的なメモリフットプリント	数十メガバイト	数百キロバイト程度
プラグインのエコシステム	大規模。成熟した入力/フィルター/出力プラグインが幅広い	小規模だが相当な数があり成長中。100 を超える組み込みプラグイン
最適な用途	中央での集約、より重い処理	大量の収集、エッジやリソースが限られた環境

Fluent Bit の C のみの実装と最小限の依存関係が、組み込み Linux デバイスや IoT ハードウェアなど、数メガバイトの Ruby プロセスを動かすのが現実的でない、本格的なエッジの規模で動作できるほどフットプリントを小さくしています。Fluentd の大きなフットプリントは、それに見合う、より大規模で成熟したプラグインのエコシステムをもたらします。これは、より重い変換を行う場合や、あまり一般的でない出力先に書き込む場合に、より重要になります。

同じアーキテクチャ、異なる実装

どちらのツールも、このシリーズ全体で説明されている同じ概念を中心に作られています。入力プラグインがソースを定義し、フィルタープラグインが転送中のデータを変換し、出力プラグインが出力先を定義し、タグがそれらの間でデータをルーティングします。一方を設定したことがあれば、構文の細部は異なっても、もう一方の設定を読んで、その形をすぐに認識できます。Fluent Bit は、純粋なログ収集を超えて、ホストやコンテナのメトリクス（CPU、メモリ、ディスク）もログと並んで収集することをネイティブにサポートしています。Fluentd の世界では、通常、単一の統合されたエージェントではなく、Prometheus の exporter のような別のツールを意味します。

組み合わせたアーキテクチャ：Fluent Bit が転送し、Fluentd が集約する

どちらのツールも、フォワーダー（データを収集して次へ送る）またはアグリゲーター（多数のフォワーダーから受信し、より重い処理を行い、最終的なストレージに送る）のどちらとしても動作でき、デプロイ全体で 1 つのツールだけを選ぶ必要はありません。特に Kubernetes では、一般的なパターンが、それぞれのツールの強みを活かします。

┌────────────┐  ┌────────────┐  ┌────────────┐
│  ノード 1   │  │  ノード 2   │  │  ノード 3   │
│ Fluent Bit  │  │ Fluent Bit  │  │ Fluent Bit  │   ← ノードごとに 1 つ (DaemonSet)、
│ (DaemonSet) │  │ (DaemonSet) │  │ (DaemonSet) │     軽量で、転送するだけ
└──────┬─────┘  └──────┬─────┘  └──────┬─────┘
       │                │                │
       └────────────────┼────────────────┘
                         ▼
                 ┌───────────────┐
                 │    Fluentd     │   ← 中央のアグリゲーター、
                 │  (aggregator)  │     より重いパース/エンリッチメント、
                 └───────┬───────┘     より広いプラグインへのアクセス
                         ▼
               Elasticsearch / S3 / Kafka / ...

Fluent Bit は DaemonSet として、ノードごとに 1 つの軽量なインスタンスで動作し、ノード上の実際のワークロードと CPU やメモリで大きく競合することなく、ログを収集して転送するために必要最小限のことを行います。Fluentd は中央で、より少ない数で動作し、複雑なパース、エンリッチメント、Fluent Bit にないプラグインを必要とする出力先へのルーティングという重い処理を担当します。それぞれのツールが、1 つのツールがすべてをそこそこにこなすのではなく、実際に得意なことをしています。

1 つだけ必要な場合の選び方

• Fluent Bit のみは、デプロイのリソースが限られていて（エッジデバイス、高い Pod 密度、規模に応じてコストに敏感）、出力先と処理のニーズが、そのプラグインセットでカバーできる範囲に十分収まる場合に適しています。
• Fluentd のみは、デプロイのリソースが特に限られておらず、より長く確立された Fluentd のエコシステムで、より成熟しているプラグインや、より柔軟な設定が必要な場合に適しています。
• 両方を一緒には、上のパターンにまさに合います。フットプリントが重要な、大量のノードごとの収集が、フットプリントがそれほど重要でない、より重い中央での処理に供給されるものです。

クラウドプロバイダーのマネージド Kubernetes のロギングアドオンは、上の表にあるパフォーマンスとフットプリントの理由から、年々 Fluentd より Fluent Bit をデフォルトにすることが増えています。マネージドクラスターのトラブルシューティングで Fluentd が動いていると思っていた場合は、知っておく価値があります。決めつける前に、実際にどちらがデプロイされているかを確認してください。