One Logging Bridge per language

[jpkrohling]

trafficstars

Description

During the joint TC/GC call on Jan 11, we agreed on a few items we'd like to accomplish this year. One such item was creating at least one logging bridge per Language SIG, so that our end-users can start using OTLP Logging natively on their applications.

We'll strive to get at least one logging bridge for each supported language. Language SIGs will be free to decide which bridge to implement based on the needs of their audiences.

Project Board

To be created.

Deliverables

For each one of the following languages, there should be at least one logging bridge available, either as part of their core repository or as part of their contrib repository. Usage of such bridge should be documented on opentelemetry.io's website.

Languages (100% of the languages available when this issue was created):

• [x] https://github.com/open-telemetry/community/issues/1900
• [x] https://github.com/open-telemetry/community/issues/1901
• [x] https://github.com/open-telemetry/community/issues/1902
• [x] https://github.com/open-telemetry/community/issues/1903
• [x] https://github.com/open-telemetry/community/issues/1904
• [x] https://github.com/open-telemetry/community/issues/1905
• [x] https://github.com/open-telemetry/community/issues/1906
• [x] https://github.com/open-telemetry/community/issues/1907
• [ ] https://github.com/open-telemetry/community/issues/1908
• [x] https://github.com/open-telemetry/community/issues/1909
• [x] https://github.com/open-telemetry/community/issues/1910

Staffing / Help Wanted

We anticipate that Language SIG maintainers will share the vision that having at least one bridge, hopefully for the most used logging API for the language, is important for the SIG, and therefore, we don't anticipate new staffing requirements. However, we'll try to recruit new contributors to work on this once we have a few examples to follow.

Required staffing

@jpkrohling is the sponsor for this project and will work with the individual Language SIGs to implement this.

Meeting Times

We'll use the regular Language SIGs meetings, as well as the maintainer's meeting on Monday.

Timeline

We aim to complete this project by the end of 2024.

[jpkrohling]

@arminru, could you please assign this to me and add the required labels, so that it appears on the board?

https://github.com/orgs/open-telemetry/projects/29/views/1

[fendrifirasleminnov]

@fendrifirasleminnov volunteering to help on this Topic.

[pellared]

We'll strive to get at least one bridge API implementation for each supported SDK.

This is clear. But... why "at least one" and not simply "one"?

Language SIGs will be free to decide which bridge would be the most useful to their audiences.

This is not clear. Is the term bridge used correctly in this sentence or do you have something else in mind? I am not sure what this sentence is about. I guess it should be "Language SIGs will be free to decide which bridge API implementation would be the most useful to their audiences.". But even then I think the issue description is missing some context. Are there many bridge API implementations? Do we want the SDK to provide many bridge API implementations?

For each one of the following SDKs, there should be at least one bridge API available, either as part of their core repository or as part of their contrib repository. Usage of such bridge should be documented on opentelemetry.io's website.

Bridge API != Bridge. Bridge API is supposed to be used to create bridges that the users would then use. I think that we can document two things:

1. Describe how users can use existing bridges
2. Describe how user can create their own bridge using Bridge API

[pellared]

I am working on implementing Logs for OTel Go. Right now, we are on a design stage of Bridge API. Here is a project that you can use for tracking: https://github.com/orgs/open-telemetry/projects/43/views/1

I also try to make the specification more clear in parts that bring confusion.

[jpkrohling]

Sorry about the confusion: admittedly, I should have been more thoughtful about the terms used here. By "Bridge API implementation," I simply mean a bridge. Like a slog handler, or a log4j appender, for OTLP.

[pellared]

For Go we plan to have an slog.Handler as log bridge. I just created an issue for tracking: https://github.com/open-telemetry/opentelemetry-go-contrib/issues/5138

[jpkrohling]

I changed the description a bit to clarify some parts, but I wanted to address some comments here:

We'll strive to get at least one logging bridge for each supported SDK

But... why "at least one" and not simply "one"?

Because we might end up having two :-)

Are there many bridge API implementations? Do we want the SDK to provide many bridge API implementations?

We want SDKs to offer support for at least one logging API that their users care about. We want Language SIG maintainers to decide which ones to implement.

[pellared]

Another note on

One such item was creating at least one logging bridge per SDK

Log bridge DOES NOT have to be part of SDK (and I think it should not even be - if possible).

The idea Bridge API was to have a separation between SDK and bridges so that the bridges can be used by different API implementations (which does not have to be the OTel SDK).

I think it is better to say.

"One such item was creating at least one logging bridge per Language SIG".

[jpkrohling]

Agreed, I replaced SDK by language in most occurrences. Thank you for calling that out!

[srikanthccv]

Python SIG has one for the stdlib logger LoggingHandler already. This is under the experimental flag and being used by several companies to my knowledge. There is also an open issue to support bridge for another popular third-party library https://github.com/open-telemetry/opentelemetry-python/issues/2993 but I guess having a handler for stdlib should be enough?

[cijothomas]

OTel .NET provides ILogger (the most common logging facade in modern .NET apps), integration already as a stable feature, used in production by many. There is support of writing bridges for other logging facades, but this is experimental only.

[lalitb]

• OTEL Rust has logging bridge implementation for the tokio-tracing library which is the most widely used logging framework in the Rust community - https://github.com/open-telemetry/opentelemetry-rust/tree/main/opentelemetry-appender-tracing

• OTel C++ doesn't have any bridge implementation in the main repo. There are a few contributions for spdlog, glog, log4cxx, and boost.log in progress in the contrib repo.

[jpkrohling]

Closed in favor of https://github.com/open-telemetry/community/pull/1886

[jpkrohling]

Reopening, as we'll use this issue to track at the GC level.

[trask]

@jpkrohling same here, move to community repo?

[jpkrohling]

Moved!