Automate naming and segmentation of requests for business transaction monitoring at scale

Dynatrace automatically detects all monitored services and monitored requests in your environment. By default, Dynatrace uses domain-specific naming schemes to identify and name each detected service and request—URLs are used for web requests, web method operations are used for web services, actor classes are used for Akka, and message flow names are used for IBM Integration Bus.

With request-naming rules, you can apply your own naming standards to reflect how your business thinks about its business-critical transactions. Request-naming rules also enable you to change how requests are grouped together in charts, baselining, and performance analysis.

We released this powerful functionality just over a year ago to define business transactions in your customer-facing workflow that are critical to the success of your digital business. This was achieved by enabling the use of request attributes in request-naming rules. With such end-to-end tracing, Dynatrace enables you to view and monitor important business transactions from end to end.

The customer feedback we’ve received regarding request-naming rules has been tremendously positive. As Dynatrace users have taken advantage of this functionality, one common request we’ve received is the ability to define request-naming rules that enforce common naming standards across multiple detected services. Another feature request we’ve received is the ability to configure request-naming rules via the API so that automation can be leveraged when setting up multiple environments. We’re happy to announce that all this functionality is now available with the release of Dynatrace 1.164.

Service request naming

In the following example of the new Service-request naming API, the icefaces request is a typical example of a request for resources in Java Server Faces. As with many REST-based approaches, the ID of the requested object is part of the URL path itself.

This leads to a lot of rather sparse requests that occur rarely or are even unique. This makes baselining and alerting on resource requests imprecise. What’s more, it clutters your request tables.

To group requests, define a request-naming rule, as shown below:

The UI controls for request naming could work fine for such a scenario, but you would to manually set up a rule with the correct pattern for each service. Now, with the request-naming API, you can use the API to define such global rules.

Request-naming API

Go to the Configuration API in the Dynatrace API Explorer and look for the request-naming API.

The API is self-explanatory and provides all the same functionality that’s available in the web UI. The condition list is quite a bit longer as it enables you not only to filter for specific requests but also to filter for specific services that you want your rules to apply to.

It takes a few minutes for new rules to go into effect. Once they do, you’ll see them listed for all applicable services in the list of available request-naming rules.

And sure enough, as you can see in the example below, the naming rule now applies to many services, not just one.

This works for all types of request-naming rules, including those that use request attributes in their naming patterns. This greatly reduces the amount of required configuration and allows you to ensure consistency across many applications, services, and teams.

You can import and export these rules, which is important if you have more then one Dynatrace environment that should share the same configuration. The import-export functionality is currently only available via the API—we’ll add a web UI option for this functionality in a future release.