EDAS provides a container monitoring function – application diagnosis that collects data to help you detect problems (such as memory and class conflict) of the applications that are deployed and run inside the Tomcat container. EDAS provides refined statistic summaries for application containers, which collects statistics of the instance where the application runs from a range of dimensions, including JVM heap memory, non-heap memory, class loader, thread, and Tomcat connector. Similar to basic monitoring, container monitoring (application diagnosis) displays application-specific single-host data.
The differences are as follows:
- The monitored object of basic monitoring is ECS instance, whereas that of container monitoring is application container.
- Application diagnosis supports query of diagnostic information in single-host mode rather than cluster mode.
- Basic monitoring has latency, whereas container monitoring is near real-time because statistical computing is not performed on collected data (except memory monitoring data).
To view container details, follow these steps:
Log on to the EDAS console, click Applications in the left-side navigation pane, and click the name of the application in the application list.
Select Application Diagnosis in the left-side navigation pane of the Application Details page.
Select an ECS instance from the ECS Instance (Instance ID/Name/IP) drop-down list.
Click tabs to view the monitoring details of the container.
The application diagnosis page has the following tabs:
Memory: Memory is monitored on a per-instance basis. EDAS provides statistics on the heap memory and non-heap memory of the JVM process of the Tomcat container where the application is located. The Memory tab appears by default after you go to the container diagnosis page. The statistical periods include 30 minutes, 6 hours, 1 day, and 1 week.
Class Loading: Provides real-time information about JAR package loading. When a JAR package of the application has version conflict, you can use this function to easily locate the path to which the JAR package is loaded, which lowers troubleshooting costs.
Thread: Displays the basic information of all threads of the current JVM process, including the thread ID, status, and name. The statistical fields are native information of JVM.
Connector: The Tomcat connector is indicated by
<Connector />in the XML configuration of Tomcat. The configuration of each
<Connector />can be considered as a line of pulled information. This view displays the running status of the corresponding connector for the last 10 minutes.
Each connector has a certain number of threads (which forms a thread pool) to process incoming requests. When concurrency or throughput bottlenecks occur, statistics of the processing status of the connector’s thread pool needs to be collected. For example, an HTTP connector has the following XML configuration:
<Connector port="8080" protocol="HTTP/1.1" maxThreads="250" .... />
Click Thread Pool Info in the “Action” field next to the connector. Relevant details are displayed.
The preceding figure shows that the application is almost load-free. If the value of “Busy Thread Count” is close to that of “Thread Pool Max. Value”, the system encounters serious concurrency issue. To solve the problem, scale up the application or optimize the service code.
Object Memory Distribution: Select System Class, Java Primitive Object Class, Class Loading Related, then statistics about number of objects, occupied disk space, and memory usages will be displayed in pie-charts and tables.
- Method Tracking: For details about method tracking, see Method tracking.
- Hot Thread: Provides thread snapshots and statistical analysis of service calls.
- Thread Snapshot: Similar to the jstack command, this command collects stack frames of all threads from the target machines. It identifies the idle threads after obtaining the thread stack, such as HSF，Tomcat，GC. In order to avoid excessive overhead, only 30 threads are retrieved among the rest of threads.
- Service Call Statistics: Performs statistic analysis of the method calls in the application during a period of time, and shows the method calls and call relations ( or call stack). Final results are displayed in tree diagrams and graphs. It highlights your business methods automatically, allowing you to locate the sources of the busiest method calls. This call request will last for about 10 seconds before it returns the results.