-
Notifications
You must be signed in to change notification settings - Fork 765
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move LoggerProvider and friends (OTEL1000) to a stable API #5648
Move LoggerProvider and friends (OTEL1000) to a stable API #5648
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5648 +/- ##
==========================================
+ Coverage 83.38% 86.15% +2.77%
==========================================
Files 297 254 -43
Lines 12531 11054 -1477
==========================================
- Hits 10449 9524 -925
+ Misses 2082 1530 -552
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Some thoughts for anyone taking a look at this...
|
… examples, and docs.
@CodeBlanch - I think we should not mark things obsolete rn. Regarding the migration guidance:
In short, the only use case we would enable right now is For future, we could decide whether we want to have the migration guidance for case 2 or go with OpenTelemetrySdk pattern. |
Based on what thinking/reasons? Please elaborate a bit 😄 |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't wait to start tell users they can finally use WithLogging
!
src/OpenTelemetry.Exporter.OpenTelemetryProtocol/OtlpLogExporterHelperExtensions.cs
Outdated
Show resolved
Hide resolved
static OpenTelemetry.Logs.LoggerProviderExtensions.Shutdown(this OpenTelemetry.Logs.LoggerProvider! provider, int timeoutMilliseconds = -1) -> bool | ||
static OpenTelemetry.OpenTelemetryBuilderSdkExtensions.WithLogging(this OpenTelemetry.IOpenTelemetryBuilder! builder) -> OpenTelemetry.IOpenTelemetryBuilder! | ||
static OpenTelemetry.OpenTelemetryBuilderSdkExtensions.WithLogging(this OpenTelemetry.IOpenTelemetryBuilder! builder, System.Action<OpenTelemetry.Logs.LoggerProviderBuilder!>! configure) -> OpenTelemetry.IOpenTelemetryBuilder! | ||
static OpenTelemetry.OpenTelemetryBuilderSdkExtensions.WithLogging(this OpenTelemetry.IOpenTelemetryBuilder! builder, System.Action<OpenTelemetry.Logs.LoggerProviderBuilder!>? configureBuilder, System.Action<OpenTelemetry.Logs.OpenTelemetryLoggerOptions!>? configureOptions) -> OpenTelemetry.IOpenTelemetryBuilder! | ||
static OpenTelemetry.Sdk.CreateLoggerProviderBuilder() -> OpenTelemetry.Logs.LoggerProviderBuilder! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ok keeping this experimental for now. Might ultimately be nice simply for consistency, but I see no reason for this discussion to block the introduction of the new APIs, especially WithLogging
.
We decided on the SIG meeting 6/4/2024 that we would:
@alanwest @vishweshbankwar PR has been updated. |
@CodeBlanch Can you update the PR description to include the changes expected to be done by end users as well, even though they are not forced to do it? Also call out that, this should be done only if their exporter supports this new model (and mention that exporters shipped from this repo already supports this model) |
|
||
var resourceBuilder = ResourceBuilder.CreateDefault(); | ||
configureResource(resourceBuilder); | ||
options.SetResourceBuilder(resourceBuilder); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️ seeing common Resource across all 3!
And also ❤️ fixing the awkwardness of calling methods like AddExporter
on a supposedly pure "Options" class!
// In production environment, ConsoleExporter should be replaced with other exporters (e.g. OTLP Exporter). | ||
.AddConsoleExporter(); | ||
}); | ||
// Add OpenTelemetry logging provider by calling the WithLogging extension. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we add a note here to warn users that this approach only works if their exporter also supports this model?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might get confusing. I think either a) we leave it as is or b) we show the old style. Let me know which you prefer! I'm hoping the gap is short-lived and we can get these extensions added soon after 1.9.0 is out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay to keep this as-is, assuming the gap is short-lived.
@cijothomas I added "Migration guidance for users" back on the PR description. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Fixes #5442
Fixes #4014
Changes
ILoggingBuilder.UseOpenTelemetry
extension left experimental for now. Pending [sdk] Add OpenTelemetrySdk builder pattern #5325 it may or may not be exposed at all.Sdk.CreateLoggerProviderBuilder
moved toOTEL1001
(remains experimental).Migration guidance for library authors
Library authors should begin adding extension methods targeting
LoggerProviderBuilder
. In a future release theILoggingBuilder.AddOpenTelemetry
extension method and theOpenTelemetryLoggerOptions.AddProcessor
&OpenTelemetryLoggerOptions.SetResourceBuilder
methods will be marked obsolete.Before:
After:
LoggerProviderBuilder
has the sameAddProcessor
andSetResourceBuilder
methods previously available onOpenTelemetryLoggerOptions
as well as the full set of methods\features available toMeterProviderBuilder
andTracerProviderBuilder
.Migration guidance for users
Note: No migration is currently required for users. All existing code should function as it did before. The following migration paths are purely optional.
When using OpenTelemetry.Extensions.Hosting
Before:
After:
For this to work, your exporter needs to expose an extension which targets
LoggerProviderBuilder
. Extensions are provided forOtlpExporter
,ConsoleExporter
, andInMemoryExporter
.If you are using an exporter from the https://github.com/open-telemetry/opentelemetry-dotnet-contrib repository or some other exporter, it may not provide this extension yet. First try to upgrade your exporter package. If there isn't an update available, you may use this pattern and continue to call the existing extension (while waiting for the component to be updated):
When using LoggerFactory.Create
There is no dedicated API provided yet to migrate from
ILoggerBuilder.AddOpenTelemetry
(which providesOpenTelemetryLoggerOptions
) to something which providesLoggerProviderBuilder
. This API will come in a future version.If for some reason you want to use
LoggerProviderBuilder
before that API is available, it is possible to useIServiceCollection.ConfigureOpenTelemetryLoggerProvider
to configure theLoggerProviderBuilder
usingILoggingBuilder.Services
:Before
After
Merge requirement checklist
CHANGELOG.md
files updated for non-trivial changes