Closed yaauie closed 3 years ago
@kares and I discussed a plan-of-attack here:
ecs_compatibility
setting provided by the ECS Compatibility Support mixin.A quick fix while migrations / new patterns are being created would be recommend using something like the "target" option so legacy patterns can be used with ECS indices by just shoving all the grok fields under a nested folder ie "logtype.fieldname". I dont think this would need an extra option maybe just some docs. You wouldn't have any of the magic ECS correlation fields but you could ingest your logs for the moment without errors.
Thanks Thomas, we already introduced target => ...
in plugin version 4.3.0
and we are planning shipping both "legacy" patterns as well as those that will have their captures ecs compatible.
Another think to consider will be defaulting overwrite => [ message ]
in ECS mode. Since the source string is usually under message
and most 'line' grok matches are going to produce a message
field which is meant to replace the original field (which should be stored under event.original
pretty much right after being constructed from the input).
As a part of the effort to make plugins able to run in an ECS-Compatible manner by default in an upcoming release of Logstash, this plugin needs to implement an ECS-Compatibility mode that does not implicitly use fields that conflict with ECS, including named captures in sub-patterns.