All Products
Search
Document Center

Application Real-Time Monitoring Service:Application overview

Last Updated:Mar 11, 2026

After you install an ARMS agent, the Overview tab on the application details page displays real-time performance data: request volume, error counts, response duration, instance count, and CPU utilization. Use this page to assess application health at a glance and identify performance bottlenecks across your deployment environments.

Prerequisites

An ARMS agent is installed for your application.

Important

Application Monitoring provides a new application details page for users who have enabled the new billing mode. If you have not enabled the new billing mode, click Switch to New Version on the Application List page to access the new application details page.

Access the application overview

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

  2. On the Application List page, select a region in the top navigation bar and click the application name.

    Note

    Icons in the Language column indicate the programming language of each application:

    • Java icon: Java

    • Go icon: Go

    • Python icon: Python

    • Hyphen (-): application monitored in Managed Service for OpenTelemetry

  3. Click the Overview tab.

Summary cards

Four cards at the top show high-level metrics for the selected time range. Each card includes a Day On Day percentage that compares the current value against the same time range on the previous day.

CardDescription
RequestsTotal number of requests.
Number of errorsTotal number of errors.
Average DurationAverage response time across all requests.
Number of instancesTotal number of running instances.

Trend charts

ChartVisualizationDescription
RequestsStacked column chartRequest volume over time, broken down by call type.
ErrorsColumn chart with trend lineError count on the left y-axis, error rate on the right y-axis.
DurationTrend chartResponse duration over time. Available metrics: average, P99, P90, and P75.
Note

Percentile metrics (P99, P90, P75) are disabled by default. To display percentile data, enable percentile statistics on the Custom Configurations page. For more information, see Customize settings for a Java application.

Peak CPU usage

A honeycomb chart shows peak CPU utilization across hosts or instances during the selected time range. Dashboard data and CPU metrics vary depending on how the application is deployed and whether the environment is monitored in Managed Service for Prometheus.

  • If the application runs in an ACK cluster monitored in Managed Service for Prometheus, the dashboard displays Prometheus data. For setup instructions, see Monitor an ACK cluster.

  • If the ACK cluster is not monitored in Managed Service for Prometheus, make sure the ARMS agent version is 4.1.0 or later. The dashboard then displays Application Monitoring data. For agent versions, see Release notes of the ARMS agent for Java.

The following table describes how the honeycomb chart behaves by deployment type:

Deployment typeHoneycomb displayColor thresholds
ECSEach cell represents a host.Green: normal. Yellow: exceeds 60%. Red: exceeds 70%.
ACK (monitored in Managed Service for Prometheus)CPU utilization at the application level. If the application spans multiple ACK clusters, the chart displays data from the first cluster that reports data.
Kubernetes (custom data collection)CPU utilization at the application level.
Kubernetes CPU usage honeycomb

Service rankings

Three Top 5 lists rank the services provided by the application:

RankingSorted by
Provided Service Ranking of RequestsHighest request volume
Provided Service Ranking of ErrorsHighest error count
Provided Service Ranking of Average DurationLongest average response duration

Rankings cover the following call types: HTTP, Dubbo, HSF, DSF, user_method, MQ, Kafka, Server, Producer, gRPC, Thrift, Sofa, Schedulerx, Spring_Scheduled, JDK_Timer, XXL_Job, and Quartz.

Peak CPU usage instance ranking

A Top 5 list shows the hosts or application instances with the highest CPU utilization during the selected time range.

Deployment typeRanked by
ECSHosts with the highest CPU utilization.
ACK (monitored in Managed Service for Prometheus)Application instances with the highest CPU utilization. If the application spans multiple clusters, the ranking displays data from the first cluster that reports data.
Kubernetes (custom data collection)Application instances with the highest CPU utilization.

Compare data by group or time

Click comparison icon above a trend chart to open the comparison panel.

Comparison panel
  • Comparison by group: Select Groups to compare data across different dimensions.

    • Basic fields: Tags shared by all metrics. Use this option to compare data by server IP address.

    • Instance tag: Default and custom instance tags for more granular comparisons. To add custom tags, see Add and use tags.

    Group options

  • Comparison by time: Specify a time range to compare current data against a previous period.

View PromQL statements

Click PromQL icon above any section to view the underlying Prometheus Query Language (PromQL) statements.

PromQL panel

Use PromQL statements to:

FAQ

Why is 99th percentile data not displayed?

Percentile metrics are disabled by default. Enable percentile statistics on the Custom Configurations page. For more information, see Customize settings for a Java application.

Why does the request count on the old console Overview page not match the actual time range?

The old console includes data from one minute before the selected time range. For example, selecting a 5-minute range displays 6 minutes of data, and selecting 30 minutes displays 31 minutes.

Why does the slow SQL count from the POP API differ from the old console?

The POP API queries slow requests across databases supported by ARMS, NoSQL databases, and caches. The old console queries only databases supported by ARMS.

To align POP API results with the old console, add an rpcType filter to your query:

QueryMetricByPageRequest.Filters filters2 = QueryMetricByPageRequest
    .Filters
    .builder()
    .key("rpcType")
    .value("60|62|63|65|66|67|68|69|58|59")
    .build();

Why does the instance count exceed the number of running instances?

Long-running queries may include destroyed instances in the total count.

Why does the request count differ between the new and old consoles?

The new console includes scheduled task data. The old console does not.