[Feature Request] OpenTelemetry tracing integration #666

Activity

1. zhiyuanliang-ms commented on May 19, 2025

   

   Zhiyuan Liang (zhiyuanliang-ms)

   on May 19, 2025

   Last edited by zhiyuanliang-ms

   Member

   More actions

   Hi, Juliano Leal Goncalves (@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"]));

   👍React with 👍1Reacted by Juliano Leal Goncalves
2. Zhiyuan Liang (zhiyuanliang-ms)

   self-assigned this

   on May 19, 2025
3. Zhiyuan Liang (zhiyuanliang-ms)

   added

   enhancementNew feature or requestNew feature or request

   on May 19, 2025
4. julealgon commented on May 19, 2025

   

   Juliano Leal Goncalves (julealgon)

   on May 19, 2025

   Author

   More actions

   Zhiyuan Liang (@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.

   👀React with 👀1Reacted by Zhiyuan Liang
5. zhiyuanliang-ms commented on May 25, 2025

   

   Zhiyuan Liang (zhiyuanliang-ms)

   on May 25, 2025

   Member

   More actions

   Hi, Juliano Leal Goncalves (@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?
6. julealgon commented on May 26, 2025

   

   Juliano Leal Goncalves (julealgon)

   on May 26, 2025

   Author

   More actions

   Zhiyuan Liang (@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.

   👍React with 👍1Reacted by Zhiyuan Liang