OpenTelemetry logs, body vs attributes for structured logs unclear in spec and behaves inconsistently in exporters

[segevfiner]

There is something that is inconsistent/missing at this time from the OpenTelemetry logs specification and is causing me quite an headache while trying to implement it into our app.

The current spec defines:

Field: Body
Type: any.

Description: A value containing the body of the log record. Can be for example a human-readable string message (including multi-line) describing the event in a free form or it can be a structured data composed of arrays and maps of other values. Body MUST support any type to preserve the semantics of structured logs emitted by the applications. Can vary for each occurrence of the event coming from the same source. This field is optional.

Field: Resource
Type: Resource.

Description: Describes the source of the log, aka resource. Multiple occurrences of events coming from the same event source can happen across time and they all have the same value of Resource. Can contain for example information about the application that emits the record or about the infrastructure where the application runs. Data formats that represent this data model may be designed in a manner that allows the Resource field to be recorded only once per batch of log records that come from the same source. SHOULD follow OpenTelemetry semantic conventions for Resources. This field is optional.

But from this it is very unclear how structured logs should be mapped into this format, including what is the main message field when the body is an object rather than just a string, and results in mismatch between directly ingesting such logs versus using OpenTelemetry into various backends.

For example, the default instrumentation for Pino (Node.js) maps the message field into body and the rest into attributes, but when this is exported into Google Cloud Logs, it puts the body as textPayload and attributes as labels where labels are just a string to string mapping, which means structured fields such as err get flattened as JSON and become inconvenient to view and query, modifying the instrumentation (Directly changing its code) to put everything into body results in the expected mapping of putting it all under jsonPayload, but for Google Cloud Logs to recognize the main message field and display it nicely, it must be called message which is not part of the spec and I had to do manually in the configuration of Pino, otherwise it becomes inconvenient to view them messages as it just shows the body JSON payload instead of the message when browsing messages.

Trying the same with SigNoz, when the message is mapped into body and attributes, it again doesn't handle the structured err attribute yet and just shows it as a JSON string which is inconvenient to query and view. When mapping it all into body, it will parse the body JSON as expected, but it will display the entire body JSON in the table, with no concept of main message field, and no option to display a field of the body as a column, though you seem able to query them but without autocompletion of fields in query message box, which is also inconvient.

I'm not sure what's the canonical use for body and attributes here, and how I should handle it then to get the correct and most convenient display in different exporter as they don't seem to act the same...

See also open-telemetry/opentelemetry-js-contrib#3012