In Dynatrace, service names come from your telemetry. Dynatrace names each service from OpenTelemetry resource attributes such as service.name and k8s.workload.name, so the names in the Services app are meaningful by default, with no naming rules to maintain. Because the name lives on the telemetry, it travels with your spans, metrics, and logs: the name you see on a dashboard is the same one you query, alert on, and build SLOs against. This page explains where service names come from and how to set a service's name yourself.
Dynatrace uses two detection models, and the naming experience differs between them. Knowing which one named a service tells you whether you need to do anything at all.
Service Detection v2 names services from the OpenTelemetry resource attributes already on your spans, so you get readable names without any configuration:
k8s.workload.name. A workload called checkout appears as the checkout service.service.name, that value becomes the service name directly.These names follow OpenTelemetry conventions, so your naming approach is the same whether your data comes from OneAgent, the OpenTelemetry SDK, or both. SDv2 services are meaningful by default and rarely need any naming configuration. For the full list of attributes Dynatrace uses, see the built-in service detection rules.
Service Detection v1 is the classic detection model for OneAgent-instrumented processes, used for technologies that don't yet report OpenTelemetry resource attributes. It names a service from the technology and properties it detects on the process, such as the web container, framework, or context root, rather than from a service.name attribute.
Because SDv1 derives the name from what it detects, this is the model where naming a service yourself makes the biggest difference. Setting service.name gives an SDv1 service the label you want and carries that name onto its telemetry, as described next.
Setting a name yourself is most useful for Service Detection v1 services, since Service Detection v2 already derives meaningful names. To choose a service's name, set the OTEL_SERVICE_NAME environment variable on the application process:
OTEL_SERVICE_NAME=my-checkout-service
This works with OneAgent. You don't need the OpenTelemetry SDK or the OpenTelemetry Span Sensor enabled.
If you want to set other resource attributes at the same time, use OTEL_RESOURCE_ATTRIBUTES instead:
OTEL_RESOURCE_ATTRIBUTES=service.name=my-checkout-service
How the value appears depends on how the service is detected:
service.name as the service name directly.service.name (detected name), and the value is also set as dt.service.name on the service's spans and metrics.When you want to tell similar services apart by environment, region, team, or application, keep the service name clean and put that context on the data as dimensions you can filter and sort by.
Instead of a name like checkout [prod, us-east, team-payments], keep checkout and filter the service list by k8s.namespace.name, region, or primary_tags.team. The information is the same, but it's structured and queryable.
In the Services app, use the Explorer Preview tab to filter and sort your services by these fields and tags directly. For more information, see Services app.
service.name appears on telemetry sent after you set it. Existing metrics and spans keep the name they were recorded with.service.name is a process-level attribute. With Service Detection v2, one process maps to one service, so each service carries its own name. With Service Detection v1, a process that hosts more than one service shares a single service.name across them.service.name for display as the transition completes.