Fluent BitはコンテナやIoT機器、エッジサーバーといった「メモリと CPU が限られる環境」でも動かせるよう、C言語で実装された軽量・高速のログ・メトリクス・トレース転送エージェントです。Treasure Data社のEduardo Silvaが2015年に設計を開始し、Fluentdの「軽量版」として位置付けてOSS公開しました。現在はCloud Native Computing Foundation（CNCF）のサブプロジェクトとしてFluentdと共にGraduatedに認定されており、Kubernetesのデフォルトログ収集役として、AWS・Google Cloud・Microsoft Azure各社のマネージドK8sサービスでも標準採用されています。
この記事の目次
- Input・Filter・Output・Bufferの構成
- Treasure DataからCNCFへ
- Kubernetesクラスタでの定番運用
- Fluentd・Logstash・Vectorとの違い
- まとめ
Input・Filter・Output・Bufferの構成
Fluent Bitのデータフローは Input → Parser → Filter → Buffer → Router → Output というパイプライン構造です。Inputには tail（ファイル末尾追従）、systemd、Docker、forward（Fluentd互換プロトコル）、kubelet、cpu／mem／diskなど多彩なプラグインが標準同梱されており、「コンテナ標準出力をDockerソケット経由で集める」「systemdジャーナルを直接読む」といった処理を設定ファイルだけで実現できます。Filterでは正規表現でフィールド抽出したり、Kubernetes Pod情報を付与したり、機密フィールドをマスクしたりと加工が自在です。
Outputには Elasticsearch、OpenSearch、Loki、Splunk、Kafka、Amazon S3／CloudWatch、Google Cloud Logging、Azure Monitor、Datadog、New Relicなど主要なログバックエンドが揃っており、複数の宛先へ同時にルーティングできます。TLS・SASL認証・圧縮・再送リトライといった本番運用に必要な機能を内蔵しつつ、コンテナイメージは数十MBに収まる軽さを保っているのが、Daemonsetとして全Nodeに常駐させても無視できるリソース消費に抑えられる秘訣です。
Treasure DataからCNCFへ
Fluent Bitの開発は2015年、当時Treasure Data社に所属していたEduardo Silvaによって始まりました。「Fluentdは強力だがRuby実装でメモリを数百MB使うため、IoT機器や組込みLinuxには重すぎる」という課題に応えるべく、C99で書き直した軽量バージョンとして設計されました。2017年のv0.10で本格的に運用に耐える品質に達し、エッジ／組込み領域から先に普及しました。
2020年代に入ると、Kubernetesクラスタの「Nodeあたり1ポッドのログ転送Daemonset」という用途で爆発的に普及し、AWS for Fluent Bit、Google Cloud Ops Agent、Azure Monitor Agentなどクラウド各社の公式エージェントの基盤にも組み込まれました。現在はCNCFのGraduatedプロジェクトとしてFluentdと並列に扱われ、Eduardo Silvaを中心としたコミュニティと、Chronosphere社（Treasure Dataから独立）がメインスポンサーとして開発を支えています。
Kubernetesクラスタでの定番運用
Kubernetesでの典型構成は、Fluent BitをDaemonsetとして全Nodeに1ポッドずつ常駐させ、ホストの /var/log/containers/*.log を tail で読み取る形です。Kubernetes Filterプラグインを有効にすると、API Serverに問い合わせてPod名・Namespace・ラベル・コンテナ名を自動で付与してくれるため、Elasticsearchやログ管理SaaS側で「サービス別の絞り込み」「Namespace別の集計」が即座に可能になります。クラウド標準のロギングエージェントとしてEKS／GKE／AKSの公式ドキュメントでも推奨されており、新規構築ではほぼ第一候補です。
Outputの並列ルーティングを使えば、「クレジットカード番号フィールドだけマスクしてElasticsearchへ」「生ログはS3に長期保存」「アラート向けにLokiにも転送」といった複数宛先の同時運用が1台のFluent Bitで実現できます。メモリ使用量は数十MB台が標準で、Sidecarとしてコンテナごとに1個立てる構成でもオーバーヘッドが小さく、リソース制約のある組込み機器やArm系エッジデバイスでも「Fluentdは重いがFluent Bitなら載る」というケースが多くあります。
Fluentd・Logstash・Vectorとの違い
兄弟分のFluentdはRuby実装で1000以上のプラグインが揃っていますが、Rubyランタイムのオーバーヘッドゆえに数百MB単位のメモリを使います。Logstash（Elastic社）はJVMベースのデータパイプラインで歴史が長く、Elasticsearchとの統合度では随一です。Datadog社のVectorはRust実装の新興エージェントで、Fluent Bitと近い軽さを持ちながらYAMLとTOMLで宣言的に構成できるのが特徴です。OpenTelemetry Collectorはログ・メトリクス・トレースを統合的に扱う方向性で、可観測性プラットフォームのエントリーポイントを狙っています。
Fluent Bitの優位性は「軽さ」「K8s統合の標準としての立ち位置」「Outputバックエンドの幅広さ」の3点に集約されます。「Edge／IoTで動かす」「全Nodeに常駐させる」「すでにFluentdエコシステムを使っている」という条件のどれかに当てはまれば、まずFluent Bitを検討するのが定石です。近年はFluent BitとFluentdを併用し、Nodeのfluent-bitが集めたログを上位アグリゲータのfluentdへ転送する「2段構え」も広く使われる構成となっています。
まとめ
Fluent BitはC実装の軽量ログ転送エージェントで、Kubernetes時代の事実上の標準として各クラウドベンダーに採用されています。兄弟分のFluentdと役割を分担しつつCNCF Graduatedの地位を共有し、エッジ・IoT・組込みからクラウドK8sまで、リソース制約のある全ての現場で「迷ったらまずこれ」と言える可観測性パイプラインの土台となっています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント