Add_field order of execution

Dan_Markhasin · July 22, 2018, 3:15pm

I've noticed that the add_field operation is executed last - this is not explicitly documented and causes unexpected behavior when doing something like:

mutate
{
add_field => {"target" => "foo"}
add_field => {"[@metadata][source]" => "bar"}
copy => {"[@metadata][source]" => "target"}
}

The result is "target" => "foo" rather than the expected "bar".

Is there any way to change this behavior?

magnusbaeck · July 22, 2018, 3:25pm

I've noticed that the add_field operation is executed last - this is not explicitly documented

No, I guess not. The add_field docs say "If this filter is successful, add any arbitrary fields to this event" which implies that it executes last.

Is there any way to change this behavior?

No. Do not rely on the execution order of the options listed in a mutate filter. If there are dependencies between them you need to use multiple mutate filters.

Badger · July 22, 2018, 3:37pm

In addition to decoration being executed last, the order of the mutate specific functions is also fixed, as you will see if you check the source...

github.com

logstash-plugins/logstash-filter-mutate/blob/9ef63d37a2d67c57aa818c4fb4ef4f21aaa0da3f/lib/logstash/filters/mutate.rb#L248-L253


      
          coerce(event) if @coerce
          rename(event) if @rename
          update(event) if @update
          replace(event) if @replace
          convert(event) if @convert
          gsub(event) if @gsub

system · August 19, 2018, 3:51pm

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.