Other protocols monitoring - RMI

In the RMI (Remote Method Invocation) section you set parameters specific to monitoring RMI-based software services.

General

The general RMI monitoring configuration comprises selecting and defining the source monitoring data.

NAM Server Data

Enable this option if you wish to include the NAM Server report server data in your RMI analysis.

ADS Data

Select if you wish to, disable ADS report server data, include only the ADS data, or if you wish to include the ADS data with the hit details.

Last packet session timeout

Define the timeout for the last packet session in seconds.

Availability

By configuring the availability, you can determine which attempt failures are included in the availability metric calculation.

The availability is measured and presented as the percentage of successful attempts (operations) compared to all attempts. Each attempt is counted in one metric: operation, standalone, abort, network failure, transport failure or application failure. All operations with availability problems are included in the Failures (transport) and Failures (application) metrics.

In RMI availability reporting, for each failure category, you can control the error classification by enabling or disabling options available in the list next to each of the available transport and application errors:

Failures (transport)

You can determine which of the incomplete response errors should be included in the calculation of Failures (transport) metric.

Incomplete responses

You can determine whether the following types of incomplete responses should be classified as failures (transport).

Partial response (standalone hit)

An incomplete response observed for a hit without an operation context, classified as a Dead hit. This pertains to situations when server started the response but never finished due to a timeout or other problems.

Aborted response (standalone hit)

An incomplete response observed for a hit without an operation context, classified as a Break. This pertains to situations when server started the response but aborted it before completion with TCP reset.

No response

A request hit with no response from a server. This pertains to situations when server did not respond at all or responded in unrecognizable way.

Partial response

An incomplete response with a Dead hit status. This pertains to situations when server started the response but never finished due to a timeout or other problems.

Aborted response

An incomplete response with a Break status. This pertains to situations when server started the response but aborted it before completion with the TCP reset.

Failures (application)

Enable or disable the automatically detected operation attributes to individually select which sets of operation attributes are included in the calculation of Failures (application) . The following operation attributes are available:

  • Fatal error
  • Error indicator
  • Operation attributes (3)
  • Operation attributes (4)
  • Operation attributes (5)

Fault Domain Isolation

Use the following threshold settings to accurately identify the true source of the problem:

Server time threshold
The Server time threshold relates to the server time portion of an overall operation time. Server times above the threshold limit are considered to be slow due to poor datacenter performance.

Idle time threshold
Threshold for the time during the operation execution when there is no network or server activity related to the operation. It is assumed that Idle time is caused by the user's software not sending requests because user's PC is busy.

Network time threshold
Threshold for the time the network (between the user and the server) takes to deliver requests to the server and to deliver page information back to the user. In other words, Network time is the portion of transaction time that is due to the delivery time on the network.

Retransmissions threshold
Percentage of retransmissions regarding all observed transmissions.

Network time affected by high retransmission threshold
Percentage of the network time affected by high retransmission threshold.

Request size threshold Threshold for the request where anything larger would be considered big request.

Network time affected by the transfer of a big request threshold
Threshold for the request where anything larger would be considered big request.

Response size threshold
Threshold for the response where anything larger would be considered big response.

Network time affected by the transfer of a big response threshold Threshold for the network time that is affected by the transfer of a big response threshold.

Number of hits threshold
Threshold for the number subcomponents of error-free operations or transactions.

Single hit duration threshold
Threshold for a hit duration as a percentage of operation time.

Rtt threshold
Threshold for the time it takes for a SYN packet to travel from the client to a monitored server and back again.

Monitoring performance of RMI and IIOP calls

NAM is capable of monitoring the selected implementation of RMI and IIOP.

NAM provides the analyzers to monitor the following implementation of the Java Remote Method Invocation:

  • JBoss
  • BEA Weblogic T3
  • Sun RMI

Additionally, there is also the Corba analyzer used to monitor the communication over the IIOP protocol.

All these analyzers are a specific implementation of the Simple Parser analyzer and provide similar set of monitoring capabilities and configuration options. The key difference is that unlike Simple Parser monitoring, they do not require special scripts to monitor the calls. For more information, see Using Universal Decode to monitor TCP-based protocols.

These analyzers allow you to monitor the method invocation timings without instrumenting the application. It refers to RMI objects and methods, and CORBA published function names in the server-server or client-server communication. The provided measurements make it possible to monitor and report performance, response times and errors.

Reporting

You can see the RMI and CORBA related measurements in the RMI and CORBA Data Center Tiers, as well as particular analyzer software service, either user defined or autodiscovered. The reports give insight into specific objects on which specific methods were called, together with accompanying parameters and their values.

JBoss RMI analyzer requires an additional configuration step to report the method names in human readable format. For more information, see Mapping RMI methods to readable names.

Limitations

Limitations include:

  • No message encryption support
  • JBoss monitoring requires also Sun RMI software service defined in parallel to JBoss software service. Two software services are needed to enable Java Bean name recognition and reporting. In the other words, Sun RMI and JBoss decodes should be configured in parallel on the same server (and different pets, respective to the Sun RMI and JBoss protocols).
  • A high number of unique operation names with detailed parameter values may increase the NAM Server load.
  • User name identification on the RMI tier. It may be a technical user, not necessarily the end user.

Mapping RMI methods to readable names

The JBoss RMI and Sun RMI analyzers report the performance of RMI calls. Traffic does not contain actual names of the called methods and classes, instead only hashcodes are available. To see the readable names on the NAM Server reports, you need to create a dictionary file with the mapping between the hashcodes and the method names.

You need to create the dictionary file on the system where the monitored application is installed using the Dynatrace provided Java utility. You have to upload the result file to the NAM Console using the dialog available in the Options tab in a Software Service rules configuration window.

  1. Copy the Java dictionary utility. Unzip and copy the Java utility provided by Dynatrace (hashGenerator.jar) to the machine where the monitored applications is installed. Either server or client.
    • Download: hashGenerator.zip
    • Sourcecode: hashGeneratorSrc.zip
  2. Run the utility. Execute the following command:
    java -jar hashGenerator.jar -type=[jboss | sun] -dir=<input_directory> -out=<dictionary_file_name>
    
    where: input_directory is the directory in which the monitored application is installed together with its jar or class file.
    disctionary_file_name is the result dictionary file.
    type - with the type option you control whether you wan to create a dictionary for JBoss RMI or Sun RMI. For example:
    java -jar hashGenerator.jar -type=jboss -dir=/var/local/myApp/Interface.class -out=interface.txt
          
    
  3. Upload the dictionary to the NAM Console. Create or edit an existing JBoss RMI software service configuration. Open the Edit Rule dialog and upload the dictionary using the form in the Options tab.