GitHub user ViliusS edited a comment on the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
> **BTW**: Using `%uuid` as value for
> [logging.googleapis.com/insertId](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.insert_id)
> does not fulfill the **unicity** requirement from the documentation:
>
> > _Optional_. A unique identifier for the log entry. If you provide a value,
> > then Logging considers other log entries in the same project, with the same
> > timestamp, and with the same `insertId` to be duplicates which are removed
> > in a single query result. However, there are no guarantees of
> > de-duplication in the export of logs.
> > If the `insertId` is omitted when writing a log entry, the Logging API
> > assigns its own unique identifier in this field.
>
> The same log event, delivered by different appenders will have different
> UUIDs. See #3503 for a discussion.
I'm going to propose PR for GcpLayout.json template shortly. Among other
things, counter cannot be used with `logging.googleapis.com/insertId` either
because it produces duplicate IDs for different JVM threads. It also restarts
from ID 1 if Java application is restarted.
I think having different UUID for different appenders are exactly how it is
supposed to work. Different appenders pushing to the same Google Cloud Log
would probably mean different log event formatting anyway, so we should ensure
that such messages are no de-duplicated by GCP.
Alternatively, `insertId` could be omitted completely, so GCP would generate
their own IDs.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12698772
----
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
