Unique ID Appenders

The unique id appender allows the logging event to carry a unique id. When used in conjunction with SelectAppender or CompositeAppender, this allows for a log record to use the same id across different logs.

For example, in application.log, you'll see a single line that starts with FfwJtsNHYSw6O0Qbm7EAAA:

FfwJtsNHYSw6O0Qbm7EAAA 2020-03-14T05:30:14.965+0000 [INFO ] play.api.db.HikariCPConnectionPool in play-dev-mode-akka.actor.default-dispatcher-7 - Creating Pool for datasource 'logging'

You can search for this string in application.json and see more detail on the log record:

{"id":"FfwJtsNHYSw6O0Qbm7EAAA","relative_ns":20921024,"tse_ms":1584163814965,"start_ms":null,"@timestamp":"2020-03-14T05:30:14.965Z","@version":"1","message":"Creating Pool for datasource 'logging'","logger_name":"play.api.db.HikariCPConnectionPool","thread_name":"play-dev-mode-akka.actor.default-dispatcher-7","level":"INFO","level_value":20000}

See the showcase for an example.


<appender name="selector-with-unique-id" class="com.tersesystems.logback.uniqueid.UniqueIdComponentAppender">
  <appender ...>


To extract the unique ID, register a converter:

<!-- available as "%uniqueId" in a pattern layout -->
<conversionRule conversionWord="uniqueId" converterClass="com.tersesystems.logback.uniqueid.UniqueIdConverter" />

ID Generators

Unique IDs come with two different options. Flake ID is the default.

Random UUID

This implementation uses RandomBasedGenerator from Java UUID Generator. This is faster than using java.util.UUID.randomUUID, because it avoids the synchronization lock.

Flake ID

Flake IDs are decentralized and k-ordered, meaning that they are "roughly time-ordered when sorted lexicographically."

This implementation uses idem with Flake128S.