Shouldn't the AspNetCore instrumentation ensure a leading slash on 'http.route' values?

[julealgon]

AspNetCore instrumentation will generate http.route values based on the route templates applied. For example the following controller

[Route("api/[controller]")]
public class CustomersController
{
    [HttpGet("{customerId}")]
    public string GetName(int customerId)...   
}

Generates an http.route value of:

• GET api/Customers/{customerId}.

Shouldn't that be:

• GET /api/Customers/{customerId}.

Instead?

I'm having a hard time finding an authoritative source for this but there is a mention of what seems to be the same thing over here:

• https://opentelemetry.io/docs/specs/semconv/attributes-registry/http/

[5]: MUST NOT be populated when this is not supported by the HTTP server framework as the route attribute should have low-cardinality and the URI path can NOT substitute it. SHOULD include the application root if there is one.

The reason I ask this question is that in our current setup, we actually have inconsistency here due to controller attribute routing, vs other middlewares such as GraphQL, Healthchecks, SignalR hubs, which we all start with the leading slash, eg:

• /graphql
• /health
• /hubs/myhub

As we are currently still relying on legacy AspNetCore 2.2 on .NET Full Framework, these middlewares don't actually produce any http.route value. To workaround that limitation, we added some custom enrichment logic on the AspNetCore Instrumentation to add the missing http.route value in a somewhat hardcoded way.

I now want to make sure I'm not introducing a future inconsistency into our observability if I prepend a slash or not on those cases.

The only other piece of "evidence" I've found is the PathString struct in AspNetCore.Routing which enforces a leading slash. This struct is actually used in a few overloads to some of those route configuration middlewares, such as:

• healthchecks: https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.builder.healthcheckapplicationbuilderextensions.usehealthchecks?view=aspnetcore-8.0#overloads
• signalR: https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.signalr.hubroutebuilder.maphub?view=aspnetcore-3.1#overloads

But other methods, such as the ones used for Minimal API, don't rely on PathString and instead use a normal string:

• MapGet: https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.builder.endpointroutebuilderextensions.mapget?view=aspnetcore-8.0#overloads

And others still, have both forms available:

• ApplicationBuilder.Map: https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.builder.mapextensions?view=aspnetcore-8.0#methods

Which one of the following is true?

• All routes should have the leading slash
• No routes should have the leading slash
• Routes can either have or don't have the leading slash (in this case, what should the criteria be?)

[DanielLaberge]

Same issue here: [ApiController, Route("/account/[action]"}) results in http.route=account/example.

Similar issue: https://github.com/open-telemetry/opentelemetry-dotnet/issues/4439

[vishweshbankwar]

@julealgon Thanks for raising this. I have tagged someone from ASP.NET Core team to see if this is intentional on the issue. Let's continue the discussion there.