WebLogic JDBC Test
This test collects measures related to JDBC pools created on the WebLogic server.
Target of the test : A WebLogic Application Server
Agent deploying the test : An internal agent
Outputs of the test : One set of results for each connection pool used by a WebLogic application server.
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 |
The port at which the specified host listens. By default, this is NULL. |
UseWarFile |
This flag indicates whether/not monitoring is to be done using a Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS is used by the server to connect to the server). If this flag is set to No, the agent directly connects to the WebLogic server using the T3 protocol (no other file needs to be deployed on the WebLogic server for this to work). Note that the T3 protocol-based support is available for WebLogic servers ver.9 and above. Also, if the UseWarFile parameter is set to No, make sure that the EncryptPass parameter is set to No as well. When monitoring a WebLogic server deployed on a Unix platform particularly, if the UseWarFile parameter is set to No, you have to make sure that the eG agent install user is added to the WebLogic users group. |
AdminServerHost and AdminServerPort |
In some highly secured environments, the eG agent may not be able to collect certain critical metrics related to JDBC from a managed WebLogic server. In such cases, to enable the eG agent to collect the required metrics, you should specify the IP address and Port of the WebLogic admin server to which the managed WebLogic server is associated with. This will enable the eG agent to connect to the WebLogic admin server and collect the required metrics pertaining to the managed WebLogic server. Specify the IP address and Port of the WebLogic admin server in the AdminServerHost and AdminServerPort text boxes. By default, these parameters are set to none. |
JSPTimeOut |
Specify the duration (in seconds) within which the eG agent should receive the response from the eGurkha WAR file deployed on the WebLogic server in this text box. By default, this is set to is 120 seconds. |
SNMPPort |
The port number on which the WebLogic server is exposing its SNMP MIB (relevant to WebLogic server 5.1 only). For version 6.0 and above, enter “none” in this text box. |
SNMPVersion |
By default, the eG agent supports SNMP version 1. Accordingly, the default selection in the SNMPversion list is v1. However, if a different SNMP framework is in use in your environment, say SNMP v2 or v3, then select the corresponding option from this list. |
SNMPCommunity |
The SNMP community name that the test uses to communicate with the firewall. This parameter is specific to SNMP v1 and v2 only. Therefore, if the SNMPVersion chosen is v3, then this parameter will not appear. |
UserName |
This parameter appears only when v3 is selected as the SNMPVersion. SNMP version 3 (SNMPv3) is an extensible SNMP Framework which supplements the SNMPv2 Framework, by additionally supporting message security, access control, and remote SNMP configuration capabilities. To extract performance statistics from the MIB using the highly secure SNMP v3 protocol, the eG agent has to be configured with the required access privileges – in other words, the eG agent should connect to the MIB using the credentials of a user with access permissions to be MIB. Therefore, specify the name of such a user against this parameter. |
Context |
This parameter appears only when v3 is selected as the SNMPVersion. An SNMP context is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context and an SNMP entity potentially has access to many contexts. A context is identified by the SNMPEngineID value of the entity hosting the management information (also called a contextEngineID) and a context name that identifies the specific context (also called a contextName). If the Username provided is associated with a context name, then the eG agent will be able to poll the MIB and collect metrics only if it is configured with the context name as well. In such cases therefore, specify the context name of the Username in the Context text box. By default, this parameter is set to none. |
AuthPass |
Specify the password that corresponds to the above-mentioned Username. This parameter once again appears only if the SNMPVersion selected is v3. |
Confirm Password |
Confirm the AuthPass by retyping it here. |
AuthType |
This parameter too appears only if v3 is selected as the SNMPversion. From the AuthType list box, choose the authentication algorithm using which SNMP v3 converts the specified username and password into a 32-bit format to ensure security of SNMP transactions. You can choose between the following options:
|
EncryptFlag |
This flag appears only when v3 is selected as the SNMPVersion. By default, the eG agent does not encrypt SNMP requests. Accordingly, the this flag is set to No by default. To ensure that SNMP requests sent by the eG agent are encrypted, select the Yes option. |
EncryptType |
If the EncryptFlag is set to Yes, then you will have to mention the encryption type by selecting an option from the EncryptType list. SNMP v3 supports the following encryption types:
|
EncryptPassword |
Specify the encryption password here. |
Confirm Password |
Confirm the encryption password by retyping it here. |
User |
The admin user name of the WebLogic server being monitored. |
Password |
The password of the specified admin user. |
Confirm Password |
Confirm the password by retyping it here. |
Timeout |
Specify the duration (in seconds) within which the SNMP query executed by this test should time out in this text box. The default is 10 seconds. |
Data Over TCP |
By default, in an IT environment, all data transmission occurs over UDP. Some environments however, may be specifically configured to offload a fraction of the data traffic – for instance, certain types of data traffic or traffic pertaining to specific components – to other protocols like TCP, so as to prevent UDP overloads. In such environments, you can instruct the eG agent to conduct the SNMP data traffic related to the monitored target over TCP (and not UDP). For this, set this flag to Yes. By default, this flag is set to No. |
Engine ID |
This parameter appears only when v3 is selected as the SNMPVersion. Sometimes, the test may not report metrics when AES192 or AES256 is chosen as the Encryption type. To ensure that the test report metrics consistently, administrators need to set this flag to Yes. By default, this parameter is set to No. |
EncryptPass |
If the specified password needs to be encrypted, set the EncryptPass flag to Yes. Otherwise, set it to No. By default, the Yes option will be selected. Note: If the UseWarFile flag is set to No, then make sure that the EncryptPass flag is also set to No. |
SSL |
Indicate whether the SSL (Secured Socket Layer) is to be used to connect to the WebLogic server. |
Server |
The name of the specific server instance to be monitored for a WebLogic server (the default value is "localhome") |
URL |
The URL to be accessed to collect metrics pertaining to the WebLogic server. By default, this test connects to a managed WebLogic server and attempts to obtain the metrics of interest by accessing the local Mbeans of the server. This parameter can be changed to a value of http://<adminserverIP>:<adminserverPort>. In this case, the test connects to the WebLogic admin server to collect metrics pertaining to the managed server (specified by the Host and Port). The URL setting provides the administrator with the flexibility of determining the WebLogic monitoring configuration to use. Note: If the admin server is to be used for collecting measures for all the managed WebLogic servers, then it is mandatory that the egurkha war file is deployed to the admin server, and it is up and running. |
Version |
The Version text box indicates the version of the Weblogic server to be managed. The default value is "none", in which case the test auto-discovers the weblogic version. If the value of this parameter is not "none", the test uses the value provided (e.g., 7.0) as the weblogic version (i.e., it does not auto-discover the weblogic server version). This parameter has been added to address cases when the eG agent is not able to discover the WebLogic server version. |
WebLogicJARLocation |
Specify the location of the WebLogic server's java archive (Jar) file. If the UseWarFile flag is set to No, then the weblogic.jar file specified here is used to connect to the corresponding WebLogic server using the T3 protocol. Note that the T3 protocol-based support is available for WebLogic servers ver.9 and above. |
Use JMX |
|
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Pool availability |
The current state of a database connection pool – whether it is available or not |
Percent |
A value of 100 denotes that the pool is available; a value of 0 denotes unavailability. |
Percent of connections used |
Percentage of database connection allocated to a connection pool that are in use |
Percent |
When this value reaches 100%, connections to the database will either have to wait for access or will time out. Consider increasing the size of the connection pool in this case. A very high percentage of use can also result if one or more of the applications that use the connection pool are not releasing the connections after their use. |
Max capacity |
The maximum number of connections configured for a JDBC connection pool |
Number |
|
Active connections current |
The number of connections currently in use for a JDBC connection pool
|
Number |
|
Waiting for connections |
The number of requests for connections to the database that are currently pending |
Number |
A high value of pending connections is indicative of a bottleneck during database access. Reasons for this could either be that the connection pool capacity is insufficient, or that the database server has slowed down, causing requests to take longer to execute their queries. |
Active connections max |
The high water mark of active connections in a pool |
Number |
Note the changes in the high water mark. This can give you an idea about the times when the JDBC pool was most heavily used. |
Waiting for connections max |
The high water mark of number of waiters for a connection from the pool |
Number |
Note the changes in the high water mark. This indicates periods when the database connection pool could have been a bottleneck. |
Connections added to pool |
The number of JDBC connections added to the pool in the last measurement period |
Number |
|
Leaked connections |
The number of connections tagged as a leaked connection during the last measurement period. A leaked connection is a connection that was checked out from the connection pool but was not returned to the pool by calling close(). |
Number |
A non-zero value indicates that the application may not be releasing connections after use. This can result in inefficient management of the database connections in the pool. |
Failures to reconnect |
The number of cases during the last measurement period when a connection pool attempted to refresh a connection to the database and failed. |
Number |
Failures could happen if the database is unavailable, or, the connection was terminated. |
Connection delay time |
Avg. time taken to get a connection from the database (in seconds) |
Secs |
An increase in this metric could indicate a bottleneck in the database tier. |
Max wait to get connection |
The high water mark of the time a thread had to wait in order to get a connection from the pool |
Secs |
|