Fluentd v11 設計案 の「1. 内部ルーティングラベルの導入」について、続き。
- プラグインは、emitするときにlabelを指定することができる（省略可能）
- Engine.emit(tag, time, record[, label])
- labelはプラグインには渡されない。ルーティングのみに使われる
- labelを保存するとか、labelを名前に含めるといった処理はできない
out_forward+in_forward で label を転送するために、プロトコルを拡張する必要がある。互換性を保ったまま拡張することは、可能。
- 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のマッチ処理は、
- label にマッチ（=ハッシュ表を引く）
- その label の中の全matchについて、上から順に一つずつマッチするかチェックしていく
という処理になるのに対し、案2は、
- すべてのmatchについて、上から順に一つずつマッチするかチェックしていく
という処理になるので、案2の方が遅い。
多少最適化するには、マッチ条件を正規表現に変換する際に工夫する。labelのマッチとmatchを合わせて一つの正規表現に変換できるはず。
# デフォルト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> と構文が同じなので、設定ファイルがまったく異なる複数の区画に別れていることを判別しにくい