Application Real-Time Monitoring Service:Custom configuration

Procedure

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

2. At the top of the Application List page, select a region, and then click the name of the application.

   Note

   The icons in the Language column indicate the following:

   : Java application integrated with application monitoring.

   : Go application integrated with application monitoring.

   : Python application integrated with application monitoring.

   -: Application integrated with Managed Service for OpenTelemetry.

3. In the left-side navigation pane, click Application Settings, and then click the Custom Configurations tab.

4. Set the custom configuration parameters, and then click Save at the bottom of the page.

Sampling rate settings

Agent switches and log level

In the Agent Switch Settings section, you can enable or disable the main agent switch and individual plug-in switches, and configure the log level.

Threshold settings

In the Threshold Settings section, you can configure the threshold for slow SQL queries.

The slow SQL query threshold is measured in milliseconds (ms) and defaults to 500 ms. An SQL query is considered a slow SQL query if its execution time exceeds this threshold.

Message queue configuration

In the Message Queue Configurations section, you can configure message-related parameters.

The Custom RabbitMQ Consumer and Custom Kafka Consumption Method settings require agent v4.x or later and take effect after you restart the application. The Automatic Context Propagation for Kafka Messages setting is supported only for Kafka v0.11.0 or later.

• Custom RabbitMQ consumer: By setting the class name of a custom consumer or a class containing an anonymous inner consumer, you can view the call chain of that consumer. Separate multiple consumer names with commas (,).

• Custom Kafka consumption method: By defining a custom consumption method, you can view call chains and metrics when consuming messages by using the native Kafka SDK.

• Automatically propagate context for Kafka messages: When sending a message, the agent automatically adds multiple headers to the Kafka message to correlate the producing call chain and the consuming call chain.

Agent collection settings

The Collect Traces setting requires agent v4.2.0 or later. The Agent Maximum QPS Threshold defaults to 10,000 and requires agent v4.1.10 or later. The default Log Level is WARN.

• Collect traces: Controls whether trace data is reported. This is enabled by default. If disabled, trace data is no longer reported.

• Throttling threshold: The maximum number of requests the agent can process per second. The default is 100. Traces for requests exceeding this threshold are not collected.

  Note

  The trace sampling rate has a higher priority than the throttling threshold.

• Agent maximum QPS threshold: The number of requests the agent can handle per second. For performance reasons, the effective threshold may deviate from the configured threshold by up to 5%. Requests exceeding this threshold will not be monitored, meaning no spans or metrics will be generated, and the log-to-trace ID association will not work.

• Collect data for internal calls without entry points: Internal calls without an entry point typically refer to span and metric data generated by scheduled tasks that send HTTP requests, interact with databases, send messages, or make RPC calls initiated through the JDK thread pool.

• Log level: Adjusts the logging level of the agent for troubleshooting.

API call settings

• Interface response time threshold: When the response time of an interface exceeds this threshold, the system marks the interface as a slow call.

• Exception filtering: ARMS does not display the exceptions that you enter here in the charts on the application details and exception analysis pages.

• Inherit exception filter for parent classes: If you enable this option and a collected exception is a subclass of an exception class configured in the exception filter allowlist, ARMS also filters it.

  As a result, exceptions that meet the filtering criteria do not appear in the ARMS console.

• Error count filtering: By default, ARMS counts status codes greater than 400 as errors. You can customize which HTTP status codes greater than 400 are not counted as errors.

• Invalid interface call filtering: Enter interfaces that you do not need to monitor. The agent will not report observability data for these interfaces, hiding them from the interface call page.

• Record upstream interface name in metrics and Record upstream application name in metrics:

  Controls whether interface metrics record the upstream application and interface that call the current interface. This primarily affects whether upstream and downstream data is available for service dependencies. When an application has many upstream callers, recording this information may significantly increase the volume of reported metrics and associated costs.

• Record original status code in metrics: Records the original response code in HTTP interface-related metrics.

Pool monitoring settings

The Thread Pool and Connection Pool Monitoring setting requires agent v2.7.3.5 or later and takes effect after the application is restarted. The Thread Name Pattern Extraction Policy for Thread Pools setting requires agent v4.1.10 or later.

• Thread pool and connection pool monitoring: Supports thread pool metric monitoring for frameworks such as Tomcat, Dubbo, and High-speed Service Framework (HSF). Requires an upgrade to the latest agent version.

• Thread name pattern extraction policy for thread pools: By default, this feature replaces all numeric characters in the thread name of any running thread in a thread pool with *. You can also adjust this to replace only the trailing characters of the thread name with *. If your application starts multiple Dubbo providers that listen on different ports, the default policy may aggregate their thread pools into one because the extracted thread name templates are identical. In this case, adjust the policy to distinguish them as separate thread pools.

• Filter by thread pool usage scenario and Filter by thread pool name pattern: Filters out monitoring metrics for certain thread pools based on their usage scenario and thread name pattern.

  Note

  This configuration takes effect only for Java agent v4.2.0 and later.

  • Thread pool usage scenario: The context in which the thread is used. Supported scenarios include Tomcat, Vert.x, Undertow, Dubbo, Jetty, AliyunJavaAgent, and default. AliyunJavaAgent represents the thread pool that the agent uses, and default represents other unclassified thread pools.

  • Thread pool name pattern: The pattern derived from processing the thread names in the pool. For example, http-nio-*-exec-* is typically obtained by replacing the numeric parts of the actual thread name with *.

Span attribute settings

Both of the following settings require agent v4.x or later. Record OpenTelemetry Specification Attributes is disabled by default. The Application Tag Association for Spans setting defaults to All Spans.

• Record OpenTelemetry specification attributes: The OpenTelemetry Specification defines the attributes to include in spans generated by each plug-in type. To reduce data volume, the ARMS agent does not record these attributes by default. You can enable this setting based on your needs. For information about the attributes that are added for each framework after this setting is enabled, see the OpenTelemetry Specification.

• Application tag association for spans: Controls which spans include the tags that you have bound to the application on the application list page in the console. By default, all spans include application tags. To manage data usage, you can choose to attach application tags only to entry spans. Entry spans typically include HTTP Server, RPC Server, MQ message consumption, and scheduled tasks.

Advanced settings

• Maximum method stack length: The default is 128, and the maximum is 400.

• Stack depth for exception differentiation: This setting specifies the stack depth for differentiating exceptions of the same type. It is typically set to the depth of the first differing call.

• Maximum SQL length: The default is 1,024 characters, with a minimum of 256 and a maximum of 4,096.

• Collect SQL bind values: Captures variable values bound to PreparedStatement parameters. This takes effect without an application restart and currently supports only scenarios where you set SQL variable values in a PreparedStatement.

• Original SQL Statements: Only truncates SQL statements without extra processing.

• Record MySQL query return value size : When enabled, ARMS records the size of MySQL query return values.

• New trace storage format: Uses a new storage format that supports time-based sorting of traces (enabled by default).

• Trace compression: Simplifies traces by collapsing repeated calls, such as those within a for-loop. This takes effect without an application restart.

• Maximum length of request parameters: The default is 512 characters, and the maximum supported length is 2,048 characters.

• Quantile statistics: Enables the quantile statistics feature.

  Note

  A quantile is a point that divides the range of a probability distribution of a random variable into continuous intervals with equal probabilities. Common quantiles include the median (2-quantile), quartiles, and percentiles.

• Automatic async propagation: Automatically propagates the asynchronous context when an async task is submitted through a thread pool.

• Packages to scan for async propagation: Add packages to scan to enable async task monitoring. When new objects that implement the Runnable, Callable, or Supplier interfaces are created in a scanned package, the agent automatically captures the current thread's trace context. When the async thread executes, it uses this context to complete the trace linkage. Requires agent v2.7.1.3 or later.

• Return trace ID in response: For HTTP requests only, this setting adds the eagleeye-traceid field to the response header.

Thread settings

In the Thread settings section, you can enable or disable the main switch for thread analysis.

Starting from agent v4.x, due to implementation changes, this feature is controlled by the CPU hotspot switch in continuous profiling.

Log association configuration

URL convergence rules

In the URL Convergence Settings section, you can enable or disable the URL convergence feature and configure its threshold and rules. URL convergence groups similar URLs to display them as a single item. For example, a series of URLs that start with /service/demo/ can be grouped. The convergence threshold is the minimum number of URLs required to trigger convergence. For example, if the threshold is 100, the system converges URLs that match the rule's regex only when their count reaches 100.

Arthas monitoring

In the Arthas Monitoring section, you can enable or disable the Arthas diagnostics feature and specify the IP addresses where it is enabled. For more information, see Arthas diagnostics.

This feature requires agent v2.7.1.3 or later. You can specify the IP addresses where Arthas diagnostics is enabled. If you specify IP addresses, the feature is enabled only for those IP addresses. If you do not specify any IP addresses, the feature is enabled for all IP addresses.

Continuous profiling

In the Continuous Profiling section, you can enable or disable the main switch, as well as switches for CPU hotspot, memory hotspot, and code hotspot features. You can also specify the IP addresses or network segments where these features take effect. For more information, see Integrate the continuous profiling feature. The IP allowlist supports multiple instance IP addresses separated by commas (,). The network segment allowlist supports the CIDR format (for example, 10.0.0.0/8) but does not support multiple segments.

Trace propagation protocol settings

In the Trace Propagation Protocol Settings section, you can select the trace propagation protocol to use based on your needs. For information about the protocols that ARMS supports, see Trace context propagation protocols supported by ARMS.

By default, no Propagation protocol is set, and the Propagation mode is Priority. This feature requires agent v4.1.x or later.

By default, when a call arrives, the ARMS agent checks for request headers in the following order: EagleEye, OpenTelemetry, SkyWalking, Jaeger, and Zipkin. If the agent detects a header for a specific protocol, it restores the trace context based on that protocol and injects corresponding headers for subsequent downstream calls. If no protocol headers are detected, the agent uses the EagleEye protocol by default.

You can select any protocol on this page as the priority protocol. After you select and save the setting, ARMS will first check for the request headers of the specified protocol. For example, if you set the Propagation protocol to Jaeger and the Propagation mode to Priority, the ARMS agent will change the detection order to Jaeger, EagleEye, OpenTelemetry, SkyWalking, and then Zipkin.

You can also force the use of a specific protocol. For example, if you set the Propagation protocol to Jaeger and the Propagation mode to Force, the ARMS agent will only check for Jaeger protocol headers. If no Jaeger protocol headers are found, the agent does not check for other protocols and will instead generate a new trace context.

Data redaction

In the Data Redaction section, you can define redaction rules. The agent then redacts content from JVM system parameters, Kubernetes YAML, method input parameters, and Arthas environment and system variables during collection. In the redaction rules, elements are separated by commas (,). Each element represents a case-insensitive regex. For example, the rule password is equivalent to the regex .*password.*. The default redaction rules include password, secret, key, token, and credentials.

When an agent collects data, it filters data keys based on the corresponding expressions. If a key meets the condition, it is considered to contain sensitive data and is desensitized. For example, if a desensitization rule contains licenseKey, information with the key -Darms.licenseKey is desensitized. When the desensitization rule is licenseKey, it desensitizes information with the key -Darms.licenseKey.

Copying configurations

If you need to apply the same configurations to other applications, you can copy them.

Copying a single configuration to other applications

1. In the corresponding configuration section, click Batch copy to other applications.

2. In the dialog box that appears, select the applications to which you want to apply the configuration, and then click OK.

   The dialog box provides two modes: Copy to all other applications and Select monitored applications. The changes take 1 to 2 minutes to take effect after a successful copy.

Copying all configurations to other applications

1. At the bottom of the page, click Batch copy to other applications.

2. In the dialog box that appears, select the applications to which you want to apply the configurations, and then click OK.

   The dialog box provides two modes: Copy to all other applications and Select monitored applications. The changes take 1 to 2 minutes to take effect after a successful copy.

Global default configuration

You can save the current configurations as the global default. New applications that you create will use these configurations by default.

1. At the bottom of the page, click Save Current Application Settings as Global Default Configurations.

2. In the dialog box that appears, click Confirm.