Try it free

Upgrade from service naming rules to service naming in Latest Dynatrace

  • Dynatrace Classic
  • Upgrade guide
  • 5-min read
  • Published Aug 28, 2026

This is a guide to upgrading from service naming rules (builtin:naming.services) to service naming in Latest Dynatrace.

Why upgrade?

In Latest Dynatrace with Smartscape on Grail, service naming rules (builtin:naming.services) no longer apply. Service names now come from your telemetry instead of from rules you maintain, so the configured display names are not carried over.

How much this affects you depends on which detection model your services use:

  • SDv2 services are largely unaffected. With SDv2 naming templates, you already get meaningful service names out of the box, so most services keep good names without any action.
  • SDv1 services are more likely to need attention. Without naming rules, they fall back to their raw detected name, which can be hard to distinguish—for example, :8080 or /api.

Where you do need to adjust a name, you have several options that work for both detection models:

  • Use primary tags instead of renaming, if your main goal is to filter and group services rather than change the displayed name.
  • Set dt.service.name with OpenPipeline Coming soon.
  • Set service.name at the source. Dynatrace prefixes it to the detected name, producing service.name + detected name.

What will you do?

You'll assess which services need attention, add context with primary Grail fields and tags, and rename services where the displayed name still needs to change.

Before you begin

Prior knowledge

  • You know the differences between Service Detection v1 and v2 and which model your services use.
  • Read how service names are derived in Latest Dynatrace.

New concepts

Primary Grail fields and tags

Dimensions enriched on all signals. Use these to carry context, such as environment, region, and team, without encoding it in the service name. See primary Grail fields and tags and our recommended approach of adding context with tags, not names.

OpenPipeline

Server-side processing rules that transform telemetry before it's stored, including renaming services without deployment changes.

Coming soon

Service naming via OpenPipeline is not available yet.

How to upgrade

1. Assess your services

Identify which detection model your services use.

  1. Go to Services Services > Explorer (Early Access).
  2. Select a service that needs attention.
  3. Examine the dt.service_detection.version property in the Properties tab to identify the applied service detection version. It states 1 for SDv1 and 2 for SDv2.

2. Enrich service metadata with primary Grail fields and tags

Before changing a service name, consider whether what you need is context, such as environment, region, team, or application. Primary Grail fields and tags add that context as queryable dimensions on all signals, so you can filter in Services Services without touching the name.

Use primary fields and tags to add the necessary context. Use them to replace service naming rules that encoded context in service names. For example, instead of a naming rule that produced my-service [prod, us-east, team-checkout], keep my-service as the name and filter by namespace=prod, region=us-east, team=checkout.

  1. If you used service naming rules, identify the context you encoded in the service names.
  2. For standard infrastructure attributes (cluster, namespace, host group, cloud account, region), use primary Grail fields. Dynatrace enriches these on every signal automatically and no configuration is required.
  3. For custom attributes such as team ownership, application name, or cost center, configure primary Grail tags to promote them into dimensions enriched on all signals.
  4. In Services Services, add the new fields and tags as columns to the table views and filter and sort by the promoted dimensions instead of relying on the encoded service name.

3. Rename a service

If primary fields and tags are not enough, you can change the service name itself.

  1. Review string-based filters that match services by name, for example, DQL queries, SLO filters, and alert conditions.

  2. Choose one of the following options.

    • SDv2 only Adjust service name templates.

      SDv2 services derive their name from attributes such as service.name and k8s.workload.name, among others—the exact attributes depend on the technology. If you need a different name, open the service detection configuration to check and adjust the service name template.

      Changing a service name template in SDv2 changes how detection works and creates new service IDs. Historical data stays under the old service ID. Do this only for newly deployed services or when breaking historical continuity is acceptable.

    • SDv2 & SDv1 Rename via OpenPipeline Coming soon.

    • SDv2 & SDv1 Set service.name at the source.

      Set OTEL_RESOURCE_ATTRIBUTES or OTEL_SERVICE_NAME as an environment variable on each application process.

    service.name is a process-level attribute. If a single process hosts multiple services, all services in the process share the same service.name. Services Services handles this by combining service.name with the detected name, for example, my-app (WebRequestService) and my-app (BackgroundWorker). Changing service.name impacts all services in the process and results in changing all their names.

  3. Update string-based references.

After you upgrade

  • Go to Services Services > Explorer (Early Access) and confirm that services show the names you expect. Name changes apply only to telemetry received after the change; existing data keeps the name it was recorded with.
  • Confirm that queries return results, SLOs compute correctly, and alerts behave as expected.

Related topics

  • Service naming
  • Service detection
  • Primary Grail fields and tags
Related tags
Application Observability