Correlate UUIDs across Appenders / LogEvent ID?

[kazariad]

Hello,
The Pattern layout features a UUID pattern converter which creates a new UUID upon every invocation for both the random and time-based generators. Effectively, the same LogEvent fed to multiple Appenders will produce a different UUID in each written log. This behavior feels unintuitive and inconsistent with the other pattern converters, which extract data from the LogEvent object and produce identical outputs (Date, Level, Thread ID, etc).

An example use-case for correlated UUIDs is logging to multiple Appenders at different detail levels, and then cross-referencing the results. A database Appender could store logs in a condensed format for inclusion into a monitoring system or dashboard, while a file Appender would store the full log including MDC, stack trace, etc. A matching UUID would allow cross-referencing these logs, but this is currently not possible and requires manually injecting a custom correlation ID from application code.

I'm curious if there's been consideration towards adding repeatable UUIDs or some broader ID system? The most direct approach would be to add an intrinsic ID to LogEvents, but perhaps there's a less invasive alternative that could leverage existing fields, like some combination of timestamp and thread ID?

[vy]

@kazariad, there might be deployments where %u (i.e., the UUID Pattern Converter) is expected to always generate a new ID. Changing the behavior as you described to a deterministic one will not be a backward-compatible default.

Have you considered implementing your own pattern converter? Could that be an option for you?

[ppkarwasz]

By their nature pattern converters do not have write access to LogEvent, so it would be tricky to assign a single UUID to the event.

Implementing a ContextDataProvider would be simpler. See Extending Thread Context for more details.

[vy]

By their nature pattern converters do not have write access to LogEvent

@ppkarwasz, do they need to? The user just needs a deterministic generateUuid(LogEvent) function, which should be trivial.

[ppkarwasz]

Yes, that should be enough, although this will generate more computational overhead. Most LogEvent fields will need to be included in the computation.

[kazariad]

Hello, I've made a draft implementation of a hashing UUID generator that could be enabled through a new UuidPatternConverter option. This would maintain backwards compatibility and avoid touching the LogEvent interface. A collision issues exists in edge cases where the same log is invoked repeatedly, such as in a tight loop. Even with the precision clock enabled, the nanoseconds value can remain unchanged leading to repeated UUIDs. The hash could be strengthened by including more LogEvent fields, but I'm not sure if there's any way around the clock issue without having write access to the LogEvent.

PR