To define a request attribute based on web request data:
- 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.
- You can define one or more rules to specify how your attribute should be fetched.
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 each and 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.
Optional post processing
In many 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. In such cases, expand the Optionally restrict or process the captured parameter(s) further option to enable post processing through the included optional fields. This option becomes visible once you choose a value from the drop lists at the bottom, for example if you choose a value from the Request attribute source drop list.
Once you expand this option, you will be presented with 5 steps of post processing. Note that each step is optional, which means that it can be skipped. Also, steps are executed in the order presented and therefore each is applied onto the values rendered from the previous step.
The first step enables you to simply extract something from the resulting string. Extraction can be performed either before, after, or between values. The extraction happens in your application and is based on string searches. For example, if your value is
<value>value1</value>, you can use the following to extract value1.
If the combination can’t be found in the captured value, then nothing will be captured. If the extraction is successful then only the extracted value will be captured.
In step 2, you can provide a text separator to split the captured value.
In step 4, you can select the option of pruning whitespaces.
Step 4 enables further filtering through the options provided in the drop list. You can define the captured values to be further filtered by considering a value for example only if it begins with a specific character.
For complex use cases, you can apply at step 5 a regular expression to the captured values.