Fluentd v11 内部ルーティングラベルの実装案あれこれ

fluentd-v11-design-label.md

Fluentd v11 内部ルーティングラベルの実装案あれこれ

Fluentd v11 設計案 の「1. 内部ルーティングラベルの導入」について、続き。

実装方法

案1. 新しいメタデータ「label」を導入する

• プラグインは、emitするときにlabelを指定することができる（省略可能）
  • Engine.emit(tag, time, record[, label])
• labelはプラグインには渡されない。ルーティングのみに使われる
  • labelを保存するとか、labelを名前に含めるといった処理はできない

課題

out_forward+in_forward で label を転送するために、プロトコルを拡張する必要がある。互換性を保ったまま拡張することは、可能。

案2. tagの命名規則を拡張する

• tag の末尾に @foobar と付ける。例えば "system.error@count_1h" で、"@count_1h" の部分が label
• label は tag の一部である
• <match> で、* は @ にマッチしない
  • <match system.**> は、"system.error" にマッチする
  • <match system.**> は、"system.error@count_1h" にはマッチしない
• <match> で、@ を明示すれば @ にマッチする
  • <match system.**@count_1h> は、"system.error@count_1h" にマッチする
• @foobar: セクションでは、tagから@foobarが取り除かれる
• labelは完全一致でのみマッチする。* とかワイルドカードは使えない

例えば、

<match system.**>
  # これは system.error@count_1h にマッチしないが
</match>

@count_1h:
<match system.**>
  # これは system.error@count_1h にマッチする
  # 加えてこのプラグインでは、tag は "system.error" に見える（emitされる前に@count_1h が取り除かれている）
</match>

課題

構成要素は少なく済むが、理解は難しくなる。

それから、マッチ条件が複雑になるので、マッチ処理が遅くなる。案1のマッチ処理は、

1. label にマッチ（=ハッシュ表を引く）
2. その label の中の全matchについて、上から順に一つずつマッチするかチェックしていく

という処理になるのに対し、案2は、

1. すべてのmatchについて、上から順に一つずつマッチするかチェックしていく

という処理になるので、案2の方が遅い。

多少最適化するには、マッチ条件を正規表現に変換する際に工夫する。labelのマッチとmatchを合わせて一つの正規表現に変換できるはず。

設定ファイルの書き方

案1. @label:

# デフォルトlabel
<match **>
</match>

@foo:
  <match **>
  </match>
  ...

@bar:
  <match **>
  </match>
  …

# includeを組み合わせる場合
@mylabel:
  include mylabel.conf

@archive:
  include archive.conf

利点と欠点

• 利点
  • 設定ファイルの記述量は少なく済む
  • <match> や <source> と構文が違うので、明らかにtagとは別の情報を扱っていることが分かる
• 欠点
  • @fooの影響範囲の終点が分かりにくい
  • <match> や <source> と構文が違うので、きもちわるい

案1. <@label>…/@label

# デフォルトlabel
<match **>
</match>

<@foo>
  <match **>
  </match>
  ...
</@foo>

<@bar>
  <match **>
  </match>
  …
</@bar>

# includeを組み合わせる場合
<@mylabel>
  include mylabel.conf
</@mylabel>

<@archive>
  include archive.conf
</@archive>

利点と欠点

• 利点
  • <@foo> の影響範囲の終点が一目で分かる
  • <match> や <source> と構文が同じなので、何となくきれい
• 欠点
  • 閉じタグを書くのが面倒
  • <match> や <source> と構文が同じなので、設定ファイルがまったく異なる複数の区画に別れていることを判別しにくい