New Dynatrace API enhances automatic service detection (Part 2)

Dynatrace automatically detects your deployed applications that are monitored by OneAgent. It does so by analyzing the running processes, identifying the applications supported by those processes, and mapping the processes to what we call “process groups” (each process group represents one application). Dynatrace then automatically detects all microservices that are part of an application through a rich combination of domain knowledge and broad technology support.

Thanks to this, Dynatrace can detect anything from Spring Boot-based REST services to business processes in IBM enterprise ESB. This works so fantastically well that we’ve integrated with ServiceNow to populate its CMDB automatically and literally put IT operations in autopilot mode.

In a recent blog post, we announced the ability to enhance Dynatrace service detection for web applications by supplementing Dynatrace knowledge about a given service. We’ve now added similar functionality for web services.

What are web services and why are they tricky to detect?

A web service is a microservice that exposes its API via HTTP. It’s always part of a web application, often the only part.

Originally all web services were SOAP-based (Simple Object Access Protocol) services. SOAP services have a very well-defined interface, but they are also cumbersome to produce and use. Dynatrace detects these automatically through its framework support in the code modules.

In the last decade, a large number of REST-based service frameworks have become popular. These have a less formal structure and are faster to implement and easier to use. The downside is that not everything that looks like a web service is a web service.

Enhancing Dynatrace automatic service detection

The following two use cases illustrate how the new Dynatrace API for automatic service detection helps with correct detection of REST-based web services.

Merge web services into the underlying web request service

Some REST-based web services aren’t really microservices. Frameworks like Jersey JAX-RS or Spring REST have a double life: they’re sometimes used to expose microservices, while in other cases, they’re just used as a convenient way to route a particular URL to a specific piece of code. When monitoring the latter, you could end up with many detected services that aren’t particularly meaningful to you.

With the new API, you can tell Dynatrace not to detect these web services but to recognize them as part of the underlying web application. As a result, all those superfluous services are merged into the underlying web request service.

Detect the same web service in multiple applications by including an application ID and/or context root

Dynatrace automatically detects and names your applications’ server-side services based on some basic application-deployment and configuration properties. However, if you happen to deploy the same web service code on an application server in two different applications, Dynatrace will detect these as just one service, not two.

With the new API, you can tell Dynatrace that it needs to include an application ID and/or context root. It can thus detect the same web service running in multiple applications correctly as separate services.

Use the service detection API to provide more context

Dynatrace uses two different notions of a web service. Consequently, there are two API endpoints in our new API.

• Fully monitored web services

These are services that expose their API via REST or SOAP APIs. Dynatrace detects this based on its rich technology support for web service frameworks. “Fully monitored” means that the underlying process is monitored by Dynatrace OneAgent.

• Opaque or external web services

Additionally, Dynatrace detects third-party and external microservices. These are called opaque services in Dynatrace because we know which processes they are hosted by but we can’t see inside them.

These are either third-party or unmonitored REST or SOAP web services that Dynatrace identifies via the technology stack in use.

As these are not directly monitored by OneAgent, we have less information. You can use the new API to provide the missing information and enhance service detection.

Attention: This endpoint is not yet ready and will return a Reserved for future error.

The new API can be found in the Configuration API:

How to use the new API

The service detection API enables you to tell Dynatrace more about your services and thus improve how they are detected. Let’s look at some concrete examples based on the use cases described above:

Merge web services into the underlying web request service

Do you have Spring REST and Jersey web services that you want to treat as web request services? Now you can easily do this with the new API. Here’s an example:
{
"type": "FULL_WEB_SERVICE",
"name": "Don't detect Jersey as WebService",
"description": "REST API example",
"enabled": true,
"detectAsWebRequestService": true,
"conditions": [
{
"attributeType": "FRAMEWORK",
"compareOperations": [
{
"type": "EQUALS",

“values”: [
“JERSEY”
] }
] },{
“attributeType”: “URL_PATH”,
“compareOperations”: [
{
“type”: “STARTS_WITH”,

“values”: [
“/idm/”
] }
] }
] }
This tells Dynatrace that all web services based on the Java framework Jersey that have URLs starting with /idm/ are to be treated as web requests rather than web services. The result in this case is that these web services aren’t detected as such.

They are replaced by a single web request service.

You’ll find all your requests here:

Detect the same web service in multiple applications

In the second use case, your web service might be exposed on a per-customer basis, yet the code is always the same. Depending on your framework, Dynatrace might not detect this. You can now use the new API to impose a context root on the web service (in the same way you would separate fully monitored web request services) or transform the web service name or namespace to accommodate the environment information.

What’s next

In the future, this functionality will cover third-party services as well.

Is your use case covered?

We welcome your feedback. Are your use cases covered? Do you have others? Please let us know.