You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the EcsLayout class in log4j2-ecs-layout defaults the event.dataset to the service name + ".log". At most we can override it with a specific value, but that specific value will be written for every log line.
In the project I am working on we are generating multiple kinds of events into a single log file, including access, egress, trace and logs. We want to be able to differentiate these events by the event.dataset field as required by an internal observability team but we can't set/override that field per event. If we set it in ContextData/MDC manually it causes the field to be written twice.
I can understand trying to negotiate the event context data per event before writing out standard fields might be opening a can of worms but I'd like to have the conversation as to how situations like this could be handled.
The text was updated successfully, but these errors were encountered:
Hi and thanks for the issue. Would it help you to have the ability to disable writing a default event.dataset so that the value from MDC is the only one?
I'm not actually sure what happens when you have the same key multiple times. Does the JSON parsing fail or does the last value win?
Currently the EcsLayout class in
log4j2-ecs-layout
defaults theevent.dataset
to the service name + ".log". At most we can override it with a specific value, but that specific value will be written for every log line.In the project I am working on we are generating multiple kinds of events into a single log file, including access, egress, trace and logs. We want to be able to differentiate these events by the
event.dataset
field as required by an internal observability team but we can't set/override that field per event. If we set it in ContextData/MDC manually it causes the field to be written twice.I can understand trying to negotiate the event context data per event before writing out standard fields might be opening a can of worms but I'd like to have the conversation as to how situations like this could be handled.
The text was updated successfully, but these errors were encountered: