What I'm going to introduce in this content is the newly added “APM”Agent-specific resource dashboardsIt's' Since this is a new screen introduced after a long time, efforts were made to improve the degree of perfection through various considerations during the planning stage. I would like to introduce this function in detail with the hope that it will be used more actively in the business.
First, this resource dashboard is a feature only available on the Java platform in APM projects. This is because this screen is structured based on Java's Memory Pool data. Please note that agents in other languages cannot collect this data, so currently only Java projects support this feature.
This dashboard uses a variety of data, but The core is Java Memory Pool dataThis is it. It is designed so that you can visually understand how the memory pool changes over time, which areas have high memory usage, and why changes in the Eden Space area are prominent even when GC has occurred.
The most difficult part of designing this screen is that it may have been somewhat difficult for first-time users because the screens that have been provided are structured from the perspective of experienced users. Also, during the analysis process, I felt that the user experience was poor due to frequent movement between screens or excessive pop-ups.
Therefore, in this project, we have a structure that minimizes these inconveniences and can derive insights by comprehensively checking key indicators on a single screen, that is, without users going back and forth A screen where you can quickly determine the cause of the problem in one placeWe proceeded with the goal of creating.
The screen you see above is a newly developed resource dashboard. This screen is designed to be analyzed as a single application unit. Therefore, please note that it is not possible to analyze by project or application task.
The following is an explanation of the screen configuration.
The human eye is generally known to move from top left to bottom right when looking at a screen. Considering this visual flow, the 'Java memory area', which is the most important data, was placed at the top left of the screen. Also, the important indicators OldGen GC Count and ObjectPendingFinalizationCount are arranged diagonally so that they follow the flow of gaze naturally.
In particular, the occurrence of OldGen GC is an important sign that a risk has been detected in the system. OldGen GC is called Full GC or Major GC, and when this phenomenon occurs Issues such as 1) Delays in response time, 2) Risk of running out of memory, and 3) Increased CPU usageIt may be accompanied by Therefore, it is very important to prevent OldGen GC in advance, so that system stability and performance can be maintained.
objectPendingFinalizationCount is the number of objects that have not yet been finalized by GCIt means A higher number indicates a large number of GC target objects, which can lead to delays in GC processing time. Also, if this causes a Finalizer Thread bottleneck, it can degrade overall system performance.
If the indicator continuously confirms a high value of 10,000 or more, please check whether to use the finalize () method in the code. If possible, it's a good idea to avoid using this method and perform resource management by clearly disabling resources.
In Java, a memory pool (memory area) refers to a memory area used by the JVM to run an application, and is managed by dividing it according to the purpose. There may be slight differences between JVMs, but they are generally divided into heap regions and non-heap zones.
Note that there are various types of JDK, such as OpenJDK, Oracle JDK, GraalVM, IBM Semeru JDK, and Azul Zing, and there are differences in the structure of each memory pool.
1. OpenJDK/Oracle JDK Memory Pool Structure
2. GraalVM's memory pool structure
3. IBM Semeru JDK memory pool structure
4. Azul Zing & Azul Zulu JDK's memory pool structure
Shows the overall memory utilization (%). Total usage based on internal configurations such as Eden, Old Gen, and Metaspace.
It represents the CPU time it took for the JVM to execute application code, in milliseconds (ms).
gcCountis the number of GCs that have occurred within a given period, gColdgenCountOnly the number of GC times for the Old region is counted separately.
Shows the time spent on garbage collection in ms.
Shows the percentage of CPU utilization of the JVM process.
Shows the number of transactions processed per second.
Shows the number of file descriptors currently in use, such as open files or sockets.
The object that GC should process finalize ()
Shows the number of remaining waiting states.
Based on recent 10 minute trends, various indicators such as current memory changes, whether full GC has occurred, and whether a specific memory area is being overused can be checked and determined at a glance. Also, there are 3 main buttons located in the upper right corner of the screen.
1. hip histogram
2. active transactions
3. Runnable thread
Can be viewed for up to 3 hoursIt was developed to do so. The reason for this is that this menu has the advantage of being a real-time dashboard. Therefore, we are planning to provide a minimal history search function and develop a separate resource analysis screen later.
History VIEW is a screen with some concepts of analysis. It is designed so that not only trend data checked on the real-time screen can be queried, but also transaction/SQL/HTTPC statistics data.
1. transaction statistics
2. SQL statistics
3. HTTP Call Statistics
The newly introduced 'Resource Dashboard by Agent' is designed to intuitively understand memory and resource usage in Java-based system operating environments and to catch signs of failure early.
In business environments that are more sensitive to system performance, these resource-based insights are likely to make a big difference in responding quickly and accurately. Using APM's new resource dashboard, we hope you'll have a deeper monitoring experience on a single screen.
Sign up Please check the agent-specific resource dashboard in APM later.