Application Real-Time Monitoring Service:Customize settings for a Java application

Auto Fill TraceId and SpanId

Automatically injects Trace ID and Span ID into logs. No changes to the log configuration file are required.

After enabling this switch, the supported frameworks automatically print Trace ID and Span ID without any modifications to the log configuration file.

Support adding traceId in log MDC

By default, agents of V4.x do not support retrieving Trace ID through org.slf4j.MDC.get("EagleEye-TraceID"). Enable this switch if your application relies on this method.

Slow call threshold

HTTP status code whitelist

By default, HTTP status codes >= 400 are classified as errors. To prevent a specific status code from being counted as an error, add it to the whitelist.

This setting applies only to the HTTP frameworks supported by Application Monitoring.

Invalid interface call filtering

Hide specific interfaces from the Provided Services tab by entering their names. The agent stops reporting observability data for these interfaces.

Record upstream interface name in interface call metric

Record upstream application name in interface call metric

These two settings control whether the upstream application and upstream interface that call this interface are recorded in the interface call metrics. This primarily affects whether data exists for upstream and downstream traces on the Provided Services tab.

When an application has many upstream callers, recording this information can significantly increase reported metric volume and costs.

After disabling these settings, the corresponding upstream data drops to 0.

Record original status code in metrics

Records the original HTTP response code in interface-related metrics, as shown below.

Record HTTP method name for interface

When enabled, the interface name displayed on the Interface Calls page includes the HTTP request method. For example, /api/v1/use/{userId} becomes GET /api/v1/use/{userId}.

Slow SQL threshold

Set the threshold (in milliseconds) for identifying slow SQL statements.

Maximum length of collected SQL statements

Set the maximum character length for SQL statements collected by the agent.

Display variable binding values in SQL

Captures variable values bound to PreparedStatement parameters and stores them as span attributes with the key db.bindvalue. The value is a comma-separated list of variable values. This setting takes effect without an application restart.

Record MySQL query return value size

Records the size of the return value for MySQL queries.

Display constant values in SQL

Displays constant values in SQL statements without additional processing. This setting takes effect without an application restart.

Preferred protocol

Select a protocol to set its priority in the detection order. For example, with the following configuration, the agent checks for protocol context in this order: Jaeger, EagleEye, W3C, SkyWalking, Zipkin.

Enforced protocol

Enforce a specific protocol so the agent only checks for that protocol's headers. If those headers are absent, the agent generates a new trace context instead of falling back to other protocols.

Common use cases

• Change the default parsing priority: If a request carries trace contexts in multiple formats and the default order does not meet your needs, set a preferred protocol. For example, if a request carries both W3C and Zipkin headers, W3C is parsed first by default. Setting Zipkin as the preferred protocol prioritizes it instead.

• Ignore an existing trace context: If a request carries a trace header but you want to generate a new context with a different protocol, set that protocol as both preferred and enforced. For example, to ignore a Zipkin header and generate a W3C context, set W3C as the protocol and change the propagation mode to Enforced. Without enforced mode, the agent still falls back to parsing the Zipkin header if W3C parsing fails.

Configuration effect

After saving, each LocalRootSpan in a trace includes a trace.protocol.type attribute indicating the active protocol.

Collect internal call data without an entry

In ARMS, HTTP services, RPC services, scheduled tasks, and message consumption are considered entries. Calls made within these entries (such as database calls and HTTP requests) are internal calls *with* an entry. Calls initiated outside of entries -- such as scheduled HTTP calls, database calls, NoSQL calls, message sends, and RPC calls through a JDK thread pool -- are internal calls *without* an entry.

Agents of V4.2.2 and later provide a one-click option to filter out entry-less internal calls. For example, the Lettuce framework periodically runs commands to maintain the Redis connection. These are internal calls without an entry. After disabling their collection, the related metrics are no longer reported.

Default metric collection filter

Filters the reporting of specified metric types. Supported types:

Custom metric collection configuration

Configure metrics defined by the OpenTelemetry SDK. For details, see Customize metrics using the OpenTelemetry Java SDK.

Baggage collection list

When your application uses baggage, this setting writes specific baggage entries to span attributes, making it easier to retrieve specific traces.

Collect plug-in exceptions

Controls whether plug-in exceptions are collected.

Stack depth for distinguishing similar exceptions

Default value is 2. This depth is used to identify similar exception types. Modifying it may cause unexpected statistical behavior. Proceed with caution.

Exception filtering whitelist

Enter the fully qualified class names of exceptions to hide them from the Exception Analysis tab.

Exception filtering for parent class inheritance

When enabled, an exception is also filtered if it is a subclass of a class in the exception filtering whitelist.

Exception message filtering

Filter exceptions of a specified type based on their message content.

Exceptions that match these criteria are not displayed in the ARMS console.

Thread pool and connection pool monitoring

Monitor thread pool metrics in frameworks such as Tomcat, Dubbo, and High-speed Service Framework (HSF). To enable this feature, upgrade the agent to the latest version.

Thread Pool Thread Name Pattern Extraction Policy

By default, all numeric characters in thread names are replaced with *. Adjust this to replace only the trailing numbers.

This matters when your application starts multiple Dubbo providers with different listening ports. With the default policy, thread pools from different providers may be merged because their extracted thread name templates are identical. Adjusting the policy helps distinguish between them.

Example: A Tomcat thread pool displays as http-nio-*-exec-* by default. After adjustment, it becomes http-nio-9099-exec-*.

Thread pool usage scenario filtering and thread pool thread name pattern filtering

Exclude specific thread pools from metric reporting based on their usage scenarios and thread name patterns.

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

• Thread pool thread name pattern: The pattern derived by replacing numeric parts of thread names with *. For example, http-nio-*-exec-*.

Example: Setting the scenario filter to AliyunJavaAgent,Jetty and the pattern filter to Catalina-utility-* means that all thread pool data for the AliyunJavaAgent scenario is not reported, and in other scenarios, thread pools matching Catalina-utility-* are also excluded.

Record OTel Spec conventional attributes

The OpenTelemetry Specification defines attributes that each plug-in type should include in generated spans. To reduce data volume, the ARMS agent does not record these attributes by default. Enable this setting to add them.

For details on the additional attributes added by each framework, see OpenTelemetry Specification.

The following example shows an HTTP Server span. The attributes within the red box are added after enabling this switch.

Span association application label configuration

Controls which spans include application labels. Application labels are configured on the Applications page. By default, all spans include application labels. To reduce data volume, attach labels only to entry spans. Entry spans typically include HTTP Server, RPC Server, message consumption, and scheduled tasks.

The following figure shows the effect when labels are attached only to entry spans. For an application with a label pair test1:value1:

Entry spans contain the label attributes:

Non-entry spans do not contain the test1:value1 attributes:

Asynchronous pass-through scan package name

To monitor asynchronous tasks, add a scan package for asynchronous propagation. When a Runnable, Callable, or Supplier object is created within the specified package, the agent automatically captures the current thread's trace context and propagates it to the new thread during task execution.

Include TraceId in HTTP response

Returns the eagleeye-traceid field in response headers for HTTP requests.

JVM GC Trigger Root Cause

Collects the root causes of JVM garbage collection (GC) triggers. View the results on the JVM Monitoring page. For details on GC trigger root causes, see GC-related metrics.

Copy a single section to other applications

1. In the target section, click Save and bulk copy to other applications.

2. If the Current settings not saved dialog box appears, click OK to save the settings first, then click Save and bulk copy to other applications again.

3. Select the target applications and click OK.

Copy all settings to other applications

1. At the bottom of the page, click Save and bulk copy to other applications.

2. If the Current settings not saved dialog box appears, click OK to save first, then click Save and bulk copy to other applications again.

3. Select the target applications and click OK.

Why do switch settings not take effect?

Check whether the setting has a minimum agent version requirement.

• If a version requirement exists, verify that your agent version meets it. If the version is compatible but the setting still does not take effect, check the agent logs for configuration-related entries.

• If no version requirement exists, check the agent logs for configuration push entries:

  • V3.x agent: Search for [Diamond] receive. If this entry appears, the configuration was pushed successfully.

  • V4.x agent: Search for config update. If this entry appears, the configuration was pushed successfully.

Why does the adjusted sample rate not take effect?

The sample rate only affects traces that originate from this application. If a request already carries a trace context, the application uses the existing context and its sampling flag -- your sample rate setting does not override it.

Why are lambda expressions not supported with the asynchronous pass-through scan package?

Upgrade the agent to V4.x. This version supports automatic asynchronous context pass-through without additional code changes or configuration.

Why do global default configurations not apply to new applications?

Global defaults are a point-in-time snapshot. Changes made after saving are not synchronized automatically. Save the defaults again to apply updated settings to new applications.

Why does filtering the /error interface not take effect?

For agents earlier than V3.2.0, interface filtering runs at the entry point of a call. The /error path is generated by the framework after an error occurs, bypassing the initial filter. Upgrade to V3.2.0 or later to resolve this.

Why are URLs still converged after disabling URL convergence?

• The URL Convergence Settings on the Custom Configurations tab apply only to V3.x agents. For V4.x agents, go to Configuration > Convergence Settings to configure convergence.

• For applications using Spring MVC with agents earlier than V3.x, upgrade the agent to V3.x or later.