out_copy とout_relabel の組み合わせによるイベントの挙動を教えてください

[mikankun1003]

forwarder から受信したevent を全量all.log に出力したい。かつ、record 中でlevel:info のkey:value を持つ場合はinfo.log にも出力したい( level ごとのファイルと、全量ファイルを出力したい)です。
out_copy のmode:no_copy を使ってevent を複製して、それぞれをrelabel してlevel 出力と全量出力をするようにしています。
(out_copy のmode:no_copy 、実は複製していないらしいけど、これがイマイチ理解できていない)

出力自体の実現はできているのですが、fluentd の挙動が分からないのでもしよければ教えてください。

以下のように設定しているのですが、out_copy のmode:no_copy はあくまで「event をplugin 間で共有している」とあります。
https://docs.fluentd.org/output/copy#copy_mode

このため、設定上は@rewrite_tag でも@all_out_file でもevent は共有されていると思っています。
けれど、実際に動かしてみるとちゃんと@rewrite_tag ではtag は変更されてmatch によってファイル出力しているし
一方の@all_out_file では元のtag がmatch してファイル出力されています。
これは、out_copy(no_copy) ではevent ではなく、tag,time,record のうちrecord を共有する、という意味なのでしょうか。
それとも、relabel しているために元のevent が別々のpipeline で処理されることから、実際にはdeep_copy のような振る舞いをしているのでしょうか。
label によるpipeline の分岐では、一方のpipeline にルーティングされたevent は他のpipeline での影響を受けないという理解のため、よくわからなくなってしまっています。。

※イベントの複製
<match hoge.*>
  @type copy
  <store>
    @type relabel
    @label @rewrite_tag
  </store>
  <store>
    @type relabel
    @label @all_out_file
  </store>
</match>

※level キーを持つレコードにlevel ごとのタグをつける(info のみ記載、実際にはemer などほかにもある)
<label @rewrite_tag>
  <match hoge.*>
    @type rewrite_tag_filter
    <rule>
      key $log
      pattern info
      tag fuga_info
    </rule>
  </match>
  <match fuga_*>
    @type file....

※全量出力
<label @all_out_file>
  <match hoge_*>
    @type file....

[daipom]

やりたいことはできているが、疑問点が残っている、ということですかね？
もしもっとこれがこうならこうできて嬉しい、という点があれば教えてください！

以下、僕の理解を説明します。

out_copy のmode:no_copy を使ってevent を複製
(out_copy のmode:no_copy 、実は複製していないらしいけど、これがイマイチ理解できていない)

out_copyのcopy_mode no_copy(デフォルト)は、複製していません！
複製せずに同じオブジェクトを各storeに渡します。(同じオブジェクトを共有します)
そのため処理効率は良いですが、どこかのstoreでイベントに変更を加える場合は、意図せず他に影響することを防ぐために必要に応じてshallowやdeepを設定することになります。

実際に動かしてみるとちゃんと@rewrite_tag ではtag は変更されてmatch によってファイル出力しているし
一方の@all_out_file では元のtag がmatch してファイル出力されています。
これは、out_copy(no_copy) ではevent ではなく、tag,time,record のうちrecord を共有する、という意味なのでしょうか。
それとも、relabel しているために元のevent が別々のpipeline で処理されることから、実際にはdeep_copy のような振る舞いをしているのでしょうか。

timeとrecordを共有することになります。

これはドキュメントがやや不正確だと思いました。
ドキュメントでは「イベントを共有する」という説明になっていて、確かにFluentdのイベントは「tag, time, record」の3つからなるという定義ですので、tagまで共有しているという誤解を招きそうです。
(「イベントを共有する」と言いたくなる気持ちも分かります。。この辺りは難しさを感じます。。)

tagはイベントのルーティングに使われるもので、timeとrecordとは少し異質なんです。
rewrite_tag_filterプラグインは、イベントのtagを変更しているというよりも、イベントに別のtagを付け直して再ルーティングさせている、といった方が正しいと思います。

同じイベントの構成要素でもtagだけはちょっと異質なんだな、rewrite_tag_filterプラグインはtagを付け直して再ルーティングさせているんだな、とまずは思っていただければと思います。
ちなみにラベルの中でrewrite_tag_filterプラグインを使うと、そのラベル内に限定して再ルーティングされます。(未確認ですが、他のラベルを明示的に指定すればラベルの外にも出せるのかもしれません)

まとめると、out_copyをどう使おうと、rewrite_tag_filterプラグインによる再ルーティングには影響ないと思います。

[mikankun1003]

timeとrecordを共有することになります。
ドキュメントでは「イベントを共有する」という説明になっていて、確かにFluentdのイベントは「tag, time, record」の3つからなるという定義ですので、tagまで共有しているという誤解を招きそうです。

ご回答ありがとうございます！ここが一番知りたかった(有識者に太鼓判を押してほしかった)ところでした。

ruby が読めないため公式のドキュメントに書いてあることが正であると考える必要があり、となるとドキュメント上の記述と実際の動作が異なっているため、他のプラグインの影響を受けている ( ここだとrelabel ) のかなと考えていました。
本件は疑問の解消が目的でしたので、以上になります！

[daipom]

よかったです！