ECS log-format doesn't comply for trace fields

[kerkhofsd]

Description

Since 3.17, Quarkus supports the ECS log-format (introduced in #43232). For example by setting following property:

quarkus.log.console.json.log-format=ecs

According to the ECS Tracing Field Details, expected fields are span.id, trace.id, ...

However AS-IS the ecs log-format still results in the nested MDC object:

... "mdc":{"spanId":"00919aa23135a7ed","parentId":"00919aa23135a7ed","traceId":"62c2815679af74499c27d6bc584b0ffb","sampled":"true"}, ...

Furthermore, I currently don't see any way possible to get the log keys compliant to the "ECS Tracing Field Details" specs.
I tried with quarkus.log.console.json.key-overrides=mdc.traceId=trace.id, which results in IllegalArgumentException: No enum constant org.jboss.logmanager.formatters.StructuredFormatter.Key.MDC.TRACEID

Implementation ideas

In case the ecs log format is configured, by default use trace field logging keys as per ECS specification.

[quarkus-bot]

/cc @brunobat (opentelemetry), @radcortez (opentelemetry)

[brunobat]

The tracing data is in the MDC context.
There needs to be an additional log formatting in the ECS side to place that data in the correct fields.

[gsmet]

@troosan any chance you could have a look?

[troosan]

indeed, I'm aware of this, which is why as a workaround I proposed a logstash filter to move the info to the right place
#43232 (comment)

and this is what is documented here
https://quarkus.io/guides/centralized-log-management#logstash_ecs

there would be work to do to abstract the work done for the google cloud logging
#43232 (comment)

[Malandril]

If you switch to the quarkiverse logging extension

<dependency>
    <groupId>io.quarkiverse.loggingjson</groupId>
    <artifactId>quarkus-logging-json</artifactId>
    <version>3.1.0</version>
</dependency>

You can use the following which will map keys from the MDC to the correct elastic keys JsonProvider which works well:

@Singleton
public class ElasticLogJsonProvider implements JsonProvider {
    public static final String TRACE_ID = "traceId";
    public static final String SPAN_ID = "spanId";
    public static final String ECS_TRACE_ID = "trace.id";
    public static final String ECS_SPAN_ID = "span.id";

    @Override
    public void writeTo(JsonGenerator generator, ExtLogRecord event) throws IOException {
        renameToElasticField(event, generator, TRACE_ID, ECS_TRACE_ID);
        renameToElasticField(event, generator, SPAN_ID, ECS_SPAN_ID);
    }

    private static void renameToElasticField(ExtLogRecord event, JsonGenerator generator, String source, String ecsKey) throws IOException {
        String value = event.getMdc(source);
        if (value != null) {
            event.removeMdc(source);
            generator.writeStringField(ecsKey, value);
        }
    }
}

[troosan]

indeed, that will work with the io.quarkiverse.loggingjson but not with the core io.quarkus quarkus-logging-json
IMHO only one of the two should be kept

[Malandril]

Oh sorry i didn't notice there were different, and yeah its confusing, you can't easily know what features are different between the two, i edited the comment, to clarify it.

[kerkhofsd]

@troosan thank you for referencing relevant comments in the related pull request. They give great insights and a good workaround.
Unfortunately, we cannot apply the proposed Logstash workaround.
Always happy to check if I can contribute, if you think that's feasible and you can give me some pointers.

@Malandril thank you for the proposed workaround! However I'd love to see this implemented in ´io.quarkus:quarkus-logging-json´, especially since the ECS log format is "officially supported" since Quarkus 3.17.

[troosan]

I opened a PR on the quarkiverse version of quarkus-logging-json to support the logging of trace.id and span.id
quarkiverse/quarkus-logging-json#343