3.3 Key technologies utilized by WTP

 < Day Day Up > 



3.3 Key technologies utilized by WTP

This section describes some of the technologies used in this release of TMTP and elaborates on some of the changes introduced to how some previously implemented technologies are utilized.

3.3.1 ARM

The Application Response Measurement (ARM) API is the key technology utilized by TMTP to capture transaction performance information. The ARM standard describes a common method for integrating enterprise applications as manageable entities. It allows users to extend their enterprise management tools directly to applications, creating a comprehensive end-to-end management capability that includes measuring application availability, application performance, application usage, and end-to-end transaction response time. The ARM API defines a small set of functions that can be used to instrument an application in order to identify the start and stop of important transactions. TMTP provides an ARM engine in order to collect the data from ARM instrumented applications.

The ARM standard has been utilized by several releases of TMTP, so it will not be discussed in great depth here. If the reader wishes to explore ARM in detail, the authors recommend the following Redbooks, as well as the ARM standard documents maintained by the Open Source Group (available at http://www.opengroup.org):

  • Introducing Tivoli Application Performance Management, SG24-5508

  • Tivoli Application Performance Management Version 2.0 and Beyond, SG24-6048

  • Unveil Your e-business Transaction Performance with IBM TMTP 5.1, SG24-6912

The TMTP ARM engine is a multithreaded application implemented as the tapmagent (tapmagent.exe on Windows based platforms). The ARM engine exchanges data though an IPC channel, using the libarm library (libarm32.dll on Windows based platforms), with ARM instrumented applications. The data collected is then aggregated in order to generate useful information, correlated with other transactions, and thresholds are measured based upon user requirements. This information is then rolled up to the Management Server and placed into the database for reporting purposes.

The majority of the changes to the ARM Engine pertain to measurement of transactions. In the TMTP 5.1 version of the ARM Engine, each and every transaction was measured for either aggregate information or instance data. In this version of this component, the Engine will be notified as to which transactions need to be measured. This is done via new APIs to the ARM Engine that allows callers to identify transactions, either explicitly or as a pattern. Measurement can be defined for "edge" transactions, which will result in response measurement of the edge and all its subtransactions.

Another large change in the functionality of the ARM Engine is monitoring for threshold violations of a given transaction. Once a transaction is defined to be measured by the ARM Engine, it can also be defined to be monitored for threshold violations. A threshold violation is defined in this release of this component to be completing the transaction (i.e. arm_stop) and having a unsuccessful return code or having a duration greater than a MAX threshold or less than a MIN threshold.

The ARM Engine will also communicate with the Monitoring Engine to inform it of transaction violations, new edge transactions appearing, and edge transaction status changes.

ARM correlation

ARM correlation is the method by which parent transactions are mapped to their respective child transactions across multiple processes and multiple servers.

This release of the TMTP WTP component provides far greater automatic support for the ARM correlator. Each of the components of WTP is automatically ARM instrumented and will generate a correlator. The initial root/parent or "edge" transaction will be the only transaction that does not have a parent correlator. From there, WTP can automatically connect parent correlators with child correlators in order to trace the path of a distributed transaction through the infrastructure and provides the mechanisms to easily visualize this via the topology views. This is a great step forward from previous versions of TMTP, where it was possible to generate the correlator, but the visualization was not an automatic process and could be quite difficult.

click to expand
Figure 3-7: Transaction performance visualization

TMTP Version 5.2 implements the following ARM correlation mechanisms:

  1. Parent based aggregation

    Probably the single largest change to the current ARM aggregation agent is the implementation of parent based correlation. This enables transaction performance data to be collected based on the parent of a subtransaction. This allows the displaying of transaction performance relative to its path. The purpose served by this is the ability to monitor the connection points between transactions. It also enables path based transaction performance monitoring across farms of servers all providing the same functionality. The correlator generation mechanism will pass parent identification within the correlator to enable this to occur.

  2. Policy based correlators

    Another change for the correlator is that a portion of the correlator is used to pass a unique policy identifier within the correlator. The associated policy will control the amount of data being collected and also the thresholds associated with that data. In this model, a user specifies the amount of data collection for the different systems being monitored. Users do not need to know the actual path taken by a transaction and can accept the defaults in order to achieve an acceptable level of monitoring. For specific transactions, users can create unique policies that provide a finer level of control over the monitoring of those transactions. An example would be the decision to enable subtransaction collection of all methods within WebSphere, as opposed to the default of collecting only Servlet, EJB, JMS, and JDBC.

  3. Instance and aggregated performance statistics

    Users have come to expect support for the collection of instance performance data. This provides both additional metrics and a complete and exact trace of the path taken by a specific transaction. The TMTP 5.1 ARM agent implementation was designed to provide an either/or model where all statistics are collected as instance or aggregate, regardless of the specific transaction being monitored. Support is provided by TMTP Version 5.2 for collecting both instance and aggregate at the same time. All ARM calls contain metrics, regardless of the users request to store instance data. This occurs because the application instrumentation is unaware of any configuration selections made at higher levels. In the past, the ARM agent, when collecting aggregated data, would normally discard the metric data provided to it. This has been changed so that any ARM call that becomes the MAX for a given aggregation period will have its metrics stored and maintained. This functionality enables a user to view the context (metrics) associated with the worst performing transaction for a given time period. It is important to note (see parent based aggregation) that the term "worst performing" is specific to each subtransaction individually and not the overall performance of the parent transaction. However, the MAX for each subtransaction within a given transaction will store its context uniquely, allowing for the presentation of the complete transaction, including the context of each subtransaction performing at its own worst level.

  4. Parent Performance Initiated Trace

    The trace flag within the ARM correlator is utilized by the agent (x'80' in the trace field) for transactions that are performing outside of their threshold. This provides for the dynamic collection of instance data across all systems where this transaction executes. The ARM agent at the transaction initiating point enables this flag when providing a correlator for a transaction that has performed slower then its specified threshold. To limit the overall performance impact of this tracing, this flag is only generated once for each transaction threshold crossing. Trace will continue to be enabled for this transaction for up to five consecutive times unless transaction performance recedes below threshold. This should enable the tracing of instance data for a violating transaction without user intervention, while allowing for aggregated collection of data at all other times. For the unique cases where these violations are not caught via this mechanism, it is expected that a user will change the monitoring policy for this transaction to be an instance in order to ensure the capture of an offending transaction. Given that each MAX transaction (and subtransaction) will already have instance metrics, the benefits of this will be seen in the collection of subtransactions that were normally not being traced. The last statement is due to the fact that a monitoring policy may preclude the collection of all subtransactions within WebSphere (and possibly other applications) from occurring during normal monitoring. To enable a complete breakdown of the transaction, all instrumentation agents collect all data when the trace flag is present.

  5. Sibling transaction ordering

    Sibling transaction ordering is the ability to determine the order of execution of a set of child transactions relative to each other. However, when ordering sibling transactions from data collected across multiple systems, the information gathered may not be entirely correct because of time synchronization issues. In case the system clocks on all the machines involved are not synchronized, the recorded data may show sibling transaction ordering sequences that are not entirely correct. This will not affect the overall flow of the transaction, only the presentation of the ordering of child transactions in situations where the child transactions execute on different systems. The recommendation is to synchronize the system clocks if you are concerned about the presentation of sibling transaction ordering.

This release of TMTP adds the notion of aggregated correlation. Aggregated correlation will provide aggregate information (that is, does not create a record for each and every instance of a transaction, but a summary of a transaction over a period of time). Instead of a singular transaction being aggregated, correlation will be used. Previous versions of TMTP only allowed correlation at the instance level, which could be an intensive process.

The logging of transactions will usually start out as aggregated correlation. There may be times when a registered measurement entry will be provided to the ARM Engine that will ask for instance logging, or the ARM Engine itself may turn on instance logging in the event of a threshold violation.

There are essentially three ways TMTP treats aggregated correlation:

  1. Edge aggregation by pattern

  2. Edge aggregation by transaction name (edge discovery mode)

  3. Aggregation by root/parent/transaction

For edge aggregation by pattern, we essentially have one aggregator per edge policy that all transactions that match that edge policy pattern will be aggregated against.

For edge aggregation by transaction name, we essentially have a unique aggregator for each transaction name that matches this policy's edge pattern. This is what we deem discovery mode, because in this situation, we will be "discovering" all the edges that match the specified edge pattern. When in discovery mode, TMTP always generates a correlator with the TMTP_Flags ignore flag set to true to signal that we do not want to process subtransactions.

For all non-edge aggregation, we will be performing correlated aggregation. What this means is each transaction instance will be directed to a specific aggregator based upon correlation using the following four properties:

  1. Origin host UUID

  2. Root transID

  3. Parent transID

  4. Transaction classID

By providing this correlation information in the aggregation, you are better able to see the aggregation information in respect to the code flow of the transactions that have run.

Every hour, on the hour, this information will be sent to an outboard file for upload to the Management Server Database.

How are correlators passed from one component to the next?

Each component of TMTP passes the correlator it has generated to each of its subtransactions using Java RMI over IIOP. Java RMI over IIOP combines Java Remote Method Invocation (RMI) technology with Internet Inter-Orb Protocol (IIOP - CORBA technology) and allows developers to pass any serialized Java object (Objects By Value) between application components.

Transactions entering the J2EE Application Server may already have a correlator associated, which has been generated because the transaction is being monitored by one of the other TMTP components, such as QoS, STI, J2EE instrumentation on another J2EE Application Server, or Rational/Genwin. If no correlator exists when a transaction enters the J2EE Application Server, the server:

  • Requests a correlator from ARM.

  • If no policy matches, J2EE does not get a correlator.

  • Subtransactions can detect their parent correlator.

  • If no correlator, performance data is not collected.

  • If correlator, performance data is logged.

In summary

This version of TMTP uses parent based aggregation where subtransactions are chained together based on correlators, allowing TMTP to generate the call stack (transaction path). The aggregation is policy based, which means that information is only collected for transactions that match the defined policy. Additionally, TMTP will dynamically collect instance data (as opposed to aggregated data) based on threshold violations. TMTP also allows child subtransactions to be ordered based on start times.

3.3.2 J2EE instrumentation

In this section we describe one of the key enhancements included with the release of TMTP Version 5.2: its ability to do J2EE monitoring at the subtransaction level without the use of manual instrumentation.

The problem

There are many applications written in J2EE that are hosted on various different J2EE application servers at varying version levels. A J2EE transaction can be made up of many components, for example, JSPs, Servlets, EJBs, JDBC, and so on. This level of complexity makes it hard to identify if there is a problem and where that problem lies. We need a mechanism for finding the component that is causing the problem.

J2EE support provided by TMTP 5.1

In TMTP 5.1, the ETP component could collect ARM data generated by applications on WebSphere servers that had IBM WebSphere Application Server Version 5.0 installed. This data was provided by the WebSphere Request Metrics facility.

This was a start, but only limited detail was provided, such as the number of servlets and number of EJBs. The ETP component could supplement this data by collecting ARM data independently of the STI Player and the STI player could trigger the collection of ARM data on its behalf.

ETP then uploaded all the ARM data from all the transactions within an application that have been configured in WebSphere. The administrator could turn data collection on or off at the application level.

These capabilities solved some business problems, but led to the need for greater control and granularity, as well as the need for greater scope.

J2EE support provided by TMTP Version 5.2

TMTP Version 5.2 provides enhanced J2EE instrumentation capabilities. The collection of ARM data generated by J2EE applications is invoked from the new Management Server, not from ETP. The ARM collection is controlled by user configured policies that are created on the Management Server. The process of creating appropriate J2EE discovery and listening policies is described in Chapter 8, "Measuring e-business transaction response times" on page 225. The monitoring policy is then distributed to the Management Agent.

Which transactions to monitor are specified using edge definitions, for example, the first URI invoked when utilizing the application, and it is possible to define the level of monitoring for each edge.

In order to monitor a J2EE Application Server, the machine must be running the TMTP Agent. A single TMTP agent can monitor multiple J2EE Application Servers on the Management Agent's host.

TMTP Version 5.2 provides J2EE monitoring for the following J2EE Application Servers:

  • WebSphere Application Server 4.0.3 Enterprise Edition and later

  • BEA WebLogic 7.0.1

TMTP's J2EE monitoring is provided by Just In Time Instrumentation (JITI). JITI allows TMTP to manage J2EE applications that do not provide system management instrumentation by injecting probes at class-load time, that is, no application source code is required or modified in order to perform monitoring. This is a key differentiator between TMTP and other products, which can require large changes to application source code. Additionally, the probes can easily be turned on and off as required. This is an important difference, which means that the additional transaction decomposition can be turned on only when required. It is important that this capability is available as though TMTP has low overheads (all performance monitoring has some overhead; the more monitoring you do the greater the overhead). The fact that J2EE monitoring can be easily enabled and disabled based on a policy request from the user is a powerful feature.

Just In Time Instrumentation explained

As discussed above, one of the key changes introduced by this release of ITM for TP is the introduction of Just In Time Instrumentation (hereafter referred to as JITI). JITI builds on the performance "listening" capabilities provided in previous versions by the QoS component to allow detailed performance data to be collected for J2EE (Java 2 Platform Enterprise Edition) applications without requiring manual instrumentation of the application.

How it works

With the release of JDK 1.2, Sun included a profiling mechanism within the JVM. This mechanism provided an API that could be used to build profilers called JVMPI, or Java Virtual Machine Profiling Interface. The JVMPI is a bidirectional interface between a Java virtual machine and an in-process profiler agent. JITI uses the JVMPI and works with un-instrumented applications.

The JVM can notify the profiler agent of various events, corresponding to, for example, heap allocation, thread start, and so on. Or the profiler agent can issue controls and requests for more information through the JVMPI, for example, the profiler agent can turn on/off a specific event notification, based on the needs of the profiler front end.

As shown by Figure 3-8 on page 75, JITI starts when the application classes are loaded by the JVM (for example, the WebSphere Application Server). The Injector alters the Java methods and constructors specified in the registry by injecting special byte-codes in the in-memory application class files. These byte-codes include invocations to hook methods that contain the logic to manage the execution of the probes. When a hook is executed, it gets the list of probes currently enabled for its location from the registry and executes them.

click to expand
Figure 3-8: Tivoli Just-in-Time Instrumentation overview

TMTP Version 5.2 bundles JITI probes for:

  • Servlets (also includes Filters, JSPs)

  • Entity Beans

  • Session Beans

  • JMS

  • JDBC

  • RMI-IIOP

JITI combined with the other mechanisms included with TMTP Version 5.2 allow you to reconstruct and follow the path of the entire J2EE transaction through the enterprise.

TMTP J2EE monitoring collects instance level metric data at numerous locations along the transaction path. Servlet Metric Data includes URI, querystring, parameters, remote host, remote user, and so on. EJB Metric Data includes primary key, EJB type (stateful, stateless, and entity), and so on. JDBC Metric Data includes SQL statement, remote database host, and so on.

JITI probes make ARM calls and generates correlators in order to allow subtransactions to be correlated with their parent transactions.

The primary or root transaction is the transaction that has no parent correlator and indicates the first contact of the transaction with TMTP. Each transaction monitored with TMTP gets its own correlator, as does each subtransaction. When a subtransaction is started, ARM can link it with its parent transaction based on the correlators and so on down the tree. With the correlator information, ARM can build the call tree for the entire transaction.

If a transaction crosses J2EE Application Servers on multiple hosts, the ARM data can be captured by installing the Management Agent on each of the hosts. Only the host that registers the root transaction need have a J2EE Listening Policy.

TMTP Version 5.2 J2EE monitoring summarized
  • JITI provides the ability to monitor the fine details of any J2EE applications. It does this by dynamically inserting probes at run time.

  • There is no need to re-run a command after deploying a new application.

  • You can view a transaction path in Topology.

  • It is easy to discover the root cause of a performance problem.

  • You can discover new transactions you were not aware of in your environment.

  • You can dynamically configure tracing details.

  • You can run monitoring at a low trace level during normal operation.

  • You can increase to a high tracing level after a problem is detected.



 < Day Day Up > 



End-to-End E-business Transaction Management Made Easy
End-To-End E-Business Transaction Management Made Easy
ISBN: 0738499323
EAN: 2147483647
Year: 2003
Pages: 105
Authors: IBM Redbooks

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net