Track business transactions using advanced request naming rules

According to most common definitions of the term “business transactions,” Dynatrace has provided business-transaction monitoring for some time already. For example, Dynatrace automatically detects your services and your requests. This means you can use request naming rules to adjust how your web requests are tracked and to define business transactions in your customer-facing workflow that are critical to the success of your digital business. With such end-to-end tracing, Dynatrace enables you to view and monitor important business transactions from end-to-end.

With the introduction of request attributes Dynatrace enables you to capture even more context around your requests and to use this to slice and dice through your data. This post explains how to use both request naming rules and request attributes to analyze the performance of key business transactions in your environment.

Business transaction setup

The first step in setting up a business transaction for monitoring is to create web-request naming rules with conditions that define the business transaction.

1. Select Transactions & services from the navigation menu.
2. Select the service you want to configure.
3. Click the Browse (…) button.
4. Select Edit.
   

   

5. On the Service settings page, select the Web request naming rules tab.
   

   
   

   The previous naming and extraction rule settings have been replaced with combined request-naming rules that are much more powerful.
   

   

6. Define a set of conditions that represent the criteria of your business transaction. In this example, the first condition specifies that—to be considered part of the business transaction—the URL path must contain the string orange-booking. The second condition specifies that the request must be an HTTP method of type GET. The last condition specifies that the request must have the attribute easyTravel destination.
   

   
   

   You can use anything from request headers to code-level method argument values to identify specific requests. This example request attribute actually has multiple sources. In this context, the source doesn’t matter—what matters is the fact that this string was detected in the transaction.
   

   
   

   All requests that match the specified criteria will be named based on the defined naming pattern, Booking.

Power of request attributes

Once you’ve defined web-request naming rules for your business transaction, you may decide to include the value of a request attribute as part of the request name to create intuitive variant names for this request. Using the request attribute easyTravel destination, you can create variant requests for tracking purposes that represent each permutation of the respective request attribute—in this case, a variant request for each destination that’s booked by customers of easyTravel.

The result is that this rule no longer creates a single kind of request; it now creates a separate trackable request for each booked destination (see the list of request names at bottom of image below).

As you can see in the list of related PurePaths below, while the URLs are all the same, each request name includes a different destination-city attribute value.

By constructing your business transactions in this way for Dynatrace monitoring, you can now track all of your organization’s key business transactions at a highly granular level.

Advanced request naming

You can even create extraction rules for your web-request naming rules that extract values from request attributes or URLs. The example below extracts the booking stage ({stage}) of the booking from the URL.

Using this extraction rule, the resulting list of request names appears as follows:

And of course, you can combine the two naming approaches detailed above to create even more finely-grained request names. The rule example below defines a request naming pattern that includes both the booking stage ({stage}) and the destination attribute ({RequestAttribute:easyTravel destination}).

The resulting request list appears below. Now we get a separate request for each booking stage, plus further splits based on the destination attribute.

And, of course, as these are all standard requests, you can use them as sources for custom charts on your Dynatrace dashboard. To create a custom chart based on a request, the request must first be marked as a key request. For details, see What are key requests?

Multi-tiered service analysis

The full value of setting up your business-critical requests in this way becomes apparent once you dig into the analysis that’s available for each individual request on the service level. To illustrate, let’s add another request naming rule that splits out the booking requests based on the attribute LoyaltyStatus.

This addition results in separate requests to this service based on loyalty status.

Now when we look at an individual PurePath we can see how useful the two defined request attributes are. In this example, we see that a Booking to Miami Beach was performed by a customer who has Gold loyalty status. This was achieved by defining a request naming rule on the easyTravel Customer Frontend service that tracks bookings per destination and separate request naming rule that tracks bookings on the backend BookingService based on loyalty status.

As you can see, request attributes give you complete flexibility in identifying and naming your requests based on your business requirements. Dynatrace tracks each request from end-to-end and tells you how all the requests are related!

Multi-dimensional analysis

Because request naming rules produce distinct service requests, we have even further filtering options based on the attributes of the new requests that have been defined. In this next example, I’ve combined the destination breakdown with Platinum loyalty status.

Of course, you can also leverage this functionality in combination with powerful hierarchical filtering. In this example, we analyze booking requests that are in stage finish, with a destination of San Francisco, and loyalty status Platinum.

While this has been possible using request attributes alone, the request naming makes this approach even more powerful than ever.

Impact on baselining, API, and analysis

Because request naming rules produce distinct service requests, each request is independently baselined and monitored for performance anomalies. These performance metrics captured for these requests are also separately accessible via the Dynatrace timeseries API endpoint.

Going forward

This improvement is a game changer in terms of how you can utilize the power of Dynatrace. Yet, this is only the beginning of what we can do with request attributes. We will soon add more functionality around request attributes. Look forward to custom- and business-error detection, custom service metrics, and more.