Service-related concepts
- Latest Dynatrace
- Explanation
- 6-min read
Dynatrace turns the telemetry your workloads emit into services you can monitor. This page explains those concepts from the top down, starting with services and their health and ending with the trace data underneath.
Services
In Dynatrace, a service monitors the functionality deployed as a workload, such as a Kubernetes workload, an AWS Lambda function, or an NGINX web server on a virtual machine (VM). All spans related to the service are enriched so that they can be accessed via the service entity in Smartscape.
To explore services and their related data in your environment, use the 
Services app.
Service metrics
For each service, Dynatrace provides three kinds of metrics:
- Endpoint metrics for the service's API, modeled as endpoints. These metrics are also called request health metrics or service request metrics and include throughput, failure count, and response time.
- Message processing metrics that model queue interactions and FaaS invocations.
- Service mesh metrics that are automatically emitted by the service mesh infrastructure.
Service detection
Dynatrace detects services automatically from the trace data your workloads emit. All spans from a single running workload belong to one service. For example, all spans from one Kubernetes workload form a single service.
Dynatrace offers two service detection approaches: Service Detection v1 (SDv1) and Service Detection v2 (SDv2). These approaches share the same goal: turn your workloads into services that provide metrics you can act on. Both approaches detect services from span data and produce the same endpoint metrics. They differ in how they define a service.
- SDv1: Classic service detection for OneAgent-instrumented processes. It uses technology-specific service types, each with dedicated configuration, and works best for monolithic applications and application servers.
- SDv2: Service detection approach that uses a single set of resource-attribute rules, both built-in and user-defined, evaluated against every span of a trace. It works with OpenTelemetry and OneAgent span data and is best suited to cloud-native microservices.
For details, see Service detection.
Service entity
Every detected service also exists as a service entity in Smartscape on Grail. This topology representation makes a service and its metrics queryable with DQL and connectable to the rest of your environment.
For relationships, use cases, and query examples, see Explore the service entity in Smartscape on Grail.
Endpoints and entry points
Endpoints
Endpoints represent the API entry points of a service: the HTTP routes and (g)RPC methods that callers reach. SDv1 also treats non-API-related spans as endpoints, giving a broader endpoint list, whereas SDv2 keeps endpoints focused on API entry points.The endpoint metrics count and measure the requests executed against them, and all endpoints appear in Services for both service detection versions.
Both service detection versions surface endpoints, but they define endpoints in slightly different ways.
- SDv1: With Enhanced endpoints activated, endpoints are derived automatically and supersede the concept of key requests.
- SDv2: Endpoints are defined through rules that match span attributes.
Endpoints vs URLs
An endpoint is a logical grouping, such as GET /orders/{id}, that represents an API rather than an individual request. A URL is the specific path of one request, such as /orders/12345 or /orders/67890. Dynatrace aggregates metrics at the endpoint level to give you stable, low-cardinality data for your dashboards, SLOs, and alerts, while the underlying URL paths are fully available in Distributed Tracing and via DQL.
Endpoint naming
Wherever possible, endpoints take descriptive names straight from your application. For HTTP requests, Dynatrace uses the http.route span attribute. Most modern frameworks, including Spring, Express, Django, ASP.NET Core, Flask, and FastAPI, set http.route automatically, so your services get the endpoints the development team defined, with clear names like GET /books/search and POST /orders/checkout. For gRPC and other RPC calls, endpoints are named by combining the RPC service and method with a dot, for example, oteldemo.PaymentService.Charge.
Web servers and reverse proxies that don't emit http.route (NGINX, Apache, IIS, Kong, and IBM WebSphere Liberty) still get a stable name: Dynatrace derives an http.route from the URL path where available, and uses a generic name like GET /* otherwise. For details, see the Automatic naming for services without http.route section for SDv1 and SDv2.
To improve or customize endpoints:
- SDv1 services: Create request naming rules to define endpoint names based on URL conditions. For details, see Fine-tune endpoint names.
- SDv2 services: Configure URL pattern matching rules to derive stable endpoint names from raw URL paths.
Entry points
Entry points mark the first span of a trace within a service that is associated with an endpoint. It's therefore flagged with transaction.is_root_span and transaction.is_endpoint_request.
- SDv1: SDv1 treats any first span produced when a service is invoked as an endpoint, even when a span doesn't represent an incoming API request. That means every
transaction.is_root_spanalso carries thetransaction.is_endpoint_requestflag. - SDv2: A span that doesn't represent an incoming API request is not treated as an endpoint, so endpoints stay focused on actual API requests. The span still carries the
transaction.is_root_spanflag.
Requests
Requests are individual executions against an endpoint. Each request feeds the endpoint metrics aggregated at the endpoint level.Both service detection versions track requests against endpoints, with a small difference in scope.
- SDv1:
- Services are split by technology, so web request services and messaging services are always separate services, even when they're part of the same process. While a messaging service has the message processing metrics, SDv1 treats every transaction as a request and records an endpoint and endpoint metrics.
- SDv1 still creates an endpoint for every consume or process messaging operation that triggers the service.
- Background services (for example, triggered by a cron job and not an incoming request) are created and provide endpoints and requests.
- SDv2: SDv2 defines an endpoint as a request to an API of a service that follows a request-response pattern. This includes any HTTP, RPC, RMI, and gRPC API of monitored services. SDv2 records endpoint metrics only for these and marks respective transaction root spans with the
endpoint.namedimension.
- Message consumption only records message processing metrics, which have different dimensions (
messaging.destination.nameandmessaging.system). - FaaS invocations are only booked for FaaS functions, which have FaaS-specific dimensions.
- An HTTP request to a FaaS function gets both an endpoint and a FaaS invocation metric.
- An SQS-triggered FaaS invocation gets message processing metrics and FaaS invocation metrics.
Key requests
Key requests are a legacy way to flag individual requests as requiring special attention, for example, critical business measures or vital technical functionality. SDv1 (with Enhanced endpoints activated) and SDv2 automatically monitor all endpoints, whereas key requests are configured manually. Additionally, message processing metrics are produced automatically in Grail, and key requests are no longer needed for these.
Switch to Enhanced endpoints for SDv1
Instead of defining key requests for SDv1 services, activate the Enhanced endpoints for SDv1 feature. It automatically surfaces all SDv1 endpoints in Services, not only key requests.
Mark endpoints with primary Grail tags
To find and filter specific endpoints as a group in dashboards, SLOs, notebooks, and workflows, use OpenPipeline to enrich the related spans with primary Grail tags, for example, primary_tags.environment or primary_tags.business_unit.
Starting with Dynatrace SaaS version 1.343+, primary Grail tags propagate to the endpoint metrics, providing a consistent filter across dashboards, SLOs, notebooks, and workflows.
Underlying telemetry
Services, endpoints, and requests are all built from the span telemetry your workloads emit. These are the underlying building blocks.
Distributed traces and spans
Spans
Spans are single units of work within a distributed trace. Depending on the instrumentation, a span often represents a single method call, but can also be a broader logical unit of work. Each span carries attributes and information such as a span ID, span name, start time, duration, span events (for example, exceptions), span kind, and parent span identifier. Spans link through the parent span identifier to form a tree.
In the context of service detection, some spans mark the root of a transaction. When that root span represents a request, it receives the endpoint attribute. The response time of the endpoint or FaaS invocation is measured from this span, and it also determines whether the request failed.
Distributed traces
Distributed traces are sequences of spans that share a trace ID and follow one path through your services and components. They show how a request propagates across a distributed system and support Dynatrace Intelligence root cause analysis for cause-and-effect relationships.
Attributes
Attributes are key-value pairs that describe spans, requests, or resources, for example, a span name, response codes, HTTP methods, URLs, or failure-detection results. Dynatrace uses attributes to group, query, find, and analyze traces. It also uses them to detect and name services, gather entity relationships for Smartscape topology, connect log data to traces, understand span duration impacts, and analyze executed code. Attribute keys adhere to the Dynatrace Semantic Dictionary.
Errors, exceptions, and failures
Errors and exceptions are captured as attributes on spans (for example, span events) within distributed traces. They provide details about request processing problems, including an error type, message, stack traces, timestamp, and associated span context. Errors and exceptions are captured automatically from OneAgent-monitored applications and OpenTelemetry instrumentation.
Failures are determined by failure detection, typically based on error and exception data. Errors and failures are distinct: a request counts as failed only when failure detection marks it as such. Configuration differs between SDv1 (global or per-service settings) and SDv2 (rule sets based on span attributes).