View application dependencies - Application Real-Time Monitoring Service

After you install an agent for your application, ARMS starts monitoring it. On the Dependencies page, you can view the application's dependencies, including external calls, database calls, and message queues.

Prerequisites

Important

ARMS Application Monitoring provides a new monitoring details page for users who have enabled the new billing model. For details about the new billing model, see Product Billing (New).

If you haven’t enabled the new billing model but want to access the new monitoring details page, click Switch to New Version on the Application List page.

You have installed a probe for your application. For instructions, see Overview of Application Monitoring Integration.

Application dependencies

Log on to the ARMS console. In the left-side navigation pane, choose Application Monitoring > Application List.
On the Application List page, select the region in the top navigation bar and then click the name of the application.
Note
Icons in the Language column have the following meanings:
- : a Java application connected to Application Monitoring.
- : a Golang application connected to Application Monitoring.
- : a Python application connected to Application Monitoring.
- -: an application connected to Managed Service for OpenTelemetry.
In the top navigation bar, click Dependencies.
- In the quick filter area, you can filter the charts and service list by Request Type, Interface Name, and Host.
- The trend chart area displays time-series curves for the total requests, error count, and average response time for calls to the application's dependencies within the selected time range.
  
  Click the icon to view metric statistics for a specific period or compare statistics between different dates. Click the icon to switch between a bar chart and a trend chart.
- In the service list area, you can view information such as the interface name, type, and RED metrics (request count, error count, and average response time).
  
  In the service list, you can perform the following operations:
  - Click an interface name, or click Details, SQL Analysis or Exception Analysis in the Actions column to view details about the corresponding service. For more information, see Dependency details.
  - Click Trace in the Actions column to view the corresponding trace. For more information, see Trace Explorer.

Supported frameworks

Dependency details

External calls

Overview

On the Overview tab, you can view statistics for the request count, error count, and average response time for the destination address or service, and a time-series curve of slow calls.

Trace Explorer

The Trace Explorer feature analyzes stored trace data in real time, allowing you to combine filter conditions and aggregation dimensions to meet various custom diagnostic needs. For more information, see Trace Explorer.

Message publishing

Note

Viewing message publishing data is not supported for Python applications.

Overview

On the Overview tab, you can view statistics for the request count, error count, and average response time for the target message, and a time-series curve of slow calls.

Sending statistics

The Sending Statistics tab lists topic sending statistics from the sender's perspective, including request count, error count, and response time.

Trace Explorer

Database calls

Note

Viewing database call data is not supported for Python applications.

Overview

On the Overview tab, you can view statistics, time-series charts, and distributions for the request count, error count, and average response time of calls to the target database instance, along with the distribution of slow call counts.

SQL Analysis

On the SQL Analysis tab, you can find the request trends (request count, slow SQL count, and average response time) for the selected database instance, as well as statistical metrics at the SQL call level. This information helps you identify which SQL statements are causing slow service responses.

Note

The Return Size metric is supported only for MySQL 5.x versions and requires Application Monitoring agent version 2.7.1.3 or later.

Click Trace to the right of an SQL statement to view the full trace that includes the SQL execution. For more information, see Trace Explorer.

Exception Analysis

On the Exception Analysis tab, you can view how many times each exception occurred during calls to the target database within a specified time range, as well as the exception details. For more information, see Exception Analysis.

Call source

On the Call Source tab, you can view time-series curves for the response time, request count, and error count of the source interfaces that call the target database.

Trace Explorer

FAQ

Database

No data for database calls

Possible reasons:

The database is not in the list of databases supported by ARMS. For a list of supported databases, see Supported Java components and frameworks for ARMS Application Monitoring.
Agent versions earlier than 4.x do not support databases that are called asynchronously or without an entry point.

Discrepancy in slow database calls

ARMS monitors from a client-side perspective, meaning its measurements cover the entire process: the application initiates a request, the request travels over the network, the server processes it, and the response returns to the client. Therefore, the database metrics collected by ARMS are affected by factors like garbage collection (GC) and network latency, which can result in higher values than those reported directly by the server. Additionally, ARMS identifies slow calls based on the Slow SQL Threshold configured on the Custom Configuration page. This threshold defaults to 500 ms and may differ from the database server's configuration.

Discrepancy in database call volume

A single database may be accessed by multiple applications. The ARMS console displays the call volume only from the current application.

Unrecorded external calls

For the 3.x agent, possible reasons include:

External calls without an entry point.

By default, the 3.x agent collects only external calls that occur within the processing flow of HTTP interfaces, RPC interfaces, scheduled tasks, and message consumption. External calls, such as database access or HTTP requests, that are initiated by background thread pools are not collected.
External calls with an entry point but with thread switching during execution.

The 3.x agent does not support automatic propagation of asynchronous contexts. If a thread switch occurs, the trace context is lost, and the call is not collected.

Both of these issues can be resolved by upgrading the agent to version 4.x.

Undefined data in external calls

Agent versions 3.1.x and earlier have a defect in the Dubbo instrumentation that prevents the agent from obtaining the peer IP address. This issue was fixed in version 3.2.x.

Garbled keys in Redis calls

An instrumentation issue in the Lettuce framework causes incorrect key retrieval. You can ignore the garbled part of the key; the rest of the key is valid.

No trace data from SQL statements

Cause: To avoid the cost and performance overhead of reporting large amounts of data in extreme scenarios, the ARMS agent enables span compression by default. When multiple child spans under a parent span share the same name, they are compressed into a single representative span. Its attributes then store the count, total duration, maximum duration, and minimum duration of all identical child spans. However, this compression discards the individual details of the aggregated spans. Consequently, SQL statements within these compressed spans cannot be directly queried on the Trace Explorer page.

Solution: Disable trace compression.

Note

After you disable compression, if an application interface frequently accesses components like databases or Redis, the amount of reported data will increase, and the ARMS sampling logic for errors and slow calls will be less effective.

Message publishing

Data difference between client and server views

The Message Subscription and Message Publishing pages display client-side performance metrics for the selected application acting as a consumer or producer, whereas the monitoring dashboard for an MQ instance shows server-side, topic-related performance metrics.

Span name formats for messages

Message type	Agent versions before 4.x	Agent 4.x and later
RocketMQ/Ons message sending	No span is created. Only method stacks are recorded.	`${topic} + publish`
RocketMQ/Ons message receiving	`Recv Topic@${topic}`	`Recv Topic@${topic}`
Kafka message sending	No span is created. Only method stacks are recorded.	`${topic} + publish`
Kafka message receiving	`Kafka/topic=${topic}`	`Kafka/topic=${topic}`
RabbitMQ message sending	No span is created. Only method stacks are recorded.	`${exchange} + publish`
RabbitMQ message receiving	`Recv Exchange@${exchange}`	`Recv Exchange@${exchange}`

Support for Spring Cloud Alibaba RocketMQ

This framework is supported in agent versions 4.x and later. If your agent version is earlier than 4.x, upgrade the ARMS agent.

Message Delay metric

Message delay refers to the total time from message production to consumption. The unit for this metric is milliseconds (ms). This metric is currently collected only for RocketMQ Client and Ons Client.

Missing consumer traces or metrics

This may happen if the agent version is earlier than 4.x and you use lambda expressions to define the consumption logic in the message listener.

Because class enhancement for lambda expressions fails in agent versions 2.x and 3.x, you can upgrade the agent to version 4.x to resolve this issue.

Kafka 'Magic v1' header error

The Java agent uses the Header field of Kafka messages to propagate trace context. In Kafka versions earlier than 0.11.0.0 (for both clients and brokers), the message format does not support headers. If you are using an older Kafka version for your broker or client, migrate to version 0.11.0.0 or later. If you cannot migrate immediately, for Java agent versions earlier than 4.x, you can disable Kafka component enhancement (the kafka-plugin switch) on the Agent Switch Settings section of the application's Custom Configurations page. For Java agent versions 4.x and later, add the -Dotel.instrumentation.kafka.producer-propagation.enabled=false JVM parameter when starting the service as a workaround.

Missing message spans in traces

Check whether the message queue client SDKs used by your producer and consumer applications are supported by ARMS. For supported components, see Supported Java components and frameworks for ARMS Application Monitoring.
Check whether both your producer and consumer applications are connected to Application Monitoring or Managed Service for OpenTelemetry, have their agent and plugin switches enabled, and are reporting to the same region. Spans for sending messages are generated in the producer, and spans for receiving messages are generated in the consumer. If either application is not configured correctly, its spans will be missing.
If you cannot see spans for sending messages, check if the producer application's agent version is 4.x or later. In agent versions earlier than 4.x, sending a message is not recorded as a separate span but is instead included in the parent span's method stack. You can click the icon next to the parent span to view the method call stack.
If you cannot see spans for receiving messages, check whether you have configured an Invalid API Filter in the Interface Call Configuration section on the Custom Configurations page of the consumer application. This filter is used to exclude unwanted spans from being collected.

Kafka response time difference across agent versions

Symptom: The response time drops from several seconds to 0.x milliseconds.

Cause:

In agent versions 3.x and earlier, when processing a BatchMessageListener, a batch of messages is treated as a single call, and their durations are aggregated into one value.

Agent versions 4.x and later separate this logic, counting each message as an individual call. Therefore, after upgrading from a 3.x to a 4.x agent, the response time per call will decrease significantly while the number of calls will increase significantly.

The statistical method used in version 3.x was less precise and has been improved in version 4.x.