3.2 Physical infrastructure components

 < Day Day Up > 



3.2 Physical infrastructure components

As mentioned previously, all of the components of IBM Tivoli Monitoring for Transaction Performance share a common infrastructure based on the IBM WebSphere Application Server Version 5.0.1. This provides the TMTP product with a lot of flexibility. The TMTP Management Server is a J2EE application deployed onto the WebSphere Application Server platform. The installation of WebSphere and the deployment of the Management Server EAR are transparent to the installer. The Management Server provides the services and user interface needed for centralized management. Management agents are installed on computers across the environment. Management agents run discovery operations and collect performance data for monitored transactions. The Management Server and Management Agents may be deployed on the AIX®, Solaris, Windows, and xLinux platforms.

Another key feature of the IBM Tivoli Monitoring for Transaction Performance infrastructure is the application response measurement (ARM) engine. The ARM engine provides a set of interfaces that facilitate robust performance data collection.

The following sections describe the Management Server, Management Agents, and ARM in more detail.

The Management Server

The Management Server is shared by all IBM Tivoli Monitoring for Transaction Performance components and serves as the control center of your IBM Tivoli Monitoring for Transaction Performance installation. The Management Server collects information from, and provides services to, the Management Agents deployed in your environment. Management Server components are Java Management Extensions (JMX) MBeans.

Deployed as a standard WebSphere Version 5.0.1 EAR file, the Management Server provides the following functions:

  • User interface: You can access the user interface provided by the Management Server through a Web browser running Internet Explorer 6 or higher. From the user interface, you create and schedule the policies that instruct monitoring components to collect performance data. You also use the user interface to establish acceptable performance metrics, or thresholds, define notifications for threshold violations and recoveries, view reports, view system events, manage schedules, and perform other management tasks.

  • Real-time reports: Accessed through the user interface, real-time reports graphically display the performance data collected by the monitoring and playback components deployed in your environment. The reports enable you to quickly assess the performance and availability of your Web sites and Microsoft Windows applications.

  • Event system: The Management Server notifies you in real time of the status of the transactions you are monitoring. Application events are generated when performance thresholds exceed or fall below acceptable limits. System events are generated for system errors and notifications. From the user interface, you can view recently generated events at any time. You can also configure event severities and indicate the actions to be taken when events are generated.

  • Object model store for monitoring and playback policies: The object model store contains a set of database tables used to store policy information, events, and other information.

  • ARM data persistence: All of the performance data collected by Management Agents is sent using the ARM API. The Management Server keeps a persistent record of the ARM data collected by Management Agents for use in real-time and historical reports.

  • Communication with Management Agents: The Management Server uses Web services to communicate with the Management Agents in your environment.

Figure 3-3 gives an overview of the Management Server architecture.

click to expand
Figure 3-3: Management Server architecture

The Management Server components are JMX MBeans running on the MBeanServer provided by WebSphere Version 5.0.1. Communications between the Management Agents and the Management Server is via SOAP over HTTP or HTTPS (using a customized version of the Apache Axis 1.0 SOAP implementation) (see Figure 3-4). The services provided by the Management Server to the Management Agents are implemented as Web Services and invoked by the Management Agent using the Web Services Invocation Framework (WSIF). All downcalls from the Management Server to the Management Agent are remote MBean method invocations.

click to expand
Figure 3-4: Requests from Management Agent to Management Server via SOAP

Note 

The Management Sever application is a J2EE 1.3.1 application that is deployed as a standard EAR file (named tmtp52.ear). Some of the more important modules in the EAR file are:

  • Report and User Interface Web Module: ru_tmtp.war

  • Web Service Web Module: tmtp.war

  • Policy Manager EJB Module: pm_ejb.jar

  • User Interface Business Logic EJB Module: uiSessionModule.jar

  • Core Business Logic EJB Module: sessionModule.jar

  • Object Model EJB Module: entityModule.jar

ARM data is uploaded to the Management Server from Management Agents at regularly scheduled intervals (the upload interval). By default, the upload interval is once per hour.

The Management Agent

Management Agents are installed on computers across your environment. Based on Java Management Extensions (JMX), the Management Agent software provides the following functionality:

  • Listening and playback behaviors: A Management Agent can have any or all of the listening and playback components installed. The components associated with a Management Agent run policies at scheduled times. The Management Agent sends any events generated during a listening or playback operation to the Management Server, where event information is made available in event views and reports.

  • ARM engine for data collection: A Management Agent uses the ARM API to collect performance data. Each of the listening and playback components is instrumented to retrieve the data using ARM standards.

  • Policy management: When a discovery, listening, or playback policy is created, an agent group is assigned to run the policy. You define agent groups to include one or more Management Agents that are equipped to run the same policy. For example, if you want to monitor the performance of a consumer banking application that runs on several WebSphere application servers, each of which is associated with a Management Agent and a J2EE monitoring component, you can create an agent group named All J2EE Servers. All of the Management Agents in the group can run a J2EE listening policy that you create to monitor the banking application.

  • Threshold setting: Management agents are capable of conducting a range of sophisticated threshold setting operations. You can set basic performance thresholds that generate events and send notification when a transaction exceeds or falls below an acceptable performance time. Other thresholds monitor for the existence of HTTP response codes or specified page content, or watch for transaction failure. In many cases, you can specify thresholds for the subtransactions of a transaction. A subtransaction is one step in the overall transaction.

    click to expand
    Figure 3-5: Management Agent JMX architecture

  • Event support: Management agents send component events to the Management Server. A component event is generated when a specified performance constraint is exceeded or violated during a listening or playback operation. In addition to sending an event to the Management Server, a Management Agent can send e-mail notification to specified recipients, run a specified script, or forward selected event types to the Tivoli Enterprise Console or the simple network management protocol (SNMP).

  • Communication with the Management Server: Management Agents communicate with the Management Server using Web services and the secure socket layer (SSL). Every 15 minutes, all Management Agents poll the Management Server for any new policy information (known as the polling interval).

  • Store and Forward: Store and Forward can be implemented on one or more Management Agents in your environment (typically only one) to handle firewall situations. Store and Forward performs the following firewall-related tasks in your environment:

    • Enables point-to-point connections between Management Agents and the Management Server

    • Enables Management Agents to interact with Store and Forward as if Store and Forward were a Management Server

    • Routes requests and responses to the correct target

    • Supports SSL communications

    • Supports one-way communications through the firewall

All applications, such as STI, QoS, and J2EE, are registered as MBeans, as are all services used by the Management Agent and Server, for example, Scheduler, Monitoring engine, Bulk Data Transfer, and the Policy Manager service.

The Application Response Measurement Engine

When you install and configure a Management Agent in your environment, the Application Response Measurement (ARM) Engine is automatically installed as part of the Management Agent. The engine and ARM API comply with the ARM 2.0 specification. The ARM specification was developed in order to meet the challenge of tracking performance through complex, distributed computing networks. ARM provides a way for business applications to pass information about the subtransactions they initiate in response to service requests that flow across a network. This information can be used to calculate response times, identify subtransactions, and provide additional data to help you determine the cause of performance problems. Some of the specific details of how ARM is utilized by TMTP are discussed in the next section.

Figure 3-6 gives an overview of how the ARM Engine communicates with the Monitoring Engine.

click to expand
Figure 3-6: ARM Engine communication with Monitoring Engine

All transaction data collected by the Quality of Service, J2EE, STI, and Generic Windows monitoring components of TMTP is collected by the ARM functionality. The use of ARM results in the following capabilities:

  • Data aggregation and correlation: ARM provides the ability to average all of the response times collected by a policy, a process known as aggregation. Response times are aggregated once per hour. Aggregate data gives you a view into the overall performance of a transaction during a given one-hour period. Correlation is the process of tracking hierarchical relationships among transactions and associating transactions with their nested subtransactions. When you know the parent-child relationships among transactions and the response times for each transaction, you are much better able to determine which transactions are delaying other transactions. You can then take steps to improve the response times of services or transactions that contribute the most to slow performance.

  • Instance and aggregate data collection: When a policy collects performance data, the collected data is written to disk. Because Management Agents are equipped with ARM functionality, you can specify that aggregate data only be written to disk (to conserve system resources and view fewer data points) or that both aggregate and instance data be written to disk. Aggregate data is an average of all response times detected by a policy over a one-hour period, whereas instance data consists of response times that are collected every time the transaction is detected. TMTP will normally collect only aggregate data unless instance data collection was specified in the listening policy.

    TMTP will also automatically collect instance data if a transaction breaches specified thresholds. This second feature of TMTP is very useful, as it means that TMTP does not have to keep redundant instance data, yet has relevant instance data should a transaction problem be recognized.



 < 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