A counter-intuitive behavior for fluent.(error|warn|info|trace) logs

[kiyoto]

Currently (at least for v0.10.57), the only way to match Fluentd's own logs is to use the fluent.** match pattern.

E.g.

The following configuration outputs fluent.warn events to stdout

<match fluent.**>
  type stdout
</match>

but the following configuration does NOT

<match fluent.warn>
  type stdout
</match>

This happens because

1. fluent.* events are emitted by Engine.log_event_loop which is only turned on if the tag fluent is matched by an output (So, <match fluent.warn> does NOT turn this on. <match fluent.**> and <match fluent> does).
2. But individual events have fluent.<LOG_LEVEL> tags.

This behavior breaks Fluentd's match semantics.

[tagomoris]

This behavior is brought by:

• default tag value fluent of global $log
  • https://github.com/fluent/fluentd/blob/master/lib/fluent/log.rb#L61
• event router matcher for logger tags
  • https://github.com/fluent/fluentd/blob/master/lib/fluent/engine.rb#L153

[repeatedly]

Another idea is introducing @LOG label to handle these logs.

[kiyoto]

@repeatedly Do you mean like @ERROR here? Perhaps it is best to start a new discussion specifically on "How plugin-specific log messages should work".

[repeatedly]

Yes. The merit is to separate normal event and fluentd's internal event.
The demerit is only v0.12 or later.