Application Real-Time Monitoring Service:Troubleshoot missing interface and pool monitoring data

Initial check

1. Log on to the Application Real-Time Monitoring Service (ARMS) console. In the left-side navigation pane, choose Application Monitoring > Application List. In the upper-right corner, choose Settings > Application Start/Stop Settings to check whether data collection is disabled.

   

2. On the Application List page, click the application. On the Application Settings page, click the Custom Configuration tab to check whether Probe Master Switch is turned on.

   

3. On the JVM monitoring tab of the Application Details page, check whether JVM data is displayed as expected.

   • If no JVM monitoring data is available, the nodes may be disconnected from the ARMS console. You can log on to the instance to check the network connectivity. For more information, see How do I test the network connectivity? If the network connectivity is stable, troubleshoot the application integration process.

   • If JVM monitoring data is available and interface monitoring data is unavailable, check whether the application has inbound traffic and the Java component is supported by ARMS. For more information, see Java components and frameworks supported by ARMS. If the Java component is not supported by ARMS, submit a ticket.

4. If the application is equipped with JDK 7 or 17, or the application was not developed based on Spring Boot, submit a ticket.

   Check the version of the ARMS agent. If the version is earlier than 2.7.3.5, you must provide the agent logs. The logs are located in the /home/admin/.opt/ArmsAgent/logs directory.

Pool monitoring data missing

1. ARMS provides pool monitoring capabilities for custom thread pools, Dubbo, Apache Tomcat, OkHttp, Apache HttpClient, Druid, and HikariCP.

2. Check whether the version of the ARMS agent is earlier than 2.8.3.

   If the version is earlier than 2.8.3, upgrade the agent to 2.8.3 or later. For more information, see Release notes of the ARMS agent for Java.

Slow call and error data missing

• Slow call: ARMS captures calls whose response time exceeds the threshold, which is 500 milliseconds. Check whether the calls of the application timed out.

• Number of errors: ARMS captures errors with HTTP status codes greater than 400 and failed interface calls thrown to the outermost layer. Check whether the calls of the application meet these conditions.