Service types
This page provides an overview of the different types of services that can be detected and monitored in Dynatrace.
Web request services
Web request services serve the web applications that you deploy either via a web server (for example, Apache, IIS, or NGINX) or within web containers (for example, Java, .NET, Node.js, or PHP). Dynatrace considers three discrete concepts when identifying and naming web services: Web server name, Context root, and Web application ID.
You can find these attributes in the Properties and tags of the service overview page.
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 the web server name + the context root. This means that if you give an IIS site a proper name or define a name for your web application in web.xml
or package.json
, Dynatrace will pick up the name you specify.
Web services
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.
Dynatrace detects web services based on technology-specific frameworks. For details on the web-service frameworks that are monitored by Dynatrace out-of-the-box, see supported web service frameworks for Java and .NET.
Sometimes 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.
Database services
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.
For the full list of database services that are supported by Dynatrace, see supported database services.
Messaging and queueing
Dynatrace detects queue and topic listeners in your applications and identifies them based on the listener class name. See supported messaging services.
Queue listener services
Queue listener services tell you which queues or topics you're listening to. These are lightweight services that don't have response times. They tell you how many messages a queue or topic has dequeued; they don't tell you anything about message processing—messaging services do that.
If Dynatrace automatically detects an event-based message listener, a queue listener service is always followed by a messaging service, which gives you insight into message details. However, if you're just monitoring a queue, and not looking into message details, the queue listener service can exist on its own.
Messaging services
Messaging services (consumer services) process messages from a queue or topic. A messaging service is always preceded by a queue listener service, which listens to the queue or topic the message came from.
If your application uses non-event-based message queue handlers or dequeues messages in batch style, Dynatrace can't automatically detect how the messages are processed. To get insight into that, you must create a custom service for the message processing.
Remoting services
Remoting services are divided into two categories:
- Remote method invocation (RMI)
- Remote procedure call (RPC)
For a list of remoting services supported by Dynatrace, see supported remoting services.
RMI service
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. However, this doesn't mean that you lose visibility into your RMI services; Dynatrace tracks and monitors each RMI class as a separate request type.
RPC service
Dynatrace tracks remote procedure calls by SDKs, Akka, and AWSLambda. Unlike RMI, Dynatrace creates a separate RPC service for each service endpoint.
Background activity services
In many cases services are called by threads that run in the background of your application or another application. These requests, executed in background threads, represent the background activity of monitored process groups that make calls to other services. They also track outgoing messages in queues.
For example, if you have a background thread in a Tomcat that makes web requests to Apache, Dynatrace represents this as an background activity service of Tomcat. You'll be able to see which requests Tomcat is making to your Apache by analyzing the response time of the background activity service of Tomcat.
Custom services
Custom services allow you to instrument an application that is not built on standard technologies. You can also fine-tune your system, and instrument a particular method, class, or interface you're interested in. You can create custom services for Java, .NET, and PHP.
To learn how to create custom services, see Define custom services.
Span (default) service
The Span service is created when Dynatrace detects a service call to a span attachment.
- If a specific technology, such as GraphQL, is detected, you can perform most of the service analysis.
- If no specific technology is detected, a Span default service is created as a placeholder service to build a valid tree structure.
We recommend migrating your instances to the Unified service type.
Unified service
A Unified service is created when Dynatrace detects spans ingested via APIs, for example via OpenTelemetry.
Volatile services
A volatile service is a single service that aggregates numerous related, though separate, services. A volatile service is created when Dynatrace determines that too many individual services will be created based on the call information. Volatile services prevent the creation of numerous distinct services that are best understood as a single service.
You can use service detection rules to reduce the number of services. For example, you can merge connections from various ports into one service.