Configure URL path pattern matching in Service Detection v2

  • Latest Dynatrace
  • How-to guide
  • 7-min read

Dynatrace SaaS version 1.330+

SDv2 (Service Detection v2) uses the http.route span attribute to create endpoint names. Web frameworks like Spring, Express, and .NET Core set http.route automatically, so most services get descriptive endpoint names—like GET /api/orders/{id}—with no configuration.

Web servers and reverse proxies, such as Nginx, Apache, IIS, and Kong, typically don't set http.route, so their endpoints fall back to generic names like GET /*. URL pattern matching fills this gap: you define URL path patterns that SDv2 uses to derive stable, low-cardinality endpoint names from raw URL paths.

You don't need to configure URL pattern matching for every service; you should do that only for the services that lack http.route. Each rule has a matching condition that scopes it to specific services, workloads, or namespaces, so teams can create and manage rules for their own services independently.

URL pattern matching doesn't discard the original URL path. The raw URL is always available. To view individual URLs, select View URLs next to an endpoint, or query them directly in Notebooks Notebooks and Dashboards Dashboards.

URL pattern matching uses the url.path.pattern span attribute. The HTTP request method and URL path pattern built-in endpoint rule uses this attribute and takes precedence over the HTTP request method and route rule, so your URL patterns take priority when both url.path.pattern and http.route are available.

Use cases and examples

The URL pattern matching feature is particularly useful for the following use cases:

Use caseURL patternURL pathResulting endpoint

Nginx reverse proxy routing

/api/_/_/{id}

/api/v1/users/john

/api/v2/users/jack

/api/v1/users/{id}

/api/v2/users/{id}

API versioning patterns

/api/_/_/{id}

/api/v1/orders/123456789

/api/v2/orders/987654321

/api/v1/orders/{id}

/api/v2/orders/{id}

Mixed depth paths

/blog/_/_/*

/blog/2024/11/my-post.md

/blog/2024/12/my-holiday.md

/blog/2026/01/15/my-thoughts.md

/blog/2026/02/05/my-memories.md

/blog/2024/11/*

/blog/2024/12/*

/blog/2026/01/*

/blog/2026/02/*

URL pattern syntax reference

URL patterns are built from four token types. Use them to replace high-cardinality parts of your URLs (IDs, version numbers, deep paths) with stable placeholders.

TokenSyntaxMatchesOutputWhen to use

Literal

/api/orders

Exact path segment

Copied as-is

Fixed path parts that never change

Placeholder

{id}, {date}

Exactly one segment

{id}, {date}

Hide dynamic values (IDs, UUIDs, timestamps)

Variable

_

Exactly one segment

Original value kept

Segment should remain visible (for example, API version)

Catch-all

*

Zero or more trailing segments (must be last)

*

Match any remaining path depth

Examples:

PatternURL pathResulting endpoint

/api/orders

/api/orders

/api/orders

/api/orders/{id}

/api/orders/1234

/api/orders/{id}

/api/_/orders

/api/v1/orders

/api/v1/orders

/internal/*

/internal/service/operation/extra

/internal/*

Configure URL pattern matching

The sections below describe how to create and manage URL pattern matching rules.

Create a URL pattern matching rule

To create a URL path pattern matching rule

  1. Go to Settings Settings > Process and contextualize > Services > URL path pattern matching.

  2. Select New rule.

  3. Fill in the following optional and required fields.

    • Rule name: User-defined name for the rule.

    • Description: Human-readable descriptor of the rule.

    • Matching condition: DQL matcher. If the matching condition applies, the rule is evaluated.

    • URL path patterns: URL path pattern according to the pattern syntax reference.

      Select Add URL path pattern when more path patterns should be added.

      If required, use (Drag to order row) to re-order the added URL path patterns, considering that the first matching pattern is used to determine the url.path.pattern attribute value.

  4. Select Create.

  5. When required, use (Drag to order row) to re-order your URL path pattern matching rule, and then select Save.

The example rule below demonstrates common URL path pattern techniques: a matching condition scopes the rule to a single Kubernetes workload, {id} placeholders normalize dynamic path segments to prevent high-cardinality endpoints, and wildcards (*) group related sub-paths together.

A URL path pattern matching rule for a HashiCorp Vault workload, with a DQL matching condition scoping it to a single Kubernetes workload and four URL path patterns using placeholders, variables, and wildcards
A URL path pattern matching rule for a HashiCorp Vault workload, with a DQL matching condition scoping it to a single Kubernetes workload and four URL path patterns using placeholders, variables, and wildcards

Scope rules to teams

The matching condition in each rule determines which spans the rule evaluates. Use matching conditions to scope rules to specific services, workloads, or namespaces so that different teams can create and manage their own URL pattern matching rules independently.

Below are the most common scoping patterns:

  • Single workload: matchesValue(k8s.workload.name, "nginx-proxy")
  • All services in a namespace: matchesValue(k8s.namespace.name, "payments")
  • Workloads by prefix: matchesValue(k8s.workload.name, "nginx*")
  • Cluster and namespace: matchesValue(k8s.cluster.name, "prod") and matchesValue(k8s.namespace.name, "checkout")

Because each rule is scoped to specific spans, teams can work independently:

  • Rules from different teams don't conflict, as each rule only evaluates spans that match its condition.
  • Teams can add, update, or reorder their own patterns without affecting other teams.
  • Place more specific rules higher in the list. Rules are evaluated from top to bottom, and only the first matching rule applies.

For matching condition syntax, see DQL matcher in OpenPipeline.

For OpenTelemetry-instrumented services that don't natively set http.route, you can derive it centrally using the OpenTelemetry Collector's transform processor. This can reduce the number of services that need URL pattern matching rules.

Manage URL pattern matching rules

You can edit, disable, or delete your URL pattern matching rules.

  1. Go to Settings Settings > Process and contextualize > Services > URL path pattern matching.
  2. Perform the required changes to your URL path pattern matching rules:
    • Edit a rule: Select (Actions menu) > .
    • Make a copy of a rule: Select (Actions menu) > Duplicate.
    • Permanently delete a rule: Select (Actions menu) > Delete.
    • Re-order the rules: Use (Drag to order row).
    • Disable or enable a rule: Use in the Status column.
  3. Select Save to apply the changes you've made.

Pattern matching logic and precedence

  • Only spans with span.kind == server and span.kind == consumer are processed.

  • For each rule, the matching condition is evaluated first. If the span doesn't match the condition, the rule is skipped and evaluation moves to the next rule.

  • One URL path pattern matching rule may contain one or more URL path patterns.

  • URL path pattern matching rules are evaluated in order from top to bottom. Only the first matching rule is applied. The first rule with a URL pattern that matches is applied to a span.

  • URL path patterns within a matching rule are also evaluated in order from top to bottom. Only the first matching URL pattern is applied.

    The first matching URL path pattern defines the resulting value for the url.path.pattern attribute of a span. When the URL pattern matches, the url.path.pattern span attribute is based on this matching URL pattern.

  • URL patterns operate on path segments; path segments are URL parts between a slash /.

  • Leading slashes in URL paths are normalized before matching.

    Before URL patterns are evaluated, any number of leading slashes in the path is reduced to a single / to ensure consistent and reliable matching.

  • Matching is case sensitive.

Related topics

Related tags
Application ObservabilityServices Classic