Support for Contextual Logging / Log Correlation

Description

Currently it is very hard if not impossible to enrich log messages related to a request or message with additional context information (e.g. a “correlation-id”). For SREs / operations it is very important to be able to correlate log messages and filter the messages in a log management tool for faster issue analysis. This is often achieved by passing some context attributes along the processing chain that will appear in all logs of related tasks of all involved systems. JBoss-Logging and slf4j provide an MDC object that allows to set context information that is available in the logger and can be included in the log-format. Since the MDC internally uses a ThreadLocal object to associate the context information, this information is lost, if the thread is switched (e.g. due to a blocking execution from a vert.x-eventloop-thread to an executor-thread). The goal of this ticket is to either make MDC work or offer an alternative solution to be able to include context information in the related log messages - which means passing context information along the execution chain.

Implementation ideas

See also https://quarkusio.zulipchat.com/#narrow/stream/187030-users/topic/Contextual.20Logging.20in.20Quarkus

[luneo7]

Created a new issue (https://github.com/quarkusio/quarkus/issues/25818) to track Infrastructure.getDefaultWorkerPool() not propagating Vert.x Context, and used OpenTelemetry as a reproducer there.

[luneo7]

For what I see, it is a design flaw, the executor that Quarkus uses is the EnhancedQueueExecutor (https://github.com/jbossas/jboss-threads/blob/main/src/main/java/org/jboss/threads/EnhancedQueueExecutor.java) it has a context handler that is set to get the current Vertx context. But SmallRye Infrastructure. getDefaultWorkerPool() uses a MutinyScheduler that wraps the EnhancedQueueExecutor and it is a ScheduledThreadPoolExecutor, the EnhancedQueueExecutor just fetches the context when the task is about to run, not when you submit the task to the executor, so when/where the task is actually run in the MutinyScheduler the vertx context doesn’t exists, thus it is always null, and it doesn’t get propagated.