Tests Disabled by Default for a Tomcat Server
To enable one/more of these tests, open the agents – tests configuration page using the Agents -> Tests -> Configure menu sequence, select Tomcat from the Component type list, scroll down the test list that appears to view the disabled tests section, select the check box corresponding to the JVM test of interest to you, and then, click the Update button. These tests have been discussed below.
Java Business Transactions Test
The responsiveness of a transaction is the key determinant of user experience with that transaction; if response time increases, user experience deteriorates. To make users happy, a Java business transaction should be rapidly processed by each of the JVM nodes in its path. Processing bottlenecks on a single JVM node can slowdown/stall an entire business transaction or can cause serious transaction errors. This in turn can badly scar the experience of users. To avoid this, administrators should promptly identify slow/stalled/errored transactions, isolate the JVM node on which the slowness/error occurred, and uncover what caused the aberration on that node – is it owing to SQL queries executed by the node? Or is it because of external calls – eg., async calls, SAP JCO calls, HTTP calls, etc. - made by that node? The Java Business Transactions test helps with this!
This test runs on a BTM-enabled JVM in an IT infrastructure, tracks all the transaction requests received by that JVM, and groups requests based on user-configured pattern specifications. For each transaction pattern, the test then computes and reports the average time taken by that JVM node to respond to the transaction requests of that pattern. In the process, the test identifies the slow/stalled transactions of that pattern, and reports the count of such transactions and their responsiveness. Detailed diagnostics provided by the test accurately pinpoint the exact transaction URLs that are slow/stalled, the total round-trip time of each transaction, and also indicate when such transaction requests were received by that node. The slowest transaction in the group can thus be identified.
For this test to run and report metrics on Tomcat, you first need to BTM-enable the Tomcat JVM. To know how, refer to the
Then, proceed to configure this test. Refer to the
JVM Details Test
This reveals the health of the Tomcat class loaders and daemon threads, and also indicates JVM availability.
Target of the test : A Tomcat Server
Agent deploying the test : An internal agent
Outputs of the test : One set of results for the Tomcat server being monitored.
Parameter | Description |
---|---|
Test Period |
How often should the test be executed. |
Host |
The IP address of the host for which this test is to be configured. |
Port |
Refers to the port at which the specified host listens to. |
Measurement Mode |
This test can extract metrics from Tomcat using either of the following mechanisms:
To configure the test to use egtomcat.war file, first select the War file option. Then, refer to the How Does eG Enterprise Monitor Tomcat Servers? to know how to deploy the WAR file on the target Tomcat server. On the other hand, if you want the test to use JMX instead, then first, select the JMX option. Then, follow the procedure detailed in the How Does eG Enterprise Monitor Tomcat Servers? to configure the test to use jmx. By default, the JMX option is chosen here. |
JMX Remote Port |
This parameter appears only if the Measurement Mode is set to JMX. Here, specify the port at which the JMX listens for requests from remote hosts. Ensure that you specify the same port that you configured in the catalina.sh (or catalina.bat) file in the <CATALINA_HOME_DIR>/bin folder of the target Tomcat server (refer to the How Does eG Enterprise Monitor Tomcat Servers? for more details). |
JMX User, JMX Password, and Confirm Password |
These parameters appear only if the Measurement Mode is set to JMX. If JMX equires authentication only (but no security), then ensure that the JMX User and JMX Password parameters are configured with the credentials of a user with read-write access to JMX. To know how to create this user, refer to the How Does eG Enterprise Monitor Tomcat Servers?. Confirm the password by retyping it in the Confirm Password text box. |
JNDIName |
This parameter appears only if the Measurement Mode is set to JMX. The JNDIName is a lookup name for connecting to the JMX connector. By default, this is jmxrmi. If you have registered the JMX connector in the RMI registery using a different lookup name, then you can change this default value to reflect the same. |
JMX Provider |
This parameter appears only if the Measurement Mode is set to JMX. This test uses a JMX Provider to access the MBean attributes of the target Java application and collect metrics. Specify the package name of this JMX Provider here. By default, this is set to com.sun.jmx.remote.protocol. |
SSL |
This parameter appears only if the Measurement Mode is set to War File. Indicate Yes if the Tomcat server is SSL-enabled. |
URL |
This parameter appears only if the Measurement Mode is set to War File. Specify the URL of the managed Tomcat server to enable the test to connect to it and extract measures from it. The URL specification should be of the format: http://{TomcatIP}:{TomcatPort}. |
UserName, Password, and Confirm Password |
These parameters appear only if the Measurement Mode is set to War File. In the UserName text box, specify a name of a user who has been assigned the Manager role on the Tomcat server to be monitored; these users are typically allowed to control web applications deployed on the Tomcat server. Specify the Password of this user, and confirm the password by retyping it in the Confirm Password text box. |
EncryptPass |
This parameter appears only if the measurement modeis set to War File. Select Yes if you want to encrypt the password. |
Timeout |
Specify the duration (in seconds) for which this test should wait for a response from Tomcat. If there is no response from Tomcat beyond the configured duration, the test will timeout. By default, this is set to 240 seconds. |
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Total classes loaded |
Refers to the total number of classes that have been loaded since the Java virtual machine started execution. |
Number |
|
Classes loaded |
Indicates the number of classes that have been loaded in the Java virtual machine since the last measurement period. |
Number |
Classes are fundamental to the design of Java programming language. Like many server applications, Tomcat installs a variety of class loaders (that is, classes that implement java.lang.ClassLoader) to allow different portions of the container, and the web applications running on the container, to have access to different repositories of available classes and resources. A consistent decrease in the number of classes loaded and unloaded could indicate a road-block in the loading/unloading of classes by the class loader. If left unchecked, critical resources/classes could be rendered inaccessible to web applications, thereby severely affecting application performance. |
Classes unloaded |
Indicates the total number of classes that have been unloaded in the Java virtual machine since the last measurement period. |
Number |
|
Total daemon threads |
Indicates the current number of live daemon threads. |
Number |
The main function of the daemon threads is to provide service to other threads, running in the same process as the daemon thread. If the value of this measure is equal to that of the Live_threads measure, then JVM would stop executing; in other words, when the only remaining threads are the daemon threads, then JVM shuts down and so does Tomcat. |
Live threads |
Indicates the current number of live daemon and non-daemon threads. |
Number |
|
Deadlock threads |
The current number of deadlock threads |
Number |
Ideally, the value of this measure should be 0. A non-zero value indicates the occurrence of a deadlock. When a thread attempts to acquire a resource that is already locked by another thread, a deadlock situation arises. |
Server uptime |
The uptime of Java virtual machine |
Mins |
To ensure that the JVM is up and running for a long time, you need to make sure that at least one non-daemon thread is executing at all times. This is because, without any non-daemon threads, the daemon threads have no recipients for the service it provides; it hence brings down both the JVM and Tomcat. |
Tomcat JVM Garbage Collection Test
Manual memory management is time consuming, and error prone. Most programs still contain leaks. This is all doubly true with programs using exception-handling and/or threads. Garbage collection (GC) is a part of Tomcat's JVM that automatically determines what memory a program is no longer using, and recycles it for other use. It is also known as "automatic storage (or memory) reclamation''. This test reports the performance statistics pertaining to the JVM's garbage collection.
Target of the test : A Tomcat Server
Agent deploying the test : An internal agent
Outputs of the test : One set of results for the Tomcat server being monitored.
Parameter | Description |
---|---|
Test Period |
How often should the test be executed. |
Host |
The IP address of the host for which this test is to be configured. |
Port |
Refers to the port at which the specified host listens to. |
Measurement Mode |
This test can extract metrics from Tomcat using either of the following mechanisms:
To configure the test to use egtomcat.war file, first select the War file option. Then, refer to the How Does eG Enterprise Monitor Tomcat Servers? to know how to deploy the WAR file on the target Tomcat server. On the other hand, if you want the test to use JMX instead, then first, select the JMX option. Then, follow the procedure detailed in the How Does eG Enterprise Monitor Tomcat Servers? to configure the test to use jmx. By default, the JMX option is chosen here. |
JMX Remote Port |
This parameter appears only if the Measurement Mode is set to JMX. Here, specify the port at which the JMX listens for requests from remote hosts. Ensure that you specify the same port that you configured in the catalina.sh (or catalina.bat) file in the <CATALINA_HOME_DIR>/bin folder of the target Tomcat server (refer to the How Does eG Enterprise Monitor Tomcat Servers? for more details). |
JMX User, JMX Password, and Confirm Password |
These parameters appear only if the Measurement Mode is set to JMX. If JMX equires authentication only (but no security), then ensure that the JMX User and JMX Password parameters are configured with the credentials of a user with read-write access to JMX. To know how to create this user, refer to the How Does eG Enterprise Monitor Tomcat Servers?. Confirm the password by retyping it in the Confirm Password text box. |
JNDIName |
This parameter appears only if the Measurement Mode is set to JMX. The JNDIName is a lookup name for connecting to the JMX connector. By default, this is jmxrmi. If you have registered the JMX connector in the RMI registery using a different lookup name, then you can change this default value to reflect the same. |
JMX Provider |
This parameter appears only if the Measurement Mode is set to JMX. This test uses a JMX Provider to access the MBean attributes of the target Java application and collect metrics. Specify the package name of this JMX Provider here. By default, this is set to com.sun.jmx.remote.protocol. |
SSL |
This parameter appears only if the Measurement Mode is set to War File. Indicate Yes if the Tomcat server is SSL-enabled. |
URL |
This parameter appears only if the Measurement Mode is set to War File. Specify the URL of the managed Tomcat server to enable the test to connect to it and extract measures from it. The URL specification should be of the format: http://{TomcatIP}:{TomcatPort}. |
UserName, Password, and Confirm Password |
These parameters appear only if the Measurement Mode is set to War File. In the UserName text box, specify a name of a user who has been assigned the Manager role on the Tomcat server to be monitored; these users are typically allowed to control web applications deployed on the Tomcat server. Specify the Password of this user, and confirm the password by retyping it in the Confirm Password text box. |
EncryptPass |
This parameter appears only if the measurement modeis set to War File. Select Yes if you want to encrypt the password. |
Timeout |
Specify the duration (in seconds) for which this test should wait for a response from Tomcat. If there is no response from Tomcat beyond the configured duration, the test will timeout. By default, this is set to 240 seconds. |
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
No of collections |
Indicates the number of garbage collections that were performed by the JVM since the last measurement period. |
Number |
If adequate memory is not allotted to the JVM, then the value of this measure would be very high. A high value of this measure is indicative of a high frequency of GC. This is not a good sign, as GC, during its execution, has the tendency of reducing the performance for applications, and a high frequency of GC would only adversely impact the application's performance. To avoid this, it is recommended that you allot sufficient memory to the JVM. |
Time taken |
Indicates the time taken for GC execution, since the last measurement period. |
Secs |
A shorter GC execution time is desired to avoid issues in application performance and database connection bottlenecks. |
Elapsed time |
Indicates the percentage of time spent on GC execution. |
Percent |
By carefully examining the application behavior in terms of memory utilization, you should arrive at an optimal ratio of the number of times the GC needs to run and how long it should take to complete. Accordingly, you can fine-tune the GC activity. |
JVM Memory Test
The memory system of the Java Virtual machines manages two types of memory, which are Heap and Non Heap. To define Heap, the Java virtual machine is a heap that is the runtime data area from which memory for all class instances and arrays are allocated. It is created at the Java Virtual Machine start-up and the memory for the objects is reclaimed by an automatic memory management systems known as Garbage collector. The Heap may be of fixed size or may be expanded and shrunk.
The Java virtual machine has a method area that is shared among all threads. This method area is called non heap. It stores per class structures such as runtime constant pool field and method data, and the code for methods and constructors. It is created at the Java Virtual Machine start up.
In order to ensure the uninterrupted functioning of the Tomcat server, sufficient memory resources need to be made available to the JVM memory pools. Inadequacies in memory allocations could lead to slow start up issues or intermittent application failures. This test periodically reports usage statistics of the JVM memory pools, so that memory bottlenecks are promptly detected and resolved.
Target of the test : A Tomcat Server
Agent deploying the test : An internal agent
Outputs of the test : One set of results for the Tomcat server being monitored.
Parameter | Description |
---|---|
Test Period |
How often should the test be executed. |
Host |
The IP address of the host for which this test is to be configured. |
Port |
Refers to the port at which the specified host listens to. |
Measurement Mode |
This test can extract metrics from Tomcat using either of the following mechanisms:
To configure the test to use egtomcat.war file, first select the War file option. Then, refer to the How Does eG Enterprise Monitor Tomcat Servers? to know how to deploy the WAR file on the target Tomcat server. On the other hand, if you want the test to use JMX instead, then first, select the JMX option. Then, follow the procedure detailed in the How Does eG Enterprise Monitor Tomcat Servers? to configure the test to use jmx. By default, the JMX option is chosen here. |
JMX Remote Port |
This parameter appears only if the Measurement Mode is set to JMX. Here, specify the port at which the JMX listens for requests from remote hosts. Ensure that you specify the same port that you configured in the catalina.sh (or catalina.bat) file in the <CATALINA_HOME_DIR>/bin folder of the target Tomcat server (refer to the How Does eG Enterprise Monitor Tomcat Servers? for more details). |
JMX User, JMX Password, and Confirm Password |
These parameters appear only if the Measurement Mode is set to JMX. If JMX equires authentication only (but no security), then ensure that the JMX User and JMX Password parameters are configured with the credentials of a user with read-write access to JMX. To know how to create this user, refer to the How Does eG Enterprise Monitor Tomcat Servers?. Confirm the password by retyping it in the Confirm Password text box. |
JNDIName |
This parameter appears only if the Measurement Mode is set to JMX. The JNDIName is a lookup name for connecting to the JMX connector. By default, this is jmxrmi. If you have registered the JMX connector in the RMI registery using a different lookup name, then you can change this default value to reflect the same. |
JMX Provider |
This parameter appears only if the Measurement Mode is set to JMX. This test uses a JMX Provider to access the MBean attributes of the target Java application and collect metrics. Specify the package name of this JMX Provider here. By default, this is set to com.sun.jmx.remote.protocol. |
SSL |
This parameter appears only if the Measurement Mode is set to War File. Indicate Yes if the Tomcat server is SSL-enabled. |
URL |
This parameter appears only if the Measurement Mode is set to War File. Specify the URL of the managed Tomcat server to enable the test to connect to it and extract measures from it. The URL specification should be of the format: http://{TomcatIP}:{TomcatPort}. |
UserName, Password, and Confirm Password |
These parameters appear only if the Measurement Mode is set to War File. In the UserName text box, specify a name of a user who has been assigned the Manager role on the Tomcat server to be monitored; these users are typically allowed to control web applications deployed on the Tomcat server. Specify the Password of this user, and confirm the password by retyping it in the Confirm Password text box. |
EncryptPass |
This parameter appears only if the measurement modeis set to War File. Select Yes if you want to encrypt the password. |
Timeout |
Specify the duration (in seconds) for which this test should wait for a response from Tomcat. If there is no response from Tomcat beyond the configured duration, the test will timeout. By default, this is set to 240 seconds. |
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Used |
Indicates the amount of memory currently in use. |
MB |
|
Free |
Indicates the amount of unused memory currently available in a server. |
MB |
Ideally, this value should be high. An unusually low value for the available memory can indicate a memory bottleneck. Check the memory utilization of individual processes to figure out the process(es) that has (have) maximum memory consumption and look to tune their memory usages and allocations accordingly. |
Initial |
Indicates the initial amount of memory that Java virtual machine requests from the operating system (OS) for memory management during startup. |
MB |
An unusually high usage of memory by the Java Virtual machine from the OS is a cause of concern. Further analysis is required to determine if specific applications or queries are consuming excess memory. |
Pending objects |
Indicates the number of objects in the heap/non-heap memory for which finalization is pending. |
Number |
Finalization allows an object to gracefully clean up after itself when it is being collected. When the garbage collector detects that an object is garbage, the garbage collector calls the object's Finalize method (if it exists) and then the object's memory is reclaimed - in other words, the garbage collector frees the memory allocated to the object. This measure is available only for the Heap_Memory and Nonheap_Memory descriptors of this test. A high value for this measure indicates that a chunk of heap / non-heap memory (as the case may be) in the JVM is awaiting reclamation. Object finalization facilitates efficient memory re-use, and thus ensures that the JVM memory pools do not run out of memory. If the value of this measure grows continuously, it could imply that objects are not releasing the memory resources properly. This in turn could be because the Finalize method does not exist for some objects, or there could be a bottleneck in the invocation of the method. Either way, thorough investigation can only provide pointers to the source of the problem. |