Enable endpoint-level metrics for SDv1 services

Latest Dynatrace
How-to guide
8-min read

With Enhanced endpoints for SDv1, every detected endpoint on your Service Detection v1 (SDv1) services automatically produces metrics: response time, throughput, and failure count. No key request configuration is needed. These metrics are available in Dashboards, Notebooks, Service-Level Objectives, alerting, and Services. They are the same dt.service.request.* metrics produced by Service Detection v2 (SDv2) and OpenTelemetry services, so a single dashboard query works across all service detection versions.

Endpoint and span names will change

Services with http.route (Spring, Express, Django, and similar frameworks) get descriptive endpoint names automatically. Services without http.route (Nginx, Apache, IIS) will have endpoints flattened to generic names like GET /*. Review How endpoint names work and Fine-tune endpoint names before activating the Enhanced endpoints feature.

What this gives you

The Enhanced endpoints feature replaces the need to configure key requests. Existing key requests are preserved—any endpoint you previously configured as a key request keeps its name and appears alongside the new automatically detected endpoints. Every detected endpoint gets its own response time, throughput, and failure count automatically, with no manual selection needed.

Automatic metrics for every endpoint: Previously, only manually configured key requests got individual metrics, while everything else was aggregated into a single NON_KEY_REQUEST bucket. Enhanced endpoints eliminates that limitation.
One query across all detection versions: SDv1 and SDv2 services use the same dt.service.request.* metric keys. Build a dashboard once, and it works for all your services regardless of detection version.
Full endpoint visibility in Services: See every endpoint for your SDv1 services in Services, so you can pinpoint which endpoint is degrading instead of investigating an aggregated bucket.

No endpoints are created for external services, background activity services, queue listener services, or key value store services. In Services, these service types have dedicated views (such as Database queries, Message processing, and Outbound calls) instead of endpoints.

Use endpoints and metrics

Endpoints and their metrics appear in Services.

Go to Services > Explorer.
Select a service.
On the Overview tab, scroll to the Endpoints section.

From there, you can view endpoint metrics, open traces for each endpoint, and perform more actions using the Actions menu.

Services app showing the Endpoints section with four endpoints and their metrics

The Endpoints section shows each endpoint with its response time, throughput, and failure rate. You can sort by any column to find your slowest or most-called endpoints. To investigate a specific endpoint, select it to see its time-series charts and traces. To see the underlying URL paths, select an endpoint and select View all URLs to open Distributed Tracing. For more information on how endpoints differ from URLs, see Endpoints vs URLs.

You can also use endpoint metrics in:

Dashboards: Query dt.service.request.response_time filtered by endpoint name to track performance trends. The same query works whether the service uses SDv1 or SDv2.
Service-Level Objectives: Create SLOs targeting a specific endpoint response time or failure rate.
Alerting: Configure alerts on individual endpoint metrics to detect when a single endpoint degrades.

Metric keys

Metric	Key
Throughput	`dt.service.request.count`
Failure count	`dt.service.request.failure_count`
Response time	`dt.service.request.response_time`

Feature availability

Environment created in	Available in	Default	Configurable?
Dynatrace version 1.329 and earlier	Dynatrace version 1.333+	Off	Yes
Dynatrace version 1.330 – Dynatrace version 1.332	Dynatrace version 1.330+	On	Yes
Dynatrace version 1.333+	Dynatrace version 1.330+	On	No

Enable enhanced endpoints

You can activate enhanced endpoints for the entire environment, a specific host group, or a Kubernetes namespace and cluster.

Enable for the entire environment

Go to Settings > Process and contextualize > Services.
Under Service detection v1, select Enhanced endpoints for SDv1.
Turn on Enable enhanced endpoints for SDv1.
Recommended Turn on Resolve request attributes for SDv1 request naming rules. For details, see Request attribute values in endpoint names.

Enable for a host group

Go to Settings.
In the upper-left corner, select Go to entity, filter by Host group, and select the target host group.
Go to Process and contextualize > Services > Enhanced endpoints for SDv1.
Turn on Enable enhanced endpoints for SDv1.
Recommended Turn on Resolve request attributes for SDv1 request naming rules. For details, see Request attribute values in endpoint names.

Enable for a Kubernetes namespace or cluster

Go to Kubernetes.
Select the namespace or cluster.
Select (Actions menu) > Service detection settings.
Go to Process and contextualize > Services > Enhanced endpoints for SDv1.
Turn on Enable enhanced endpoints for SDv1.
Recommended Turn on Resolve request attributes for SDv1 request naming rules. For details, see Request attribute values in endpoint names.

The settings page is not available for environments created in Dynatrace version 1.333+ because Enhanced endpoints is always on.

How endpoint names work

Dynatrace names endpoints using the http.route span attribute. Services that provide http.route get descriptive names automatically; services without it get generic names like GET /*. For the general naming mechanism, see How endpoint names work.

For SDv1 services specifically, existing request naming rules continue to apply to endpoint names. Existing key requests are also preserved—any endpoint you previously configured as a key request keeps its name and appears alongside the automatically detected endpoints. You don't need to create new key requests because every endpoint gets individual metrics automatically.

Volatile and non-volatile placeholders in naming rules

Naming rule placeholders are either non-volatile (stable values like {HTTP-Method}) or volatile (high-cardinality values like {URL}). Dynatrace handles them differently to prevent endpoint explosion.

	Web request services	All other service types
Non-volatile placeholders only	Placeholders are replaced with actual values.¹	Placeholders are replaced with actual values.²
Contains volatile placeholders	Volatile placeholders are kept as is in the endpoint name.²	Volatile placeholders are kept as is in the endpoint name.²

For example, the {HTTP-Method} - {Request:IsKeyRequest} - user authentication endpoint template results in the GET - yes - user authentication endpoint endpoint name. Both {HTTP-Method} and {Request:IsKeyRequest} are replaced with their values, as these are non-volatile placeholder attributes.

For example, the {HTTP-Method} - {URL} - user authentication endpoint template results in the GET - {URL} - user authentication endpoint endpoint name. {HTTP-Method} (non-volatile) is replaced with GET, while {URL} (volatile) is not replaced and is used as is. The volatile placeholder attributes are: {OneAgentAttribute:} (except http.route), {Relative-URL}, {URL:Path}, {URL:Query}, {URL}, and customer-defined patterns based on these.

Request attribute values in endpoint names

If your naming rules use the {RequestAttribute:_} placeholder, turn on Resolve request attributes for SDv1 request naming rules to replace the placeholder with actual values. This produces separate endpoints per request attribute value, giving you finer-grained metrics. See Enable enhanced endpoints for detailed instructions.

Environment created in	Available in	Default	Configurable?
Dynatrace version 1.333+	Dynatrace version 1.333+	On	No
Dynatrace version 1.332 and earlier	Dynatrace version 1.333+	Off	Yes

Changes to span names in Distributed Traces

With all web requests now covered by an endpoint, span names in Distributed Tracing show the endpoint name rather than the URL path.

Trace list: To see the full URL path alongside the endpoint name, add a Url path column.
Single-trace view: The URL path and service name appear alongside the span name, as shown below.

Distributed Tracing app showing span with the name of the endpoint, URL path, and service name

Fine-tune endpoint names

Services that use generic endpoint names like GET /* group all traffic under a single endpoint, which limits your ability to set targeted SLOs, alerts, and dashboard filters. To get per-endpoint visibility for these services, identify which services need attention and then create request naming rules to produce specific endpoint names.

Identify services with generic endpoint names using DQL

Run this query in Notebooks to find services that lack http.route and see how many distinct URL paths each one handles:

fetch spans
| filter isNull(`http.route`)
      and request.is_root_span == true
      and isNotNull(`http.request.method`)
| summarize urls_without_http_route = countDistinct(url.path), by: {dt.entity.service, dt.service.name}
| sort urls_without_http_route desc
| limit 1000

Example results:

`dt.entity.service`	`dt.service.name`	`urls_without_http_route`
SERVICE-03694216F69B651D	:6767	607
SERVICE-A4365F245D125CDF	go-gorilla-mux	606
SERVICE-352C0D90592C8454	frontend-proxy	36

Each row shows a service and how many distinct URL paths are grouped under generic endpoints. Services with high counts are good candidates for request naming rules.

To see the actual URLs for a specific service, copy its service ID from the results and run this follow-up query (replace SERVICE-XXXXXXXXXXXXXXXX with the service ID):

fetch spans
| filter isNull(`http.route`)
      and request.is_root_span == true
      and isNotNull(`http.request.method`)
      and dt.entity.service == "SERVICE-XXXXXXXXXXXXXXXX"
| summarize request_count = count(), by: {http.request.method, url.path}
| sort request_count desc
| limit 100

Example results:

`http.request.method`	`url.path`	`request_count`
GET	/books	605
POST	/books	602

The results show you the individual URL paths and HTTP methods, helping you decide what request naming rules to create.

Find URL paths for a specific service in the Services app

Go to Services > Explorer and select your service.
In the Endpoints section, select the GET /* endpoint.
Select View all URLs to open Distributed Tracing with URL paths visible.

Services app showing the View all URLs button highlighted in the Endpoints section

The results show you the actual traffic patterns. For example, you might see /books, /books/403, /books/405, and other paths grouped under a single GET /* endpoint. These distinct URL paths are good candidates for a request naming rule.

Distributed Tracing showing a GET /* endpoint with distinct URL paths like /books, /books/403, and /books/405 grouped underneath

Create a naming rule

Create request naming rules to define specific endpoint names based on URL conditions. Request naming rules are configured per service—your existing per-service naming rules continue to apply when Enhanced endpoints is active. For example, if your service handles /books/* requests, you can create a rule that produces GET /books, POST /books, and DELETE /books endpoints instead of a single GET /*.

Go to Services and select the service you want to configure.
In the Endpoints section header, select (Actions menu) > Configure request naming.

Alternatively, select (Actions menu) > Settings in the upper-right corner, then go to Request naming or Web request naming.
Select Add rule.
Define a naming pattern using placeholders. For example, {HTTP-Method} /books captures the HTTP method and uses a fixed path segment.
Set conditions to match the target URLs. For example, URL path begins with /books.

Request naming rule configuration with the pattern {HTTP-Method} /books and a condition for URL path begins with /books

The key to stable endpoint names is using non-volatile placeholders (like {HTTP-Method}) combined with fixed path segments. This produces a small, predictable set of endpoint names. Avoid volatile placeholders like {URL} or {URL:Path} in naming patterns, as they contain high-cardinality values (order IDs, session tokens, or GUIDs) that create a new endpoint for every unique URL, which defeats the purpose of grouping.

More examples: Extract stable endpoint names from URLs

API with versioned paths: If your service handles /api/v1/users/123, /api/v1/users/456, /api/v2/orders/789, you can create rules to group by resource type:

Pattern: {HTTP-Method} /api/v1/users
Condition: URL path begins with /api/v1/users
Pattern: {HTTP-Method} /api/v2/orders
Condition: URL path begins with /api/v2/orders

This produces endpoints like GET /api/v1/users and POST /api/v2/orders instead of a unique endpoint per user or order ID.

Multiple path segments: If your service has /checkout/cart, /checkout/payment, and /checkout/confirmation, a single rule handles all three:

Pattern: {HTTP-Method} /checkout
Condition: URL path begins with /checkout

As an alternative, if you want separate endpoints per checkout step, create one rule per path.

Using the View all URLs workflow: The most effective approach is to first find the actual URL paths your service handles, then create rules that match the patterns you see. The URLs in Distributed Tracing Distributed Tracing results show you what to group.

View your new endpoints

After the naming rule takes effect, you should see specific endpoints that match your rule. Each endpoint has its own metrics for response time, throughput, and failure rate.

Distributed Tracing showing specific endpoints GET /books, DELETE /books, and POST /books with individual URL paths grouped under each

With specific endpoints in place, you can use them in dashboards, SLOs, and alerting as described in Use endpoints and metrics.

Manage endpoint cardinality

After configuring request naming rules, use the Endpoint Cardinality Dashboard to monitor how many endpoints each service produces and identify where you may need to tune your rules.

Endpoint Cardinality Dashboard showing services ranked by distinct endpoint count, with SpringBoot Distributor at 16 endpoints and other services below

The dashboard shows the maximum distinct endpoint names across all services and ranks services by their endpoint count. If a service produces an unexpectedly high number of endpoints, review its request naming rules to ensure volatile placeholders aren't creating excessive cardinality.

The Endpoint Cardinality Dashboard ranks your services by endpoint count, helping you identify where to adjust naming or detection rules to control cardinality.

To view services with the most endpoints

Go to Dashboards.
In the Dashboards panel on the left, select All dashboards.
In Search by name, enter Endpoint Cardinality Dashboard.
Select the dashboard to open it.

To display additional endpoint-heavy services, duplicate this dashboard and edit the DQL query behind the service list (for example, change 100 in limit 100 to the required value). Alternatively, you can add this query to Notebooks and modify it there.

If high-cardinality request attributes produce an excessive number of endpoints, turn off Resolve request attributes for SDv1 request naming rules to reduce endpoint volume. See Enable enhanced endpoints for detailed instructions.

Static resource requests

When the Enhanced endpoints feature is active, static resource requests (Image, Binary, CSS, and JavaScript) are unmuted and grouped into a single Static resources endpoint with the same metrics as other endpoints.

To mute static resource requests, follow the steps in Mute monitoring of service requests. After muting, the Static resources endpoint no longer appears in the endpoint list, and these requests don't count toward overall service metrics.

Whether static resources are muted or not, you can always use Distributed Tracing to view and analyze spans for CSS, images, or binary requests.

You can add or edit filename extensions that count toward the Static resources endpoint. For details, see Configure resource request detection. Existing resource request detection configuration still applies.

Licensing considerations

The Enhanced endpoints for SDv1 feature collects per-endpoint metrics individually rather than aggregating non-key-request endpoints into a single NON_KEY_REQUEST entry. The additional metric volume is typically within the included allowance for Full-Stack Monitoring.