search

open-telemetry / community

OpenTelemetry community content
https://opentelemetry.io
Apache License 2.0
752 stars 228 forks source link

One Logging Bridge per language #1970

Open jpkrohling opened 7 months ago

jpkrohling commented 7 months ago

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):

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 commented 7 months ago

@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 commented 7 months ago

@fendrifirasleminnov volunteering to help on this Topic.

pellared commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

srikanthccv commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago
jpkrohling commented 7 months ago

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

jpkrohling commented 6 months ago

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

trask commented 6 months ago

@jpkrohling same here, move to community repo?

jpkrohling commented 6 months ago

Moved!