v1でのラベル and フィルタの実装

filter_and_label.md

v11は互換性が無かったためガリガリと実装出来たが，v1ではそれは出来ないため，必要な機能だけうまくマージする必要がある．

Agent

プラグイン群の実行単位としてAgentを導入して，Engineはそのrootを指すようにした．ラベルもAgentの一部で，いくつかの処理はrootに委譲する． RootAgentはsourceを持てるが，Labelなどは実装的に持てなくなっている．

名前はcontextとかの方がいいかもしれない？

InputもOutputもAgentではない

v11でなんでこれらがAgentだったのか設計は覚えていないのだけど，多分問題ない？Inputがネストしたmatchを持てたからかな…？

もちろんHasNestedMatchモジュールも削除

EventRouter

Agentの中で実際にtagをルーティングする所．Filterもこの中でハンドリングする．OutputもFilter群も，キャッシュすればそれなりに高速に動くはず

フィルタ

上から順番に適用される

class Filter
  def filter(tag, time, record)
    # record_reformerなどレコード本体を弄る向け
    # recordを返り値にすべき？
  end

  def filter_stream(tag, es)
    # filter_streamはデフォルトではfilterメソッドを呼ぶ
    # esを返す必要がある
    # grepなどのプラグインはこちらをoverwriteする
  end
end

Collector

v11でOutputやFilterをまとめてこう呼んでいたので，一部でこの名前をそのまま変数名やドキュメントで流用している．v11ではCollectorとしてAPIと提供していたが，v1ではFilterとOutputでAPIを同じにするのは難しいため，今回は入れてない

特別なラベル

<label @ERROR>があれば，デフォルトのemitエラー時の例外を投げるだけの処理を，Outputプラグインに投げるように置き換えることが出来る．

<label @LOG>は何に使うのか忘れたので，現状未実装．

Agentは、起動/終了操作のために追加したもの。ネストしたAgentを持つAgent（≒ネストしたoutputプラグインを持つoutputプラグイン。例えばout_copyとか）があるときに、その起動と終了をプラグイン側でなくFluentdコア（Worker）で処理するため。主にはマルチプロセス対応で必要だった。

HasNestedMatchは、RootAgentとLabelでコードを共通化する目的が主。lib/plugin/*以下にあるモジュールでは無いので、プラグイン向けAPIではない。

filter_streamメソッドを入れるか否かは、<label @ERROR> をどう実装するかを一度考慮した方が良いと思う。grep系はfilterでnilを返しても良いので。

<label @LOG>は、fluent.* の置き換え。<match **>で fluent.* が混じるのを避けたい人向け。
あと<label @LOG>内の<match PLUGIN_NAME>で、特定プラグインからのログだけを収集できるようにする目論見もあった。

その起動と終了をプラグイン側でなくFluentdコア（Worker）で処理するため。主にはマルチプロセス対応で必要だった。

v11の実装でWorker側で処理出来るのは理解したけど，これって今のrootから順番に辿ってどんどん起動/終了していく，だとなんかまずい所がある？Worker側で直接start/shutdown/close呼ぶ必要がある？

filter_streamメソッドを入れるか否かは、<label @error> をどう実装するかを一度考慮した方が良いと思う。

grep系みたいにストリーム全体に対して行うフィルターはこれ系が必須だと思われる(過去のemits相当?)．<label @ERROR>の場合，デフォルトだと失敗したEventStreamをそのまま渡すのが，現状のAPIを維持したままだとベターかなと．v11のようにemit(tag, time, record)が全体通して統一されていないv1(v0.10)だと，本当に1レコードずつ@ERRORに流すなら，router.error_emit()みたいな便利メソッドを提供するか，format周りで適宜begin - rescueを挟む感じになるかなと思っている

<label @log>は、fluent.* の置き換え。<match **>で fluent.* が混じるのを避けたい人向け。
あと<label @log>内ので、特定プラグインからのログだけを収集できるようにする目論見もあった。

ああ，なるほど．しかし今のところ <match fluent**> で苦情は来てない感じがするし，当分は問題なさそう？

Worker側で直接start/shutdown/close呼ぶ必要がある？
いや、必要は無い。プラグインの実装は簡単になる。
以前（かなり前）のマルチプロセス実装だと、ネストしたoutputプラグインの内の子outputだけを別プロセスに割り付ける…みたいな設定が可能だったので、必要だった。

router.error_emit()みたいな便利メソッドを提供するか，format周りで適宜begin - rescue
便利メソッドを提供するのは良さそう。
そうするとoutputプラグイン側にもrouter（と言うか@ERRORラベルへのcollector）を持たせる必要があって、@ERRORラベル内のoutputがエラーを吐いたら無限ループしてマズイ…という話が起きうるので、RootAgentProxyWithoutErrorCollectorのようなハックがあった。

ネストしたoutputプラグインの内の子outputだけを別プロセスに割り付ける…みたいな設定が可能だったので、必要だった。

OK. 把握した

flowcounterみたいなプラグインがあるから，それもどうするかだなぁ．結局routerが必要か…