Fluentd は、ログの収集と利用を統合するオープンソースのデータコレクターです。多くのソースから多くの宛先へ、ログデータを追跡、パース、バッファリング、ルーティングし、ログがどのように生成されるかと、最終的にどこにたどり着くか（検索インデックス、オブジェクトストレージ、ログ分析プラットフォーム、あるいはその 3 つすべて）を切り離します。

仕組み

Fluentd は（多くの場合、ノードごとに 1 つの Kubernetes DaemonSet として）エージェントとして動作し、入力プラグインでログデータを読み取り、必要に応じてフィルタープラグインで変換し、出力プラグインで書き出します。このプラグインアーキテクチャにより、1 つの Fluentd パイプラインが、ノードのファイルシステムからコンテナのログを読み取り、異なる形式とリトライの動作を持つ複数の宛先に振り分けることができます。

主要な概念

• 入力プラグイン — ファイル、TCP ソケット、Kubernetes のコンテナログディレクトリなど、ソースからログイベントを読み取ります。
• フィルタープラグイン — 生のログ行から構造化されたフィールドをパースしたり、Kubernetes のメタデータを付与したりするなど、パイプライン内のイベントを変換またはエンリッチします。
• 出力プラグイン — Elasticsearch、S3、Kafka、ホスト型ログプラットフォームなど、数十の宛先にイベントを書き込みます。
• バッファ — 入力と出力の間にある Fluentd 内部のキューで、バックプレッシャーを吸収し、失敗した書き込みをリトライします。

チームが Fluentd を採用する理由

• ベンダー中立。 大規模なプラグインエコシステムにより、ログの宛先の切り替えは、アーキテクチャの作り直しではなく、設定の変更になります。
• 大量のデータ向けに構築。 バッファリングとチャンクのモデルは、バースト的で高スループットなログストリームを確実に処理するように設計されています。
• 構造化されたログモデル。 イベントは生のテキストではなく構造化されたフィールドを持つため、後段のフィルタリングとルーティングがはるかに正確になります。
• CNCF graduated。 可観測性スタックにおける Prometheus の位置づけのロギング版で、広く採用され、活発に保守されています。

はじめに

Fluentd を DaemonSet としてデプロイして、すべてのノードでエージェントが動作するようにし、コンテナのログを追跡するように設定し、ログを最終的に届けたい場所向けの出力プラグインを追加します。以降のガイドでは、最も一般的な収集とルーティングの構成を説明します。