Capture request attributes based on web request data
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.
Indicate Data type.
The Data type can't be changed 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.
Each rule needs a source. DESK 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).
Click Save to save your data source definition.
You can define one or more rules to specify how your attribute should be fetched.
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 (destination).
This 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 DESK.
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 iceform:destination 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 DESK 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.
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.