Just like the base fields, the tracing fields are not nested under the name of the field set. So it's not base.@timestamp, it's @timestamp, and it's not tracing.trace.id, it's trace.id.
In the Beats field yaml file the ECS project generates, the tracing fields are incorrectly nested under a tracing section, which means Beats interprets the field names incorrectly (tracing.trace.id).
This is a bug, these fields shouldn't be nested this way.
In order to fix this issue, we should remove this nesting in the Beats yml output. Just like @timestamp and other base fields are not nested under a field group.
I think this bug fix will be at minimum backported to 1.7. Thoughts welcome on this, is there a need to backport to 1.6 as well?
The Beats PR elastic/beats#22571 to import ECS 1.7 should be adjusted with these changes, once the bug fix is ready. cc @andrewstucki
Just like the
basefields, thetracingfields are not nested under the name of the field set. So it's notbase.@timestamp, it's@timestamp, and it's nottracing.trace.id, it'strace.id.In the Beats field yaml file the ECS project generates, the tracing fields are incorrectly nested under a
tracingsection, which means Beats interprets the field names incorrectly (tracing.trace.id).This is a bug, these fields shouldn't be nested this way.
In order to fix this issue, we should remove this nesting in the Beats yml output. Just like
@timestampand other base fields are not nested under a field group.I think this bug fix will be at minimum backported to 1.7. Thoughts welcome on this, is there a need to backport to 1.6 as well?
The Beats PR elastic/beats#22571 to import ECS 1.7 should be adjusted with these changes, once the bug fix is ready. cc @andrewstucki