LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

ログ収集・転送パイプラインとは——Fluentd/Fluent Bitの役割

Fluentd/Fluent Bitのログ収集・転送パイプラインとは、サーバーやコンテナ上で発生するログをエージェントが読み取り、加工・振り分けを行った上で、検索・分析基盤へ配信する仕組みを指します。Fluentdのイベントは「タグ」「タイムスタンプ」「レコード（JSON形式のログデータ）」の3要素で構成され、この3要素を単位として入力から出力まで処理が進みます^*1。

Fluent Bitでも同様に、取り込まれた各イベントには「タグ」が割り当てられます。このタグは、後段でどのフィルタ・出力段を経由させるかをルーター（Router）が判断するために使う内部識別子です^*2。つまり両ツールとも、タグを軸にイベントを識別し、複数の入力元・出力先を1つのパイプラインで扱える構造を持っています。本稿では、格納・検索基盤の設計ではなく、収集・転送を担うエージェント自体の構成と外注時の論点に絞って解説します。

Input・Parser・Filter・Buffer・Output——5段のプラグイン構造

Fluentdの処理は、設定ファイルに記述した順序に沿って複数のプラグインを通過する形で進みます。基本的な流れは、Input（データソースからイベントを生成）、Filter（条件に基づきイベントを受理または除外）、Buffer（Output側でイベントを蓄積しフラッシュ条件を満たしてから書き込む）、Output（処理済みイベントを目的地へ送信）という順です^*1。Parser（テキストログをフィールドに分解する処理）はInputプラグインの内部、またはFilterの一種として組み込まれることが多く、生ログを構造化データへ変換する役割を担います。

Filterプラグインは、イベントストリームを修正する目的で使われます。代表的なものに、条件に合致するイベントだけを通すgrep、新しいフィールドを追加するrecord_transformerがあります^*3。複数のフィルタが同一タグに適用される場合は、設定ファイルの記述順に上から下へ処理される点も、パイプラインを設計する際の前提になります^*3。

Fluent Bitも構成要素はほぼ共通です。Input（プラグイン単位でイベントを取得）、Filter（内容の修正・追加・削除）、Output（送信先の指定）に加え、パイプライン内でデータを変換するProcessor、タグマッチングでイベントを振り分けるRouterという概念が用いられます^*2。設計思想は近く、Fluentdで組んだパイプライン構成の考え方は、Fluent Bitへ持ち込みやすいといえます。

タグによるルーティングの仕組み

タグは、イベントの生成元を示し、メッセージのルーティングに使う識別子です^*1。Fluentdの設定では、マッチルールでタグをフィルタリングし、条件に合致したイベントだけを特定のOutputプラグインへ振り分けます。複数のInputから集めたログを1本のパイプラインに集約しつつ、種類ごとに異なる出力先へ振り分ける、という運用がタグによって実現します。

複雑な設定を扱う場合は、ラベル機能を使うこともできます。ラベルは、設定ファイルの記述順（トップダウン）に縛られず、リンク参照のように動作するルーティングセクションを定義する仕組みです^*1。パイプラインの分岐が増えるほど、タグとラベルの設計が構成全体の見通しを左右します。

Fluent Bitでは、取り込まれたすべてのイベントにタグが割り当てられ、Routerがこのタグを使って、後段でどのFilter・Output段を経由させるかを判断します^*2。Fluentdと役割は同じですが、Fluent Bit側はC言語で実装された軽量なルーターとして動作する点が異なります。

バッファリングとリトライ——転送失敗にどう備えるか

Fluentdのバッファは「チャンク」という単位で構成されます。チャンクは、イベントを結合した1つのまとまり（blob）として管理され、ファイル形式またはメモリ形式で保持されます^*4。チャンクはステージ（新規イベントで満たされる場所）、キュー（転送待ちの場所）、配信という順で流れていきます^*4。

転送に失敗した場合、Fluentdには組み込みのリトライ機構があります。デフォルトでは指数バックオフを採用し、試行のたびに待機時間が指数的に増えていく仕様です^*4。例えば初期待機1秒・指数因子2の設定では、待機時間は1秒→2秒→4秒→8秒と伸びていきます。待機時間は既定で0.875〜1.125倍の範囲でランダム化され、輻輳を避ける工夫がされています^*4。

連続的な失敗が続く場合、リトライ回数が上限（retry_max_times）を超えるか、最初のリトライから既定で72時間（retry_timeoutのデフォルト値）を超えると、送信自体が中止されます^*4。バッファがディスクを使い切る、あるいは出力先の障害が長時間続くと、ログが欠落するリスクに直結するため、この閾値をどう設定するかは、パイプライン設計における実務上の要点です。

FluentdとFluent Bitの使い分け

FluentdとFluent Bitは同じCNCF傘下のプロジェクトですが、実装と用途に明確な差があります。Fluentdはメモリ使用量が60MB以上、実装言語はCとRubyで、1,000を超える外部プラグインが利用できます^*5。対してFluent BitはメモリがおよそKB単位（450KB程度）、全体がC言語で実装されており、100を超える組み込みプラグインを備えます^*5。Fluent Bitは組み込みLinux・コンテナ・サーバーを対象範囲とし、依存関係を持たない軽量エージェントとして位置づけられています^*5。

両者は競合ではなく併用されることが多く、各ノードにFluent Bitを配置してログを軽量に収集し、後段の集約層でFluentdが多様なプラグインを使って変換・振り分けを担う、という2階層構成もよく採用される設計です。どちらを主軸にするかは、ノード数・必要なプラグインの種類・許容できるリソース消費で判断します。

Kubernetes環境でのDaemonSet配置

Kubernetesクラスタでは、複数のノード上でコンテナが稼働するため、ログエージェントは各ノードで動作する必要があります。公式ドキュメントでも「Fluent Bitのログエージェントは、すべてのPodからログを収集するために、すべてのノードで実行する必要がある」とされ、その実現手段として「Fluent Bitはクラスタの各ノードで実行されるPodであるDaemonSetとしてデプロイされる」と明記されています^*6。DaemonSet（クラスタ内の全ノードに1つずつPodを配置するKubernetesのワークロード種別）を使うことで、ノードの増減に応じてエージェントも自動的に追加・削除される構成になります。

Fluent Bitの稼働時には、Kubernetesフィルタプラグインが各ログエントリにメタデータを付与します。このプラグインはKubernetes APIサーバーと通信し、pod_id・ラベル・アノテーションといった情報を取得する一方、pod_name・container_id・container_nameはローカルから取得し、取得済みの情報はキャッシュしてAPIサーバーへの問い合わせを減らす仕組みになっています^*6。デプロイ自体は公式Helmチャートの利用が推奨されており、リポジトリを追加してインストールする手順が示されています^*6。

Loki・OpenSearch・S3など出力先バックエンドの選択

Fluentdのoutputプラグインには、他のFluentdへ転送するout_forward、ファイルへ出力するout_file、Amazon S3へ出力するout_s3など多様な種類があります^*7。ドキュメントの例ではElasticsearchへの出力にファイルバッファを組み合わせる構成も紹介されており、出力先とバッファの組み合わせは用途に応じて選べる設計です^*7。

実運用では、ログ集約基盤としてLoki・OpenSearch・S3などが出力先の候補になります。バックエンドの選定基準は、検索性能・保持コスト・既存の監視スタックとの統合性など複数の軸で決まるため、格納・検索側の設計は別テーマとして扱うのが適切です。本稿では、収集・転送エージェントの側から見た要点として、出力プラグインの選択肢の広さと、バッファ設定を出力先の特性（書き込みレイテンシ・スループット）に合わせて調整する必要がある、という点を押さえておきます。

導入を内製で進める難易度と外注委託範囲

Fluentd/Fluent Bitのパイプラインを内製で構築・運用するには、複数領域の知識が同時に求められます。タグ設計・Filterプラグインの選定・バッファのチューニング・出力先ごとのプロトコル理解に加え、Kubernetes環境ではDaemonSetのリソース制限やKubernetesフィルタの挙動理解も必要です。設定ミスがそのまま本番ログの欠落や転送遅延に直結するため、検証を伴う段階的な導入が欠かせません。

バッファ設定を誤ると、出力先の障害時にログが失われるリスクがあります。リトライ上限（retry_max_times）や再送タイムアウト（retry_timeout、既定72時間）を出力先の復旧見込みより短く設定すると、復旧前にリトライが打ち切られ、その間のログが失われる可能性があります^*4。障害対応の運用フローと合わせてこの閾値を検討する必要があります。

内製で進める場合と専門パートナーに依頼する場合の違いは、設計の初期段階で顕在化します。内製では、タグ設計・Filter順序・バッファ閾値の妥当性を検証する工数を自社で確保する必要があり、Kubernetes・各出力先バックエンドの双方に詳しい担当者を確保できるかが課題になります。外部パートナーに依頼する場合は、既存のパイプライン構成パターンやトラブルシューティングの知見を活用しながら、要件に応じた設定の妥当性を短期間で検証できる点がメリットです。

外注に委託する範囲は、要件定義（収集対象・出力先・保持期間の整理）、パイプライン設計（タグ・Filter・Buffer構成の設計）、構築・テスト（Kubernetes環境への配置と動作検証）、運用引き継ぎ（監視方法・障害時の切り戻し手順の整備）に分けて検討すると整理しやすくなります。LASSICでは元請（プライムベンダー）としてシステム保守・運用を受託する体制のもと、こうした収集・転送パイプラインの設計から構築、運用引き継ぎまでを一連の工程として支援します。

まとめ：Fluentd/Fluent Bit導入の3つの判断軸

本稿では、Fluentd/Fluent Bitによるログ収集・転送パイプラインについて、プラグイン構造・タグルーティング・バッファリング・Kubernetes配置・外注委託範囲を整理しました。要点は3つに集約できます。第一に、Input・Filter・Buffer・Outputという処理段とタグによるルーティングの仕組みを理解することが設計の土台になります。第二に、FluentdとFluent Bitはメモリ使用量・実装言語・プラグイン数で特性が異なり、ノードごとの軽量収集と集約層での変換を分担する併用構成も選択肢になります。第三に、バッファ・リトライの閾値設定とKubernetesでのDaemonSet配置が、障害時のログ欠落リスクを左右する実務上の要点です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Fluentd「Life of a Fluentd event」
2. *2　出典：Fluent Bit「Key Concepts」
3. *3　出典：Fluentd「Filter Plugins Overview」
4. *4　出典：Fluentd「Buffer Plugins」
5. *5　出典：Fluent Bit「Fluentd & Fluent Bit」
6. *6　出典：Fluent Bit「Kubernetes」
7. *7　出典：Fluentd「Output Plugins Overview」

Tweet