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
. - The URL path must contain the string
-
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.
- Placeholder(s) can extract values from request attributes or URLs.
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
Service-level rules and settings, including web request services clean URL rules, override global request-naming 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
, andIBAN
. -
Create clean URL rule.
Define the regular expressions to remove parts of a web request service URL path, such as IDs.
-
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.
Limitations
Atomic groups are not allowed in regular expressions for global request naming rules.