Logs Bridge API design

[pellared]

Problem Statement

Design the following components in accordance to the OTel Specifcation (https://opentelemetry.io/docs/specs/otel/logs/):

• Logs Bridge API
• Logs SDK
• slog.Handler implementation; log appender; bridge
• Stdout exporter

Proposed Solution

Create a separate proposal PR which contains:

1. A design document.
2. A prototype implementation.

This issue is to track the whole proposal. It should be closed when the OTel Go maintainers and approvers accept the proposed design and prototype.

The prototype should have a PoC (happy-path; tests and proper error handling is not required) implementation of all components, with example and benchmarks. The main focus is on the API and performance. The prototype can have everything as a single Go module for ease of development.

After the proposal is accepted, the actual implementation will be built based on the prototype as many PRs with tests, benchmarks, and documentation.

Current design and prototype

• log: Add design doc #4809
• Logs Bridge API prototype #4725
• ...

Prior Art

• Begin prototyping Log API/SDK #3606
• https://github.com/MadVikingGod/opentelemetry-go/tree/mvg/slog

Additional Context

It is worth to get all the lessons learned that the Go team had when they created slog:

• https://go.dev/blog/slog
• https://go.googlesource.com/proposal/+/master/design/56345-structured-logging.md
• https://github.com/golang/go/tree/master/src/log/slog
• https://golang.org/s/slog-handler-guide
• log/slog: structured, leveled logging golang/go#56345
• structured, leveled logging golang/go#54763

It is important to notice that API design can affect performance (e.g. allocations).
It would be good to create benchmarks similar to https://github.com/golang/go/tree/master/src/log/slog
Reference: https://www.youtube.com/watch?v=tC4Jt3i62ns

[pellared]

@jba Do you want to participate (in any way you feel comfortable with) in adding logs to OpenTelemetry Go? I would be more than happy to get any feedback from you.

[jba]

Yes, I'd love to review the work related to slog.

[cloorc]

Hi @pellared , I'm very interested in this feature lately. We are going to build a new system that will import full OpenTelemetry stack. But yesterday we found the latest opentelemtry-go SDK is still not supporting log report(to otel collector), however, our another team using opentelemetry-java, which has already supported.

I'm glad to help if there is anything I can do.

[MrAlias]

Hi @pellared , I'm very interested in this feature lately. We are going to build a new system that will import full OpenTelemetry stack. But yesterday we found the latest opentelemtry-go SDK is still not supporting log report(to otel collector), however, our another team using opentelemetry-java, which has already supported.

I'm glad to help if there is anything I can do.

@cloorc one thing to keep in mind is the OTel "logs implementation" is going to be a bridge that will back popular logging APIs. If you are using something like slog, logr, zap, ... there will likely be an OTel export pipeline built for these systems.

[cloorc]

Hi @pellared , I'm very interested in this feature lately. We are going to build a new system that will import full OpenTelemetry stack. But yesterday we found the latest opentelemtry-go SDK is still not supporting log report(to otel collector), however, our another team using opentelemetry-java, which has already supported.
I'm glad to help if there is anything I can do.

@cloorc one thing to keep in mind is the OTel "logs implementation" is going to be a bridge that will back popular logging APIs. If you are using something like slog, logr, zap, ... there will likely be an OTel export pipeline built for these systems.

Yeah, it sounds like what we are looking forward to. Thanks!

[pellared]

Closing per #4809.

New issues will be created e.g. for SDK design.