Service detection and naming

DESK automatically detects and names your applications' server-side services based on some basic properties of your application deployment and configuration. This topic explains how DESK detects services and how it names the detected services.

Process groups

DESK automatically groups related processes into process groups. When DESK 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 DESK 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 clustered service). Conversely, if DESK 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 DESK detects process groups.

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). DESK considers three discrete concepts when identifying and naming services—Web server name, Context root, and Web application ID.

• Web server name

  There are three different terms—Virtual host, Server block, and Site—that represent similar concepts across different technologies. Virtual domain name hosting combines web requests from multiple hosts, domains, and IP addresses into a single configuration on a web server. For example, Apache HTTP Server allows you to configure www.desk.com, www.desk.at, and www.desk.us all within the same virtual host. NGINX uses server block concept. In case of a server block, one needs to configure a server_name. Site is a concept established in Microsoft IIS. In kubernetes-based environments, Apache and NGINX web servers are often configured only as "localhost" or just an IP address. In these cases DESK automatically uses the auto-detected base pod name as the web server name to provide more a meaningfull representation out-of-the-box.

• Context root

  Within any given web container you may have multiple applications in multiple directories. For example /admin leads to the admin application while /shop leads 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.

• Web application ID

  Some technologies allow you to give your deployed web applications explicit names.

  • For Java servlets this is done by defining a display-name in the web.xml file.
  • For Spring boot applications you have to define the spring.application.name, which may be in the application.properties file or the application.yml file.
  • For Java technologies that don't allow for application naming (and to provide default application naming) you can define the Java command line property -Ddesk.application.id=<name>. This won't override the naming options mentioned above—it serves as a default for instances when no application name is otherwise available.
  • For Node.js you can define a name in the package.json file.
  • For other technologies, or to provide a default name, you can use the environment variable DT_APPLICATIONID=<name>. This won't override the naming options mentioned above—it serves as a default for instances when no application ID is available.

In DESK, you can easily find the above attributes for a service:

1. Select Transactions & services from the navigation menu.
2. Select the web request service you want to examine.
3. Click Properties and tags to expand the service. You can then view the above attributes.

DESK picks up some or all of these properties and then creates a unique service based on them. When DESK 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, DESK will pick up the name you specify.

Web services

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. DESK 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 DESK 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 DESK uses the web service endpoint rather than the name.

Database services

When DESK 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.

DESK 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?

For the full list of database services that are supported by DESK, see supported database services.

Messaging and queueing

DESK detects queue and message listeners in your applications and identifies them based on listener class name. Please see supported messaging services.

Queue listener services

Queue listener services tell you which queues you're listening to. These are light-weight services that don't have response times. These services tell you how many messages a queue has dequeued. They don't tell you anything about message processing—messaging services do that.

If DESK automatically detects an event-based message listener, a queue listener service is always followed by a messaging service, which gives you insight into messages details. However, if you're just monitoring a queue, and not looking into message details, the queue listener service may exist on its own.

Messaging services

Messaging services process messages from a queue. A message service is always preceded by a queue listener service, which listens to the queue the message came from.

If your application dequeues messages in a busy loop, DESK can't detect automatically how the messages are processed. To get insight for that, you can 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 the full list of remoting services that are supported by DESK, please 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, DESK creates only a single RMI service for each process group. This doesn't however mean that you lose visibility into your RMI services; DESK tracks and monitors each RMI class as a separate request type.

RPC service

DESK tracks remote procedure calls by SDKs, Akka, and AWSLambda. Unlike RMI, DESK 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, DESK 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.

See Why are my services not auto-detected? page to learn how to create custom services.

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 'DT_LOCALTOVIRTUALHOSTNAME' for each web server process to any value (for example, www.desk.com). DESK 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 DT_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 desk.application.id.

Rotating and anonymous ports

DESK 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 DT_IGNOREDYNAMICPORT=true. This removes the port from the detection and replaces it with *.