The Application Transactions Layer
The tests mapped to this layer monitor transactions to Java applications deployed on Tomcat. The overall health, responsiveness, and user experience with these transactions are monitored, and the under-performing / error-prone transactions are accurately pinpointed.
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
HTTP Response Status Test
HTTP response status codes are issued by a server hosting a web site/application in response to a client's request for a business transaction. For some of these transaction requests, the server may return error responses - for eg., HTTP response code 4xx is returned if a request contains bad syntax. It is important to identify such transactions quickly, figure out why the error response was returned, and initiate corrective measures, so that user experience with the web site/application remains unaffected. This is where the HTTP Response Status test thelps!
Using this test, eG Java BTM automatically categorizes business transactions to a target web site/application based on HTTP response status codes. The codes monitored by default are as follows:
-
100 – 199 = Informational responses
-
200 -299 = Success responses
-
300 – 399 = Redirection responses
-
400 – 499 = Client errors
-
500 – 599 = Server errors
For each HTTP response-based transaction group, the test then reports the count of transactions for which the corresponding response status was returned. In the process, the test alerts administrators to transactions that return HTTP error responses. The detailed diagnostics point administrators to the precise transaction requests for which the error responses were returned by the server. By rapidly pinpointing problem transactions and the HTTP error they encountered, the test saves time and labor involved in troubleshooting the errors.
Target of the Test : A BTM-enabled JVM
Agent deploying the test : An internal/remote agent
Output of the test : One set of results is reported for each default and user-configured (if any) HTTP status code range that is configured for monitoring. For the All Responses descriptor, metrics are aggregated across all HTTP response codes.
Test parameters:
| Parameter | Description |
|---|---|
|
Test Period |
How often should the test be executed. |
|
Host |
The host for which this test is to be configured. |
|
Port |
Specify the port at which the specified Host listens |
|
Specific Status Code List |
As mentioned already, this test monitors the following status code patterns by default: 1xx, 2xx, 3xx, 4xx, and 5xx. This is why, the Specific Status Code List is set to none by default. Sometimes however, application developers may custom-define new HTTP response codes to suit the needs of the application and its users. If the target application is associated with such codes, then you can configure this test to monitor these custom codes as well by providing a comma-separated list of these codes here - eg., 700,805,901 |
|
Max Per Status Code DD List |
By default, for each status code, the detailed diagnosis of this test reports the top-10 transactions that returned a response of that code, starting with the oldest transaction. If the eG database in your environment is well-tuned and has space enough to store more number of transactions, then you may want detailed diagnostics to report more than 10 transactions. In this case, you can increase the value of this parameter. On the other hand, if you do not want to strain your eG database by adding more transaction records to it, then, you can choose to view less number of transactions as part of detailed diagnosis. For this, specify a number than less than 10 here. |
|
DD Frequency |
Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD frequency. |
|
Detailed Diagnosis |
To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:
|
| Measurement | Description | Measurement Unit | Interpretation |
|---|---|---|---|
|
Request processed |
Indicates the number of transaction requests that returned this HTTP response code during the last measurement period. For the All responses descriptor, this measure will report the total number of transaction requests that were processed by the target web site/application during the last measurement period, regardless of their HTTP response code. |
Number |
Compare the value of this measure across HTTP response codes to know if error transactions were more than informational / successful transactions. If so, then user experience with the target web application is bound to be sub-par. Use the detailed diagnosis of this measure to know which transactions returned this HTTP response code. |
|
Requests processed per minute |
Indicates the number of transaction requests that returned this HTTP response per minute. For the All responses descriptor, this measure will report the total number of transaction requests that the target web site/application processed per minute , regardless of their HTTP response code. |
Number |
Compare the value of this measure across HTTP response codes to determine if transactions returned error responses frequently. This is a cause for concern. |
|
Error page redirections |
Indicates the number of transaction requests with this HTTP response, which were redirected to error pages during the last measurement period. For the All responses descriptor, this measure will report the total number of transaction requests that were redirected to error pages during the last measurement period, regardless of the HTTP response code of the transactions. |
Number |
Ideally, the value of this measure should be low. |
|
Status 2xx |
Indicates the percentage of transactions requests that returned HTTP response codes of the range 200-299. |
Percent |
HTTP response codes of the range 200-299 represent successful responses. Such a response implies that the request was successfully received, understood, and accepted. A high value of this measure is hence desired. This measure is reported only for the All responses descriptor. |
|
Status 3xx |
Indicates the percentage of transactions requests that returned HTTP response codes of the range 300-399. |
Percent |
HTTP response codes of the range 300-399 represent redirection responses. Such a response implies that further action needs to be taken in order to complete the request. Ideally, the value of this measure should be low. This measure is reported only for the All responses descriptor. |
|
Status 4xx |
Indicates the percentage of transactions requests that returned HTTP response codes of the range 400-499. |
Percent |
HTTP response codes of the range 400-499 represent client errors. Such a response implies that the request contains bad syntax or cannot be fulfilled. Ideally, the value of this measure should be low. This measure is reported only for the All responses descriptor. |
|
Status 5xx |
Indicates the percentage of transactions requests that returned HTTP response codes of the range 500-599. |
Percent |
HTTP response codes of the range 500-599 represent server errors. Such a response implies that the server failed to fulfill an apparently valid request. Ideally, the value of this measure should be low. This measure is reported only for the All responses descriptor.
|
Code Exceptions Test
In Java “an event that occurs during the execution of a program that disrupts the normal flow of instructions” is called an exception. This is generally an unexpected or unwanted event which can occur either at compile-time or run-time in application code. Java application developers often struggle to detect and manage the 'run-time' exceptions, as its difficult to predict when they will occur. Most commonly, such exceptions may occur when specific transactions are performed on the target Java application. If such transactions are not promptly captured, then application developers may not be able to determine where in the application code the corresponding exceptions need to be handled or how to handle them. As a result, the transactions will continue to throw the Java exceptions, thereby impacting user experience with the target application. To avoid this, it is important to quickly identify which transactions throw Java exceptions. This is where the Code Exceptions test helps!
This test automatically groups business transactions to a target application based on run-time Java exceptions that eG BTM detects in them. For each such exception-based transaction group, the test then reports the count of transactions in which those exceptions were observed. In the process, the test sheds light on those Java exceptions that have affected the maximum number of transactions. The detailed diagnosis of the test (if enabled) reveals which transactions were affected by which Java exceptions.
Target of the Test : A BTM-enabled JVM
Agent deploying the test : An internal/remote agent
Output of the test : One set of results is reported for each type of Java exception captured in business transactions. For the Summary descriptor, metrics are aggregated across all Java exceptions.
Test parameters:
| Parameter | Description |
|---|---|
|
Test Period |
How often should the test be executed. |
|
Host |
The host for which this test is to be configured. |
|
Port |
Specify the port at which the specified Host listens |
|
DD Frequency |
Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD frequency. |
|
Detailed Diagnosis |
To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:
|
| Measurement | Description | Measurement Unit | Interpretation |
|---|---|---|---|
|
Exceptions |
Indicates the number of transactions that encountered this Java exception during the last measurement period. For the Summary descriptor, this indicates the total number of transactions that encountered Java exceptions during the last measurement period, regardless of the exception type. |
Number |
Compare the value of this measure across Java exceptions to identify the exception that has affected the performance of the maximum number of transactions. Use the detailed diagnosis of this measure to know which transactions were affected by Java exceptions of this type. |
|
Exceptions per minute |
Indicates the number of transactions that encountered this Java exception per minute. For the Summary descriptor, this measure will report the total number of transactions per minute that threw Java exceptions, regardless of the exception type. |
Number |
Compare the value of this measure across Java exceptions to determine which type of exception was frequently encountered by the target application. |
|
Unique exceptions |
Indicates how many distinct types of exceptions occurred during the last measurement period. |
Number |
This measure is reported only for the Summary descriptor. |
|
Exception percentage |
Indicates the percentage of transactions that encountered this Java exception during the last measurement period. For the Summary descriptor, this measure will report the percentage of total transactions that encountered Java exceptions, regardless of the exception type. |
Number |
Compare the value of this measure across Java exceptions to determine which type of exception affected a majority of the transactions. |
Note:
By default, the detailed diagnosis of this test only reveals which business transactions were affected by a specific type of Java exception. However, it does not reveal what is the cause of that exception. To obtain useful root-cause analytics from the detailed diagnosis of this test, edit the btmOthers.props file available on the eG BTM-enabled JVM, and toggle the following flags in it:
-
CAPTURE_CAUSE_OF_EXCEPTION: By default, this flag is disabled. Set this flag to true, if you want the detailed diagnosis of the test to reveal the Java exception that is the immediate cause of the exception in question. In other words, if the Java exception in question occurred soon after and as a result of another exception in the same transaction, then setting this flag to true will display that parent transaction in the detailed diagnosis.
-
ENABLE ROOT CAUSE EXCEPTION TRACKINGand MAX_EXCEPTION_CAUSE_DEPTH: A single Java exception in a transaction may sometimes trigger one or more child exceptions in the same transaction. In such situations, knowing which Java exception is the 'source' of all child exceptions, including the exception in question, will help application developers figure out how to handle that exception in code. In such cases, the exception captured at source is treated as the 'parent' of all the child exceptions it spawns, and is hence deemed to be the root-cause of the exceptions. By default, the ENABLE ROOT CAUSE EXCEPTION TRACKING flag is set to false, indicating that by default, the detailed diagnosis of this test does not reveal the 'root-cause' of the Java exception. If this flag is set to true, then detailed diagnosis will enable you to trace down a transaction stack to hierarchically view a specific number of parent Java exceptions that had occurred in that transaction, before the monitored exception occurred. By default, this specific number is 10. Accordingly, the MAX_EXCEPTION_CAUSE_DEPTH parameter is set to 10 by default. You can increase the value of this parameter, so you can view more parent Java exceptions in the detailed diagnosis and perform root-cause analytics effectively. For instance, if this value is set to 20, then the detailed diagnosis of the test will trace back from the exception in question to display 20 parent Java exceptions that occurred before it.
