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.
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).
For each service, Dynatrace provides three kinds of metrics:
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.
For details, see Service detection (Services Classic).
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.
Both service detection versions surface endpoints, but they define endpoints in slightly different ways.
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 Traces.
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.
To improve or customize endpoints:
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.
transaction.is_root_span also carries the transaction.is_endpoint_request flag.transaction.is_root_span flag.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:
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.name dimension.
Message consumption only records message processing metrics, which have different dimensions (messaging.destination.name and messaging.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 are a legacy way to flag individual requests as requiring special attention, for example, critical business measures or vital technical functionality. SDv1 and SDv2 automatically monitor all endpoints, whereas key requests are configured manually.
Services, endpoints, and requests are all built from the span telemetry your workloads emit. These are the underlying building blocks.
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 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 Davis AI root cause analysis for cause-and-effect relationships.
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, connect log data to traces, understand span duration impacts, and analyze executed code.
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).