Library Name

Spring Cloud Gateway

Library Version(s)

Spring Cloud Gateway 3.1.5
Spring Cloud 2021.0.5
Spring Boot 2.7.8

Describe the feature you would like

Inbound Reactor Netty server spans created for Spring Cloud Gateway requests should use the matched Gateway Path predicate as the http.route tag.

For example, given this route:

spring:
  cloud:
    gateway:
      routes:
        - id: api-service
          uri: http://localhost:8081
          predicates:
            - Path=/api/**
          filters:
            - StripPrefix=1

A request such as:

GET /api/users/123?page=1

should produce:

operation.name: netty.request
http.route: /api/**

When route-based server resource naming is enabled, the resource name should also become:

GET /api/**

The matched predicate is preferable to the concrete request path because it is stable and low-cardinality.

Is your feature request related to a problem?

Yes. Spring Cloud Gateway does not publish its matched route through the WebFlux standard HandlerMapping.BEST_MATCHING_PATTERN_ATTRIBUTE.

Instead, it stores routing information in Gateway-specific exchange attributes:

GATEWAY_ROUTE_ATTR
GATEWAY_PREDICATE_MATCHED_PATH_ATTR
GATEWAY_PREDICATE_MATCHED_PATH_ROUTE_ID_ATTR

The current Spring WebFlux instrumentation only reads:

exchange.getAttribute(HandlerMapping.BEST_MATCHING_PATTERN_ATTRIBUTE)

As a result, the inbound Reactor Netty span can contain:

operation.name: netty.request
resource.name: GET /api/users/123
http.url: http://localhost:8080/api/users/123?page=1
http.route: absent

Spring Cloud Gateway already contains the low-cardinality matched pattern /api/**, but the tracer does not consume it.

Relevant sources:

• dd-trace-java HandlerAdapterAdvice
• Spring Cloud Gateway PathRoutePredicateFactory
• Spring Cloud Gateway RoutePredicateHandlerMapping
• Spring Cloud Gateway GatewayPathTagsProvider

When reading the Gateway-specific matched path, the implementation should verify that GATEWAY_PREDICATE_MATCHED_PATH_ROUTE_ID_ATTR belongs to the route in GATEWAY_ROUTE_ATTR. This avoids using a path left by an earlier candidate route whose remaining predicates did not match.

Describe alternatives you have considered

1. Setting http.route from the concrete request URL. This is not suitable because IDs and other dynamic path segments would create high-cardinality route values.

2. Manually tagging the active span in a Gateway filter. This couples application code to the tracing API and duplicates information already available from Spring Cloud Gateway.

3. Replacing RoutePredicateHandlerMapping in the application to copy the matched Gateway path into BEST_MATCHING_PATTERN_ATTRIBUTE. This is intrusive and requires every Spring Cloud Gateway application to implement the same workaround.

Tracer-level support for Spring Cloud Gateway route attributes would provide consistent behavior without application-specific tracing code.

Additional context

Observed with dd-java-agent 1.63.4.

The issue applies to inbound Spring Cloud Gateway requests handled by Spring WebFlux and Reactor Netty. Query parameters and StripPrefix filters should not affect the ingress route value.