Service detection rules

Dynatrace automatically detects your deployed applications monitored by OneAgent and related microservices through specific properties of your application deployment and configuration, such as the application identifier, part of the URL, or the server name. In certain cases, information available to Dynatrace might be insufficient or incorrect for high-precision service detection. Service detection rules and the related API enable you to feed Dynatrace the needed information to improve out-of-the-box detection.

Manage rule-based service detection

To manage service detection rules, in the Dynatrace menu, go to Settings > Service Detection.

• If the requests are fully monitored by Dynatrace, select Full web request rules or Full web service rules
• If the requests go to external resources, select External web request rules or External web service rules

Detection rules are evaluated from top to bottom, and the first matching rule applies, so be sure to place your rule in the correct position on the list.

Create a rule

To define a new service detection rule

1. Select Add item.

2. Type a Rule name.

3. To identify your service, turn on at least one of the following: Application identifier, URL context root, and Server name.

4. optional Consider restricting your detection rule by:

   • Setting a management zone
   • Adding specific conditions
   • Disabling the port

   While this step is optional, it provides a quick means of reducing the number of services to which a rule applies.

5. Select Save changes.

Depending on the rule configuration, the original services might get less traffic or no traffic at all. New monitoring data is then redirected according to the rule configuration, between the original and the newly-detected services.

Edit a rule

To edit an existing rule

1. Expand the row of the rule.
2. Edit the rule settings.
3. Select Save changes.

When you edit a rule, some services might not be affected by it anymore. While historic data is available only for the previous service, all newly captured data is then associated with the new standalone service.

Delete a rule

To delete a service detection rule, select (Delete row) in the Delete column of the corresponding row.

If you delete a rule, all individual services are split and once again treated as standalone services.

Schema info

You can view the Schema ID by selecting More (…) > Schema info in the upper-right corner of the settings page. They are:

• builtin:service-detection.full-web-request
• builtin:service-detection.full-web-service
• builtin:service-detection.external-web-request
• builtin:service-detection.external-web-service

FAQ

Improve automatic and rule-based service detection

Web server naming issues

• In some cases, web servers don't have well-defined virtual hosts, server names, or sites. A web server may simply be named localhost. This can result in multiple similar services that contain multiple website instances. To remedy such issues, adjust process-group detection settings.

• When there is no virtual host configured on an Apache HTTP server, the web server name defaults to the name of the physical host. In cloud environments, this leads to one virtual host for each physical host instance and thus one service instance. If the cloud environment starts and stops the hosts, these services will be temporary.

  To remedy such localhost scenarios, use an environment variable to define virtual host names: set DT_LOCALTOVIRTUALHOSTNAME for each web server process to any value. Dynatrace will pick up the names and use them in place of the existing localhost virtual host names. With this approach, you ensure that multiple physical hosts report the same virtual host and thus get one service with multiple instances, one instance per physical host.

Define web application IDs

Some technologies don't provide unique application names. In such cases, you can define an environment variable called DT_APPLICATIONID to provide a unique name. This only impacts services of the respective process that don't already have application IDs. For Java applications, you can alternatively use the system property dynatrace.application.id.

Rotating and anonymous ports

Dynatrace takes the listen port of each web request service into account when naming and detecting requests. In some cases, these ports are meaningless or random, changing with each restart. This is especially true if you're using a load balancer that dynamically assigns ports to application processes, as is the case in many Node.js scenarios.

To remedy this, set environment variable DT_IGNOREDYNAMICPORT=true. This removes the port from detection and replaces it with *.