Fluentdとは？ ― ログを「集めて・加工して・届ける」統合ログ収集ツール
Fluentd（フルエントディー）とは、さまざまなソースからログデータを収集し、フィルタリング・変換した上で、任意の出力先に転送するオープンソースのデータ収集ツールです。CNCFのGraduatedプロジェクトとして認定されており、Kubernetesのログ収集デファクトスタンダードとなっています。
郵便局の仕分けセンターに例えると、Fluentdは各地域（サーバー）から届く手紙（ログ）を受け取り、宛先ごとに仕分け（フィルタリング）して、適切な配送先（Elasticsearch、S3、BigQueryなど）に届ける役割です。手紙の形式がバラバラでも、統一フォーマットに変換して処理できるのが強みです。
なぜ統合的なログ収集が必要なのか
現代のシステムでは、Webサーバー、アプリケーションサーバー、データベース、ロードバランサー、コンテナなど、多数のコンポーネントがログを出力します。マイクロサービス化が進むと、ログの出力元は数十〜数百に及びます。
各サーバーにSSHでログインしてログを確認する運用は、規模が大きくなると破綻します。Fluentdを使えば、すべてのログを一箇所に集約し、統一的な検索・分析が可能になります。障害発生時の原因調査や、セキュリティ監視、ビジネスメトリクスの収集に不可欠な基盤です。
Fluentdのアーキテクチャ ― Input・Filter・Output
Fluentdのデータパイプラインは3つの段階で構成されます。
Input（入力プラグイン）：ログの収集元を定義します。ファイルの末尾監視（tail）、HTTP受信、syslog、Docker/Kubernetesのコンテナログなど、多彩な入力源に対応しています。
Filter（フィルタープラグイン）：収集したログを加工します。不要なフィールドの除去、フィールドの追加・変更、条件によるログのフィルタリング（特定のログレベルだけ通すなど）を行います。
Output（出力プラグイン）：加工済みのログを出力先に転送します。Elasticsearch、Amazon S3、BigQuery、Kafka、ファイル出力など、700以上のプラグインが利用可能です。
この「Input → Filter → Output」のパイプラインを設定ファイル（fluent.conf）で宣言的に定義するのが、Fluentdの基本的な使い方です。
FluentdとFluent Bitの違い
| 比較項目 | Fluentd | Fluent Bit |
|---|---|---|
| 言語 | Ruby + C | C |
| メモリ使用量 | 約40MB〜 | 約1MB〜 |
| プラグイン数 | 700以上 | 約100 |
| 適したユースケース | ログの集約・加工（アグリゲータ） | エッジでの軽量ログ収集（フォワーダ） |
| Kubernetes環境 | 集約ノードとして利用 | DaemonSetとして各ノードに配置 |
大規模環境では、各ノードにFluent Bitを配置してログを軽量に収集し、Fluentdの集約サーバーで加工・転送するという二段構成がベストプラクティスです。
FluentdとLogstashの比較
ELKスタック（Elasticsearch + Logstash + Kibana）のLogstashはFluentdと同じカテゴリのツールです。
| 比較項目 | Fluentd | Logstash |
|---|---|---|
| 開発元 | Treasure Data → CNCF | Elastic社 |
| 言語 | Ruby + C | Java（JRuby） |
| メモリ消費 | 比較的少ない | JVMのため多い（数百MB〜） |
| 設定形式 | XML風の独自形式 | 独自DSL |
| Kubernetes連携 | CNCFプロジェクトで統合が強力 | Elastic Agentへ移行中 |
| バッファリング | メモリ＋ファイルの二段バッファ | メモリキュー中心 |
Kubernetes環境やCNCFエコシステムとの統合を重視するならFluentd、既にElastic Stackを中心としたインフラがある場合はLogstashが自然な選択です。
Fluentd導入の実践ポイント
バッファリング設計：Fluentdのバッファはメモリバッファとファイルバッファの2種類があります。データロスを防ぐため、本番環境ではファイルバッファを推奨します。出力先が一時的にダウンしても、ファイルにログが蓄積され、復旧後に自動的にリトライされます。
タグによるルーティング：Fluentdはすべてのログイベントに「タグ」を付与し、タグのパターンマッチで出力先を振り分けます。例えば app.web.* はWebサーバーのログ、app.db.* はDBのログ、というようにタグ設計を体系的に行いましょう。
監視とヘルスチェック：Fluentd自体の監視も重要です。monitor_agentプラグインを有効にして、バッファのキュー長やリトライ回数をPrometheusで監視するのが定番の構成です。
よくある質問（FAQ）
Q. FluentdはKubernetes以外でも使えますか？
A. はい。VM、物理サーバー、AWS EC2、オンプレミスなど、あらゆる環境で利用可能です。ただし、Kubernetes環境での採用が圧倒的に多く、ドキュメントや事例もKubernetes中心です。
Q. ログの欠損を防ぐにはどうすればよいですか？
A. ファイルバッファの使用、リトライ設定の適切な調整、Fluentdプロセスの監視とアラート設定が基本です。さらに、At-least-once（最低1回）配信を保証する設定を適用しましょう。
Q. 大量のログでFluentdがボトルネックになりませんか？
A. 単体での処理能力に限界はありますが、マルチプロセスワーカーの設定や、Fluentdの多段構成（フォワーダ→アグリゲータ）、Fluent Bitとの併用で水平スケールが可能です。
まとめ
Fluentdは、多様なソースからログを統合的に収集・転送するための強力なツールです。CNCFのGraduatedプロジェクトとしてKubernetesエコシステムとの統合が特に優れており、700以上のプラグインによる柔軟なパイプライン構築が魅力です。Fluent Bitとの使い分けやバッファリング設計を適切に行うことで、安定した大規模ログ基盤を構築できます。
コメント