Remove ActivitySourceAdapter #1836
Conversation
src/OpenTelemetry.Instrumentation.Http/TracerProviderBuilderExtensions.cs
Outdated
Show resolved
Hide resolved
|
@alanwest @CodeBlanch please take a look. This would eliminate the need of ActivitySourceAdapater, by making the TracerProviderSdk itself being aware of legacy activities. |
|
I like this approach! It kind of makes what I'm doing on #1761 impossible, but probably better to approach that through the runtime team anyway 😄 |
…tions; Fixed unit tests; Added unit tests for testing legacy activity processing
Codecov Report
@@ Coverage Diff @@
## main #1836 +/- ##
==========================================
+ Coverage 83.77% 83.95% +0.17%
==========================================
Files 187 187
Lines 5967 5970 +3
==========================================
+ Hits 4999 5012 +13
+ Misses 968 958 -10
|
|
With this new approach, we have introduced a few conditional checks to the TracerProviderSdk hot path for processing activities. I ran some benchmark tests and found that this has increased the mean time to run for the Tracer Benchmark test by up to ~20ns. I feel this is acceptable considering the convenience it brings by getting rid of ActivitySourceAdapter entirely. Here are the benchmarking results: BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19042 With the new changes:
I added two Benchmark tests called
Without these changes (main branch):
|
src/OpenTelemetry.Instrumentation.AspNet/TracerProviderBuilderExtensions.cs
Outdated
Show resolved
Hide resolved
| @@ -42,7 +42,9 @@ public static class TracerProviderBuilderExtensions | |||
| var aspnetOptions = new AspNetInstrumentationOptions(); | |||
| configureAspNetInstrumentationOptions?.Invoke(aspnetOptions); | |||
|
|
|||
| builder.AddDiagnosticSourceInstrumentation((activitySource) => new AspNetInstrumentation(activitySource, aspnetOptions)); | |||
| builder.AddInstrumentation(() => new AspNetInstrumentation(aspnetOptions)); | |||
| builder.AddSource(typeof(AspNetInstrumentation).Assembly.GetName().Name); | |||
There was a problem hiding this comment.
please move the sourcename to a constant. There is inconsistency now as this uses AspNetInstrumentation vs HttpInListener actually. (name is ultimately same, but lets do this consistently)
There was a problem hiding this comment.
I have updated the code to use ActivitySourceName from the listener implementation for all four instrumentation libraries
| /// <param name="options">Configuration options for ASP.NET Core instrumentation.</param> | ||
| public AspNetCoreInstrumentation(ActivitySourceAdapter activitySource, AspNetCoreInstrumentationOptions options) | ||
| public AspNetCoreInstrumentation(AspNetCoreInstrumentationOptions options) |
There was a problem hiding this comment.
I initially thought (inccoreclty) this is a breaking change! The public api analyzer is a gift!
There was a problem hiding this comment.
Should we change this to internal?
| { | ||
| this.diagnosticSourceSubscriber = new DiagnosticSourceSubscriber(new HttpInListener("Microsoft.AspNetCore", options, activitySource), null); | ||
| this.diagnosticSourceSubscriber = new DiagnosticSourceSubscriber(new HttpInListener("Microsoft.AspNetCore", options), null); |
There was a problem hiding this comment.
there are lot of special names - lets move them to a common place where it can be commented and probbaly linked to aspnetcore repo source code.
(separate PR)
| builder.AddDiagnosticSourceInstrumentation((activitySource) => new AspNetInstrumentation(activitySource, aspnetOptions)); | ||
| builder.AddInstrumentation(() => new AspNetInstrumentation(aspnetOptions)); | ||
| builder.AddSource(typeof(AspNetInstrumentation).Assembly.GetName().Name); | ||
| builder.AddLegacyActivityOperationName("Microsoft.AspNet.HttpReqIn"); |
There was a problem hiding this comment.
dont we create sibling activities in asp.net also?
There was a problem hiding this comment.
Thanks! I missed this one. I have added it.
| this TracerProviderBuilder tracerProviderBuilder, | ||
| Func<ActivitySourceAdapter, TInstrumentation> instrumentationFactory) | ||
| where TInstrumentation : class | ||
| public static TracerProviderBuilder AddLegacyActivityOperationName(this TracerProviderBuilder tracerProviderBuilder, string operationName) |
There was a problem hiding this comment.
| public static TracerProviderBuilder AddLegacyActivityOperationName(this TracerProviderBuilder tracerProviderBuilder, string operationName) | |
| public static TracerProviderBuilder AddLegacyActivity(this TracerProviderBuilder tracerProviderBuilder, string operationName) |
There was a problem hiding this comment.
I have updated the name to AddLegacyActivity and updated the public API docs as well.
| /// Adds a DiagnosticSource based instrumentation. | ||
| /// This is required for libraries which is already instrumented with | ||
| /// DiagnosticSource and Activity, without using ActivitySource. | ||
| /// Adds an activity listener for activities created the legacy way with the provided OperationName. The listener samples and processes these activities |
There was a problem hiding this comment.
/// Adds activity with given operation name to the list of subscribed activities. This is for legacy activities (i.e activities created without using ActivituSource API).
There was a problem hiding this comment.
I have updated the description.
| /// Adds a DiagnosticSource based instrumentation. | ||
| /// This is required for libraries which is already instrumented with | ||
| /// DiagnosticSource and Activity, without using ActivitySource. | ||
| /// Adds the OperationName of an activity created by DiagnosticSource instrumentation to the provider. |
There was a problem hiding this comment.
its misleading to say "created by DiagnosticSource instrumentation".
There was a problem hiding this comment.
I have updated the description for this to match the public extension method's description.
| Sdk.CreateTracerProviderBuilder() | ||
| .SetSampler(new AlwaysOnSampler()) | ||
| .AddSource(this.sourceWithOneInstrumentation.Name) | ||
| .AddAspNetCoreInstrumentation() |
There was a problem hiding this comment.
This benchmark has nothing to do with AddAspNetCoreInstrumentation. You can simply use the raw API directly - AddLegacyActivity("somename")
There was a problem hiding this comment.
I have removed the instrumentations and used AddLegacyActivity.
…er' into utpilla/Remove-ActivitySourceAdapter
| builder.AddDiagnosticSourceInstrumentation((activitySource) => new GrpcClientInstrumentation(activitySource, grpcOptions)); | ||
| builder.AddInstrumentation(() => new GrpcClientInstrumentation(grpcOptions)); | ||
| builder.AddSource(GrpcClientDiagnosticListener.ActivitySourceName); | ||
| builder.AddLegacyActivity("Grpc.Net.Client.GrpcOut"); |
There was a problem hiding this comment.
nit: create as a const, just like aspnetcore
| builder.AddDiagnosticSourceInstrumentation((activitySource) => new HttpClientInstrumentation(activitySource, httpClientOptions)); | ||
| builder.AddInstrumentation(() => new HttpClientInstrumentation(httpClientOptions)); | ||
| builder.AddSource(HttpHandlerDiagnosticListener.ActivitySourceName); | ||
| builder.AddLegacyActivity("System.Net.Http.HttpRequestOut"); |
|
|
||
| namespace OpenTelemetry.Instrumentation | ||
| { | ||
| internal static class ActivityInstrumentationHelper |
There was a problem hiding this comment.
should we compile the existing extension instead of duplicating it?
| internal TracerProviderBuilder AddDiagnosticSourceInstrumentation<TInstrumentation>( | ||
| Func<ActivitySourceAdapter, TInstrumentation> instrumentationFactory) | ||
| where TInstrumentation : class | ||
| internal TracerProviderBuilder AddLegacyActivity(string operationName) |
There was a problem hiding this comment.
nit: we could change this to params string[], we have many cases calling this twice.
|
@open-telemetry/dotnet-approvers Please take a look. Will proceed to merge this in next few hours as 1st step in unblocking instrumentations in contrib repo. |
src/OpenTelemetry.Instrumentation.AspNetCore/Implementation/HttpInListener.cs
Show resolved
Hide resolved
| static OpenTelemetry.Trace.TracerProviderBuilderExtensions.AddLegacyActivity(this OpenTelemetry.Trace.TracerProviderBuilder tracerProviderBuilder, string operationName) -> OpenTelemetry.Trace.TracerProviderBuilder |
There was a problem hiding this comment.
Not a big fan of this name. How about AddLegacySource? Given we have AddSource already.
There was a problem hiding this comment.
I am okay with AddLegacySource
There was a problem hiding this comment.
we have opportunity to rename this until 1.1 stable is out, so i'd prefer to not block this pr.
There was a problem hiding this comment.
Fine by me, I'll stamp as approved.
Currently, the instrumentation libraries depend on ActivitySourceAdapter to set the activity sampling to comply with the TracerProvider sampler. This PR demonstrates how we could implement instrumentation libraries without using ActivitySourceAdapter. I have updated AspNet, AspNetCore, HttpClient, and gRPC client instrumentation libraries to work without ActivitySourceAdapter.
Changes
ActivitySourceAdapterAddDiagnosticSourceInstrumentationAddLegacyOperationNamewhich creates an activity listener for the empty ActivitySourceName andmaintains a list of operation names to be looked up against on ActivityStarted callback to decide if the legacy activity should be processed
sourcesinAddInstrumentationmethod ofTracerProviderBuilderSdk.cs. ActivitySource is updated from an empty string to the assembly name inOnStartActivityof the instrumentation listeners, therefore we need to add these assembly names as a Source to the provider so that ActivityStopped callback can be called.ActivityInstrumentationHelper.csunder OpenTelemetry\Internal which is used by both AspNetCore and HttpClient instrumentation libraries.CHANGELOG.mdupdated for non-trivial changes