Closed CodeBlanch closed 1 month ago
Attention: Patch coverage is 76.01246%
with 77 lines
in your changes missing coverage. Please review.
Project coverage is 86.00%. Comparing base (
6250307
) to head (898c1a8
). Report is 285 commits behind head on main.
This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.
Closed as inactive. Feel free to reopen if this PR is still being worked on.
Relates to #5642 Relates to #5643
Changes
ConcurrencyModes
andConcurrencyModesAttribute
AddBatchExportProcessor
andAddSimpleExportProcessor
extensions onLoggerProviderBuilder
andTracerProviderBuilder
IDeferredLoggerProviderBuilder
onOpenTelemetryLoggerOptions
Details
ConcurrencyModes
We want to allow users (component authors) to be able to opt-out of the
lock
used by SimpleExportProcessor. @reyang introducedConcurrencyModes
on #5643 but the challenge there isSimpleExportProcessor<T>
needs to implement all the logic which makes it a) not very simple and b) more expensive (perf-wise). The goal here was to supportConcurrencyModes
but in a way where we could specialize the implementation(s) without leaking them into public APIs. There could also be moreConcurrencyModes
in the future for exampleGlobal
was originally in the design which uses an OS-level synchronization mechanism and further complicatesSimpleExportProcessor<T>
.AddBatchExportProcessor and AddSimpleExportProcessor extensions
Mistakes have been made in the design of
BatchExportProcessor<T>
. Users (component authors) must correctly pass in settings on the ctor. Those settings should be controllable by users. Some exporters do this manually (OneCollector), some do it usingBatchExportActivityProcessorOptions
(Geneva), and some don't give users any configurability at all (AzureMonitor).Adding
AddBatchExportProcessor
andAddSimpleExportProcessor
extensions allow the SDK to take care of this so it is always done correctly and gives it a spot to inspectConcurrencyMode
to select the correct implementation to use whenSimpleExportProcessor<T>
is requested.Implement IDeferredLoggerProviderBuilder on OpenTelemetryLoggerOptions
In
1.9.0
we exposedLoggerProviderBuilder
which is where the new extensions landed. The problem is we also haveOpenTelemetryLoggerOptions
and a lot of shipped registration extensions targeting it which need to create simple or batch processors. I really didn't want to add new builder methods onOpenTelemetryLoggerOptions
as we ought to obsolete the existing ones. What I did was implementIDeferredLoggerProviderBuilder
onOpenTelemetryLoggerOptions
so that component authors can access theLoggerProviderBuilder
extensions if needed. This is an explicit implementation so it is hidden from users unless they perform a cast. Is this safe to do? Yes.OpenTelemetryLoggerOptions
can perform all the late-bound builder tasks because it has theIServiceProvider
available. It just can't do the early stuff which needsIServiceCollection
. So it may beIDeferredLoggerProviderBuilder
but it can't beILoggerProviderBuilder
.Follow-up work
PeriodicExportingMetricReader
is really subject to the same pitfalls asBatchExportProcessor<T>
but that isn't addressed here. If this goes forward similar work will need to happen for it. Probably an extension onMeterProviderBuilder
along the lines ofAddPeriodicExportingMetricReader
.Merge requirement checklist
CHANGELOG.md
files updated for non-trivial changes