Add 'log.record.original' attribute

[djaglowski]

Fixes #1137

Changes

Add 'log.record.original' attribute.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[joaopgrassi]

I skimmed through the linked spec issue and I see most folks agree with a semantic conventions for this, but I wonder what will be the outcome of having this convention here? Will then receivers have to build knowledge of this semantic field? What is the overall plan? I ask because your last comment there says there's no support for it so I wonder what the convention will solve.

[djaglowski]

I skimmed through the linked spec issue and I see most folks agree with a semantic conventions for this, but I wonder what will be the outcome of having this convention here? Will then receivers have to build knowledge of this semantic field? What is the overall plan? I ask because your last comment there says there's no support for it so I wonder what the convention will solve.

Even if there is no functionality provided for this attribute, it will be helpful for users who are looking for a standard way to back up the original log value. The question of how to properly preserve it has come up many times and this would provide a standard answer. For example, one team may make a point to populate this attribute according the description, without any need to understand whether or how it will be used. Another team downstream can check for the attribute and use it is present.

That said, if this is released I will propose adding support to several receivers in the collector. Tentatively, that functionality may include:

• In several receivers which deal directly with traditional logs (filelog, syslog, tcplog, udplog), automatically populate this attribute when a string or []byte body is overridden.
• In other receivers which interact with traditional log providers (windows event log, journald), add a config option to both parse and preserve the log. (e.g. windows event log currently forces a choice but some users need both).
• Potentially, OTTL could populate this attribute automatically.
• Some exporters may choose to check for this attribute and use it if present.

[joaopgrassi]

@djaglowski thanks for the explanation!