You can use Application Monitoring of Application Real-Time Monitoring Service (ARMS) to monitor applications. After you install an ARMS agent for an application, ARMS starts monitoring it. You can view data like application topology, traces, abnormal transactions, slow transactions, and SQL analysis.
Application lifecycle
A lifecycle starts when the application is connected to Application Monitoring, and ends when it's deleted. Throughout its lifecycle, the application may be in different states.
State | Property | Description |
Normal | Stable state | If the application is connected to Application Monitoring and receives external traffic, monitoring becomes active. You can query the monitoring data in the ARMS console. |
Slow | Intermediate state | When the average time consumed for the application reaches the specified threshold, the application enters an intermediate state. The Slow state may occur due to many reasons, such as high load of basic resources, slow response of external dependencies, and high self-load. |
Failed | Intermediate state | When the application encounters an error, the application enters an intermediate state. The Failed state indicates that the application has failed service calls within a period of time. |
No Data | Offline or no traffic | When the ARMS console does not display the monitoring data of the application, the application enters the No Data state. This state is triggered when a network problem occurs, the application is running abnormally, or the application is not accessed by external traffic. |
Feature overview
Feature | Description |
Displays information about the application, such as time consumed, and number of requests, errors, and instances. | |
Displays the topological relationships among services of the application. | |
Displays information about the services provided by the application, including interface calls, message queues, and scheduled tasks. | |
Displays information about the services that the application depends on, including external calls, database calls, and message queues. | |
Allows you to combine filter conditions and aggregation dimensions for real-time analysis based on stored full trace data. This can meet the custom diagnosis requirements in various scenarios. | |
Displays information about application instances, such as basic metrics, garbage collection (GC), and Java virtual machine (JVM) memory. | |
Identifies bottlenecks in Java programs caused by CPU, memory, and I/O. It provides detailed statistics by method name, class name, and line number, ultimately assisting developers in optimizing programs, reducing latency and costs, and increasing throughput. | |
Displays the thread-specific statistics of CPU time consumption and number of threads for each type to simulate the code execution process. In case of excessively high CPU utilization or many slow methods, you can use the thread profiling feature to locate the threads or methods that consume many CPUs. | |
Uses bytecode enhancement technology to view program execution details without restarting the JVM process. | |
Displays the exceptions of the application. | |
Analyzes logs to identify the exceptions of your application. |
Notes
The application list contains applications monitored both in ARMS Application Monitoring and Managed Service for OpenTelemetry.
If an application is renamed by modifying the startup parameter
arms.appName, it enters the No Data state and is still displayed in the application list. If you no longer need the application, you can delete its data.