Dynatrace recently introduced request attributes, a valuable new service-monitoring feature that enables fine-grain service filtering and performance analysis. By defining request attributes for your service’s requests, you can enable advanced filtering for service requests across all Dynatrace analysis views. Once configured, request attributes help you to better understand the relationships between performance, errors, and application-specific meta data in your requests.
Until now this functionality was only available for web request data; we’ve now extended request attribute functionality to include Java methods argument and return values.
Capturing a method argument value
To configure a request attribute
- Go to Settings > Server-side services > Request attributes.
- Click the Create new request attribute button.
- Click the Add new data source button.
- Optionally define the scope of the request attribute (for complete instructions, see our recent blog post).
- From the Request attribute source drop list, select Java method parameter(s).
- Click the Select method sources button to open the new Java class wizard. Here you can select the Java class of the method whose argument you want to set an attribute on.
- Begin by selecting the process group that contains the classes or interfaces you’re interested in and click Continue.
- Search for the Java class that includes the method you’re interested in. Simply begin typing the Java class name and click the Search button. The list may take a few seconds to populate.
- Pick a class from the displayed list. If the list doesn’t contain the class you’re looking for, refine the search string.
- Finally, pick one or more methods that you want to capture parameters from and click Finish.
The methods you select are listed in the method argument capture rule (see below). Now select which argument or return value you want to capture for each method.
You can always extend the list or remove methods later. Once saved, either restart the processes that you want this rule to apply to or go to Settings > Server-side service monitoring > Custom service detection and ensure that the Enable real-time updates to Java services switch is set to the On position.
Once your services begin calling the respective methods, you should see the request attribute appear on the service’s overview page, on the Request attributes tab.
You can now use your request attribute to filter your data. In the PurePath example below, note the new request attribute in the header and within the respective service call’s summary section.
Finally, notice that the code-level tree view also contains these methods. This view will be used later to display the argument values in case the method is called multiple times with different values.
Request attribute tips & tricks
In addition to argument values, you can also capture the Return value of any method, or simply the number of Occurrences. While return values should be clear, occurrences can be a bit tricky. You should only use a single method rule when capturing occurrences. Dynatrace will count the number of calls of this method within a single request.
Note: You can capture non-primitive and non-string objects. However, Dynatrace OneAgent will automatically call toString. In most cases, this should not be an issue. It can, however, result in performance overhead. Some objects may inadvertently change their state in toString, so be careful here. We will add more sophistication here in the coming weeks.
Multiple possible values
It is not hard to imagine that you could end up with multiple possible values. Simply define multiple data sources or multiple java methods. Even if you define a single java method, it might be executed multiple times in a single request.
At the moment only a single value is stored per service request and attribute. This means that if you capture multiple values in a single request only the first occurrence is used. The order is determined first by the order of data sources, second by the order of methods in the list and thirdly by the execution order of a single method (if that method occurs multiple times).
We will enhance this to allow more flexibility soon.
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, you can use the optional fields shown below to enable some post processing.
Simple data extraction
The first part 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.
Only capture specific values
Following simple extraction, you can decide if you really want to capture the specific value. This happens after the pre-processing mentioned above. This allows a simple string check that only captures values that fit a certain pattern.
Regex for advanced use cases
Finally, for the really complex use cases, you can use a regular expression to extract something from the captured value. This happens following the two other pre processing steps. You can use this regex in two different ways.
Simple match
Lets say you have a value Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0 Safari/537.36 and you want to capture the Windows version from this string. The regex Windows NT[^)]+ will capture Windows NT 10.0.
Group match
If you have more complicated needs you can use a group match. For example, if you want to extract the Chrome version without the word “Chrome,” use the regex Chrome\/([^ )]+) to extract 56.0. In this case only the group will be extracted and not the whole match.
Restrictions
Regular expressions are powerful, but they can lead to unexpected results (Lazy vs greedy matching) and they can quickly get expensive (Catastrophic Backtracking and repeated capture groups). For these reasons, we’ve decided to restrict regular expressions in the Dynatrace product:
- Quantified groups aren’t allowed. Please solve this in another way.
- Dynatrace doesn’t allow greedy matches within capture groups. Use lazy or possessive matching instead.
- Dynatrace allows exactly one capture group in places where you need to extract a value. The logic here is that if the regular expression contains a group, Dynatrace will use it. Otherwise, the full match is used for extraction.
- For pure matching cases, Dynatrace doesn’t allow any capture groups. Please use atomic groups instead.
- Dynatrace doesn’t allow back references.
OneAgent Requirements
This feature requires OneAgent version 125 or above.
Looking for answers?
Start a new discussion or ask for help in our Q&A forum.
Go to forum