[Feature Request] `OpenTelemetry` tracing integration

[julealgon]

I noticed in the latest release notes for 8.2.0:

• https://github.com/Azure/AppConfiguration-DotnetProvider/releases/tag/8.2.0

That new Activities are now created for some of the actions performed by this package, with an activity source named Microsoft.Extensions.Configuration.AzureAppConfiguration.

With this in mind, could the team also provide an official instrumentation package for OpenTelemetry that listens on that activity source?

Usually, all traces and metrics are exposed to OTEL via one of those OpenTelemetry.Instrumentation.* packages, that either instrument the code themselves, or just tap into existing instrumentation (which I assume would be the case here).

In the meantime, my assumption is that we just need to call AddSource("Microsoft.Extensions.Configuration.AzureAppConfiguration") on the TracerProviderBuilder for the newly introduced activities to be propagated in a simplistic manner?

[zhiyuanliang-ms]

Hi, @julealgon. Thanks for reaching out! Good to hear from you again!

App Config is going to have its .NET Aspire component: PR.

.NET Aspire components all need to support OTEL tracing PR

With this in mind, could the team also provide an official instrumentation package for OpenTelemetry that listens on that activity source?

So, I personally don’t think providing the OTEL package should be a high priority. But I am not saying we will never provide a package for OTEL since OTEL is the trending and Microsoft is embracing it.

For those who are not using .NET Aspire, as long as they know the activity source, the below code snippet for OTEL is not very complex for them to configure tracing for App Config.

builder.Services.AddOpenTelemetry()
                .WithTracing(traceBuilder =>
                    traceBuilder.AddSource(["Microsoft.Extensions.Configuration.AzureAppConfiguration"]));

[julealgon]

@zhiyuanliang-ms thanks for getting back on this.

Adding the source works fine indeed, but just keep in mind that existing instrumentations also tend to add a custom Instrumentation object with metadata about the instrumentation.

The "official" package would likely have that in addition to the AddSource call.

[zhiyuanliang-ms]

Hi, @julealgon

Adding the source works fine indeed, but just keep in mind that existing instrumentations also tend to add a custom Instrumentation object with metadata about the instrumentation.

This is interesting. So this targets on the scenario of "tap into existing instrumentation". For my education, could you give me some examples?

The "official" package would likely have that in addition to the AddSource call.

Is there any existing examples to reference?

[julealgon]

@zhiyuanliang-ms I believe the closest example to what the AppConfig OTEL instrumentation would look like is the HTTP Client one, since that one also fully redirects to the built-in instrumentation starting with .NET7:

Here you can see how it adds both the source(s), as well as the instrumentation object that I mentioned.

https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/03c577940d9b3eb223e21af98ac8eeb692e8e5c9/src/OpenTelemetry.Instrumentation.Http/HttpClientInstrumentationTracerProviderBuilderExtensions.cs#L79-L86

The http version of that class doesn't implement any specific interface and in that case only has private members. You may want to double check why the OTEL team tends to add those, but I believe the main purpose is so that the OTEL SDK can output metadata about which instrumentations are present, including their versions, which it captures from the assembly version of the type you provide:

https://github.com/open-telemetry/opentelemetry-dotnet/blob/6209ed8f807a930110742ecb30de1abeb8a42047/src/OpenTelemetry/Trace/Builder/TracerProviderBuilderSdk.cs#L54-L62

It is interesting though the the Runtime metric instrumentation, another one which basically delegates to native instrumentation on later versions, doesn't seem to register that "instrumentation" object when it taps into the native one as evidenced by this:

https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/03c577940d9b3eb223e21af98ac8eeb692e8e5c9/src/OpenTelemetry.Instrumentation.Runtime/MeterProviderBuilderExtensions.cs#L38-L41

So perhaps the instrumentation object should really only be added when the logic actually contains custom instrumentations, and not when it just redirects to native instrumentation?

It is a bit confusing to me that these 2 examples appear to clash with each other. I assume someone from the OTEL team could clarify the distinction.