Dynatrace automatically detects and names your applications’ server-side services based on some basic properties of your application deployment and configuration. Generally speaking, these properties and the resulting service names should be intuitive to you because they reflect your service landscape. In some cases Dynatrace may not be able to detect a service, or the detected name may not make sense to you. This topic explains what Dynatrace looks for when detecting services and how it names the services that it detects.
Dynatrace places the processes it monitors into process groups. When Dynatrace detects multiple process groups it assumes that the process groups represent separate applications, or at least separate logical parts of a single application. Process groups therefore represent boundaries for the services they contain.
When Dynatrace detects the same service in multiple processes within the same process group, it represents the service as a single service running on multiple processes or hosts (i.e., a service cluster). Conversely, if Dynatrace detects a seemingly identical service in multiple process groups, it represents the separate service instances as separate services, even though the services appear to be the same. For this reason it sometimes makes sense to customize how Dynatrace detects process groups.
Web request services
Web request services serve the web applications that you deploy either in a Web server (for example, Apache, IIS, or Nginx) or run in a other web containers (for example, Java, .NET, Node.js, PHP, or Ruby). In all such cases there are three concepts that Dynatrace considers when identifying and naming services.
- Virtual host, Server block, Site
Virtual domain name hosting combines web requests from multiple hosts, domains, and IP addresses into a single configuration on a web server. As an example, Apache HTTP Server allows you to configure
dynatrace.comall within the same virtual host. Nginx has a similar concept called a “server block” where one needs to configure a
server_name. Microsoft IIS refers to this concept as a Site.
In Dynatrace you can find this attribute on any service page:
- Click the Services tile on the home dashboard.
- Select the service you want to examine.
- Click Show properties and look for the Web server name entry.
On any given web container you may have different applications in multiple directories. For example
/adminleads to the admin application while
/shopleads to the online store. In the Java world this is called a “context root.” Microsoft IIS refers to this concept as a Virtual directory. Most Web servers don’t even include this as an explicit concept. In Dynatrace you’ll find this value displayed beneath the Web server name (see instructions above for accessing service properties).
Web application ID
Some technologies allow you to give your deployed web applications explicit names. For Java servlets this can be done by defining a display-name in the web.xml file. For Node.js you can define a name in the package.json file. For other technologies this can be defined via an environment variable, see Adjusting service detection below.
Dynatrace picks up some or all of these properties and then creates a unique service based on them. When Dynatrace finds a Web application ID, it uses the ID as the default service name. In other cases, web request services are named based on Web server name + (context root). This means that if you give an IIS site a proper name or define a name for your web application in
package.json, Dynatrace will pick up the name the name you specified.
Web services are detected based on technology-specific Web service frameworks. Web services are defined by Web Services Description Language (WSDL), which is part of your deployment. WSDL defines services, how services are called, and service names. Dynatrace picks up service names along with
targetNamespace values and combines these values to uniquely identify each service.
For details on the web-service frameworks that are monitored by Dynatrace out-of-the-box, see supported web service frameworks.
In some cases it’s technically not possible to easily detect a web service name. In such cases Dynatrace uses the web service endpoint rather than the name.
When Dynatrace detects that your application makes database requests, it identifies the name of the database or schema, the database vendor, and the IP address/port of the database. It uses this information to define a unique monitored database service and, where possible, detect on which process the database service runs.
Dynatrace creates a unique monitored database service for each detected instance of Amazon RDS. For setup details, see How do I start Amazon Web Services monitoring? Note: The hostname you use to connect to Amazon RDS must be identical to the actual endpoint name (see examples below).
For the full list of database services that are supported by Dynatrace, see supported database services.
Dynatrace detects message listeners in your Java applications and identifies them based on listener class name.
To find out which messaging services are monitored by Dynatrace, please see supported messaging services.
In the world of Java, Remote Method Invocation (RMI) is a common means of communication used by JVMs. As there may be many dynamically-created RMI servers within a single JVM, Dynatrace creates only a single RMI service for each process group. This doesn’t however mean that you lose visibility into your RMI services; Dynatrace tracks and monitors each RMI class as a separate sub-service.
For the full list of remoting services that are supported by Dynatrace, please see supported remoting services. .
In many cases services are called by threads that run in the background of your application or another application. We refer to these as internal services. We at Dynatrace believe that you should want to know where these calls come from. Internal services represent the background activity of monitored process groups that make calls to other services. If you have a background thread in a Tomcat that makes web requests to Apache, Dynatrace represents this as an internal service of Tomcat. You’ll be able to see which requests Tomcat is making to your Apache by analyzing the response time of the Tomcat Internal service.
Adjusting 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 web site instances. To remedy such issues, configure process-group detection settings.
When there is no virtual host configured in 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, then these services will be temporary.
To remedy such localhost scenarios, use an environment variable to define virtual host names. Simply set ‘DYNATRACE_LOCALTOVIRTUALHOSTNAME’ for each web server process to any value (for example, www.dynatrace.com). Dynatrace will pick up the names and use them in place of the existing localhost virtual host names. With this approach you can ensure that multiple physical hosts (i.e., a “cluster”) 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 these cases, you can define an environment variable called
RUXIT_APPLICATIONID to provide 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
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 you can set the environment variable ‘RUXIT_IGNOREDYNAMICPORT=true’. This removes the port from the detection and replaces it with *.