Add log bridge implementation guidelines

[pellared]

Add guidelines how logging bridges should map their logs into the OTel.

We should also recommend that each logging bridge has to document how the conversion is done like e.g. https://pkg.go.dev/go.opentelemetry.io/contrib/bridges/otelslog#hdr-Record_Conversion

Originally posted by @segevfiner in open-telemetry/opentelemetry-specification#4722 (reply in thread)

What I'm suggesting is to make it an official part of the spec of how structured loggers map to OTEL, if we are meant to put the entire thing in the body, then define the needed conventions and mapping so that the main message field can be recognized and so on, so that it can be remapped appropriately for the conventions of the destination, rather than just pass through and let the user/developer handle it. Or to define that body shouldn't be a structure, the rest goes into attributes, and clearly define, make it an option, add a new metadata field to the LogRecord, to handle it in the various exporters. E.g. I want to get a jsonPayload, in GCP that combines both body and attributes into a jsonPayload.

The Logs API is provided for logging library authors to build log appenders, which use this API to bridge between existing logging libraries and the OpenTelemetry log data model.

It is the responsibility of otel to define what each field of a LogRecord should normally be, if it keeps it too vague and up to interpretation, than it just leaves implementors to guess, which just results in this very inconsistency I'm talking about. With the spec clearly defining how the body and attributes should look like for the different types of loggers, implementations can align to that so we get optimal export behavior to the different destinations, without me having to apply transforms specific to each destinations to handle the deficiencies is describe in this thread.

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.}

[Dipanshusinghh]

Hi @pellared, this seems like an important gap since different logging bridges currently map structured logs into OTel differently, which can lead to inconsistent export behavior across backends.
I .,hd like to help work on the implementation guidelines and document clearer mapping expectations for LogRecord body/attributes if this is open for contribution. Thanks!