All Products
Search
Document Center

Application Real-Time Monitoring Service:Troubleshoot Missing Data in Pool, API, and Other Monitoring Views

Last Updated:Aug 24, 2026

Missing data in the pool, API, and other monitoring views of Application Real-Time Monitoring Service (ARMS) Application Monitoring can have several causes, from disabled data collection to unsupported component or agent versions. Complete the common checks in this topic first, and then continue with the section for the monitoring view where data is missing.

Common checks for missing monitoring data

Complete the following checks in order. These checks apply to every missing-data symptom, regardless of which monitoring view is empty.

Note

The checks in this topic apply to applications that are monitored by the ARMS Java agent.

  1. In the ARMS console, go to the Application Monitoring > Application List page. In the upper-right corner, choose Settings > Application Start/Stop Settings and check whether data collection is disabled.

    In the Start/Stop All Applications dialog box, view the current application status. The dialog box provides the following policies:

    • Stop all applications (automatically start at 00:00 the next day)

    • Stop all applications (do not automatically start the next day)

    • Keep running (automatically stop applications after the quota is reached and automatically start at 00:00 the next day)

      If the current status is one of the stop policies, data collection is disabled. To resume data collection, select the keep-running policy.
  2. On the Application List page, click the target application. Then, on the Application Settings > Custom Configurations page, check whether the Agent Master Switch is turned on.

    If the Agent Master Switch is turned off, ARMS cannot monitor the application. Turn on the switch to resume monitoring. Changes to the switch take effect without restarting the application.

  3. On the Application Details > JVM Monitoring page, check whether JVM data exists.

    • If no JVM data exists, the instance that runs the agent may have lost its connection to ARMS. Log on to the instance and check network connectivity. For more information, see How to test network connectivity. After you confirm that the network is connected, complete the application integration procedure again and then troubleshoot the issue.

    • If JVM data exists but the API monitoring view is empty, see Missing data in the API monitoring view.

  4. Confirm the version of the ARMS agent that the application uses. The agent version determines whether pool monitoring is available and whether you must provide agent logs when you submit a ticket.

    If these checks do not identify the cause, continue with the section for the monitoring view where data is missing.

Missing data in the pool monitoring view

If the pool monitoring view is empty after you complete the common checks, verify the component type and the agent version.

Verify the component type

Pool monitoring supports the following component types:

  • Custom thread pools

  • Dubbo

  • Tomcat

  • OkHttp

  • Apache HttpClient

  • Druid

  • HikariCP

    Confirm that your thread pool component is one of these types.

Check the agent version

If the agent version is earlier than 2.8.3, upgrade the agent to 2.8.3 or later. For more information, see Java Agent Version Notes.

Missing data in the API monitoring view

If the JVM Monitoring page has data but the API monitoring view is empty, check application traffic and component compatibility.

  1. Confirm that the application is receiving traffic.

  2. Confirm that the component versions used by the application are supported by ARMS. For the supported component versions, see Java components and frameworks supported by ARMS Application Monitoring.

  3. If the component versions are outside the supported scope, submit a ticket.

Missing slow call and error metrics

The slow call and error metrics in ARMS Application Monitoring count only the requests that meet specific conditions. Check whether the requests in your application meet the following conditions.

  • Slow calls — A request is recorded as a slow call when its response time exceeds the slow call response time threshold, which is 500 ms by default. Check whether requests in the application exceed this threshold.

  • Error count — ARMS counts a request as an error request when its response code is greater than 400, or when the request throws an exception to the outermost layer during an API call. Check whether requests in the application meet either condition.

    If no request in the application meets these conditions, empty slow call and error metrics are expected.

Submit a ticket

If your application uses JDK 7 or JDK 17, or is not based on Spring Boot, submit a ticket.

For agent versions earlier than 2.7.3.5, you must provide the agent logs when you submit a ticket. By default, the agent logs are located in the /home/admin/.opt/ArmsAgent/logs directory.