Allow structured logging with relocated or disabled context elements

[philwebb]

Our structure logging currently always adds MDC items. It's possible that user doesn't want them so we should offer a property to disable the feature. We could also offer a way to locate MDC content under a different key (e.g. under labels in ECS logging.

[lauroschuck]

@philwebb Thanks for this feature, I wanted this for a long time. However, I think that it has a problem by using the same prefix for MDC and key-value pairs.

MDC fits well with ECS's description for labels, which is modelled to only accept keyword (plain Strings, exactly what MDC values are). This is exactly my use case, I want to nest MDC values into labels.

Key-value pairs are structured data, I never used them, but I assume that's what you would use if you wanted to include geodata, for example (as mentioned in the previous issue 45063). And then you really don't want them prefixed, you'd want them in the root.

Example (Spring Boot 3.5.0-RC1):

application.yaml:

logging:
  structured:
    format:
      console: ecs
    json:
      context:
        prefix: labels

Code:

MDC.put("user-id", "abc123");
log.atInfo().addKeyValue("geo.city_name", "London").setMessage("My message").log();

Result:

{"@timestamp":"2025-05-21T14:30:41.130217448Z","log":{"level":"INFO","logger":"MyClass"},"process":{"pid":1185729,"thread":{"name":"main"}},"message":"My message","labels":{"user-id":"abc123","geo":{"city_name":"London"}},"ecs":{"version":"8.11"}}

As you can see, now I have labels.user-id as I need it, but the geodata is labels.geo.city_name, which violates ECS schema for labels (would cause this event to be dropped during ingestion). It would be good if key-pairs could be prefixed differently (like logging.structured.json.mdc.context and logging.structured.json.key-value.context), or at least that only MDC gets prefixed like that and key-pairs are not.

[philwebb]

@lauroschuck I've opened #45641 to see what we can do to support this. It's a little interesting because Logback and Log4J have different features and so far we haven't need properties that apply to only one.