Fluentd のパイプライン、つまり収集、変換、送信は、少数のディレクティブから構築された 1 つの設定ファイルだけで表現されます。このガイドでは、各ディレクティブの役割、タグがそれらをどうつなぐか、実際のトラフィックを任せる前に設定を確認する方法を説明します。

設定ファイルの場所

Fluentd 自身のパッケージ版ディストリビューションは fluent-package と呼ばれます（以前の名前 td-agent の後継です。td-agent に言及しているドキュメントやチュートリアルを読むときは、以前のブランド名での同じプロジェクトです）。この方法でインストールした場合、設定ファイルは通常 /etc/fluent/fluentd.conf にあります。別の組織が保守している別のディストリビューションである Calyptia Fluentd は、独自のパスを使います。場所を決めつけず、お使いのインストール方法のドキュメントで正確な場所を確認してください。

3 つの中心的なディレクティブ

• <source> は、ログデータの出所を定義します。各 source はプラグインの @type（ファイルを追跡する tail、HTTP でエントリを受け付ける http など）を宣言し、そして重要なことに、tag を宣言します。これは、このソースからのすべてのエントリが、パイプラインの残りを通じて持ち続けるラベルです。
• <filter> は、指定されたタグパターンに一致するエントリを、出力に到達する前に、その場で処理します。一般的な用途は、フィールドの追加（エンリッチメント）、フィールドの削除（マスキング）、パターンに一致するエントリの完全な破棄です。
• <match> は、一致するエントリが実際に送られる場所です。<filter> と同様にタグパターンに限定されますが、その場でデータを変換するのではなく、パイプラインの出力段階です。出力先と、そこへの書き込み方法を知っているプラグインの @type を指定します。

<source>
  @type tail
  path /var/log/apache2/access.log
  pos_file /var/log/fluent/apache-access.log.pos
  tag apache.access
  <parse>
    @type apache2
  </parse>
</source>

<filter apache.access>
  @type record_transformer
  remove_keys host
</filter>

<match apache.access>
  @type elasticsearch
  host localhost
  port 9200
  index_name fluentd-apache
</match>

上から下へ読みます。source は Apache のアクセスログを追跡し、Fluentd に組み込みの Apache ログ形式パーサーで各行をパースし、結果の各エントリに apache.access というタグを付けます。同じタグに限定された filter は、先へ進む前に各エントリから host フィールドを削除します。同じくそのタグに限定された match は、（マスキング済みの）エントリを Elasticsearch に送信します。

完全一致だけでなく、タグのパターンマッチ

<filter> や <match> ブロックのタグパターンは、厳密な文字列である必要はありません。apache.* は apache. で始まるあらゆるタグに一致し、** はすべてに一致します。これがルーティングを柔軟にします。1 つの <match **> ブロックが包括的な出力先として機能し、より具体的なパターンが特定のソースを別の方法で処理できます。1 つのソースのデータはマスキングし、別のものはしない、あるいは異なるソースをまったく別の出力先に送る、といったことです。

データの読み取り：入れ子の <parse> ブロック

生のログ行を構造化されたキーと値のデータに変換するのはパーサーの仕事で、source 内の入れ子の <parse> ブロックとして設定します（この入れ子の形式が現在の Fluentd の構文です。古い設定例では、パースのオプションを source に直接フラットなパラメーターとして示していることがありますが、これは古いスタイルで、現在のバージョンが期待する書き方ではありません）。Fluentd には、一般的な形式のパーサーが最初から付属しています。json、apache2、nginx、syslog、csv、そして組み込みの形式に一致しないものを扱う regexp パーサーです。

<parse>
  @type json
</parse>

ソースに適したパーサーを選ぶことが、構造化されていないテキスト行を、不透明なテキストの塊ではなく、後段で個別にフィルター、エンリッチ、クエリできるフィールドに変えるのです。

include で設定を構造化する

設定が複数のソースをカバーするようになると、すべてを 1 つのファイルに保つのは扱いにくくなります。@include ディレクティブは、設定を複数のファイルに分割します。

# fluentd.conf
@include apache.conf
@include containers.conf
@include outputs.conf

含まれる各ファイルは、それぞれの <source>、<filter>、<match> ブロックを持ち、Fluentd はそれらを、インラインで書かれているかのように組み立てます。これは純粋に整理のためのもので、タグ、マッチング、処理の仕組みは変わらず、設定が増えても読みやすさを保つための手段にすぎません。

実行前に検証する

Fluentd を実際に起動する前に、設定が実際に正しい形式であることを確認します。

fluentd --dry-run -c /etc/fluent/fluentd.conf

これは、実際のログデータを処理せずに、設定を解析して検証します。dry run がきれいに通っても、パイプラインが意図どおりに動作することは保証されません。それには実際のデータでのテストが必要ですが、明らかな構文エラーやプラグインの設定ミスを、分かりにくい実行時の失敗として現れる前に見つけられます。

実行して動作を確認する

手動テストの場合（管理されたバックグラウンドサービスとして Fluentd を動かす、本番での通常の動かし方とは異なります）：

fluentd -c /etc/fluent/fluentd.conf

ファイルを追跡する source と、@type stdout に書き込む match があれば、ソースファイルに新しい行が書き込まれるにつれて、エントリがパイプラインを流れる様子をリアルタイムで確認できます。実際の出力先に向ける前に、新しい source や filter が期待どおりに動作しているかを確認する、手早い方法です。