Add stdoutlog exporter

[pellared]

Create a go.opentelemetry.io/otel/exporters/stdout/stdoutlog module providing a logs console exporter.

The exporter should have options WithWriter, WithPrettyPrint and WithoutTimestamps like https://pkg.go.dev/go.opentelemetry.io/otel/exporters/stdout/stdouttrace.

We may want to add JSON marshaling to the go.opentelemetry.io/otel/sdk/log.Record type.

• Add config and doc for stdoutlog exporter #5158
• stdoutlog: Add exporter #5172
• stdoutlog: Implement OTLP JSON encoding #5174
• stdoutlog: Do not print timestamps when WithoutTimestamps is set #5175
• stdoutlog: Implement Resource serialization #5211
• stdoutlog: Test resource, scope, dropped attributes serialization #5212
• Add example for stdoutlog #5242

[MrAlias]

Are we planning to just follow the metric STDOUT exporter here and accept some kind of encoder?

[pellared]

Not necessary.

I am against having an encoder interface like in stdoutmetric which does not even take the io.Writer into consideration.

We could accept an interface like type Handler interface { Handle(w io.Writer, r log.Record) } but it doesn't need to be added in the initial version.

[MrAlias]

Can you fill out the description of this issue with what is needed in the initial version? It's pretty blank currently 😉

[XSAM]

I am against having an encoder interface like in stdoutmetric which does not even take the io.Writer into consideration.

We could accept an interface like type Handler interface { Handle(w io.Writer, r log.Record) } but it doesn't need to be added in the initial version.

I wonder what is the reason for having a io.Writer in the Handler interface. The io.Writer can be part of the implementation of a handler and might not be necessary in the interface.

[pellared]

I think that the main idea of using stdout exporter is to have it working with io.Writer that can set via WithWriter. Personally, I do not see a good reason to provide such customization. One can always create its own exporter.

Can we start with an implantation that only has WithWriter, WithPrettyPrint and WithoutTimestamps options like https://pkg.go.dev/go.opentelemetry.io/otel/exporters/stdout/stdouttrace?

[XSAM]

I feel like we only treat the stdoutlog exporter as a debug tool.

Do you think we might end up having a full-function logging exporter, like the slog? So, we can provide native OTel logging without importing contrib libs (or other third-party libs). We can also reduce the log model transform at least once, as our logging implementation uses our own log model.

[pellared]

I feel like we only treat the stdoutlog exporter as a debug tool.

This is indeed one of its main use cases.

Do you think we might end up having a full-function logging exporter, like the slog?

Can please you elaborate? The SDK allows adding a custom logging exporter. Am I missing something?

Or do you mean that you would like Logs SDK to export logs the slog? If so it is possible to create an exporter that would emit logs to slog.

So, we can provide native OTel logging without importing contrib libs (or other third-party libs).

Just for reference, Logs Bridge API should not be used directly.

Note: this document defines a log backend API. The API is not intended to be called by application developers directly. It 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.

The Logs Bridge API is not intended to be called by application developers directly, and SHOULD include documentation that discourages direct use.

Right now, I would encourage users to use slog together with otelslog for logging. Depending on standard library should be a good practice. The API and SDK is designed in a way to not produce a lot of performance overhead.

In future, users would be also able to use Events API to emit events without importing third-party libs.

We can also reduce the log model transform at least once, as our logging implementation uses our own log model.

This is why propose adding JSON marshaling to the go.opentelemetry.io/otel/sdk/log.Record type to reduce the amount of object transformations.