Application Real-Time Monitoring Service (ARMS) allows you to extract specific parameters from requests and responses without modifying the code. This helps you locate the root causes of issues and trace request information. You can configure business parameter extraction rules and configure matching rules of custom error codes based on the configurations of the extracted parameters.
This continuous profiling feature is available only to Java applications.
Java reflection and serialization or deserialization are involved in business parameter extraction rules. This may incur extra overheads for your business. For information about the details of the overheads, see the Performance overheads section of this topic.
Prerequisites
An ARMS agent V4.1.0 or later is installed. For more information, see Application Monitoring overview. When you use an ARMS agent earlier than V4.1.0, this feature does not take effect even if it is configured.
In an ARMS agent V4.2.0 or later, multiple API match rules and parameter extraction rules can be added to a single business parameter extraction rule.
In an ARMS agent whose version is earlier than 4.2.0 but later than 4.1.0, only the first match rule takes effect.
Go to the Business Parameter Extraction Rules page
Log on to the ARMS console. In the left-side navigation pane, choose .
On the Application List page, select a region in the top navigation bar and click the name of the application that you want to manage.
NoteIf the icon is displayed in the Language column, the application is connected to Application Monitoring. If a hyphen (-) is displayed, the application is connected to Managed Service for OpenTelemetry.
In the top navigation bar, choose
.In the Business Parameter Extraction Rules section, you can create, view, or modify business parameter extraction rules for the application.
The ARMS agent dynamically identifies changes in business parameter extraction rules and extracts business parameters based on all enabled rules.
In the Customizing Error Settings section, you can configure matching rules of custom error codes to filter the values of the extracted business parameters.
Business parameter extraction rules
Supported parameter types and sources
Business parameter extraction rules impose requirements on frameworks and use methods. The following table describes the parameter types and sources that are supported by business parameter extraction rules.
Parameter type | Parameter source | Supported framework | Remarks |
HTTP server request |
|
| - |
Body | Spring MVC 4.2.0+ | The class name must be annotated with the @Controller annotation and the method must be annotated with the @RequestBody annotation. | |
HTTP server response |
|
| - |
Body | Spring MVC 4.2.0+ | The class name must be annotated with the @Controller annotation and the method must be annotated with the @ResponseBody annotation. | |
Exception information | Message | - | The class must inherit java.lang.Exception. |
Create a rule
After you create and enable a business parameter extraction rule, the rule is sent to the ARMS agent in real time and takes effect 1 to 2 minutes later. You do not need to restart the application.
Extracted business parameters are recorded to the attributes of the spans. You can query the parameters on the Trace Explorer page.
By default, an attribute name is prefixed with
biz.
and must be unique.Whether span data is reported is affected by the sampling policy. You can modify the sampling policy to ensure that important data is correctly reported. For more information, see Select a trace sampling mode for the ARMS agent earlier than V3.2.8.
If the business parameters that you want to extract are not found in the trace, check whether the configurations of the business parameter extraction rule are valid.
In the Business Parameter Extraction Rules section, click New Rule. On the page that appears, configure the parameters and click OK.
Rule Name: the name of the rule.
Attribute name: the name of the attribute that corresponds to the value extracted by the rule in the span. By default, the value consists of the prefix biz. and multiple words. Each word can contain only letters, digits, hyphens (-), and underscores (_) and must be separated by a period (.). Up to 10 words are allowed in an attribute name.
Parameter extraction type: the type of the parameters that you want to extract.
Effective Interface: the HTTP interfaces to which the rule applies. The ARMS agent extracts the parameters only from the matched interfaces. This parameter is valid only if the Parameter extraction type parameter is set to HTTP server request or HTTP server response.
Exception Class Name: the class names related to exceptions. The ARMS agent extracts the parameters only from the matched exceptions. This parameter is valid only if the Parameter extraction type parameter is set to Exception information.
Text encoding type: the encoding format of the parameters that you want to extract.
Parameter Extraction Rules: the sources that contain the parameters that you want to extract and the method that you want to use to extract the parameters. You can specify multiple parameter sources and parameter extraction steps. If parameters can be extracted from multiple sources, the parameters are extracted based on the order of the parameter extraction steps. For more information, see the Example of business parameter extraction rules section of this topic.
Parameter Source: the source from which you want to extract parameters. If you select Header, Cookie, or Parameter from the drop-down list, you must enter the key for initial extraction. If you select Body or Message from the drop-down list, parameters are extracted from the entire body or message.
Add parameter processing steps: the steps for extracting the parameters. This configuration is used to parse the parameter values that you want to obtain from one or more sources. You can specify multiple parameter extraction steps. The parsing result of a step is the input of the next step. If you do not specify a parameter extraction step, the parameter values that are obtained are the JSON texts of the sources. For more information, see the Best practices for parameter extraction steps section of this topic.
The following parameter extraction methods are supported:
Ognl: The input parameters must be objects. Object-Graph Navigation Language (OGNL) expressions that use dot notation are supported. Example:
#this.data.getCode()
.JsonPath: The input parameters must be JSON strings. JsonPath expressions that use dot notation are supported. Example:
$.data.code
.Regex: The input parameters must be strings. Regular expressions that are based on named capturing groups are supported. The substring to be extracted corresponds to a capturing group named res. Example:
.*from:(?<res>[a-z]+).*
.
Enabling Status: specifies whether to enable the rule.
Verify a rule
After you configure a business parameter extraction rule for an application, the rule takes effect without the need to restart the application. You can go to the Trace Explorer page to view the related trace. If a custom attribute is added to the span of the corresponding interface, the business parameter extraction rule takes effect.
Find the name of the attribute that corresponds to the rule that you created.
On the Trace Explorer page, add
attributes.$attributesName
as a filter condition to query the spans.Click a trace to view the custom attributes of the span.
Manage rules
To enable or disable a rule, turn on or off the Enabling Status switch for the rule.
To modify or delete a rule, click Edit or Delete in the Actions column of the rule.
To delete multiple rules at a time, select the rules and click Batch Delete below the rule list.
To synchronize multiple rules to other applications at a time, select the rules and click Bulk Copy to Other Applications below the rule list. In the dialog box that appears, specify whether to synchronize the rules to all other applications or a specific application.
NoteWait for 1 to 2 minutes for the operation to take effect.
Only the business parameter extraction rules are synchronized. The relevant errors are not synchronized.
The name of the attribute that corresponds to a business parameter extraction rule must be unique. If an attribute that has the same name already exists in the destination application, the rule is not synchronized to the application.
Example of business parameter extraction rules
OGNL
OGNL is an expression language for getting and setting properties of Java objects. You can extract Java objects annotated with the @ResponseBody or @RequestBody annotation. The extraction result is converted into a string. If a Java object is extracted, a JSON string is returned for further extraction. Example:
@RestController
@RequestMapping("/components/api/v1/mall")
public class MallController {
@RequestMapping("/product")
@ResponseBody
public ResponseBody product(@RequestBody RequestBody req) {
// Business code
}
static class RequestBody {
String requestId;
Map<String, String> queryParam;
public String getQueryJsonStr() {
return JSON.toJsonString(queryParam);
}
}
static class ResponseBody {
int code;
boolean success;
String message;
}
}
Extract the requestId field from the RequestBody, as shown in the following figure.
Extract the code field from the RequestBody, as shown in the following figure.
OGNL allows you to use the get methods in an object to obtain fields. Extract the execution result of the getQueryJsonStr() method in the RequestBody, as shown in the following figure.
Make sure that the getQueryJsonStr() method exists in the class in advance.
JsonPath
JsonPath expressions allows you to extract a JSON string and obtain properties from the JSON string. Example:
{
"code": 200,
"message": "Query success.",
"success": true,
"data": {
"name": "John",
"age": 21
}
}
Extract the data.age field from the preceding JSON data, as shown in the following figure.
Regex
A regular expression (regex) is a text string used to match character combinations in strings. You can take capturing groups named "res" as the extraction results. Example:
By default, a regular expression starts matching from the start of a string. To specify random matching, add .*
before and after the expression.
https://test.aliyun.com/v2/workitem#requestId=0c978f115b6f7&cityCode=34&env=online
Extract the cityCode field from the preceding URL, as shown in the following figure.
Sample class
The following class contains the Body objects of an application:
class DemoResponse {
int code = 200;
boolean success = true;
String message = "text content";
String extraInfo = "{\"id\": 15, \"cityInfo\": \"from:hangzhou,to:beijing\"}";
public String getExtraInfo() {
return this.extraInfo;
}
}
Extract the city name indicated by "from" in the cityInfo sub-field of the extraInfo field, as shown in the following figure.
The ARMS agent performs the following steps to extract the parameters:
Obtain the DemoResponse object from the response.
Execute the
#this.getExtraInfo()
statement to obtain the extraInfo field.Execute the
$.cityInfo
statement to parse the value of the extraInfo field as a JSON string and obtain the cityInfo sub-field.Execute the
^from:(?<res>[a-z]+).*
statement to parse the value of the cityInfo sub-field as a string and match it to the capturing group named "res", which is thehangzhou
substring.Write
hangzhou
as the extraction result to the attribute of the span.
Parameter extraction steps
How it works
You can specify parameter extraction steps to further retrieve and search for the required information from the source. These steps can be regarded as a stream mapping rule in which the output of the preceding step is used as the input of the next step.
Each parameter extraction method imposes unique requirements on the input data type. If the input data type does not meet the requirements, the subsequent process is terminated and the current result is recorded as the final value.
Parameter extraction method | Input data type | Output data type |
OGNL | Java object | String or JSON string after serialization |
JsonPath | JSON string | String |
Regex | String | String |
Performance overheads
The execution of parameter extraction steps incurs the highest performance overheads in the business parameter extraction process because serialization or deserialization, Java reflection, and regular expressions are involved in these steps. We recommend that you do not specify a large number of steps for interfaces that have high requirements on response time (RT) and performance. If you want to extract parameters for interfaces that have high requirements on RT and performance, you can modify your business code.
For example, if security compliance requirements are met, you can write parameters to the headers in your business code.
For information about how to manually write parameters to the attribute of a span by using OpenTelemetry SDK for Java, see Use OpenTelemetry SDK for Java to add custom instrumentation code for an application.
Valid statements for parameter extraction
To ensure the security of the extraction logic, ARMS imposes stricter restrictions on statements for extracting parameters than open source OGNL, JsonPath, and regular expressions.
Parameter extraction method | Syntax reference | Additional syntax limit | Valid example |
OGNL | You can extract parameters only from fields and call methods that use dot notation. If you extract parameters from a call method, the call method must start with get. The access depth for parsing is 10. | #this.extraInfo.getPid() | |
JsonPath | You can extract only fields that use dot notation. The access depth for parsing is 10. | $.cityInfo | |
Regex | You must include one and only one capturing group named res to specify the extraction result. | ^from:(?<res>[a-z]+).* |
Matching rules of custom error codes
If an extracted parameter triggers a matching rule of custom error codes, the span which contains the parameter is considered failed. If an error occurs during service access, the error is collected with the arms_$callType_requests_error_count
metric. In this case, you can configure alerting for the matching rule.
The sampling policy does not affect the data collection of custom error codes and failed spans that are not sampled.
For information about service access types and available dimensions, see the Application monitoring metrics.
Configure a matching rule of custom error codes
In the Customizing Error Settings section, turn on the Custom error code switch to enable the data collection of custom error codes.
Click Add matching rules to add a rule.
Select a business parameter extraction rule and configure the filter condition.
Click Save. The rule takes effect within 1 to 2 minutes without the need to restart the application.
Verify a rule
After you configure a rule, the rule takes effect without the need to restart the application. You can go to the Trace Explorer page to check whether failed spans that meet the conditions specified by the matching rule exist.
Confirm the name and condition of the attribute that is used to match the rule.
On the Trace Explorer page, select all failed spans as the query condition to view all failed spans.
Click a trace and check whether the attribute of the trace matches the configured rule.
In the following example, the value of the biz.resp.body attribute is 670, which is greater than 499, the condition specified by the error matching rule.
Go to the Overview page to view if the number of errors is correctly added to the error dashboard.
Performance overheads
The business parameter extraction feature brings extra overheads to your application. Most of the extra overheads are incurred from serialization or deserialization and Java reflection during parameter extraction. In this section, a demo is built to verify the overheads of the business parameter extraction feature. Preparations:
Pod specifications: 1 core and 2 GB memory.
Five HTTP interfaces exist on the server. The stress tester calls each interface at 2,000 queries per second (QPS) to generate spans. Each interface corresponds to a source from which parameters are extracted.
Test configurations: 240 custom parameters are extracted and 20 regular expressions, 40 JsonPath expressions, and 40 OGNL expressions are processed in every 100 calls.
The following table describes the overheads incurred before and after a business parameter extraction rule is enabled.
Item | Feature disabled (baseline) | Feature enabled | Overhead increase |
CPU | 0.230 c | 0.257 c | +0.027 c |
Memory (20 minutes after startup) | 575 MB | 693 MB | +118 MB |
RT | 101 ms | 101 ms | +0 ms |
FAQ
What do I do if parameter extraction fails?
If you extract parameters from Body objects, check whether Spring MVC is used in your application, whether the @Controller is added to the class of the method, and whether the @RequestBody and @ResponseBody annotations are added to the method and parameters.
If you extract parameters from response Cookie, check whether you are using Tomcat v7.0.4-9.x or Undertow v1.4.0.Final+. If not, we recommend that you use request Cookie instead.
What is the effective scope of exception extraction?
The ARMS agent for Java blocks only custom exceptions that are thrown outside spans. If you want to extract exceptions from the key call methods inside spans and mark the exceptions as errors, you can instrument the call method. For more information, see Add custom methods for monitoring.
How do I configure business parameter extraction rules for common annotations in Spring MVC applications?
The following table shows the mappings between Spring MVC annotations that are supported by business parameter extraction rules and the rule configurations.
Annotation | Parameter type | Parameter source |
@RequestParam | HTTP server request | Parameter |
@RequestHeader | HTTP server request | Header |
@CookieValue | HTTP server request | Cookie |
@RequestBody | HTTP server request | Body |
@ResponseBody | HTTP server response | Body |
How do I extract business parameters that are not supported?
You can use OpenTelemetry SDKs to instrument the application and write the business parameters that you want to extract as attributes to the spans. For more information, see Use OpenTelemetry SDK for Java to add custom instrumentation code to traces.
Is extraction from Body objects decorated by RequestBodyAdvice and ResponseBodyAdvice supported?
Yes, it is. The ARMS agent extracts parameters from Body objects after the user-defined BodyAdvice and before the built-in Spring BodyAdvice.