"tags" as document field for error details causes potential issues

[niklas-kunz]

Logprep currently writes processor errors to a document field named tags.

Example: tags : [ _generic_adder_failure ].

This can be confusing if the original document already contains a field named tags (which often occurs) since there is no clear distinction between document fields and technical/Logprep-generated fields. I therefore propose a different field naming for auxiliary fields in order to make them easily distinguishable from regular document fields. Suggestion: logprep_tags or logprep_failure_tags instead of tags.

[ekneg54]

Thank you for you report.
The currently implemented behavior should not be changed. Instead I suggest to make the target tags field name configurable per rule with a default of "tags". This does not break the API and should resolve your report.

What are your thougths about this?

[niklas-kunz]

I'm not sure what this would look like in practice - would the name of the error tags field have to be configured for each processor then? Since the failure tags can occur for all processors...

[ekneg54]

As the failure tags themselfs it would be configurable on rule basis with a default of tags.

As now the tag_on_failure option of each rule can be used to tag the event with a list of tags which is concatenated to the tags field. The default is ["_<rule_type>_failure"]

The same would be implemented for the tag field name itself. The default is tags, but you will be able to configure this with the future option of tag_on_failure_field.

So it is on the user to decide which field name is suitable for his environment. This will be bettet than renaming this field to another hard coded value.