Logging configuration

Read about the use of logging API in {project-name}, configuring logging output, and using logging adapters to unify the output from other logging APIs.

{includes}/observability-include.adoc

Quarkus uses the JBoss Log Manager logging backend for publishing application and framework logs. Quarkus supports the JBoss Logging API and multiple other logging APIs, seamlessly integrated with JBoss Log Manager. You can use any of the following APIs:

JBoss Logging
JDK java.util.logging (JUL)
SLF4J
Apache Commons Logging
Apache Log4j 2
Apache Log4j 1

Use JBoss Logging for application logging

When using the JBoss Logging API, your application requires no additional dependencies, as {project-name} automatically provides it.

An example of using the JBoss Logging API to log a message:

import org.jboss.logging.Logger;

import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;

@Path("/hello")
public class ExampleResource {

    private static final Logger LOG = Logger.getLogger(ExampleResource.class);

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
        LOG.info("Hello");
        return "hello";
    }
}

Note	While JBoss Logging routes log messages into JBoss Log Manager directly, one of your libraries might rely on a different logging API. In such cases, you need to use a logging adapter to ensure that its log messages are routed to JBoss Log Manager as well.

Get an application logger

To get an application logger in {project-name}, select one of the following approaches.

Declaring a logger field
Simplified logging
Injecting a configured logger

Declaring a logger field

With this classic approach, you use a specific API to obtain a logger instance, store it in a static field of a class, and call logging operations upon this instance.

The same flow can be applied with any of the supported logging APIs.

An example of storing a logger instance into a static field by using the JBoss Logging API:

package com.example;

import org.jboss.logging.Logger;

public class MyService {
    private static final Logger log = Logger.getLogger(MyService.class); (1)

    public void doSomething() {
        log.info("It works!"); (2)
    }
}

Define the logger field.
Invoke the desired logging methods on the log object.

Simplified logging

Quarkus simplifies logging by automatically adding logger fields to classes that use io.quarkus.logging.Log. This eliminates the need for repetitive boilerplate code and enhances logging setup convenience.

An example of simplified logging with static method calls:

package com.example;

import io.quarkus.logging.Log; // (1)

class MyService { // (2)
    public void doSomething() {
        Log.info("Simple!"); // (3)
    }
}

The io.quarkus.logging.Log class contains the same methods as JBoss Logging, except that they are static.
Note that the class does not declare a logger field. This is because during application build, a private static final org.jboss.logging.Logger field is created automatically in each class that uses the Log API. The fully qualified name of the class that calls the Log methods is used as a logger name. In this example, the logger name would be com.example.MyService.
Finally, all calls to Log methods are rewritten to regular JBoss Logging calls on the logger field during the application build.

Warning

Use the Log API only in application classes, not in external dependencies. Log method calls not processed by Quarkus at build time will result in an exception.

Using io.quarkus.logging.Log in extensions:

While the Log API simplifies logging in application classes, it is not recommended for use in extension modules or external dependencies.

The following considerations apply:

io.quarkus.logging.Log depends on Quarkus bytecode transformations that occur at build time.
In extension modules, Log works only if the module includes a Jandex index. However, this behavior is unsupported and can lead to unreliable logging.

For extension development, use org.jboss.logging.Logger.getLogger(String) instead of io.quarkus.logging.Log.

Injecting a configured logger

The injection of a configured org.jboss.logging.Logger logger instance with the @Inject annotation is another alternative to adding an application logger, but is applicable only to CDI beans.

You can use @Inject Logger log, where the logger gets named after the class you inject it to, or @Inject @LoggerName("…") Logger log, where the logger will receive the specified name. Once injected, you can use the log object to invoke logging methods.

An example of two different types of logger injection:

package com.example;

import org.jboss.logging.Logger;

@ApplicationScoped
class SimpleBean {

   @Inject
   Logger log; (1)

   @LoggerName("foo")
   Logger fooLog; (2)

   public void ping() {
     log.info("Simple!");
     fooLog.info("Goes to _foo_ logger!");
   }
}

The fully qualified class name (FQCN) of the declaring class is used as a logger name, for example, org.jboss.logging.Logger.getLogger(SimpleBean.class) will be used.
In this case, the name foo is used as a logger name, for example, org.jboss.logging.Logger.getLogger("foo") will be used.

Note	The logger instances are cached internally. Therefore, when a logger is injected, for example, into a `@RequestScoped` bean, it is shared for all bean instances to avoid possible performance penalties associated with logger instantiation.

Use log levels

{project-name} provides different log levels, which helps developers to control the amount of information logged based on the severity of the events.

Available log levels:

OFF	A special level used in configuration to turn off logging.
FATAL	A critical service failure or total inability to handle any requests.
ERROR	A major issue in processing or an inability to complete a request.
WARN	A non-critical service error or problem that might not require immediate correction.
INFO	Service lifecycle events or other important infrequent information.
DEBUG	Additional information about lifecycle events or events not tied to specific requests, useful for debugging.
TRACE	Detailed per-request debugging information, potentially at a very high frequency.
ALL	A special level to turn on logging for all messages, including custom levels.

You can also configure the following levels for applications and libraries that use java.util.logging:

SEVERE	Same as ERROR.
WARNING	Same as WARN.
CONFIG	Service configuration information.
FINE	Same as DEBUG.
FINER	Same as TRACE.
FINEST	Increased debug output compared to `TRACE`, which might have a higher frequency.

Table 1. The mapping between the levels

Numerical level value	Standard level name	Equivalent `java.util.logging` (JUL) level name
1100	FATAL	Not applicable
1000	ERROR	SEVERE
900	WARN	WARNING
800	INFO	INFO
700	Not applicable	CONFIG
500	DEBUG	FINE
400	TRACE	FINER
300	Not applicable	FINEST

Configure the log level, category, and format

JBoss Logging, integrated into {project-name}, offers a unified configuration for all supported logging APIs through a single configuration file that sets up all available extensions. To adjust runtime logging, modify the application.properties file.

An example of how you can set the default log level to INFO logging and include Hibernate DEBUG logs:

quarkus.log.level=INFO
quarkus.log.category."org.hibernate".level=DEBUG

When you set the log level to below DEBUG, you must also adjust the minimum log level. This setting might be applied either globally with the quarkus.log.min-level configuration property, or per category:

quarkus.log.category."org.hibernate".min-level=TRACE

This sets a floor level for which Quarkus needs to generate supporting code. The minimum log level must be set at build time so that Quarkus can open the door to optimization opportunities where logging on unusable levels can be elided.

An example from native execution:

Setting INFO as the minimum logging level sets lower-level checks, such as isTraceEnabled, to false. This identifies code like if(logger.isDebug()) callMethod(); that will never be executed and mark it as "dead."

Warning

If you add these properties on the command line, ensure the " character is escaped properly:

-Dquarkus.log.category.\"org.hibernate\".level=TRACE

All potential properties are listed in the logging configuration reference section.

Logging categories

Logging is configured on a per-category basis, with each category being configured independently. Configuration for a category applies recursively to all subcategories unless there is a more specific subcategory configuration.

The parent of all logging categories is called the "root category." As the ultimate parent, this category might contain a configuration that applies globally to all other categories. This includes the globally configured handlers and formatters.

Example 1. An example of a global configuration that applies to all categories:

quarkus.log.handlers=con,mylog

quarkus.log.handler.console.con.enable=true
quarkus.log.handler.file.mylog.enable=true

In this example, the root category is configured to use two named handlers: con and mylog.

Example 2. An example of a per-category configuration:

quarkus.log.category."org.apache.kafka.clients".level=INFO
quarkus.log.category."org.apache.kafka.common.utils".level=INFO

This example shows how you can configure the minimal log level on the categories org.apache.kafka.clients and org.apache.kafka.common.utils.

For more information, see Logging configuration reference.

If you want to configure something extra for a specific category, create a named handler like quarkus.log.handler.[console|file|syslog].<your-handler-name>.* and set it up for that category by using quarkus.log.category.<my-category>.handlers.

An example use case can be a desire to use a different timestamp format for log messages which are saved to a file than the format used for other handlers.

For further demonstration, see the outputs of the Attaching named handlers to a category example.

Property Name	Default	Description
`quarkus.log.category."<category-name>".level`	`INFO ^[1]`	The level to use to configure the category named `<category-name>`. The quotes are necessary.
`quarkus.log.category."<category-name>".min-level`	`DEBUG`	The minimum logging level to use to configure the category named `<category-name>`. The quotes are necessary.
`quarkus.log.category."<category-name>".use-parent-handlers`	`true`	Specify whether this logger should send its output to its parent logger.
`quarkus.log.category."<category-name>".handlers=[<handler>]`	`empty ^[2]`	The names of the handlers that you want to attach to a specific category.

Note	The `.` symbol separates the specific parts in the configuration property. The quotes in the property name are used as a required escape to keep category specifications, such as `quarkus.log.category."io.quarkus.smallrye.jwt".level=TRACE`, intact.

Root logger configuration

The root logger category is handled separately, and is configured by using the following properties:

Property Name	Default	Description
`quarkus.log.level`	`INFO`	The default log level for every log category.
`quarkus.log.min-level`	`DEBUG`	The default minimum log level for every log category.

The parent category is examined if no level configuration exists for a given logger category.
The root logger configuration is used if no specific configurations are provided for the category and any of its parent categories.

Note	Although the root logger’s handlers are usually configured directly via `quarkus.log.console`, `quarkus.log.file` and `quarkus.log.syslog`, it can nonetheless have additional named handlers attached to it using the `quarkus.log.handlers` property.

Logging format

{project-name} uses a pattern-based logging formatter that generates human-readable text logs by default, but you can also configure the format for each log handler by using a dedicated property.

For the console handler, the property is quarkus.log.console.format.

The logging format string supports the following symbols:

Symbol	Summary	Description
`%%`	`%`	Renders a simple `%` character.
`%c`	Category	Renders the category name.
`%C`	Source class	Renders the source class name.^[3]
`%d{xxx}`	Date	Renders a date with the given date format string, which uses the syntax defined by `java.text.SimpleDateFormat`.
`%e`	Exception	Renders the thrown exception, if any.
`%F`	Source file	Renders the source file name.^[3]
`%h`	Host name	Renders the system simple host name.
`%H`	Qualified host name	Renders the system’s fully qualified host name, which might be the same as the simple host name, depending on operating system configuration.
`%i`	Process ID	Render the current process PID.
`%l`	Source location	Renders the source location information, which includes source file name, line number, class name, and method name.^[3]
`%L`	Source line	Renders the source line number.^[3]
`%m`	Full Message	Renders the log message plus exception (if any).
`%M`	Source method	Renders the source method name.^[3]
`%n`	Newline	Renders the platform-specific line separator string.
`%N`	Process name	Render the name of the current process.
`%p`	Level	Render the log level of the message.
`%r`	Relative time	Render the time in milliseconds since the start of the application log.
`%s`	Simple message	Renders just the log message, with no exception trace.
`%t`	Thread name	Render the thread name.
`%t{id}`	Thread ID	Render the thread ID.
`%z{<zone name>}`	Time zone	Set the time zone of the output to `<zone name>`.
`%X{<MDC property name>}`	Mapped Diagnostic Context Value	Renders the value from Mapped Diagnostic Context.
`%X`	Mapped Diagnostic Context Values	Renders all the values from Mapped Diagnostic Context in format `{property.key=property.value}`.
`%x`	Nested Diagnostics context values	Renders all the values from Nested Diagnostics Context in format `{value1.value2}`.

Alternative console logging formats

Changing the console log format is useful, for example, when the console output of the Quarkus application is captured by a service that processes and stores the log information for later analysis.

JSON logging format

The quarkus-logging-json extension might be employed to add support for the JSON logging format and its related configuration.

Add this extension to your build file as the following snippet illustrates:
pom.xml
```
<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-logging-json</artifactId>
</dependency>
```
build.gradle
```
implementation("io.quarkus:quarkus-logging-json")
```
By default, the presence of this extension replaces the output format configuration from the console configuration, and the format string and the color settings (if any) are ignored. The other console configuration items, including those that control asynchronous logging and the log level, will continue to be applied.

For some, it will make sense to use humanly readable (unstructured) logging in dev mode and JSON logging (structured) in production mode. This can be achieved using different profiles, as shown in the following configuration.

Disable JSON logging in application.properties for dev and test mode:

%dev.quarkus.log.console.json=false
%test.quarkus.log.console.json=false

Configuration

Configure the JSON logging extension using supported properties to customize its behavior.

{generated-dir}/config/quarkus-logging-json.adoc

Warning

Enabling pretty printing might cause certain processors and JSON parsers to fail.

Note	Printing the details can be expensive as the values are retrieved from the caller. The details include the source class name, source file name, source method name, and source line number.

Log handlers

A log handler is a logging component responsible for the emission of log events to a recipient. {project-name} includes several different log handlers: console, file, and syslog.

The featured examples use com.example as a logging category.

Console log handler

The console log handler is enabled by default, and it directs all log events to the application’s console, usually the system’s stdout.

A global configuration example:

quarkus.log.console.format=%d{yyyy-MM-dd HH:mm:ss} %-5p [%c] (%t) %s%e%n

A per-category configuration example:

quarkus.log.handler.console.my-console-handler.format=%d{yyyy-MM-dd HH:mm:ss} [com.example] %s%e%n

quarkus.log.category."com.example".handlers=my-console-handler
quarkus.log.category."com.example".use-parent-handlers=false

For details about its configuration, see the console logging configuration reference.

File log handler

To log events to a file on the application’s host, use the Quarkus file log handler. The file log handler is disabled by default, so you must first enable it.

The Quarkus file log handler supports log file rotation.

Log file rotation ensures efficient log management by preserving a specified number of backup files while keeping the primary log file updated and at a manageable size.

A global configuration example:

quarkus.log.file.enable=true
quarkus.log.file.path=application.log
quarkus.log.file.format=%d{yyyy-MM-dd HH:mm:ss} %-5p [%c] (%t) %s%e%n

A per-category configuration example:

quarkus.log.handler.file.my-file-handler.enable=true
quarkus.log.handler.file.my-file-handler.path=application.log
quarkus.log.handler.file.my-file-handler.format=%d{yyyy-MM-dd HH:mm:ss} [com.example] %s%e%n

quarkus.log.category."com.example".handlers=my-file-handler
quarkus.log.category."com.example".use-parent-handlers=false

For details about its configuration, see the file logging configuration reference.

Syslog log handler

The syslog handler in Quarkus follows the Syslog protocol, which is used to send log messages on UNIX-like systems. It uses the protocol defined in RFC 5424.

By default, the syslog handler is disabled. When enabled, it sends all log events to a syslog server, typically the local syslog server for the application.

A global configuration example:

quarkus.log.syslog.enable=true
quarkus.log.syslog.app-name=my-application
quarkus.log.syslog.format=%d{yyyy-MM-dd HH:mm:ss} %-5p [%c] (%t) %s%e%n

A per-category configuration example:

quarkus.log.handler.syslog.my-syslog-handler.enable=true
quarkus.log.handler.syslog.my-syslog-handler.app-name=my-application
quarkus.log.handler.syslog.my-syslog-handler.format=%d{yyyy-MM-dd HH:mm:ss} [com.example] %s%e%n

quarkus.log.category."com.example".handlers=my-syslog-handler
quarkus.log.category."com.example".use-parent-handlers=false

For details about its configuration, see the Syslog logging configuration reference.

Socket log handler

This handler sends logs to a socket. Socket log handler is disabled by default; enable it to use it. When enabled, it sends all log events to a socket, such as a Logstash server.

A global configuration example:

quarkus.log.socket.enable=true
quarkus.log.socket.endpoint=localhost:4560

Typically, this handler is used with the quarkus-logging-json extension to send logs in ECS format to an Elasticsearch instance. For an example configuration, see the Centralized log management guide.

Add a logging filter to your log handler

Log handlers, such as the console log handler, can be linked with a filter that determines whether a log record should be logged.

To register a logging filter:

Annotate a final class that implements java.util.logging.Filter with @io.quarkus.logging.LoggingFilter, and set the name property:

An example of writing a filter:

package com.example;

import io.quarkus.logging.LoggingFilter;
import java.util.logging.Filter;
import java.util.logging.LogRecord;

@LoggingFilter(name = "my-filter")
public final class TestFilter implements Filter {

    private final String part;

    public TestFilter(@ConfigProperty(name = "my-filter.part") String part) {
        this.part = part;
    }

    @Override
    public boolean isLoggable(LogRecord record) {
        return !record.getMessage().contains(part);
    }
}

In this example, we exclude log records containing specific text from console logs. The specific text to filter on is not hard-coded; instead, it is read from the my-filter.part configuration property.

An example of Configuring the filter in application.properties:

my-filter.part=TEST

Attach the filter to the corresponding handler using the filter configuration property, located in application.properties:
```
quarkus.log.console.filter=my-filter
```

Examples of logging configurations

The following examples show some of the ways in which you can configure logging in {project-name}:

Console DEBUG logging except for Quarkus logs (INFO), no color, shortened time, shortened category prefixes

quarkus.log.console.format=%d{HH:mm:ss} %-5p [%c{2.}] (%t) %s%e%n
quarkus.log.console.level=DEBUG
quarkus.console.color=false

quarkus.log.category."io.quarkus".level=INFO

Note	If you add these properties in the command line, ensure `"` is escaped. For example, `-Dquarkus.log.category.\"io.quarkus\".level=DEBUG`.

File TRACE logging configuration

quarkus.log.file.enable=true
# Send output to a trace.log file under the /tmp directory
quarkus.log.file.path=/tmp/trace.log
quarkus.log.file.level=TRACE
quarkus.log.file.format=%d{HH:mm:ss} %-5p [%c{2.}] (%t) %s%e%n
# Set 2 categories (io.quarkus.smallrye.jwt, io.undertow.request.security) to TRACE level
quarkus.log.min-level=TRACE
quarkus.log.category."io.quarkus.smallrye.jwt".level=TRACE
quarkus.log.category."io.undertow.request.security".level=TRACE

Note	As we do not change the root logger, the console log contains only `INFO` or higher level logs.

Named handlers attached to a category

# Send output to a trace.log file under the /tmp directory
quarkus.log.file.path=/tmp/trace.log
quarkus.log.console.format=%d{HH:mm:ss} %-5p [%c{2.}] (%t) %s%e%n
# Configure a named handler that logs to console
quarkus.log.handler.console."STRUCTURED_LOGGING".format=%e%n
# Configure a named handler that logs to file
quarkus.log.handler.file."STRUCTURED_LOGGING_FILE".enable=true
quarkus.log.handler.file."STRUCTURED_LOGGING_FILE".format=%e%n
# Configure the category and link the two named handlers to it
quarkus.log.category."io.quarkus.category".level=INFO
quarkus.log.category."io.quarkus.category".handlers=STRUCTURED_LOGGING,STRUCTURED_LOGGING_FILE

Named handlers attached to the root logger

# configure a named file handler that sends the output to 'quarkus.log'
quarkus.log.handler.file.CONSOLE_MIRROR.enable=true
quarkus.log.handler.file.CONSOLE_MIRROR.path=quarkus.log
# attach the handler to the root logger
quarkus.log.handlers=CONSOLE_MIRROR

Centralized log management

Use a centralized location to efficiently collect, store, and analyze log data from various components and instances of the application.

To send logs to a centralized tool such as Graylog, Logstash, or Fluentd, see the Quarkus Centralized log management guide.

OpenTelemetry logging

Logging entries from all appenders can be sent by using OpenTelemetry Logging.

For details, see the Quarkus OpenTelemetry Logging guide.

Configure logging for `@QuarkusTest`

Enable proper logging for @QuarkusTest by setting the java.util.logging.manager system property to org.jboss.logmanager.LogManager.

The system property must be set early on to be effective, so it is recommended to configure it in the build system.

Setting the java.util.logging.manager system property in the Maven Surefire plugin configuration:

<build>
  <plugins>
    <plugin>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>${surefire-plugin.version}</version>
      <configuration>
        <systemPropertyVariables>
          <java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager> (1)
          <quarkus.log.level>DEBUG</quarkus.log.level>  (2)
          <maven.home>${maven.home}</maven.home>
        </systemPropertyVariables>
      </configuration>
    </plugin>
  </plugins>
</build>

Make sure the org.jboss.logmanager.LogManager is used.
Enable debug logging for all logging categories.

For Gradle, add the following configuration to the build.gradle file:

test {
	systemProperty "java.util.logging.manager", "org.jboss.logmanager.LogManager"
}

Use other logging APIs

{project-name} relies on the JBoss Logging library for all the logging requirements.

Suppose you use libraries that depend on other logging libraries, such as Apache Commons Logging, Log4j, or SLF4J. In that case, exclude them from the dependencies and use one of the JBoss Logging adapters.

This is especially important when building native executables, as you could encounter issues similar to the following when compiling the native executable:

Caused by java.lang.ClassNotFoundException: org.apache.commons.logging.impl.LogFactoryImpl

The logging implementation is not included in the native executable, but you can resolve this issue using JBoss Logging adapters.

These adapters are available for popular open-source logging components, as explained in the next chapter.

Add a logging adapter to your application

For each logging API that is not jboss-logging:

Add a logging adapter library to ensure that messages logged through these APIs are routed to the JBoss Log Manager backend.

Note	This step is unnecessary for libraries that are dependencies of a Quarkus extension where the extension handles it automatically.

Apache Commons Logging:

pom.xml

<dependency>
    <groupId>org.jboss.logging</groupId>
    <artifactId>commons-logging-jboss-logging</artifactId>
</dependency>

build.gradle

implementation("org.jboss.logging:commons-logging-jboss-logging")

Log4j:

pom.xml

<dependency>
    <groupId>org.jboss.logmanager</groupId>
    <artifactId>log4j-jboss-logmanager</artifactId>
</dependency>

build.gradle

implementation("org.jboss.logmanager:log4j-jboss-logmanager")

Log4j 2:

pom.xml

<dependency>
    <groupId>org.jboss.logmanager</groupId>
    <artifactId>log4j2-jboss-logmanager</artifactId>
</dependency>

build.gradle

implementation("org.jboss.logmanager:log4j2-jboss-logmanager")

Note	Do not include any Log4j dependencies, as the `log4j2-jboss-logmanager` library contains everything needed to use Log4j as a logging implementation.

SLF4J:

pom.xml

<dependency>
    <groupId>org.jboss.slf4j</groupId>
    <artifactId>slf4j-jboss-logmanager</artifactId>
</dependency>

build.gradle

implementation("org.jboss.slf4j:slf4j-jboss-logmanager")

Verify whether the logs generated by the added library adhere to the same format as the other Quarkus logs.

Use MDC to add contextual log information

Quarkus overrides the logging Mapped Diagnostic Context (MDC) to improve compatibility with its reactive core.

Add and read MDC data

To add data to the MDC and extract it in your log output:

Use the MDC class to set the data.

Add import org.jboss.logmanager.MDC;

Set MDC.put(…) as shown in the example below:

An example with JBoss Logging and io.quarkus.logging.Log

package me.sample;

import io.quarkus.logging.Log;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import org.jboss.logmanager.MDC;

import java.util.UUID;

@Path("/hello/jboss")
public class GreetingResourceJbossLogging {

    @GET
    @Path("/test")
    public String greeting() {
        MDC.put("request.id", UUID.randomUUID().toString());
        MDC.put("request.path", "/hello/test");
        Log.info("request received");
        return "hello world!";
    }
}

Configure the log format to use %X{mdc-key}:

quarkus.log.console.format=%d{HH:mm:ss} %-5p request.id=%X{request.id} request.path=%X{request.path} [%c{2.}] (%t) %s%n

The resulting message contains the MDC data:

08:48:13 INFO request.id=c37a3a36-b7f6-4492-83a1-de41dbc26fe2 request.path=/hello/test [me.sa.GreetingResourceJbossLogging] (executor-thread-1) request received

MDC and supported logging APIs

Based on your logging API, use one of the following MDC classes:

Log4j 1 - org.apache.log4j.MDC.put(key, value)
Log4j 2 - org.apache.logging.log4j.ThreadContext.put(key, value)
SLF4J - org.slf4j.MDC.put(key, value)

MDC propagation

In Quarkus, the MDC provider has a specific implementation for handling the reactive context, ensuring that MDC data is propagated during reactive and asynchronous processing.

As a result, you can still access the MDC data in various scenarios:

After asynchronous calls, for example, when a REST client returns a Uni.
In code submitted to org.eclipse.microprofile.context.ManagedExecutor.
In code executed with vertx.executeBlocking().

Note	If applicable, MDC data is stored in a duplicated context, which is an isolated context for processing a single task or request.