All Products
Search
Document Center

Application Real-Time Monitoring Service:Extract business parameters

Last Updated:Mar 11, 2026

When diagnosing production issues, standard trace data often lacks the business context needed to pinpoint root causes -- you cannot filter traces by order ID, user ID, or transaction code. Application Real-Time Monitoring Service (ARMS) solves this by extracting specific parameters from HTTP requests, responses, and exceptions at the span level, without modifying application code. Extracted parameters become span attributes that you can use to filter traces, detect business-logic errors, and trigger alerts.

Use cases

After you configure extraction rules, the ARMS agent captures parameter values and writes them as span attributes. These attributes enable the following capabilities:

  • Filter traces by business context -- Locate all requests for a specific order ID, user ID, or transaction code on the Trace Explorer page.

  • Detect business-logic errors -- Mark spans as failed when an extracted parameter value matches a custom error code rule.

  • Set up alerting -- Trigger alerts when error counts based on extracted parameters exceed thresholds.

Prerequisites

Note

Business parameter extraction applies only to Java applications.

Before you begin, make sure that:

  • An ARMS agent V4.1.0 or later is installed. For more information, see Application Monitoring overview. The feature does not take effect on agents earlier than V4.1.0, even if rules are configured.

    • V4.2.0 or later: Multiple API match rules and parameter extraction rules can be added to a single business parameter extraction rule.

    • V4.1.0 to V4.2.0: Only the first match rule takes effect per rule.

image

Supported parameter types and sources

The ARMS agent dynamically detects rule changes and extracts parameters based on all enabled rules. The following table lists the supported parameter types, sources, and framework requirements.

Parameter typeParameter sourceSupported frameworkRemarks
HTTP server requestHeader, Cookie, ParameterTomcat 7.0.4+, Jetty 8.0.0+, Undertow 1.4.0.Final+The ARMS agent calls the javax.servlet.ServletRequest.getParameters() method. For ContentType: application/x-www-form-urlencoded, this triggers premature InputStream reading in the request body. Because InputStream in ServletRequest is single-read, subsequent access by business code fails. If your code requires InputStream access, exclude the interface to prevent failures.
HTTP server requestBodySpring MVC 4.2.0+The class must be annotated with @Controller and the method must be annotated with @RequestBody.
HTTP server responseHeader, CookieTomcat 7.0.4+, Jetty 8.0.0+, Undertow 1.4.0.Final+-
HTTP server responseBodySpring MVC 4.2.0+The class must be annotated with @Controller and the method must be annotated with @ResponseBody.
HTTP client requestHeader, ParameterApache HttpClient 2.0+, OkHTTP 2.2+-
HTTP client responseHeaderApache HttpClient 2.0+, OkHTTP 2.2+-
Exception informationMessage-The class must inherit java.lang.Exception.

Open the extraction rules page

  1. Log on to the ARMS console. In the left-side navigation pane, choose Application Monitoring > Application List.

  2. Select a region in the top navigation bar and click the application.

    Note

    Icons in the Language column indicate the application's programming language: - Java图标: Java - image: Go - image: Python - - (Hyphen): an application monitored in Managed Service for OpenTelemetry

  3. In the top navigation bar, choose Configuration > Business Parameter Extraction Rules.

  4. In the Business Parameter Extraction Rules section, create, view, or modify extraction rules for the application.

image
  1. In the Customizing Error Settings section, configure matching rules of custom error codes to filter extracted parameter values.

image

Create an extraction rule

Important
  • Rules are delivered to the agent in real time upon creation and enabling. The first rule requires an application restart to take effect. Subsequent rules take effect in 1 to 2 minutes without a restart.

  • Extracted parameters are recorded as span attributes. Query them on the Trace Explorer page.

  • Attribute names are prefixed with biz. by default and must be unique.

  • Whether span data is reported depends on the sampling policy. To make sure important data is reported, adjust the sampling policy. For more information, see Select a trace sampling mode for the ARMS agent earlier than V3.2.8.

  • If extracted parameters do not appear in the trace, verify that the rule configuration is correct.

In the Business Parameter Extraction Rules section, click New Rule. Configure the following parameters and click OK.

image
ParameterDescription
Rule NameThe name of the rule.
Attribute nameThe span attribute key for the extracted value. Format: biz. prefix followed by dot-separated words. Each word can contain letters, digits, hyphens (-), and underscores (_). Maximum: 10 words.
Parameter extraction typeThe type of parameter to extract: HTTP server request, HTTP server response, HTTP client request, HTTP client response, or Exception information.
Effective InterfaceThe HTTP interfaces to which the rule applies. The ARMS agent extracts parameters only from matched interfaces. Available only when Parameter extraction type is set to HTTP server request or HTTP server response.
Exception Class NameThe exception class names to match. The ARMS agent extracts parameters only from matched exceptions. Available only when Parameter extraction type is set to Exception information.
Text encoding typeThe encoding format of the parameters to extract.
Enabling StatusWhether to enable the rule.

Parameter extraction rules

Specify the sources that contain the parameters to extract and the extraction method. Multiple parameter sources and processing steps are supported. If parameters can be extracted from multiple sources, they are extracted in the order the steps are defined. For more information, see Extraction rule examples.

  • Parameter Source: The source from which to extract parameters. If you select Header, Cookie, or Parameter, enter the key for initial extraction. If you select Body or Message, parameters are extracted from the entire body or message.

  • Add parameter processing steps: Define steps to parse the parameter values from one or more sources. Each step's output becomes the next step's input. If no step is specified, the raw JSON text of the source is used. For more information, see Parameter extraction steps. The following extraction methods are supported:

    MethodDescriptionExample
    OGNLInput must be a Java object. Supports OGNL expressions with dot notation.#this.data.getCode()
    JsonPathInput must be a JSON string. Supports JsonPath expressions with dot notation.$.data.code
    RegexInput must be a string. Uses named capturing groups. The substring to extract must correspond to a capturing group named res..*from:(?<res>[a-z]+).*

Verify an extraction rule

After a rule takes effect, check the Trace Explorer page for the related trace. If a custom attribute appears on the span of the corresponding interface, the rule is working.

  1. Find the attribute name that corresponds to the rule.

    image

  2. On the Trace Explorer page, add attributes.$attributesName as a filter condition to query spans.

    image

  3. Click a trace to view the custom attributes of the span.

    image

Manage extraction rules

  • To enable or disable a rule, toggle the Enabling Status switch.

  • To modify or delete a rule, click Edit or Delete in the Actions column.

  • To delete multiple rules, select them and click Batch Delete below the list.

  • To copy rules to other applications, select them and click Bulk Copy to Other Applications. In the dialog box, specify whether to copy the rules to all applications or a specific one.

Note
  • Wait 1 to 2 minutes for changes to take effect.

  • Only extraction rules are copied. Custom error settings are not included.

  • Attribute names must be unique. If an attribute with the same name exists in the target application, the rule is not copied.

image

Configure custom error code matching

If an extracted parameter value matches a custom error code rule, the span is marked as failed. Failed spans increment the arms_$callType_requests_error_count metric, which you can use for alerting.

Note
  • The sampling policy does not affect data collection for custom error codes. Failed spans that are not sampled are still counted.

  • For service access types and available dimensions, see Application monitoring metrics.

Create a custom error code rule

  1. In the Customizing Error Settings section, turn on the Custom error code switch.

  2. Click Add matching rules.

  3. Select an extraction rule and configure the filter condition.

    image

  4. Click Save. The rule takes effect within 1 to 2 minutes without an application restart.

Verify a custom error code rule

After you configure a rule, check the Trace Explorer page for failed spans that match the rule conditions.

  1. Confirm the attribute name and condition used by the rule.

    image

  2. On the Trace Explorer page, filter for failed spans.

    image

  3. Click a trace and check whether the attribute value matches the rule condition. In the following example, the biz.resp.body attribute value is 670, which is greater than 499 (the threshold specified by the error matching rule).

    image

  4. On the Overview page, verify that the error count is correctly reflected in the error dashboard.

    image

Extraction rule examples

The following examples chain OGNL, JsonPath, and Regex methods. Each step's output feeds into the next step as input.

OGNL

Object-Graph Navigation Language (OGNL) reads and sets properties of Java objects. Use it to extract fields from objects annotated with @ResponseBody or @RequestBody. The result is converted to a string. If the extracted value is a Java object, it is serialized to a JSON string for further extraction.

@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 RequestBody:

image

Extract the code field from ResponseBody:

image

Call a getter method to extract the result of getQueryJsonStr():

Important

Make sure the getQueryJsonStr() method exists in the class.

image

JsonPath

JsonPath expressions extract properties from a JSON string.

{
  "code": 200,
  "message": "Query success.",
  "success": true,
  "data": {
    "name": "John",
    "age": 21
  }
}

Extract data.age from the JSON data:

image

Regex

Regular expressions match character combinations in strings. Use a capturing group named res to specify the extraction result.

Note

By default, a regex starts matching from the beginning of a string. To match at any position, add .* before and after the expression.

https://test.aliyun.com/v2/workitem#requestId=0c978f115b6f7&cityCode=34&env=online

Extract the cityCode value from the URL:

image

Multi-step extraction

This example chains OGNL, JsonPath, and Regex to extract a nested value from a response body.

The following class contains the response body object:

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;
    }
}

Goal: Extract the city name indicated by "from" in the cityInfo sub-field of extraInfo.

image

The ARMS agent processes the extraction in these steps:

  1. Get the DemoResponse object from the response body.

  2. Run #this.getExtraInfo() (OGNL) to get the extraInfo field.

  3. Run $.cityInfo (JsonPath) to parse extraInfo as JSON and get the cityInfo sub-field.

  4. Run ^from:(?<res>[a-z]+).* (Regex) to match the capturing group named res, which returns hangzhou.

  5. Write hangzhou as the attribute value on the span.

Parameter extraction steps

How steps work

Extraction steps retrieve and parse values from source data. Steps form a pipeline: each step's output becomes the next step's input.

image

Each method requires a specific input type. If the input does not match, the pipeline stops and records the current result as the final value.

Extraction methodInput data typeOutput data type
OGNLJava objectString or JSON string after serialization
JsonPathJSON stringString
RegexStringString

Syntax restrictions

ARMS imposes stricter syntax restrictions than open-source OGNL, JsonPath, and regex to maintain security.

MethodSyntax referenceRestrictionsValid example
OGNLApache Commons OGNLDot notation only. Call methods must start with get. Maximum access depth: 10.#this.extraInfo.getPid()
JsonPathJsonPathDot notation only. Maximum access depth: 10.$.cityInfo
RegexJava RegexMust include exactly one capturing group named res.^from:(?<res>[a-z]+).*

Performance considerations

Extraction steps involve serialization/deserialization, Java reflection, and regex processing -- the most resource-intensive operations in the extraction pipeline. For latency-sensitive interfaces, consider these alternatives:

Performance overhead

Business parameter extraction adds CPU and memory overhead due to serialization/deserialization and Java reflection. The following benchmark quantifies the impact.

Test environment:

  • Pod specifications: 1 core, 2 GB memory

  • 5 HTTP interfaces at 2,000 QPS each

  • 240 custom parameters extracted per 100 calls: 20 regex, 40 JsonPath, and 40 OGNL expressions

image
ItemFeature disabled (baseline)Feature enabledIncrease
CPU0.230 c0.257 c+0.027 c
Memory (20 minutes after startup)575 MB693 MB+118 MB
Response time101 ms101 ms+0 ms
Important

Extraction involves Java reflection and serialization/deserialization, which increase CPU and memory usage. For interfaces with strict latency requirements, write parameters to headers or use the OpenTelemetry SDK instead.

FAQ

What do I do if parameter extraction fails?

The cause depends on the parameter source:

  • Body: Make sure Spring MVC is used, the class has the @Controller annotation, and the method has the @RequestBody or @ResponseBody annotation.

  • Response Cookie: Make sure you are running Tomcat v7.0.4-9.x or Undertow v1.4.0.Final+. Otherwise, use request Cookie instead.

What is the scope of exception extraction?

The ARMS agent for Java captures only custom exceptions thrown outside spans. To extract exceptions from key call methods inside spans and mark them as errors, instrument the call method. For more information, see Add custom methods for monitoring.

How do I map Spring MVC annotations to extraction rules?

AnnotationParameter typeParameter source
@RequestParamHTTP server requestParameter
@RequestHeaderHTTP server requestHeader
@CookieValueHTTP server requestCookie
@RequestBodyHTTP server requestBody
@ResponseBodyHTTP server responseBody

How do I extract unsupported parameter types?

Use OpenTelemetry SDKs to instrument your application and write the parameters as span attributes directly. For more information, see Use OpenTelemetry SDK for Java to add custom instrumentation code to traces.

Does extraction support Body objects with RequestBodyAdvice and ResponseBodyAdvice?

Yes. The ARMS agent extracts parameters after user-defined BodyAdvice runs, but before Spring's built-in BodyAdvice.