Set up request naming

You can use request naming rules to adjust how your requests are tracked and to define service entry and endpoints in your customer-facing workflow. With such end-to-end tracing, you can easily recognize and monitor important business transactions that are critical to the success of your digital business.

By using request attributes in combination with naming rules, you can capture even more context around your requests and use these additional details to slice and dice your monitoring data.

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

Before you start

Request naming rules are supported for the following service types.
- Web request (except Requests to unmonitored hosts and Requests to public networks)
- Web
- Method request
- Messaging and queing (except listener services)
- RMI
- CICS
- IMS
- Enterprise service bus
- Remote call
Key request detection is name based. If a request naming rule affects a key request and you want Dynatrace to keep detecting it as a key request, you need to add the new name to the list of key request names.

Create a request naming rule for a service

The first step in setting up clear naming for your service (web) requests is to create request naming rules with conditions that define how they appear in your environment.

In the Dynatrace menu, go to Services and select the service you want to configure.
Select More (…) > Settings.
On the Service settings page, go to the Request naming rules (or Web request naming rules) and select Add rule.
Define a set of conditions that represent the criteria of your service operations.

You can use anything from request headers to code-level method argument values to identify specific requests. All requests that match the specified criteria will be named based on the defined naming pattern.

In the example above, three conditions are defined.
- The URL path must contain the string orange-booking-payment.
- The request must be an HTTP method of type GET.
- The request must have the attribute easyTravel destination.
All requests matching all the specified criteria will be named based on the defined naming pattern PAYMENT.
Select Save.

Global request-naming rules

Service request naming API enables you to consolidate or refine requests across multiple services. Additionally, you can synchronize these rules across multiple Dynatrace environments. To learn how to create a global request-naming rule via API, see this use case.

Additional elements for request naming

Request attributes and placeholders

You can include the value of request attributes and placeholders in naming patterns.

Use a Request attribute to create intuitive variant names for your request. The request creates a separate trackable request for each permutation of the respective request attribute.

Example: Request attributes in naming patterns

Using the request attribute easyTravel destination in the naming pattern, a variant request is created 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.

Looking at the distributed traces, the URLs are all the same but each request name includes now a different destination-city attribute value.

Placeholder(s) can extract values from request attributes or URLs.

Example: Custom placeholders

If the URL path contains the string orange-booking, the booking defined by the placeholder stage is extracted from the URL naming pattern and uppercased. The placeholder stage is defined as the text between orange-booking- and .jsf in the URL path.

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

By constructing your service entry and end points in this way for Dynatrace monitoring, you can track all of your organization’s key operations, such as business transactions, at a highly granular level.

Cleanup rules

You can define global request-naming rules through the API to clean up the URLs of one or more services at the time.
Web request services have unique features to generate clean URLs via UI.

Accessing Service settings > Web request naming, you can:
- Remove UUIDs, IP addresses and IBANs from URLs.
  
  This action normalizes URL paths containing UUIDs, IP addresses, and IBANs by replacing specific values with content-related static strings, such as UUID, IPv4, and IBAN.
- Create clean URL rule.
  
  Define the regular expressions to remove parts of a web request service URL path, such as IDs.

Service-level rules and settings, including web request services clean URL rules, override global request-naming rules.

Note: Custom service request names are never masked.

Preview

You can modify a request naming rule or combine them to create even more fine-grained request names. Preview Rule shows the output of the new request naming rule.

In the above example, a new rule, Booking {RequestAttribute:easyTravel destination} - {stage}, combines the previous two examples. It defines a request naming pattern that includes not only the booking stage ({stage}) but also the destination attribute ({RequestAttribute:easyTravel destination}). Now we get a separate request for each booking stage, plus further splits based on the destination attribute.

Data masking

You can choose to display unmasked data for specific requests by selecting the checkbox Access unmasked data.

This will potentially expose personal data before it is stored and displayed.

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.

Request attributes give you absolute 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-tiered analysis

To illustrate multi-tiered analysis, let’s add another request naming rule that splits out the booking requests based on the attribute Loyalty.

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

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

Multidimensional analysis

Because request naming rules produce distinct service requests, you have even further filtering options based on the attributes of the new requests that have been defined. In the example below, the destination breakdown is combined with PLATINUM loyalty status.

You can also leverage this functionality in combination with powerful hierarchical filtering. In this example, we analyze booking requests that are in the finish stage, with a destination of shizunai, response time range 1s-2s, and Platinum loyalty status.

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