Component(s)
receiver/journald
Is your feature request related to a problem? Please describe.
In it's current state, the journald receiver maps the raw json data cleanly into the log body and leaves most attribute mapping to operators and processors.
That is except for the timestamp. The input operator parses the __REALTIME_TIMESTAMP value and then, most notably, deletes the field from the body.
This is a challenge for some backend logging systems which rely on a timestamp field to be present in the log body and don't (yet?) have a mechanism to retrieve the value from another kv pair in the event payload.
Describe the solution you'd like
Given the efforts being made on building out additional mappings to align with sem conv (#46500) it may be appropriate to also plan for use cases where forwarding the original JSON is most appropriate.
The wineventlog receiver already has a boolean that enables stashing the complete original XML event data inside of log.record.original, and it would make sense for this receiver to have a similar option that could immediately copy the full JSON (including __REALTIME_TIMESTAMP) into log.record.original before parsing attributes and modifying the body.
Describe alternatives you've considered
At minimum, I would suggest that the deletion of __REALTIME_TIMESTAMP be gated behind a new receiver parameter so users could opt-in to shipping the original payload, intact.
Currently it is possible to use an operator stanza to restore the deleted kv pair into the log body, but this would be a short term workaround rather than a desirable configuration.
Additional context
No response
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.
Component(s)
receiver/journald
Is your feature request related to a problem? Please describe.
In it's current state, the journald receiver maps the raw json data cleanly into the log body and leaves most attribute mapping to operators and processors.
That is except for the timestamp. The input operator parses the __REALTIME_TIMESTAMP value and then, most notably, deletes the field from the body.
This is a challenge for some backend logging systems which rely on a timestamp field to be present in the log body and don't (yet?) have a mechanism to retrieve the value from another kv pair in the event payload.
Describe the solution you'd like
Given the efforts being made on building out additional mappings to align with sem conv (#46500) it may be appropriate to also plan for use cases where forwarding the original JSON is most appropriate.
The wineventlog receiver already has a boolean that enables stashing the complete original XML event data inside of log.record.original, and it would make sense for this receiver to have a similar option that could immediately copy the full JSON (including __REALTIME_TIMESTAMP) into log.record.original before parsing attributes and modifying the body.
Describe alternatives you've considered
At minimum, I would suggest that the deletion of __REALTIME_TIMESTAMP be gated behind a new receiver parameter so users could opt-in to shipping the original payload, intact.
Currently it is possible to use an operator stanza to restore the deleted kv pair into the log body, but this would be a short term workaround rather than a desirable configuration.
Additional context
No response
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding
+1orme too, to help us triage it. Learn more here.