After you install an Application Real-Time Monitoring Service (ARMS) agent for an application, ARMS starts to monitor the application. On the Provided Services tab of the application details page, you can view information about the services provided by the application, such as interface calls, message queues, and scheduled tasks.
Prerequisites
Application Monitoring provides a new application details page for users who have enabled the new billing mode. For more information, see Billing (new).
If you have not enabled the new billing mode, you can click Switch to New Version on the Application List page to view the new application details page.
An ARMS agent is installed for the application. For more information, see Application Monitoring overview.
Procedure
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.
NoteIcons displayed in the Language column indicate languages in which applications are written.
: Java application
: Go application
: Python applicationHyphen (-): application monitored in Managed Service for OpenTelemetry.
In the top navigation bar, click the Provided Services tab.
In the Quick Filter section (icon 1), you can query charts and services by Request Type, Operation, or Host.
In the trend charts section (icon 2), you can view the time series of the number of requests, number of errors, and average time consumed.
Click the
icon. In the dialog box that appears, you can view the metric data in a specific period of time or compare the metric data in the same period of time on different dates. You can click the 
icon to display the data in a column chart or a trend chart. In the service list section (icon 3), you can view the name, request type, and key metrics of each interface defined by the RED Method: rate, errors, and duration.
In the service list, you can perform the following operations:
Click an interface name or click Details, SQL analysis, or NoSQL analysis in the Actions column to view the details of the service. For more information, see the Interface details section.
Click Traces in the Actions column to view the trace details of an interface. For more information, see Trace Explorer.
Supported frameworks
External calls initiated by the following HTTP clients and Remote Procedure Call (RPC) frameworks are automatically discovered and monitored:
Apache HttpClient
Google HTTP Client
OkHttp/OkHttp3
Spring Web (RestTemplate)
AsyncHttpClient
Dubbo
High speed framework of Alibaba Cloud (Ali-HSF)
GRpc
Thrift
Database calls initiated by the following database clients are automatically discovered and monitored:
Mysql Connector
Postgresql JDBC Driver
Microsoft JDBC Driver for SQL Server
MariaDB Java Client
Oracle ojdbc
Sharding-jdbc
Druid
Hikari-CP
MyBatis
MyBatisPlus
Jedis
Lettuce
Redisson
MemCached
MongoDB Java Driver
Spring-MongoDB
Elasticsearch Rest Client
Elasticsearch Rest High Level Client
Clickhouse JDBC Driver
influxDB
Message-oriented middleware (MOM) calls initiated by the following messaging clients are automatically discovered and monitored:
RocketMQ Java Client
Spring-RocketMQ
Aliyun ONS
RabbitMQ Java Client
Kafka-client
For information about the versions of the preceding frameworks, see Java components and frameworks supported by ARMS.
Interface details
Interface calls
Overview
On the Overview tab, you can view the number of requests, number of errors, average duration, HTTP status codes, and time series of slow calls.
SQL and NoSQL analysis
On the SQL analysis and NoSQL analysis tabs, you can view the lists of SQL and NoSQL requests initiated by the interface. You can also query databases by host. On these tabs, you can locate slow SQL statements or NoSQL statements that cause slow responses of the service.
You can click a SQL or NoSQL database name to view the details of the database. You can also click Traces in the Actions column to view the trace of a SQL or NoSQL statement. For more information, see Trace Explorer.
Upstream and downstream interface calls
On the Upstream and Downstream tabs, you can view the upstream interfaces that call the application and downstream interfaces called by the application, and the relevant metric data, including the number of requests, number of errors, and duration.
Trace Explorer
Trace Explorer allows you to combine filter conditions and aggregation dimensions for real-time analysis based on the stored full trace data. This can meet the custom diagnostics requirements in various scenarios. For more information, see Trace Explorer.
Message queues
Message queues of Python applications cannot be viewed.
Overview
On the Overview tab, you can view the number of requests, number of errors, average duration, and consumption delay. Only the consumption delay data of RocketMQ v4.8.0 and later can be viewed.
SQL and NoSQL analysis
On the SQL analysis and NoSQL analysis tabs, you can view the lists of SQL and NoSQL requests initiated by the interface. You can also query databases by host. On these tabs, you can locate slow SQL statements or NoSQL statements that cause slow responses of the service.
You can click a SQL or NoSQL database name to view the details of the database. You can also click Traces in the Actions column to view the trace of a SQL or NoSQL statement. For more information, see Trace Explorer.
Consumption statistics
On the Expenses Statistics tab, you can view the consumption details of a topic, including the number of requests, number of errors, and duration, from the perspective of a consumer.
Trace Explorer
Trace Explorer allows you to combine filter conditions and aggregation dimensions for real-time analysis based on the stored full trace data. This can meet the custom diagnostics requirements in various scenarios. For more information, see Trace Explorer.
Scheduled tasks
Only the scheduled tasks of Java applications can be viewed.
Overview
On the Overview tab, you can view the number of requests, number of errors, average duration, and time series of scheduling latency.
SQL and NoSQL analysis
On the SQL analysis and NoSQL analysis tabs, you can view the lists of SQL and NoSQL requests initiated by the interface. You can also query databases by host. On these tabs, you can locate slow SQL statements or NoSQL statements that cause slow responses of the service.
You can click a SQL or NoSQL database name to view the details of the database. You can also click Traces in the Actions column to view the trace of a SQL or NoSQL statement. For more information, see Trace Explorer.
Downstream interface calls
On the Downstream tab, you can view the downstream interfaces called by the application, and the relevant metric data, including the number of requests, number of errors, and duration.
Trace Explorer
Trace Explorer allows you to combine filter conditions and aggregation dimensions for real-time analysis based on the stored full trace data. This can meet the custom diagnostics requirements in various scenarios. For more information, see Trace Explorer.
FAQ
What does the Upstream tab of the interface details page show?
The Upstream tab of the interface details page shows details about upstream services that call the current application and are being monitored by an ARMS agent. If the application calls itself, it is also displayed as an upstream service on the Upstream tab.
Why are the upstream services of some interfaces not displayed on the Upstream tab?
If the upstream services are not monitored by an ARMS agent, they are not displayed on the Upstream tab.
Why is the upstream and downstream service data disordered?
By default, if the SkyWalking component is installed in the trace, SkyWalking is regarded as the tracing protocol of the entire trace. The ARMS agent earlier than v4.2.x is not fully compatible with the SkyWalking protocol, which causes upstream and downstream service recognition errors. You can upgrade the agent to v4.2.x or later, or configure a protocol for propagation in the Call Chain Pass-through Protocol Settings section of the Custom Configurations page. For more information, see Customize settings for a Java application.
Why are traces of error calls missing?
The ARMS agent earlier than v3.2.x may not correctly record the status codes of Dubbo traces. The ARMS agent 3.2.x and later has fixed the issue.
Why are traces of abnormal calls missing?
The ARMS agent earlier than v4.1.x records only traces of error and slow calls, and does not record those of abnormal calls, whereas the ARMS agent v4.1.x and later records traces of slow, abnormal, and error calls.
Why did interface traffic drop?
Determine if interface traffic has actually dropped. This can be assessed by examining whether concurrent changes happen in metrics like CPU utilization and network I/O before and after the reported drop occurred:
If interface traffic has actually dropped, it was caused by service traffic decrease.
If interface traffic has not dropped, the ARMS server may have encountered errors. We recommend that you submit a ticket.
Why is the traffic data of Spring Cloud Gateway not correct?
The ARMS agent earlier than v4.x has deficiencies in the instrumentation of Spring Cloud Gateway. We recommend that you upgrade the agent to v4.x.
How do I query the slow SQL statements of an interface?
Perform the following operation:
New console
On the Provided Services tab, click the name of the interface. On the SQL analysis tab of the interface details page, view the slow SQL statements.
Old console
On the SQL Analysis tab of the Interface Invocation page, view the slow SQL statements.
What does the yellow dot between two interfaces on the Interface Invocation page of the old console mean?
Move the pointer over the dot to check the prompt.
A yellow dot indicates a slow call. By default, a call that takes more than 500 milliseconds is identified as a slow call. You can change the duration threshold in the Interface call configuration section of the Custom Configuration tab on the Application Settings page.
A red dot indicates an error call.
Why is some 5xx status code data not collected?
Per RFC7231, status codes like 502 and 504 are error codes emitted by the Gateway. These status codes might not reflect the actual response codes of the services it calls. In scenarios where only the services connected to the Gateway are monitored by an ARMS agent and the Gateway itself is not, 5xx responses generated by the Gateway are not tracked or reported.
What is "NetWork And Dubbo Response Decode"?
It is a span that is used to count the time consumed by deserialization at the Dubbo transport layer.
Why do interface names contain characters such as * or ARMS keywords?
As interface names are divergent, ARMS converges them by replacing the different parts of similar interfaces. For more information, see ARMS convergence policies.
Why are the external interface call duration and downstream service duration different?
The server-side processing time refers to the duration taken by the server to handle a request after it has been received by the interface. On the other hand, the client-side processing time is measured from when the request is initiated and includes additional time for connection establishment and network latency. The ARMS console separately displays the server-side processing time for handling requests and the total client-side time from when the request is initiated. However, the network-related latency cannot be precisely determined.
Why is the number of exceptions of a normal interface call is greater than 0?
The exceptions were thrown internally by certain frameworks (such as OkHttp3) and were caught externally by the framework itself. Therefore, the business logic remained unaffected. However, because ARMS has instrumented this framework, it also recorded these exception details. This does not indicate an actual issue with the business operations. You can evaluate whether these exceptions require any action or remediation. To view the message information of a specific exception, click the corresponding trace and then click the 
icon on the right side of the interface and view the exception information in the method stack.
Why are some interface names /error, /404, /*, and /**?
This is because ARMS was unable to find appropriate routes for the following unexpected requests:
A non-existent URL was requested.
An error was reported when the request verification failed because the request header was invalid. For example, the header contained invalid characters.
An HTTP server without routing configurations was used, such as Netty.
Why is the number of calls displayed on the Provided Services tab different from that displayed on the Trace Explorer tab?
Data provided by Trace Explorer is calculated based on the sampled trace data and varies with the sampling rate.
Why are the duration quantiles displayed on the Provided Services tab different from those displayed on the Trace Explorer tab?
Quantiles on the Provided Services tab are calculated per machine based on bucketing, whereas quantiles provided by Trace Explorer are calculated based on the duration of spans related to the interface after sampling. For more information, see ARMS metric quantile calculation.
Why did the interface calls suddenly increase by about two times?
This is because an ARMS agent v3.x and an ARMS agent v4.x were both installed for the application when some interface calls were called. In the top navigation bar of the application details page, choose . In the agent list, click View Details in the Actions column to view JVM parameters.
As shown in the following figure, two -javaagent parameters exist, which indicates that an ARMS agent v3.x and an ARMS agent v4.x are both installed.
Why is the number of calls in the ARMS console is inconsistent with that provided by a third-party observability tool?
This may happen in various scenarios. Examples:
Suppose that the number of interface calls per minute for an application calculated by ARMS is 500, whereas that calculated by NGINX is 200. In general, this is most likely caused by traffic bypassing NGINX to directly access the application.
Suppose that the number of times that an application accesses a database per minute is 400, whereas the number of executions on the database per minute is 1,000. Generally, the database is accessed by multiple applications. The ARMS console can only view the page views of specific applications.
How does ARMS support Spring WebFlux?
The ARMS agent v4.x only supports native Spring WebFlux and Spring Cloud Gateway. WebFlux-related plug-ins that have been modified by using custom web handlers, such as Apache ShenYu, are not supported.