URL grouping not applied to traces in Splunk APM

Applicability

Splunk Distribution of OpenTelemetry Collector Splunk Distribution of OpenTelemetry .NET (auto-instrumentation) ASP.NET (.NET Framework) applications using WebForms (.aspx) OpenTelemetry.Instrumentation.AspNet

Description

A user configured the span/custom processor with the intent of grouping spans by HTTP method and route. The processor was added to the traces pipeline and the collector was restarted. After applying the change, span names from the ASP.NET WebForms application continued to appear in their original format rather than the expected METHOD::route format.

Example configuration that did not produce the expected span names:

 

processors:
  span/custom:
    name:
      from_attributes:
        - http.request.method
        - http.route
      separator: '::'service:
  pipelines:
    traces:
      processors: [memory_limiter, batch, span/custom]

 

In Splunk APM Trace Analyzer, the Initiating Operation column shows span names in the unchanged service-prefixed format (for example service-name: GET) rather than the configured GET::/some/path format.

 

Investigation

Open one of the failing traces in Splunk Observability Cloud APM Trace Analyzer and inspect the root server span. The right-hand details panel displays the span's attributes under a "Tags" heading and the resource attributes under a "Process" heading. Use the browser find function (Cmd+F or Ctrl+F) to search the panel for http.route.

 

If the search returns 0 of 0 (no matches), http.route is not present on the span. The span/custom processor renames a span only when every attribute listed in name.from_attributes is present. When any one is missing, the rename is silently skipped with no error or log message.

 

Reference: Span processor documentation, Splunk Observability Cloud

The reason http.route is missing on traces from ASP.NET classic WebForms applications is that the OpenTelemetry.Instrumentation.AspNet library does not populate http.route for WebForms pages. The OpenTelemetry HTTP semantic conventions state that "http.route 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." ASP.NET classic WebForms does not use route templates; .aspx pages are served directly from the file system, so the framework does not provide a matched route to the instrumentation.

 

Reference: OpenTelemetry semantic conventions for HTTP spans

 

Other frameworks where http.route may not be populated by the instrumentation library include any HTTP server that lacks a routing layer or where the routing is performed outside the framework's request lifecycle.

 

Resolution

Replace http.route with url.path in the span/custom processor

 

The OpenTelemetry.Instrumentation.AspNet library populates url.path consistently. For applications where dynamic identifiers are passed via query string (so they appear in url.query rather than url.path), url.path is low-cardinality and is suitable for use as a span-name source attribute.

 

Updated processor configuration:

processors:
  span/custom:
    name:
      from_attributes:
        - http.request.method
        - url.path
      separator: '::'

 

Apply and verify

1. Save the updated configuration file.
2. Restart the Splunk OpenTelemetry Collector service.
3. Generate a few new requests against the application.
4. In Splunk APM Trace Analyzer, open a recent trace and confirm that the root server span name follows the METHOD::url.path format. For example, a request to /myapp/SomePage.aspx via HTTP GET would now appear as GET::/myapp/SomePage.aspx.

 

When url.path is not safe to use directly

This approach is appropriate only when url.path itself remains low-cardinality. If the application embeds dynamic identifiers directly in the URL path (for example /myapp/Order/12345/Detail.aspx), using url.path for span naming will produce a high-cardinality explosion of distinct span names.

 

In that case, place a transform processor with OTTL statements before span/custom to normalise the path, replacing dynamic segments with placeholders, before the rename. The normalised value should be written to a temporary attribute that span/custom then consumes.

 

Revision History

Revision	Publish Date	Comments
1.0	01-Oct-2026	Initial Release