Propose new "log.original.body" attribute

[djaglowski]

Area(s)

area:log

Is your change request related to a problem? Please describe.

When working with traditional string logs, the log's Body field is sometimes overloaded. This happens because the field is defined such that it is intended for multiple purposes which were previously believed to be mutually exclusive. Paraphrasing from the data model, the body is intended as the appropriate place for any of the following:

1. A complete original representation of a structured log
2. A complete original representation of an unstructured (string) log
3. The "message" portion of a log

However, as demonstrated by examples in open-telemetry/opentelemetry-specification#3932, it is sometimes necessary and often wise to retain more than one of the above within the same payload. Since we will not add a field to disambiguate the "message" from the "original" values, I'm proposing that we define a semantic convention to act as an optional backup location for the original log.

Describe the solution you'd like

A new attribute: log.original.body
Data type: string or []byte
Description: A copy of the Log Record's original Body value. If the field contains a value, it MUST be exactly the value which the Body first contained. When this field contains a value, it SHOULD be assumed that the Body field was changed.

Describe alternatives you've considered

This follows from a lengthy discussion about adding this as a top-level field in the log data model. Consensus in that conversation appeared to be strongly in favor of a semantic convention instead.

Additional context

No response

[djaglowski]

What needs to happen in order to move this forward? Should I open a PR?

[MSNev]

@lmolkova We don't believe that this is related to events, so removing from our tracking board.

[trask]

What needs to happen in order to move this forward? Should I open a PR?

that seems reasonable to me given the discussion that has already taken place in open-telemetry/opentelemetry-specification#3932

since there's no Semantic Convention expert group that covers log.* attributes, it may help to join the General Semantic Convention SIG meeting to discuss if your PR doesn't get traction