When monitoring with OneAgent, your deployed applications and related microservices are automatically detected by Dynatrace, based on specific properties of your application deployment and configuration, such as the application identifier, part of the URL, or the server name.
Attributes used for detection are marked with an asterisk ✱ on the service overview page, under Properties and tags.
In certain cases, the quality of data available to Dynatrace might be insufficient for high-precision service detection. To tailor out-of-the-box detection to your environment, you can create new rules or setup improvements.
Manage rule-based service detection
You can use transformation rules, for example, to remedy the following use cases:
If the web Application IDs contain the version or build date, you can define a rule that removes the build date/ID from the web application ID.
When server names are not properly defined in the underlying deployment (for example, with Apache HTTP or Nginx in AWS environments), you can define a stable web server name and therefore a stable cluster service containing all instances.
You can correct the misuse of the context root in the deployed application.
A typical web server has a concept called the context root to separate services based on the URL. For some technologies, such as Node.js, the context root is not available or it's improperly defined. You can superimpose the context root, and create separate services for each of your applications, instead of a single service containing multiple applications.
You can ignore the port for service detection. This is helpful when the port is used dynamically, for example, in Node.js applications.
Additionally, the rules can be exported and imported from one environment to another.
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.
API onlyrequired To be able to configure rule-based service detection via the Settings API, you need an access token with Read settings (settings.read) and Write settings (settings.write) scopes. To learn how to obtain it, see Create an access token.
Create a rule
When you define a new rule, depending on the 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.
To define a new service detection rule via web UI
Go to Settings.
Expand Service Detection and select a request type (Full web request rules or Full web service rules, or External web request rules or External web service rules).
Select Add item and start configuring the parameters of the new rule.
Type a Rule name.
To identify your service, turn on at least one of the following:
Application identifier
URL context root
Server name.
To target the rule application, configure restrictions related to, for example, a management zone, specific conditions, or the port.
Select Save changes.
This procedure overwrites any existing configuration. If you want to modify an existing configuration, see the Modify a rule section below.
To define a new service detection rule via API
Query the settings schema via the GET a schema call—it contains the information about parameters included in the settings object.
The ID of schema depends on the request type, as summarized in the following table.
When you modify a rule, some services might not be affected by it anymore. While historical data is available only for the previous service, all newly captured data is then associated with the new standalone service.
To edit an existing rule via the web UI
Go to Settings.
Expand Service Detection and select a request type (Full web request rules or Full web service rules, or External web request rules or External web service rules).
Expand the row of the rule.
Edit the rule settings.
Select Save changes.
To update an existing rule via API
Query the settings schema via the GET a schema call—it contains the information about parameters included in the settings object.
The ID of schema depends on the request type, as summarized in the following table.
"name":"Detect Application, Application-1 as the same",
"description":"Example: merge services",
"managementZones":["-8445121454707515572"],
"idContributors":{
"applicationId":{
"enableIdContributor":true,
"serviceIdContributor":{
"contributionType":"TransformValue",
"transformations":[
{
"transformationType":"REMOVE_NUMBERS",
"minDigitCount":1,
"includeHexNumbers":false
}
]
}
},
"contextRoot":{
"enableIdContributor":false
},
"serverName":{
"enableIdContributor":false
}
},
"conditions":[
{
"attribute":"ApplicationId",
"compareOperationType":"StringStartsWith",
"textValues":["application"],
///Added condition to ignore case sensitivity for texts.
"ignoreCase":true
}
]
}
}
]
Use the PUT an object call to send your configuration.
Delete a rule
If you delete a rule, all individual services are split and once again treated as standalone services.
To delete a service detection rule
Go to Settings.
Expand Service Detection and select a request type (Full web request rules or Full web service rules, or External web request rules or External web service rules).
In the Delete column for the corresponding rule row, select Delete row
To delete a rule via API
Query the list of existing rules via the GET objects call. Specify the schema of your request type in the schemaIds query parameter.
The ID of schema depends on the request type, as summarized in the following table.
Find the rule you want to delete, and copy its objectId.
Delete the rule via the DELETE an object call. Use the object ID obtained in the previous step.
Examples
Separate fully monitored web request services based on URL or superimposed context root
For some technologies monitored by Dynatrace, the context root is not supported. A single service per process group is detected by default. You can change service detection by imposing a context root on a fully monitored web request.
In this example, when the URL path of a full web request starts with specific wording (blog/), we want to detect a service, whose ID will be transformed to the first segment of the URL.
Go to Settings.
Expand Service Detection and select Full web request rules.
In the full web request rules, select Add item.
Configure the parameters as follows
Enter a Rule name.
optional Enter a Description.
Go to URL context root and turn on Transform this value before letting it contribute to the Service ID.
From the Contribution type list, select Use transformed URL path.
In Segments to copy from URL path, enter the number of segments of the URL to be kept (1).
Go to Conditions and select Add item.
From the Take the value of this attribute list, select URL path.
From the Apply this operation list, select Starts with.
Go to Values and select Add item, then enter blog/.
"description":"Detect first segment of an URL path as service when it starts with blog/",
"managementZones":[],
"idContributors":{
"applicationId":{
"enableIdContributor":false
},
"contextRoot":{
"enableIdContributor":true,
"serviceIdContributor":{
"contributionType":"TransformURL",
"segmentCount":1,
"transformations":[]
}
},
"serverName":{
"enableIdContributor":false
}
},
"conditions":[
{
"attribute":"UrlPath",
"compareOperationType":"StringStartsWith",
"textValues":["blog/"],
"ignoreCase":false
}
]
}
}
]
Merge application data into a single service, based on the application ID value
When incoming data is volatile or not specific enough, you can use service detection rules to merge services, for example, Apache HTTP clusters in AWS without a proper virtual host or web application IDs containing the build date.
In this example, we want to merge in the same service all incoming data from applications whose ID starts with application.
Go to Settings.
Expand Service Detection and select Full web request rules.
In the full web request rules, select Add item.
Configure the parameters as follows.
Enter a Rule name.
optional Enter a Description.
Select Set a management zone and choose the management zone for the list.
Go to Application identifier and turn on Trasform this value before letting it contribute to the Service ID.
From the Contribution type list, select Use transformed value.
Go to Transformations and select Add item.
From the Transformation type list, select remove numbers.
Enter a min digit count (1)
Go to Conditions and select Add item.
From the Take the value of this attribute list, select Application identifier.
From the Apply this operation list, select Starts with.
Go to Values and select Add item, then enter application.
Separate services for “public network services” based on URL
In this example, when the top-level domain of an external web request ends with a specific wording (dynatrace.com), we want to detect a service, whose ID will be transformed to the first segment of the URL.
Go to Settings.
Expand Service Detection and select External web request rules.
In the full web request rules, select Add item.
Configure the parameters as follows.
Enter a Rule name.
optional Enter a Description.
Go to URL context root and turn on Transform this value before letting it contribute to the Service ID.
From the Contribution type list, select Use transformed URL path.
In Segments to copy from URL path, enter the number of segments of the URL to be kept (1).
Go to Public domain name and turn off Port.
Go to Conditions and select Add item.
From the Take the value of this attribute list, select Top level domain.
From the Apply this operation drowpdown list, select Ends with.
Go to Values and select Add item, then enter dynatrace.com.
Separate services for “public network services” based on subdomains
If different endpoints shouldn’t be combined in the same service (for example, support.dynatrace.com and blog.dynatrace.com), you can instruct Dynatrace to detect multiple services from the same domain, based on the detected hostname instead of the request's domain name.
Go to Settings.
Expand Service Detection and select External web request rules.
In the full web request rules, select Add item.
Configure the parameters as follows.
Enter a Rule name.
optional Enter a Description.
Go to Public domain name and turn on Transform this value before letting it contribute to the Service ID.
From the Contribution type list, select Use the original value.
Turn on Copy from host name.
Turn off Port.
Go to Conditions and select Add item.
From the Take the value of this attribute list, select Top level domain.
From the Apply this operation drowpdown list, select Ends with.
Go to Values and select Add item, then enter dynatrace.com.
"description":"Blog example: Separate services for public network services based on subdomains ",
"managementZones":[],
"idContributors":{
"applicationId":{
"enableIdContributor":false
},
"contextRoot":{
"enableIdContributor":false
},
"publicDomainName":{
"enableIdContributor":true,
"serviceIdContributor":{
"contributionType":"OriginalValue",
"copyFromHostName":true
}
},
"portForServiceId":false
},
"conditions":[
{
"attribute":"TopLevelDomain",
"compareOperationType":"StringEndsWith",
"textValues":["dynatrace.com"],
"ignoreCase":true
}
]
}
}
]
Separate services for unmonitored hosts based on hostname or IP range
Similarly to how you can add information about requests to third-party domains, you can tell Dynatrace more about services to unmonitored hosts and also check against the called IP addresses.
In this example, the service Single Sign On is behind all requests to the IP range 211.44.94.0–212.113.5.0. Dynatrace retains information about the multiple IPs in the detected service and tracks the performance of the different IPs as separate service instances. In this way, you can set up detection to have:
A single service for multiple hosts and/or IP ranges.
Multiple services based on hostname subdomains.
Multiple services based on the superimposed context root.
Go to Settings.
Expand Service Detection and select External web request rules.
In the full web request rules, select Add item.
Configure the parameters as follows.
Enter a Rule name.
optional Enter a Description.
Go to Application identifier and turn on Trasform this value before letting it contribute to the Service ID.
From the Contribution type list, select Override to constant value.
Go to Value ovveride, in the Value field, enter Single Sign On.
From the Transformation type list, select remove numbers.
Enter a min digit count (1)
Go to Public domanin name and turn off Port.
Go to Conditions and select Add item.
From the Take the value of this attribute list, select IP.
From the Apply this operation list, select Is in range.
In From and To, enter the values of the IP range (211.44.94.0–212.113.5.0).
"description":"Unmonitored hosts based on IP range (211.44.94.0–212.113.5.0)",
"managementZones":[],
"idContributors":{
"applicationId":{
"enableIdContributor":true,
"serviceIdContributor":{
"contributionType":"OverrideValue",
"valueOverride":{
"value":"Single Sign On"
}
}
},
"contextRoot":{
"enableIdContributor":false
},
"publicDomainName":{
"enableIdContributor":false
},
"portForServiceId":false
},
"conditions":[
{
"attribute":"IpFromContainer",
"compareOperationType":"IpInRange",
"ipRangeFrom":"211.44.94.0",
"ipRangeTo":"212.113.5.0"
}
]
}
}
]
Improve 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 might 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 *.
Frequently asked questions
When you create, edit, or delete a rule, data monitored after the change in service detection rules is aggregated and assigned to services, depending on the rule configuration. If a service stops receiving data, its historical data remains available (for example, for charting). You can still see the service and its traces in your environment.
