This section defines the list of figures (CPU, memory, MX, process information..) to capture on the monitored process.
It applies for the AdvancedMXAgent and AdvancedJMX recording methods.
Feel free to adjust it by removing or commenting out the fields you do not need.
By default, the standard profile is provided with an optimized set of parameters.
In some cases, depending on the JVM implementation, the data may not be available : the recorder will set then a default value of -1 for the requested field, which will be interpreted correctly by the Jeyzer Analyzer.
This configuration is stored in the <recording profile>_advanced_mx.xml file.
Process card
When activated (see recording attributes), the process card automatically collects the system properties and some internal JVM values (prefixed with jzr.ext.process in the process card).
It is also possible to capture in the process card :
- MX static values exposed by the monitored process giving their MX object name and attributes. Example for AMQ :
<process_card>
<mx_parameters
name="org.apache.activemq:type=Broker,brokerName=*"
attributes="BrokerName,BrokerVersion"/>
...
</process_card>
- Jar Manifest attributes : capture information from any jar file in the classpath of the monitored application. Only available in agent mode.
Interest : capture the version, module name or build number for the deobfuscation mapping selection (see the Jeyzer demos for examples).
Captured manifest attributes are stored in the process card as :jzr.jar.<jar name>.<attribute name>=<attribute value>
All below patterns are regular expressions.
<process_card>
<manifest>
<jar>
<filter pattern="log.*.jar"/>
<manifest_info>
<filter pattern="Implementation-Title"/>
<filter pattern="Implementation-Version"/>
<filter pattern="Implementation-Build"/>
</manifest_info>
</jar>
</manifest>
...
</process_card>
.
Process jar paths
Process jar paths are the paths of the jar files loaded by the JVM.
Only available in AdvancedMXAgent mode.
Jar paths are collected periodically as jars can be loaded by convention at any time :
period: the collection periodstart_offset: the first collection will happen after this offset. It lets the JVM to load a representative set of jars.
<jar_paths period="15m" start_offset="1m"/>
.
Process modules
Since Jeyzer Recorder 2.2.
Process modules are the Java modules loaded by the JVM.
Only available in AdvancedMXAgent mode.
Java module information is collected periodically as modules can be loaded by convention at any time :
period: the collection periodstart_offset: the first collection will happen after this offset. It lets the JVM to load a representative set of Java modules.
<modules period="15m" start_offset="1m"/>
.
Threads
Threads are captured along with the deadlock information.
This is the equivalent of a “thread dump”.
Note that the Jeyzer Analyzer is also able to detect deadlocks.
<threads capture_deadlocks="true"/>
.
System data
System data is CPU and memory related :
<system> <system_cpu_load/> <free_physical_memory/> <total_physical_memory> </system>
.
Process
Process data is defined in the process block.
Standard process data is captured : CPU load, process up time, open file count (since Jeyzer 3.0), garbage collection and memory (see below dedicated sections for the last two).
<process> <process_cpu_load/> <process_up_time/> ... </process>
Process MX data can also be captured.
This is dynamic data (otherwise describe/capture it in the process card section).
MX object bean and attributes must be provided.
<process>
<mx_parameters
name="org.apache.activemq:type=Broker,brokerName=*"
attributes="MemoryPercentUsage,StorePercentUsage,TempPercentUsage">
...
</process>
Applicative data exposed through the Jeyzer Publisher are captured using the jeyzer_process_parameters
<process>
<jeyzer_process_parameters/>
...
</process>
.
Thread figures
Standard Java figures can be collected at thread level : CPU time, user time and allocated bytes.
<thread> <thread_cpu_time/> <thread_user_time> <thread_allocated_bytes> ... </thread>
Jeyzer Publisher figures can also be obtained when a Jeyzer context gets associated to a thread through the Jeyzer Publisher API. It deals with the user, the context id, the action name (= action principal), the action start time, the action id and the applicative parameters published for that action.
<thread> <jzr_thread_user/> <jzr_thread_context_id/> <jzr_thread_action/> <jzr_thread_action_start_time/> <jzr_thread_action_id/> <jzr_thread_parameters/> ... </thread>
.
Memory
The JVM memory parameters can be collected for the heap, non heap and the number of objects in pending finalization.
The heap and non_heap figures can be :
init: initial memory pool sizeused: currently used memory sizemax: maximum pool size. Will be below or equal to Xmx. Can fluctuate.committed: guaranteed memory size. Can fluctuate.
<memory>
<object_pending_finalization_count/>
<heap>
<usage>
<used/>
<max/>
</usage>
</heap>
<non_heap>
<usage>
<used/>
</usage>
</non_heap>
</memory>
.
Garbage collection
The garbage collector configuration defines the set of garbage collection figures to collect.
Usually, JVMs do use two garbage collectors : one for the young generation and one for the old generation memory zone.
Garbage collectors are JDK implementor dependent : the all_garbage_collectors_advanced_mx.xml file defines the exhaustive set of garbage collectors available (JDKs 5 to 11).
Garbage collector which are not available on the monitored JVM are ignored and therefore not dumped.
The default standard.xml recording profile is set to collect data from the PS Scavenge and PS MarkSweep garbage collectors.
Feel free to change it : the all_garbage_collectors_advanced_mx.xml located in the same directory contains all the possible garbage collector block fields.
For a garbage collector, it is possible to get the count of executions and total accumulated execution time. The last_gc_info is of interest to catch the memory pool sizes before and after the garbage collector execution as well as its last execution time (end_time).
<garbage_collectors>
<collector name="PS Scavenge">
<collection>
<count/>
<time/>
</collection>
<last_gc_info>
<end_time>
<before>
<pool name="PS Old Gen">
<usage>
<used/>
<max/>
</usage>
</pool>
...
<before>
</last_gc_info>
<collector>
...
</garbage_collectors>
.
Memory pools
The memory pool configuration defines the set of memory pool figures to collect.
The default standard.xml recording profile is set to collect data from the PS Old Gen and PS Eden Space memory zones.
Feel free to change it : the all_pools_advanced_mx.xml file defines the exhaustive set of pools available.
Memory pools which are not available on the monitored JVM are ignored and therefore not dumped.
Memory pool snapshots can be taken at different times:
peak: last memory peakusage: right nowcollection: right after the last garbage collection of this pool
For each of these times, the following figures can be obtained :
init: initial memory pool sizeused: currently used memory sizemax: maximum pool size. Will be below or equal to Xmx. Can fluctuate.committed: guaranteed memory size. Can fluctuate.threshold: not used (yet)
<memory_pools>
<pool name="PS Old Gen">
<peak>
<used/>
</peak>
<usage>
<used/>
<max/>
<committed/>
</usage>
<collection>
<used/>
</collection>
</pool>
...
</memory_pools>
.
Disk usage
The jeyzer_agent_recording_write_time permits to capture the disk write time of the last recording snapshot.
Only available in AdvancedMXAgent mode.
Value is usually very low and will take some meaning in case the process starts to slow down or if the disk controller gets into trouble.
Disk spaces
Disk spaces can be monitored in term of free_space, used_spaced and total_space.
Each one is identified by a name and points to a directory.
Like in any variable resolution, the directory can refer to Java standard directories such as the working directory user.dir.
Only available in AdvancedMXAgent mode.
<disk>
<jeyzer_agent_recording_write_time/>
<disk_spaces>
<disk_space name="work" directory="${user.dir}">
<free_space/>
<used_space/>
<total_space/>
</disk_space>
...
</disk_spaces>
</disk>