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

Attributes during Sampling for HttpClient and ASP.NET Core spans #2012

Open
vishweshbankwar opened this issue Sep 6, 2023 · 3 comments
Open
Labels
comp:instrumentation.aspnetcore Things related to OpenTelemetry.Instrumentation.AspNetCore comp:instrumentation.http Things related to OpenTelemetry.Instrumentation.Http enhancement New feature or request

Comments

@vishweshbankwar
Copy link
Member

vishweshbankwar commented Sep 6, 2023

Feature Request

Spec requires client and server spans to provide certain attributes(for client and for server) during sampling so that the information can be used to make sampling decisions. In .NET this is currently not possible to do at the instrumentation library level, as the spans are created by the HttpClient and ASP.NET Core libraries itself. To support this requirement, the change need to be done on the libraries side.

Opening this issue for reference.

@vishweshbankwar vishweshbankwar added the enhancement New feature or request label Sep 6, 2023
@martinjt
Copy link
Member

martinjt commented Sep 6, 2023

I've created a request here for this.

dotnet/aspnetcore#50488

@cijothomas
Copy link
Member

Need to create issue for HttpClient as well.
IIRC, one of the reason why this was not done was because ActivityTagsCollection is heap allocated and hence we avoided its usage until after sampling decision is made. It might be possible to leverage TagList for this purpose, with some support from Activity class itself in runtime.

We do this in SqlClient without alloc (because it was feasible). See open-telemetry/opentelemetry-dotnet#1971 (comment) too

@martinjt
Copy link
Member

martinjt commented Sep 6, 2023

the idea I had was to make it more of an extension, in the case that .NET didn't want to add the extra bits then it can become something that OpenTelemetry does.

Providing that extension point would be useful I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp:instrumentation.aspnetcore Things related to OpenTelemetry.Instrumentation.AspNetCore comp:instrumentation.http Things related to OpenTelemetry.Instrumentation.Http enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants