Skip to content
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

[.NET 9.0] Native Trace Instrumentation Support for ASP.NET Core as per OTel specification #52439

Open
1 task done
vishweshbankwar opened this issue Nov 29, 2023 · 6 comments
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Milestone

Comments

@vishweshbankwar
Copy link

vishweshbankwar commented Nov 29, 2023

Is there an existing issue for this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Currently, users depend on the instrumentation library provided by the OpenTelemetry .NET repository to enable the enrichment of activities created during incoming requests, following the OpenTelemetry specification. This instrumentation library enriches activities by subscribing to DiagnosticSource events generated by ASP.NET Core. However, this approach has certain limitation and performance overhead of Diagnostic Source listeners and reflection.

Describe the solution you'd like

We are requesting the addition of native instrumentation support for ASP.NET Core in .NET 9.0. This enhancement will complement the out-of-the-box OTel metrics instrumentation introduced in .NET 8.0.

Additional context

When designing this feature, we need to consider the following aspects:

  1. Support for Enrichment and Filtering of Spans: Ensure that the native instrumentation supports the enrichment and filtering of ASP.NET Core spans.

  2. Custom Propagators: Address the differences in API between propagators in OpenTelemetry and the DistributedContextPropagator. Determine how custom propagators should be handled in this context.

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label Used by the dotnet-issue-labeler to label those issues which couldn't be triaged automatically label Nov 29, 2023
@vishweshbankwar
Copy link
Author

vishweshbankwar commented Nov 29, 2023

@noahfalk @tarekgh @JamesNK FYI

@gfoidl gfoidl added area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions and removed needs-area-label Used by the dotnet-issue-labeler to label those issues which couldn't be triaged automatically labels Nov 29, 2023
@amcasey
Copy link
Member

amcasey commented Dec 1, 2023

@vishweshbankwar Can you please tell me more about how this relates to #50488?

@amcasey
Copy link
Member

amcasey commented Dec 1, 2023

Also, this seems like something @JamesNK would already have thought about.

@dotnet-policy-service dotnet-policy-service bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@wtgodbe wtgodbe removed the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@dotnet-policy-service dotnet-policy-service bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@amcasey
Copy link
Member

amcasey commented Feb 8, 2024

@cijothomas Sorry, the bot went rogue. I believe it's fixed now.

@cijothomas
Copy link

@JamesNK Could you confirm if this is planned for .NET 9?

@JamesNK
Copy link
Member

JamesNK commented Jun 13, 2024

No it's not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Projects
None yet
Development

No branches or pull requests

8 participants
@adityamandaleeka @JamesNK @cijothomas @gfoidl @amcasey @wtgodbe @vishweshbankwar and others