Capture request attributes based on web request data
To define a request attribute based on web request data:
- In the Dynatrace menu, go to Settings > Server-side monitoring > Request attributes.
- Click the Create new request attribute button.
- Provide a unique Request attribute name. You can rename an attribute at any point in the future.
- Indicate Data type.
You can't change Data type following request attribute setup.
- If multiple values exist in a single request, specify what should be stored in the request attribute for every request, and choose how to normalize the text.
- Check whether this rule should access unmasked data, and whether the request attribute contains confidential data.
This will potentially access personalized data.
- Add a data source. You can define one or more rules to specify how your attribute should be fetched.
Each rule needs a source. Dynatrace needs to know where it can collect the request attribute. You can define the rule by first selecting where the rule should be applied (based on process group, host group, service technology, or group tag), and then indicating where the actual parameter can be found (Request attribute source).
- Once you have added all the data sources, click Save to save your request attribute rule.
Request attribute rules
Have a look at the example request attribute rule below. Note that the request attribute
destination can obtain its value from two different sources, either an
HTTP Post parameter (
iceform:destination) or an
HTTP GET parameter (
destination). Rules are executed in order. If a request meets the criteria for both rules, its value will be taken from the first rule.
Each rule needs a source. In the example below, the request attribute source is a web request
HTTP GET parameter (
GET parameter will be captured on all monitored processes that support code-level insight and it will be reported on all requests that are monitored by Dynatrace.
While this is convenient, it’s not always what’s needed. This is why you can restrict rules to a subset of process groups and services. To do this, select process group and service names from the four drop-lists above to reduce the number of process groups and services that the rule applies to.
You may not be interested in capturing every value. In other cases, a value may contain a prefix that you want to check against. To do this, specify that the designated parameter should only be used if its value matches a certain value. You can also opt to not use an entire value, but instead extract a portion of a value. The example below is set up to only consider
HTTP POST parameters that begin with the string
Journey :. This approach will extract everything that follows the string
Journey: and store it in the request attribute.
Requests can have as many attributes as you want.
Request attribute sources for web requests
There are several different sources of request attributes for web requests. The most obvious are:
- HTTP POST parameters
- HTTP request and response headers
- Web request URL or one of its constituents, like the path or a query parameter
In the last two cases you can not only capture the necessary information, you can also choose if you are interested in the calling side of a web request (the client) or the processing side (the server). These sources are all technology independent and work everywhere. There are also some sources that are specific to certain technologies.
These two are specific to Java servlets and ASP.NET respectively. They are available with Dynatrace version 1.163+. In both cases the application can hold a complex object in such an attribute, and OneAgent will convert it to a string upon capture. This can have side effects, so be careful with what you capture.
In most cases, a captured value will contain what it is you’re looking for. However, you may not want an entire value, or even every value. With post processing you can manipulate the captured value.
Expand the Optionally restrict or process the captured parameter(s) further option to see the processing steps. The steps are executed in the presented order—each step is applied to the result of the previous step.
You don't have to apply all the steps. Each step becomes active once you provide a value for it or select the option box.
Step 1 enables you to extract something from the resulting string based on delimited characters.
Step 2 can split the captured value into several values based on a delimited character.
Step 3 removes whitespaces.
Step 4 enables you to filter out captured values that don't fit the provided criterion.
Step 5 enables you to extract something from the resulting string based a regular expression.