Multi offer a
log operator that can be used to trace events as they flow through operators.
Mutiny does not make any assumption on how logging is defined, and does not rely on any specific logging API.
Using a logging operator#
log method comes in 2 forms: one that takes an identifier and one that derives the identifier from the upstream class:
log operator traces all events between the
onItem().transform(...) operator and the subscriber, as in the following output:
11:01:48.709 [main] INFO Multi.MultiMapOp.0 - onSubscription() 11:01:48.711 [main] INFO Multi.MultiMapOp.0 - request(9223372036854775807) 11:01:48.711 [main] INFO Multi.MultiMapOp.0 - onItem(10) >>> 10 11:01:48.711 [main] INFO Multi.MultiMapOp.0 - onItem(20) >>> 20 11:01:48.711 [main] INFO Multi.MultiMapOp.0 - onItem(30) >>> 30 11:01:48.711 [main] INFO Multi.MultiMapOp.0 - onCompletion()
There are a few things to note here:
- we are logging on a
Multi, so the logging event is prefixed with
Uniin the case of a…
- since we did not specify any identifier in the
MultiMapOphas been derived from the preceding operator (non-qualified) class name, and
- since there can be multiple subscriptions an integer is appended to the identifier (
What happens when events are being logged is defined with the
Events are written by default to the standard console output in a format similar to:
The following is an example of configuring logging with http://www.slf4j.org[SLF4J]:
Note that this is only useful to do when embedding Mutiny in your own stack, some frameworks like Quarkus will already have defined the correct logging strategy.