After you install an agent for an application, Application Real-Time Monitoring Service (ARMS) starts monitoring it. On the Application List page, you can view basic metrics such as requests per second, error rate, and response time, as well as the global application topology and overall health.
Application List
The Application List displays basic metrics for all monitored applications, such as requests per second, error rate, and average response time.
In the upper-right corner of the page, you can switch between List View and Grid View. The table also includes the CVE Vulnerabilities and Smart Insight columns.
-
Click an application name to view its detailed data and configure custom settings. For more information, see View monitoring details (new).
-
Click the
icon in the Tag column to tag an application. For more information about how to create a tag, see Create and bind custom tags.You can use application tags to filter applications, manage application permissions, and allocate costs.
If you use tags to filter other application data, such as scenario-based analysis data, follow the naming conventions of open-source Prometheus. Tags must contain only letters, numbers, and underscores (_) and must start with a lowercase letter.
Icons in the Language column indicate the application's programming language:
-
: Java -
: Go -
: Python -
- (Hyphen): an application monitored in Managed Service for OpenTelemetry
Global Topology
The Global Topology page displays the call relationships among all monitored applications within a specified time range.
Click the Topology View icon in the upper-right corner to switch to the graph view. The left-side panel supports three layouts: Force-directed, Hierarchical, and Circular. In the topology graph, metrics such as requests per second, response time, and error count are displayed above each application node. Lines between nodes represent call relationships, and a warning icon is displayed on abnormal nodes.
Health
On the Health page, each application is represented by a square colored red, yellow, or green based on the configured thresholds.
In the upper-right corner of the page, you can switch to the Grid View. The top of the page displays the total number of applications and a count for each status: Normal, Warning, and Critical. You can search by application name or select the Hide Normal Applications checkbox to filter the view.
Click Threshold Settings to set the thresholds for uncleared alerts, new exceptions, and average duration.
After you set the thresholds, the color priority for the squares is Red > Yellow > Green. If multiple threshold conditions are met, the color with the highest priority is used. For example, if the status for uncleared alerts is yellow, new exceptions is green, and average duration is red, its square is colored red.
The default thresholds are as follows: uncleared alerts: Green for 0, Yellow for 1, and Red for 2. new exceptions: Green for 0, Yellow for 1, and Red for 2. average duration: Green for 0 ms, Yellow for 100 ms, and Red for 500 ms. You can enable or disable each metric by using its switch. Click Confirm to apply the settings.
Click a square to view the application's uncleared alerts, new exceptions, and average duration for the current time period.
In the pop-up dialog box, uncleared alerts are listed by name along with their priority levels (such as P2 and P4). New exceptions are grouped and counted by type (such as RuntimeException and IOException). The average duration is the average response time for the current time period.
FAQ
Why do duplicate application names appear?
Duplicate application names may appear in the following two scenarios:
-
Two applications from different sources use the same name. For example, an application integrated with ARMS via another cloud product like EDAS or SAE shares a name with an application you connected manually.
-
Two applications built with different language frameworks are configured with the same name.
RAM users cannot view applications
A RAM user granted only the ReadOnlyAccess or AliyunARMSReadOnlyAccess system policy can log on to the ARMS console but cannot view applications. You must also grant the ReadTraceApp permission for specific resource groups. Otherwise, ARMS cannot display the Application List under resource group-based authorization. For more information, see Custom RAM authorization policies for Application Monitoring.
When granting the ReadTraceApp permission policy, set the Resource Scope to the resource group level.
On the RAM user's My Permissions tab, the ReadTraceApp policy type is Custom, and the Resource Scope column lists a specific resource group, such as default resource group.