One Logging Bridge per Language

[jpkrohling]

@jpkrohling has volunteered to be the sponsor for this.

[jpkrohling]

Created: #1970

[jpkrohling]

This is in the scope for an LFX mentorship: cncf/mentoring#1134

[Sanket-0510]

Hey, from my understanding the projects aims to cover logging bridges for each language as discussed in #1970 for .NET we already have ILogger which gives log bridge capability. Python SIG provides logging.handler same with Rust tokio-tacing does the job.

Now it comes to languages like c++, go,etc. will have to build the required logging bridge.
I'll explore logging bridge in go for starting to get the understanding.taking refference of this issue, open-telemetry/opentelemetry-go-contrib#5138.

Do you know of any other sources or files I should look into to understand this better? I'm thinking about joining the LFX mentorship to dive deeper into this. If you have any suggestions for beginner-friendly issues to start with or anything related to logging bridges, I'd really appreciate it.

Thanks a bunch!

[jpkrohling]

That's great to hear! Given that your interest is in Go, we can talk about it on the concrete issue for slog.

[jpkrohling]

I realized that a few things I wrote on the target issue applies to other languages as well, so, here it is:

Recommended reading:
https://opentelemetry.io/docs/specs/otel/ (especially the Bridge API part)

And perhaps before that, I'd also recommend getting familiar with OpenTelemetry, if you aren't already:
https://opentelemetry.io/docs/what-is-opentelemetry/

It might also help to understand what OpenTelemetry is by taking a look at the demo:
https://github.com/open-telemetry/opentelemetry-demo

[djaglowski]

To clarify, the goal here is to get to at least one logging bridge per language, right? That is, we're not suggesting that only one logging library per language will be supported in the long term?

[verma-kunal]

I realized that a few things I wrote on the target issue applies to other languages as well, so, here it is:

Recommended reading: https://opentelemetry.io/docs/specs/otel/ (especially the Bridge API part)

And perhaps before that, I'd also recommend getting familiar with OpenTelemetry, if you aren't already: https://opentelemetry.io/docs/what-is-opentelemetry/

It might also help to understand what OpenTelemetry is by taking a look at the demo: https://github.com/open-telemetry/opentelemetry-demo

Hi @jpkrohling , thanks for sharing these resources! I'm interested to contribute to this task, specifically in Go. Will go through these & understand what needs to done and work on a strong proposal for the same!

Additionally, would love to know which specific SIG (from the list given here) would this task come under? It would be great to attend their meetings to have discussions or ask doubts.
Thanks

[Sanket-0510]

I realized that a few things I wrote on the target issue applies to other languages as well, so, here it is:

Recommended reading: https://opentelemetry.io/docs/specs/otel/ (especially the Bridge API part)

And perhaps before that, I'd also recommend getting familiar with OpenTelemetry, if you aren't already: https://opentelemetry.io/docs/what-is-opentelemetry/

It might also help to understand what OpenTelemetry is by taking a look at the demo: https://github.com/open-telemetry/opentelemetry-demo

Greetings @jpkrohling.
Thank you so much for sharing the resources I really got an Idea about the project, about Open Telemetry in general. I am looking forward to join and contribute to this thriving community and project helping folks to enhance services by providing the best in class observability solutions.

At start I was bit confused about open-telemetry, what it is and what exactly it does but after demo and setup its all clear.

And I would suggest people really give a watch to this videos https://youtu.be/coPrhP_7lVU?si=J38_h9vW3W4pO_of
to get a general overview of Open-Telemetry.

[enesonus]

Hi, to be able to have a cleaner view of what is going to be achieved and focused on LFX Mentorship project I made some research and found out that there are some SDK implementations of logging bridges (some of them do not specify stability level) which are indicated as not implemented in this issue. These are:

C++

We have an example that uses a LogRecordExporter and registers a Logger Provider. Stability level is not mentioned.

Java

In the opentelemetry-java SDK repository there is Logging Bridge API's components implementation files . It was lacking a readme inside it's own repo but in the opentelemetry-java-examples they have a log-appender example and at opentelemetry.io we see SdkLoggerProvider class inside the Usage part. I also found some repositories (1, 2) using the SdkLoggerProvider class but I couldn't find any information on stability level. Also check this they are currently using java log report.

Javascript

Here is the SDK of JS LoggerProvider. It also has an example inside repository (This example needs some refinement at the README part IMO). It states clearly that the implementation is currently experimental and under active development i.e. may have some breaking changes

PHP

We have a LoggerProvider configured inside the SDK Builder example usage at opentelemetry.io. Here is the LoggerProvider class implementation that implements LoggerProviderInterface . I couldn't find any info regarding stability level.

I am not sure if these information are sufficient to have them marked as done but I thought it would be helpful.

For Erlang, Go, Ruby and Swift OpenTelemetry does not seem to have a Logging Bridge implemented. I am planning to apply for LFX Mentorship at this Mar-May batch. I have some experience with Go and slog. I would be very happy to implement the Go Logging bridge. If possible, I would also like to improve Java and Python's Logging bridge implementations or documentation.

[Sanket-0510]

To clarify, the goal here is to get to at least one logging bridge per language, right? That is, we're not suggesting that only one logging library per language will be supported in the long term?

I think you are very much correct. Having support for more than one library will be very much needed after Looking at the deprecation and support loss caused by languages version and associated frameworks and libraries

[jpkrohling]

@djaglowski, yes, sorry, I should have made it clearer here. The project that got merged states this:

During the joint TC/GC call on Jan 11 2024, 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 in their applications.

@enesonus, I believe one of the first tasks (for me) is to identify which languages are lacking a bridge which ones we'll focus during the internship. People from the community are helping there as well already, which is why I closed a few items already. Your information will help me confirm with the SIGs whether I should mark them as "done" already.

[EshaanAgg]

Hi! Just a small suggestion from my end! Can we consider creating (or migrating the existing JS bridge) to a TypeScipt bridge? This way it could be utilized by JS/TS developers alike, and even the developers who want to use JS would get neat autocompletion and inference in their IDE's because of their editor's LSPs, that too without any additional steps!

[Bakugo90]

Hello @jpkrohling,
Thank you for the information provided.

I have experience in PHP and application development for iOS platforms.
Therefore an implementation or improvement of the Logging bridge in PHP and Swift would interest me for the LFX mentorship to come.
Hi @Sanket-0510, happy to see you here.

[jpkrohling]

This shouldn't be closed at this point.

[nachoBonafonte]

Hello @jpkrohlin, the otel-swift project confirm that we are interested in receiving a contribution related to new logging bridges.