Customize Dynatrace Service Detection and Naming Rules (2026)

Dynatrace’s default service detection and naming rules are surprisingly rigid, often forcing you into their predefined categories rather than reflecting your actual application architecture.

Let’s say you have a microservice written in Go, exposing an API via net/http. By default, Dynatrace might group this under a generic "Go" service or even a broader "HTTP" service, obscuring its unique identity and purpose.

Here’s what that looks like in the Dynatrace UI, before any customization:

Services
  -> Go
    -> /api/v1/users
  -> HTTP
    -> default

This is not ideal. You want to see user-service and product-catalog-api clearly distinguished.

The core problem Dynatrace solves here is mapping unstructured network traffic and code execution to meaningful, business-oriented service entities. It does this by inspecting network protocols, HTTP headers, and specific code patterns.

Internally, Dynatrace’s OneAgent uses a combination of heuristics and configuration to identify what constitutes a "service." This involves:

1. Protocol Detection: Identifying the underlying network protocol (HTTP, gRPC, Kafka, etc.).
2. Technology Detection: Looking for specific libraries or frameworks (e.g., Spring Boot, Node.js, ASP.NET Core).
3. Code-Level Instrumentation: In some cases, injecting code to observe specific function calls or request patterns.
4. Configuration Matching: Applying user-defined rules to override or refine the automatically detected services.

The primary levers you control are Dynatrace’s Service Detection Rules and Naming Rules, accessible through the Dynatrace UI under Settings -> Services -> Detection and naming.

Let’s dive into customizing these.

Customizing Service Detection

Service detection rules tell Dynatrace what to consider a service. You can create rules based on various attributes like process group name, IP address, port, or even specific process arguments.

Scenario: You have multiple Go applications running on the same host, distinguished by their command-line arguments.

Default Behavior: Dynatrace might group them all as "Go" or "HTTP."

Customization Goal: Distinguish them as user-service and payment-gateway.

Steps:

1. Identify a Unique Attribute: In your Go applications, you might start them with different binary names or flags, e.g.:

   • /usr/local/bin/user-service --port 8080
   • /usr/local/bin/payment-gateway --listen 9000

2. Create a Detection Rule:

   • Navigate to Settings -> Services -> Detection and naming -> Service detection rules.
   • Click "Add rule."
   • Rule Name: Go Microservices by Binary Name
   • Scope: Process group
   • Conditions:
     • Process name equals user-service (for the user service)
     • Process name equals payment-gateway (for the payment gateway)
   • Action: Detect as service.

   If your distinguishing factor is a command-line argument, you’d use Command line arguments contains <your_argument>.

Why it works: This rule explicitly tells Dynatrace that any process whose executable name is user-service or payment-gateway should be treated as a distinct service, overriding more generic detections.

Customizing Naming Rules

Naming rules tell Dynatrace how to label the services it detects. You can create sophisticated naming conventions based on existing attributes.

Scenario: You want all services running on port 8080 to be named [SERVICE_NAME]-api-v1 if they are HTTP services.

Default Behavior: Services might be named based on the technology (e.g., "HTTP") or the URL path.

Customization Goal: Standardized naming like user-service-api-v1.

Steps:

1. Create a Naming Rule:
   • Navigate to Settings -> Services -> Detection and naming -> Naming rules.
   • Click "Add rule."
   • Rule Name: Standardize HTTP API Naming
   • Scope: Service
   • Conditions:
     • Technology equals HTTP
     • Port equals 8080
   • Naming Pattern: Use a combination of attributes. A common pattern is to use the process group name and append a suffix.
     • {ProcessGroup:Name}-api-v1

Why it works: This rule applies a specific format to any service identified as HTTP and listening on port 8080. The {ProcessGroup:Name} placeholder dynamically inserts the name of the process group (which you might have also customized via detection rules).

The Power of Contextual Rules

You can combine detection and naming rules to build a highly accurate representation of your architecture. For instance, you can first detect a service based on a specific process argument, and then apply a naming rule that uses that detected service’s unique identifier.

Example: Imagine a Java application using a custom framework.

• Detection Rule:

  • Rule Name: CustomJavaFrameworkService
  • Scope: Process group
  • Conditions: Process name contains my-custom-app AND Command line arguments contains -Dcustom.framework.enabled=true
  • Action: Detect as service

• Naming Rule (applied after detection):

  • Rule Name: CustomFrameworkNaming
  • Scope: Service
  • Conditions: Service type equals CustomJavaFrameworkService (this refers to the detected service type from the previous rule)
  • Naming Pattern: {ProcessGroup:Name}-processing

This layered approach allows you to peel back generic layers and reveal the specific business logic running within your infrastructure.

One subtle but powerful aspect of naming rules is their ability to use a variety of placeholders, including custom request attributes you might have instrumented. This means you can name services not just by their technical identifiers, but by business-relevant data passed within transactions, like a customer ID or tenant ID, provided you’ve configured Dynatrace to capture those attributes.

The next step you’ll encounter is learning how to use Topology Analysis to visualize the dependencies between these meticulously named services.