Management of Service-Oriented Architecture â€” IBM Tivoli SOA

Management of Service-Oriented Architecture — IBM Tivoli SOA Management SuiteWhite PaperJ B BakerDarrell ReimerSam SpiroJohn Whitfield

June 2005

Copyright NoticeCopyright © 2005 IBM Corporation, including this documentation and all software. All rights reserved. May only be used pursuant to a Tivoli Systems Software License Agreement, an IBM Soft-ware License Agreement, or Addendum for Tivoli Products to IBM Customer or License Agreement. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without prior written permission of IBM Corpora-tion. IBM Corporation grants you limited permission to make hardcopy or other reproductions of any machine-readable documentation for your own use, provided that each such reproduction shall carry the IBM Corporation copyright notice. No other rights under copyright are granted without prior writ-ten permission of IBM Corporation. The document is not intended for production and is furnished “as is” without warranty of any kind. All warranties on this document are hereby disclaimed, including the warranties of merchantability and fitness for a particular purpose.Note to U.S. Government Users—Documentation related to restricted rights—Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation.

TrademarksThe following are trademarks of IBM Corporation or Tivoli Systems Inc.: IBM, Tivoli, AIX, Cross-Site, NetView, OS/2, Planet Tivoli, RS/6000, Tivoli Certified, Tivoli Enterprise, Tivoli Ready, TME. In Den-mark, Tivoli is a trademark licensed from Kjøbenhavns Sommer - Tivoli A/S.Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.UNIX is a registered trademark of The Open Group in the United States and other countries.C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both.Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.Lotus is a registered trademark of Lotus Development Corporation.PC Direct is a trademark of Ziff Communications Company in the United States, other countries, or both and is used by IBM Corporation under license.ActionMedia, LANDesk, MMX, Pentium, and ProShare are trademarks of Intel Corporation in the United States, other countries, or both.SET and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. For fur-ther information, see http://www.setco.org/aboutmark.html.Other company, product, and service names may be trademarks or service marks of others.

NoticesReferences in this publication to Tivoli Systems or IBM products, programs, or services do not imply that they will be available in all countries in which Tivoli Systems or IBM operates. Any reference to these products, programs, or services is not intended to imply that only Tivoli Systems or IBM prod-ucts, programs, or services can be used. Subject to valid intellectual property or other legally pro-tectable right of Tivoli Systems or IBM, any functionally equivalent product, program, or service can be used instead of the referenced product, program, or service. The evaluation and verification of operation in conjunction with other products, except those expressly designated by Tivoli Systems or IBM, are the responsibility of the user. Tivoli Systems or IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, New York 10504-1785, U.S.A.Printed in Ireland.

• • • ••

I

Table of Contents

White Paper Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3Management Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6Middleware Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9Transaction Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11Alerts and Corrective Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12Management Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13Installing and Configuring Tivoli Monitoring for Transaction Performance . . . . . . . . . . . . . . . . 1-17

Configuring the Database on DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20Installing and Configuring IBM Tivoli OMEGAMON XE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-40Creating SOA Workspaces in CandleNet Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-51

SOA Workspace Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-69Creating Situations in Tivoli OMEGAMON XE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-76Configuring Tivoli Monitoring for Transaction Performance to Send Events to the Tivoli Enterprise

Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-83

II Management of Service-Oriented Architecture — IBM Tivoli SOA Management Suite ©Copyright IBM Corp. 2005

• • • ••

Table of Contents

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

• • • ••

1

White Paper

Introduction

The IBM® Tivoli® Service Oriented Architectures (SOA) are being positioned by IBM and other vendors as a way to improve business agility and reduce costs by using formally defined software interfaces to increase the re-usability of software, overcome technology-driven barriers among internal and external organizations, and lower integration costs. Where SOA is an architectural approach to building applications, the Enterprise Service Bus (ESB) is a best practice for building a scalable and manageable infrastructure on which the SOA applications are deployed. Services can be orchestrated using a process choreography engine that adds an additional level of complexity to monitoring, management, debugging, and analysis.

Services management manages the elements that are deployed in the services architecture as discrete resources regardless of their implementation. While services management addresses many of the traditional problems of integrating disparate business processes and applications, deploying service-oriented applications introduces new complexities that must be managed.

The major features of services management include the following:

• Discovers all key elements of the services architecture, including discovering new service interfaces and identifying the relationships of those services to other services, the IT infrastructure, and business processes.

• Monitors the services layer against Service Level Agreements (SLAs). Performance and availability data collected can also be used to help define an SLA and provide problem identification.

• Respects and enforces management policies for the architectural elements of services management.

• Controls the services management through configuration and operations.

• Provides notifications to the management application when states change or problems occur.

• Provides services security.

• Manages the life cycle of services in production, facilitating the graceful introduction and deprecation of services, including versioning capabilities.

• Provides root-cause analysis and problem resolution based on errors at the services layer.

2 Management of Service-Oriented Architecture — IBM Tivoli SOA Management Suite ©Copyright IBM Corp. 2005

• • • ••

White Paper


• Transforms and routes messages based on message content and context, as well as policy (usually in support of SLA or version management).

• Tracks the business impact of services on the business processes that Web Services support.

• Manages the IT infrastructure that supports the services, associating problems in the infrastructure with the manifestation of problems at the service layer.

This paper describes how to apply the products in the Tivoli SOA Management Suite to satisfy a significant number of the management requirements. As additional function is added to the products and new products are introduced, the complete set of management requirements are addressed. The Tivoli SOA Management Suite consists of the following products:

• IBM Tivoli OMEGAMON® XE for Distributed Systems

• IBM Tivoli OMEGAMON DE for Distributed Systems

• IBM Tivoli OMEGAMON XE for WebSphere Application Server

• IBM Tivoli OMEGAMON XE for WebSphere Business Integration

• IBM Tivoli Monitoring for Transaction Performance

• IBM Tivoli Enterprise Console®

• IBM Tivoli Monitoring for Web Services (PRPQ)

©Copyright IBM Corp. 2005 Management of Service-Oriented Architecture — IBM Tivoli SOA Management Suite 3

• • •••

White Paper


Environment

The IBM Redbook title Patterns: Implementing an SOA Using an Enterprise Service Bus (www.redbooks.ibm.com) guides you through the process of implementing an Enterprise Service Bus using current IBM technologies. The Web Services Interoperability Organization (WS-I) has developed a supply chain management (SCM) business scenario and sample application to demonstrate features of the WS-I Basic Profile 1.0. The Redbook implements the WS-I SCM application in the context of a number of different ESB patterns, such as the Bus Router variation and the Broker variation. This paper augments that work by addressing the topic of systems management using the sample application and scenarios in the IBM Redbook and applying the management capabilities in the Tivoli SOA Management Suite Solution Bundle. Refer to the Redbook for specific details of the sample application and configuration of the environment.

The business application scenario used in the Redbook is a manufacturing supply chain system, shown in the illustration, used by end-users to buy electronic goods. The retail component obtains stock from the warehouse that in turn replenishes the stock from the manufacturers. Given the increased competition, growing mergers and acquisitions trends among suppliers, and the growing complexity of managing multiple applications and communications infrastructures, the business is looking at an SOA solution to help provide faster response to business changes and reduced costs.

Based on the business requirements, an SOA implementation pattern can be chosen; when a single warehouse is involved, the Bus Router pattern is appropriate because there are no requirements for data aggregation. The selected pattern can then be applied to the business scenario in conjunction with the customer’s technology choices to generate a system


• • • ••

White Paper


diagram. The chosen technology in this case is WebSphere® Application Server v5.1.1 with the Web Services Gateway.

When multiple warehouses are involved, an order from a customer must be broken up into multiple requests to different warehouses. The Broker variation is the appropriate technology choice because the broker has the ability to break a request into multiple requests and aggregate the result to form a single response to the requester.


• • •••

White Paper



• • • ••

White Paper


Systems Management Perspective

Management Environment

The previous section of this document introduced two different ESB implementations based on the WS-I supply chain application. In this section, the previous examples are augmented with the management capabilities of the Tivoli SOA Management Suite. The products in the solution bundle include the agent, management server, and management console components that are introduced into the environment. At this point, the general structure of how these components are introduced and the capabilities they provide is covered. Detailed installation and configuration is covered in Systems Management Quick-Start Guides.

Agent components run on each of the systems that support the application environment and collect statistics, performance metrics, error notifications, and perform corrective actions under the direction of the management server. In the Bus Router scenario, where all the managed systems are WebSphere based servers, the following agents are installed on each server supporting the environment as shown in the illustration.

• IBM Tivoli OMEGAMON XE for Distributed System agent

• IBM Tivoli OMEGAMON XE for WebSphere Application Server agent

• IBM Tivoli Monitoring for Transaction Performance agent with the J2EE component

• IBM Tivoli Monitoring for Web Services PRPQ agent


• • •••

White Paper


Two management servers are used in the environment, with one hosting the Tivoli OMEGAMON XE CandleNet Portal® Server and Candle Management Server component and the other hosting the Tivoli Monitoring for Transaction Performance Management server. The consoles for Tivoli OMEGAMON XE and Tivoli Monitoring for Transaction Performance are both Web consoles and are run on one server, along with the Tivoli Monitoring for Web Services viewer.

The Broker scenario as shown in the illustration introduces WebSphere WBI Message Broker and WebSphere MQ as the main ESB infrastructure. This results in the following different agent composition:

• IBM Tivoli OMEGAMON XE for Distributed System Agent

• IBM Tivoli OMEGAMON XE for WBI Agent (Message Broker and MQ)


• • • ••

White Paper



• • •••

White Paper


Middleware Monitoring

Two levels of middleware monitoring are provided in the Tivoli SOA Management Suite. The first is basic health monitoring that provides a high level at-a-glance view of the well-being of the major components of the system. Basic health monitoring essentially provides a dashboard for the environment. The second is a comprehensive view of the middleware components and is used to isolate and diagnose problems in the environment. Comprehensive monitoring is also a key source of alert and event information that is discussed in more detail in Alert and Corrective Actions.

Basic health monitoring is implemented by selecting a set of key metrics that give an accurate representation of each component’s ability to perform real work. A customized presentation, using Tivoli OMEGAMON XE, shows the metrics for the environment on one window to provide the at-a-glance view. For example, a simple retail scenario includes a point of sale terminal, a transaction log service, and a back-end database. Typical metrics include the average response time for simulated transactions sent to the transaction log service and the average response time for a query run against the back-end database. These two metrics, along with metrics for other parts of the overall environment are combined on one status window. The screen capture below shows an example of a Basic Health workspace.

Comprehensive monitoring of the middleware component is also provided by the Tivoli OMEGAMON XE family of monitoring products shown in the screen captures on the following page and Tivoli Monitoring for Transaction Performance. Tivoli OMEGAMON


• • • ••

White Paper


XE provides the ability to monitor key attributes of the managed resources and generate events when they vary from defined settings. Customized Tivoli OMEGAMON XE situations and monitoring workspaces, as well as IBM Tivoli Monitoring for Transaction Performance listening and discovery policies, are identified for each scenario.


• • •••

White Paper


Transaction Performance

The IBM Tivoli Monitoring for Transaction Performance product captures detailed performance data for all system transactions. The software monitors every step of a transaction as it passes through the complex array of hosts, systems, and applications: Web and proxy servers, Web application servers, database management systems, and applications. For the WS-I Supply Chain application, Tivoli Monitoring for Transaction Performance analyzes the transactions starting with the user accessing a Web browser site catalog and shopping cart. When the user makes a purchase, the Web application makes a Web service call to the retail system to submit the order. The retail system then makes a Web Services call to the warehouse to fulfill the order and the warehouse can make calls to manufacturers to order additional stock. The WS-I transactions discovered by TMTP are shown in the following image.


• • • ••

White Paper


Alerts and Corrective Actions

Events, indicating error situations, are generated in the system by both the base monitoring capabilities, as well as Common Event Infrastructure (CEI) business events encoded into the business process. Base monitoring events are generated by the situations deployed in Tivoli OMEGAMON XE and by Tivoli Monitoring for Transaction Performance, based on the thresholds established in the listening policies. Tivoli OMEGAMON XE situations can be changed and created in the Situation Editor shown in the image. Additional information on working with situations is provided in Creating Situations in Tivoli OMEGAMON XE. The image shows how events can be sent to the Tivoli Enterprise Console for correlation and corrective action.


• • •••

White Paper


Management Scenario

A failure scenario is used to illustrate how the products in the Tivoli SOA Management Suite can be used to effectively manage an ESB based environment.

An application on the computer that supports the warehouse service has an error that causes it to loop and consume large amounts of CPU time. This is brought to the attention of the operator either by the Tivoli OMEGAMON XE situation that is triggered by CPU utilization being above a set threshold, or by a Tivoli Monitoring for Transaction Performance threshold violation showing that the response time of this transaction type had exceeded its limit, as shown in the graphic. The basic health monitoring workspace shown in the screen capture shows that there is a problem and helps the operator to take the first steps of identifying the problem. The screen capture shows that the CPU utilization on the back-end computer is much higher than expected. By viewing the comprehensive monitoring workspaces for the individual products, the operator determines that the response times for WebSphere requests have increased.


• • • ••

White Paper


This increase in response times leads the operator to perform further analysis on the services component by using Tivoli Monitoring for Transaction Performance. The transaction view in the next screen capture shows slow response times for the getConfigurationOptions operation caused by excessively high CPU utilization.


• • •••

White Paper


Using the detailed Tivoli OMEGAMON XE view shown in the screen capture, a Java™ application is identified as the cause and terminated.


• • • ••

White Paper


Systems Management Quick-Start Guides

The final section of this document includes several quick-start guides to help you quickly install and configure the following products:

• Tivoli Monitoring for Transaction Performance

• Tivoli OMEGAMON XE

• SOA Workspaces in CandleNet Portal

• Coexistence of Tivoli Monitoring for Transaction Performance and Tivoli OMEGAMON XE for WebSphere Application Server

• Configuring Tivoli Monitoring for Transaction Performance to send events to the Tivoli Enterprise Console

Keep in mind that it is not the intention of these guides to act as a replacement for the official product documentation, but rather to serve as a supplement. The information in this section covers only basic configuration to allow you to install these products in a test environment for a proof of concept.

The test environment used for the preparation of this guide was based on the following product versions.

• WebSphere Application Server 5.1.1.3

• Tivoli Monitoring for Transaction Performance 5.3

• Tivoli OMEGAMON XE Candle Management Server V350

• Tivoli OMEGMAON XE CandleNet Portal Server V196.4341a

• IBM Tivoli OMEGAMON® XE for Distributed Systems V400

• IBM Tivoli OMEGAMON® XE for Databases V400

• IBM Tivoli OMEGAMON XE for WebSphere Application Server V130

• IBM Tivoli OMEGAMON XE for WebSphere Business Integration V360


• • •••

White Paper


Installing and Configuring Tivoli Monitoring for Transaction Performance

This section covers the installation of Tivoli Monitoring for Transaction Performance, along with the installation and configuration of the J2EE Managed Agent. This section describes only basic Windows® software installations within a WebSphere Application Server environment collecting data in an IBM DB2® database.

The following discussion points are included:

• Identifying prerequisites

• Database creation

• Installing the management server

• Installing the management agent

• Deploying the J2EE component

• Configuring the J2EE management agent to collect Web service information

Before You Install

This section covers what you need to install on the management server before you can install Tivoli Monitoring for Transaction Performance, as well as how to configure the management server database.

Tivoli Monitoring for Transaction Performance Quick-Start Assumptions

The content contained within this quick-start guide assumes the following:

• All environments are based on the Windows platform.

• WebSphere Application Server is used to host the management server.

• WebSphere Application Server is used on the management agent.

• IBM DB2 is installed and used as the management server database.


• • • ••

White Paper


Operating Systems

As previously stated, only Windows-based installations are covered here. For a complete list of the supported operating systems for Tivoli Monitoring for Transaction Performance, refer to the following Web page.

http://publib.boulder.ibm.com/tividd/td/ITMFTP/prereq53/en_US/HTML/OSMatrix53alt.html

Management Server Requirements

Space and Memory

Database Requirements

• IBM DB2 Universal Database Enterprise Edition, Version 7.2 Fix Pack 7 or higher

• IBM DB2 Universal Database Enterprise Extended Edition, Version 7.2 Fix Pack 7 or higher

• IBM DB2 Universal Database Enterprise Server Edition, Version 8.1 Fix Pack 3 or higher

• IBM DB2 Universal Database Enterprise Server Edition, Version 8.2

• Oracle Database 8i Standard Edition, Release 3 (Version 8.1.7)

• Oracle Database 9i Standard Edition, Release 2 (Version 9.2)

Supported WebSphere Application Server Versions

• WebSphere Application Server Base Edition, Version 5.0.2

Memory 2 GB (suggested)1 GB (minimum)

Temp space 400 MB

Temp Space for DB2 on AIX® and Solaris® 1460 MB on AIX1440 MB on Solaris

Disk space: typical 1.9 GB

Disk space (custom): management server only 760 MB

Disk space (custom): WebSphere Application Server installation 540 MB

Disk space (custom): IBM DB2 600 MB

Disk space (custom): Two table spaces for DB2 1 GB


• • •••

White Paper


• WebSphere Application Server Base Edition, Version 5.1

• WebSphere Application Server Base Edition, Version 5.1.1 (Suggested)

• WebSphere Business Integration Server Foundation, Version 5.1.1

Management Agent Requirements

Space and Memory

Note: Only the J2EE component in WebSphere v5.x is discussed in this quick-start guide.

J2EE Instrumentation

• WebSphere 4.x Advanced Enterprise and WebSphere 4.1 Enterprise Edition

• WebSphere 5.0, 5.0.1, and 5.0.2 Base Edition and Enterprise Edition

• WebSphere 5.1 and 5.1.1 Base Edition

• WebSphere 5.1 Business Integration Server

• WebSphere for z/OS 50204 and higher service levels

• WebSphere for z/OS 510003 and higher service levels

Note: For monitoring Web Services that use the J2EE managed agent, it is suggested that you upgrade your WebSphere Application Server to version 5.1.1 cumulative fix 1 or higher.

Memory 512 MB (Suggested)256 MB (Minimum)

Temp space 120 MB

Disk space: base 90 MB

Disk space: Store and Forward agents 200 MB

Disk space: Generic Windows Component 350 MB

Disk space: Quality of Service component 33 MB

Disk space: J2EE component 15 MB

Disk space: STI component 85 MB


• • • ••

White Paper


Configuring the Database on DB2

The Tivoli Monitoring for Transaction Performance management server uses a database to store information regarding various aspects of the environment, including agent information, policy details, and monitored data. There are a number of manual steps required to configure the database before you install the management server. All actions noted here are performed with the Administrator user. If there are restrictions placed on the use of this user, you can use the db2admin user or any other user that is a member of the Administrators group. It is also assumed in this section that the database name to be configured is ITMTPDB, though you can choose any meaningful name.

Create the Database and User (If Needed)

1. Log on to the DB2 server and issue the following command to create the database:

db2 create database <database_name> , or, in our case;db2 create database itmtpdb

If you need to enable support for double-byte characters, issue the following command:

db2 create database itmtpdb USING CODESET UTF-8 TERRITORY US

2. Create a user account that the management server uses to access the DB2 database. This step is not entirely necessary, unless, as mentioned previously, there are restrictions on the use of the Administrator user. If you want to create another user for the management server to use, issue the following command from a DOS prompt:

net user <user_name> <password> /add

Configure the Buffer Pool

Perform the following steps to configure the management server buffer pool, which must be larger than what is created by default in DB2.

1. Disconnect all applications from the database if any exist.

db2 disconnect all

2. Connect to the database you just created (in this case, ITMTPDB):

db2 connect to itmtpdb user <user_name> password <password>

3. Create a buffer pool with a size of at least 250 and a page size of 32K (minimum):

db2 create bufferpool buffpool32k size 250 pagesize 32k


• • •••

White Paper


4. Update the database configuration for the database you created to increase the application heap size:

db2 update db cfg for itmtpdb using APPLHEAPSZ 513

5. Ensure the new buffer pool was created successfully:

db2 select * from syscat.bufferpools

Output from the above command looks similar to the following:

BPNAME BUFFERPOOLID DBPGNAME NPAGES PAGESIZEIBMDEFAULTBP 1 - 250 4096BUFFPOOL32K 2 - 250 32768

6. Close all applications connected to the database:

db2 force applications all

7. Log back on to the database (if you are logged on to the server as the user who created the database, you do not have to re-enter your user name and password):

db2 connect to itmtpdb user <user_name> password <password>

8. By default, the user who created the database is given the appropriate permissions to the database (in our case, Administrator). However, if you want to install the management server under a different user who requires administrator privileges to the database, additional configuration might be needed. After the management server is installed, the user permissions are verified through the DB2 Control Center.

Optimizing the Database Configuration

The following steps are not required, but help to optimize the database configuration. These steps increase the number of primary logs, as well as enable the log retain feature.

1. List the database configuration:

db2 get db cfg for itmtpdb

2. Increase the number of log primaries (in this example, increase the number to 10):

db2 update db cfg for itmtpdb using logprimary 10

3. Turn on log retain:

db2 update db cfg for itmtpdb using logretain on

4. Disconnect all applications connected to the database:

db2 force application all


• • • ••

White Paper


5. Make a backup of the database to a directory of your choice:

db2 backup db itmtpdb to C:\<backup_directory>

Installing the Tivoli Monitoring for Transaction Performance Management Server

This section walks you through the process of installing the Tivoli Monitoring for Transaction Performance management server. It is assumed that a WebSphere Application Server is already installed and the management server database has already been created using the steps provided in the previous section.

1. Log on to the server where the management server is to be installed and launch the appropriate executable (in this case for the Windows installation, run setup_MS_w32.exe).

2. Select Next to view the license agreement window. Accept the license agreement and click Next.

3. Type in the directory where you want to install the management server, or accept the default location (on Windows, this is C:\Program Files\ibm\tivoli\MS). The disk space required is 760 MB. Select Next.

4. On the following window, specify if you want to enable SSL or not. For this example, SSL is not enabled. Select Next.


• • •••

White Paper


5. In the following window, search results are displayed for an installed WebSphere. Supply a valid user name and password to enable security (if not already enabled). For this example, supply the Administrator user name and password. Click Next.

6. The following window provides you with database-specific options. If you already have DB2 installed (which is assumed), select the Use an existing DB2 database radio button.

7. After selecting the DB2 option, you are asked to supply the database name (ITMTPDB), along with the associated user name and password (in this case, supply the Administrator user name and password. If you created a separate user in the previous section to use the database, specify that user and password here). The JDBC path is filled in automatically.

8. The final window you encounter confirms your installation location. Select Next to begin the installation.

9. Close to halfway through the installation process, the installation prompts you to insert Disk 2. Insert the second disk or browse to where the image for Disk 2 is located.


• • • ••

White Paper


10. After the components from Disk 2 are installed, the installation begins to configure the management server. During this time, you are asked if you want to restart WebSphere. Select Yes.

11. When complete, click Finish.

12. Step 8 in “Configure the Buffer Pool” on page 20 discusses ensuring that the defined user has the proper database privileges. You can check this now by going into the DB2 Control Center and making sure that the user you specified during the management server installation has access to the table spaces. Navigate to DB Users, as shown in the following screen capture:

13. Right-click the user you specified during the management server installation (in this case, Administrator), and select Change.


• • •••

White Paper


14. On the Database tab, make sure all boxes are selected, click the Table Space tab, and ensure you see the following:

15. Click Cancel after verifying the above table space.

16. Verify that the management server was installed successfully by logging on to the management server GUI, either by double-clicking Tivoli Monitoring for Transaction Performance management server on the desktop or typing the following address in a Web browser:

http://<server_name>:<port>/tmtpUI

Where <server_name> is the name of the management server, and

Where <port> represents the port specified during the installation (default is 9082)

17. Log in to the management server using the user name and password you specified during the management server installation.

Installing the Tivoli Monitoring for Transaction Performance Management Agent

After the management server has been successfully installed, you can install the management agent software on the server you want to monitor. Review the following before you start the installation:

• You must first install the management agent code, which is a separate installable image that lays down the required code that allows the agent to communicate back to the management server. This is covered in the first part of this section.

• After you have successfully installed the management agent code, deploy the management agent components, such as STI, QOS, and J2EE, which is covered in the second part of this section.


• • • ••

White Paper


Installing the Management Agent

1. Log in to the server where the management agent will be installed and launch the appropriate executable (in this case for Windows platforms, run setup_MA_w32.exe).

2. Select Next to view the license agreement window. Accept the license agreement and click Next.

3. Enter the directory name where you want the management agent to be installed, or accept the default location (on Windows, this is C:\Program Files\ibm\tivoli\MA). The disk space required is 90 MB. Select Next.

4. On the following window, type the location of the management server and select if you want to enable SSL (in this example, SSL is not enabled). Enter the appropriate information and select Next.

5. The following window asks you to identify a user under which the management agent will run. You can either specify an existing user or create a new one. In this example, the Administrator user name and password are selected.

6. The final window asks you to confirm the installation location. Select Next to begin the installation.


• • •••

White Paper


7. If the installation finished successfully, a confirmation window is displayed. Click Finish to exit.

8. Confirm that the management agent was installed successfully by logging on to the management server as detailed in the previous section. After you log in to the management server, the following window opens:

9. In the Navigator tree on the left side of the window, expand System Administration and select Work with Agents.

10. If the management agent installed successfully, Work with Agents is displayed under the Management Agents section on the right side of the window, with a status of Online. Stay on this panel to begin the next section.


• • • ••

White Paper


Deploying the Management Agent Component

After you have successfully installed the Management Agent code, specify the component you want to install on the management agent. This example uses the J2EE component, which allows you to monitor the performance of both J2EE servlets and J2EE Web Services that are running on WebSphere Application Server.

1. If you are not already logged on to the management server, log on now, expand the System Administration section in the navigation tree on the left side of the window, and select Work with Agents. A window is displayed that is similar to the one shown on the previous page.

2. Select the Please make a selection check box next to the management agent that you just installed. Click anywhere in the drop-down box and select Deploy J2EE Monitoring Component (the third selection). Click Go.

3. In the Deploy Components panel, ensure that the following information is correct:

– The top box shows Configure J2EE Component.

– The drop-down box below that (Application Server Type) shows WebSphere.

– The drop-down box below that (Application Server Version) shows 5.X.

– Type the WebSphere server name in the box labeled Application Server Name (default is server1).

– In Application Server Home, type the directory path where WebSphere was installed (the default is C:\Program Files\WebSphere\AppServer).

– If you want the WebSphere Application Server to automatically restart, click the first check box.

– If security has been enabled on the WebSphere Application Server where the management agent resides, click the second check box. After you select the check box, type the user name and password associated with the WebSphere Application Server (in our case, type the Administrator user name and password).

4. Click OK when finished.

5. You are taken back to the Work with Agents panel where you started. The only difference in this panel now is the Components column shows J2EE and the Status column shows Installing. If the management agent component is deployed successfully, the Status column is updated to reflect Running. Refresh the window a couple of times by clicking the Refresh icon at the top of the table (a circular arrow) to acknowledge this change.


• • •••

White Paper


Configuration

This section discusses how to configure both a Discovery and a Listening policy that allow you to begin monitoring your Web Services. It is assumed that an application or group of applications already resides in your WebSphere Application Server that is Web Service-based. For the sake of retrieving data quickly, the examples included here are very basic in nature and configured to search for all instances of Web Services running on the management agent. This is acceptable in a testing environment, but for production environments, follow the instructions contained within the official Tivoli Monitoring for Transaction Performance product documentation.

Before You Begin

There are a couple of steps that need to be taken before you create a Discovery policy. These same steps can be performed during the Discovery policy creation, but here they are broken out to give you a better idea as to how all the pieces fit together. The examples included in this section represent a very basic configuration, suitable only for testing environments.

Creating a Schedule

Create a schedule before writing your Discovery policy. This schedule is applied later to the policies that you write and specifies how often and for how long the policies run:

1. If you are not already logged in to the management server, do that now. After you are logged in, expand the Configuration section in the navigator tree on the left side of the panel and click Work with Schedules.

2. The Work with Schedules panel opens. In the top drop-down box, ensure that the Discovery or Listening selection is highlighted, and click Create New.

3. The Configure Schedule (Discovery or Listening Policy) panel opens.

– Type a schedule name that accurately describes the type of schedule you are trying to create. This example uses a schedule that runs all day, every day, so name the schedule 24x7.

– If you want the schedule to start now, select the Start as soon as possible radio button. If you want the schedule to begin at a later time, click the Start later at radio button and provide the day/month/year and hour/minute you want the schedule to start.

– For the next option labeled Iteration, if you want the schedule to run continuously, select the Run continuously radio button. If you want more granularity to your schedule, click the Run between radio button and select the times you want your schedule to run. You can also specify single days of the week here.


• • • ••

White Paper


– Finally, decide if you want the schedule to Run forever or to Stop later at a specific point in time. Type your selection here and click OK at the bottom of the page.

4. After clicking OK, you are taken back to the Work with Schedules panel, where your new schedule now appears.

Creating an Agent Group

You need to create an agent group before creating your listening policy (even if you only have one agent currently configured). This agent group can be configured any number of ways. You can group certain agents together according to their respective operating system or you can group together agents that host an application that consists of a set of distributed Web Services. Ensure that the agents included in each agent group have the same discovery and listening policy applied to them (you will learn more about this later).

1. Expand the Configuration section in the navigator tree on the left side of the panel and click Work with Agent Groups.

2. The Work with Agent Groups panel opens. Click Create New at the top of the page.

3. On this panel, you are asked to name the agent group. Select a meaningful name for the agents you are including. You are presented with a list of all management agents associated with this management server.

4. Click the check box of each server you want to include in this agent group. After selecting your management agents, click OK at the bottom of the page.

5. After clicking OK, you are taken back to the Work with Agent Groups panel, where your new agent group is displayed.

Creating a Discovery Policy

You have created your schedule and you have defined your agent group. You are now ready to create your discovery policy. Basically, you create a discovery policy to discover Web Service interfaces (as defined in the associated Web Service WSDL files). After the policy is created, the discover policy searches for Web Service interfaces based on the parameters you specified during policy creation and produces a list of all discovered transactions. From this list you create a listening policy (which will be discussed later).

This example does not describe how to write a granular discovery policy that searches on specific parameters contained within the respective WSDL files. Instead, it shows you how to write a very basic policy that searches for everything. Consult the official product documentation on how to write more specific discovery policies.

1. If you are not already logged in to the management server, do that now. After you log in, expand the Configuration section in the navigator tree on the left side of the panel and click Work with Discovery Policies.


• • •••

White Paper


2. The Work with Discovery Policies panel opens. In the drop-down box, select J2EE Web Services and click Create New.

3. The Configure J2EE Web Services Discovery panel opens.

– For Transport Type, choose HTTP, JMS, or both. This example uses HTTP. If you are not sure which one applies, refer to the IBM Tivoli Monitoring for Transaction Performance Administator’s Guide.

– For the next two boxes, Port Name and Operation Name, you want to type something that is specific to the Web Services you are trying to monitor. This example searches for everything by including .* (period asterisk) in the field.

– Leave the next two boxes as-is.

– Leave the Sample Rate radio button selected, and change the number to 100. This discovers 100% of the transactions.

– You cannot type an entry in the last box because this policy is based on the Sample Rate.

4. Click Next. You are presented with the Work with Schedules panel. Select the schedule you just created and click Next.

5. The Work with Agent Groups panel opens. Select the agent group you just created and click Next.

6. Assign a name to your discovery policy and click Finish. Make sure the name is something representative of what you are trying to monitor.


• • • ••

White Paper


7. You are taken back to the Work with Discovery Policies panel where the new discovery policy that you just created is displayed.

Creating a Listening Policy

After transactions have been discovered (make sure you are running Web Service traffic through your application so that transactions can be discovered), you can write a listening policy against the discovered transactions. The main purpose of the listening policy is to collect performance data for those discovered transactions to help you identify established and potential performance problems.

1. If you are not already logged in to the management server, go ahead and do so. Expand the Configuration section in the navigator tree on the left side of the panel and click Work with Discovery Policies.

2. Select the discovery policy you just wrote, and in the table drop-down box (Please make a selection), select View Discovered Transactions and click Go.

3. If you see nothing in the discovered transactions table, it might be because no transactions have been discovered based on the parameters you specified, or the data has not been refreshed. To verify the latter, click the database icon near the top of the panel. You are presented with a box, on which you click OK. Another box is displayed stating that retrieval is taking place and will refresh after the data retrieval is complete. Expand the Details section and make sure you see your management agent listed there with a No Failure message. If you see a message stating No data available, that means no transactions were discovered.

4. Click Update and Close to go back to the View Discovered Transactions panel. If transactions were discovered, they are listed here.

5. Select the transaction you want to write a listening policy against, and in the top drop-down box, select Create Listening Policy From. Click Go.


• • •••

White Paper


6. The following panel opens:

– For this example, leave the Match All radio button selected.

– For Transport Type, you can select either HTTP or JMS. What is displayed here by default is determined by the discovered transaction.

– The next four boxes (Port Name, Operation Name, Target Namespace, and Input Message Name) are filled in automatically from the discovered transaction. You do not have to alter these.

– For this example, change the Sample Rate to 100% so that everything is sampled.

– You cannot select Number of Samples if Sample Rate is selected.

– In this case, select the Aggregate and Instance radio button. This collects aggregate data (an average for all response times) and instance data (response time average for each individual discovered transaction). Combining this with a sample rate of 100% is acceptable for a test environment, but you want to


• • • ••

White Paper


significantly decrease the sample rate in a production environment because of the amount of performance data that is collected.

7. After clicking Next, the Configure J2EE Settings panel opens.

– Start under the Advanced Listening Settings section. In the Choose Default Configuration drop-down, choose the level of trace you want to be applied. For this example, choose High.

– Under the Configure J2EE Thresholds section at the top of the panel, you can choose to create a threshold based on the Performance of your applications or on the actual Transaction status (did it run or did it fail). For this example, choose Performance and click Create.

8. On this panel, configure the thresholds you want to apply to the discovered transaction. The threshold value (in seconds) is automatically filled in for you based on the first transaction discovery run. You can change this value if you want. You also choose the associated response level and event response level on this panel. After you make your selections, select the Apply button. If you want to set additional thresholds, you can do that at this time.


• • •••

White Paper


9. You can click Next if you want to continue, or Back to ensure the thresholds were applied successfully.

10. Click Next on the Configure ARM Settings panel (which does not apply in this example).

11. Select the schedule you created previously, or create a new one.

12. Select the agent group you created previously.

13. The Work with Policy Groups panel opens. Create a new policy group to assign this listening policy to and click Next.

14. To complete the policy creation, assign a name to the listening policy and click Finish.

15. Go to the Work with Listening Policies panel to view the new listening policy you just created.

Visualizing Web Service Status and Performance

Tivoli Monitoring for Transaction Performance offers a number of reporting methods that provide valuable insight as to how your Web Service applications are running and performing. This section provides a high-level overview of what is contained in each report within the Reports section of the management server console.

If you have not done so already, log in to the management server and expand the Reports section.


• • • ••

White Paper


Big Board

The Big Board is primarily used to view status of a policy for each management agent to which that policy has been deployed.

The status of each policy (as denoted in the first column above) is equal to the threshold-specific response level you set during the listening policy creation. You can also use the Big Board to view the following:

• By clicking the Event View icon , you can view the component level events for each policy.

• By clicking the Transaction Topology icon , you can view a graphical representation of a transaction’s performance.


• • •••

White Paper


View Dashboard

Displaying information in a more high-level view than the Big Board, the Dashboard provides status related to each policy group from data collected over the past eight hours. From this report you can see the overall status of the policy group, the number of violations received across the total number of individual policies, the associated management agent availability, and the time since the last violation was received. See the following example.

After selecting your policy group, use the drop-down menu to perform the following actions:

• View Policies: Shows how each policy in the selected policy group is performing.

• View Events: Takes you to the component events table associated with each policy and agent in the selected policy group.

• Fast Path to Failure: Provides an easy way to display a topology report that breaks down transactions that are performing the worst, while also displaying the root cause of the performance problem.

View General Reports

A variety of reporting formats are contained within the General Reports section of the management server console, including the following:

• Overall Transaction Over Time

• Slowest Transactions


• • • ••

White Paper


• Availability

• Transaction with Sub-transactions

• Topology

• Page Analyzer View

For more details regarding these reports, consult the official product documentation.

View Component Events

The component events table can be accessed through the other reports, or it can be accessed in the same manner as the other reporting sections. An example of this table is shown below.


• • •••

White Paper


The default view shows component events received for all management agent components. You can also use the drop-down menu to filter the events based on the specific component. Clicking the event message link takes you to the Event Details panel, as shown below.


• • • ••

White Paper


Installing and Configuring IBM Tivoli OMEGAMON XE

This section covers the installation and configuration of the IBM Tivoli OMEGAMON XE products, including the Candle Management Server, Candle Net Portal Server, Candle Net Portal, components and several Tivoli OMEGAMON XE agents.

Discussion topics include:

• Installing the main components of a Tivoli OMEGAMON XE environment

• Configuring each component

• Installing and configuring Tivoli OMEGAMON XE for WebSphere Application Server agent

Installation

This section walks you through the installation of all Tivoli OMEGAMON XE components on a single server. It is assumed that the components are installed on a Windows server, with the required DB2 server already in place.

1. Log on to the server where you want to install the OMEGAMON XE components and launch the appropriate executable (for Windows, this is setup.exe).

2. On the Welcome window, click Next.

3. Accept the license agreement.

4. Choose the installation directory path or accept the default (on Windows, type C:\Candle). Click Next.


• • •••

White Paper


5. You are presented with a window asking you to the select the specific features you want to install. After you are finished making your selections, click Next.

• In first section, Agents and Adapters, select the following:

– DB2 Universal Database Monitoring Agent

– WebSphere Application Sever Monitoring Agent

– WebSphere MQ Monitoring Agent

– Windows Servers Monitoring Agent

• In second section, Candle Management Server and Application support, select the following:

– DB2 Universal Database Support

– WebSphere Application Server on Distributed Systems Support

– WebSphere MQ Monitoring Agent Support

– Windows Servers Support

• In the third section, CandleNet Portal Server and Application Support, choose:




• • • ••

White Paper




• In the fourth section, CandleNet Portal Desktop Client and Application Support, choose:





• In the fifth section, Candle Management Workstation and Application Support, choose:




6. Choose the default program folder (Candle OMEGAMON XE) and click Next.

7. Review your selections and click Next.

8. After all files are copied, you are presented with a window asking if you want to configure the available options now or wait until after the installation completes. Those options preceded with an asterisk must be configured now. For our example, leave all boxes selected.


• • •••

White Paper


9. After you click Next on the above window, you are presented with a series of boxes that cover the configuration of each component selected. The following sections are broken down according to each set of configuration boxes.

Configure Candle Net Portal

1. The first window asks you the host name of the server where the Candle Net Portal Server resides. By default, the server name is filled out.

2. A pop-up box asks you to supply the Candle Net Portal Server data source configuration parameters.

– The data source name is automatically provided (CNPS2).

– Type the DB2 user name, followed by the DB2 user password.

– Keep the default values provided for the Candle Net Portal Server database user ID or type your own. For this example, change the Candle Net Portal Server password to conform to password requirements.

Click OK when finished. If completed successfully, you receive a confirmation window.


• • • ••

White Paper


3. Another pop-up box asks for the CNP Server connection parameters. Specify if your connection must pass through a firewall, and then select the specific communication. protocols. In this example, TCP/IP is already specified, so choose the defaults. Click OK.

4. A third CNP Server configuration window opens. If you specified only TCP/IP as your protocol, you only need to verify your host name and port number (default is 1918). Click OK.

Configure and Seed Candle Management Server with Application Data

1. After configuring the CNP, the Candle Management Server Configuration window opens. Accept the defaults unless changes are necessary and click OK.

2. The Hub CMS Configuration window opens. If the TCP/IP protocol was the only protocol you chose previously, you only need to verify the host name and port number (default is 1918). Click OK.

3. Click OK on the Seed CMS pop-up box. The radio button labeled On this computer is selected by default. Click OK.

4. Manage Candle Services opens, stating that the Candle Management Server is currently not running. Click OK to start the server so that the seed data operation can be performed.

5. The next box that opens is Select Product to Seed CMS. In this box, all the agents you specified previously are displayed. Ensure that all are highlighted and click OK.

6. If the Candle Management Server seeding completed successfully, a confirmation window is displayed. Ensure no errors are present and click Next.


• • •••

White Paper


Configure Agents Default Connection to Candle Management Server

1. A box entitled Configuration Defaults for Connecting to a CMS opens. Specify if your connection must pass through a firewall, and then select the specific communication protocols. In this example, TCP/IP is already specified, so choose the defaults. Click OK.

2. A second box opens that prompts you for additional configuration defaults for connecting to a Candle Management Server. If the TCP/IP protocol was the only protocol you chose previously, you only need to verify the host name and port number (default is 1918). Click OK.

3. When the step completes, a window is displayed stating that the installation is complete, with the option of displaying the README file. Click Finish to complete the installation.

Launch Manage Candle Services for Additional Configuration Options and to Start Candle Services

After completing the installation, the Manage Candle Services window opens, as shown below. Agent configuration is detailed in the next section.


• • • ••

White Paper


Agent Configuration

The following section walks you through a basic configuration of the agents that you installed in the previous section (DB2, Windows OS, MQ, WebSphere Application Server). If you are running the Tivoli OMEGAMON XE for WebSphere Application Server agent on the same computer as the Tivoli Monitoring for Transaction Performance J2EE managed agent, take note of the advised changes to the respective XML files.

Configuring the DB2 UDB Agent

1. From the Manage Candle Services window, right-click DB2 Universal Database Template and select Configure Using Defaults.

2. When prompted to type the DB2 instance name, enter DB2 (this is the default DB2 instance on Windows. You can verify this by going to a DB2 command window and typing db2ilist.)

3. A new DB2 line is displayed in the Manage Candle Services window. When ready, you can start the agent by double-clicking the new DB2 line. After it starts, the following is displayed:

Configuring the Windows Servers Monitoring Agent

1. From the Manage Candle Services window, right-click Windows Servers Monitoring Agent and select Configure Using Defaults.

2. Double-click the Windows Servers Monitoring Agent. If started successfully, the following is displayed:

Configuring the WebSphere MQ Monitoring Agent

1. From the Manage Candle Services window, right-click WebSphere MQ Monitoring Agent and select Configure Using Defaults.

2. You are presented with a box asking if you want to update the mq.cfg file prior to configuration. You can take one of the following two paths:

– Click No if you already have a default queue manager defined. You do not have to make any modifications to the agent’s configuration file, and the agent is configured using the defaults. You can customize this file later if the need arises.


• • •••

White Paper


– Click Yes if you do not already have a default queue manager defined, or if you are configuring this agent to monitor a queue manager other than the default. To do this, insert the name of the queue manager in the MANAGER NAME() and MGRNAME() parameter fields of the configuration file. After configuration, click Yes.

3. After you are returned to the Manage Candle Services window, double-click WebSphere MQ Monitoring Agent. If started successfully, the following is displayed:

4. Further configuration can be performed at a later time by editing the agent’s configuration file (the quickest way to do this is to right -click MQ agent in the Manage Candle Services window and select Reconfigure). For example, if you want to enable the collection of historical monitoring data, set HISTORY(YES) in the agent’s configuration file.

Configuring the WebSphere Application Server Agent

Take special note of this section if you are want to install the Tivoli OMEGAMON XE for WebSphere Application Server agent on the same server as the Tivoli Monitoring for Transaction Performance J2EE management agent.

Enable PMI

To begin the configuration, you must enable Performance Monitoring Infrastructure (PMI) to allow the extraction of WebSphere performance data. There are two ways to perform this: using a Take Action command from CandleNet Portal, or directly through the WebSphere Application Server administration console.

1. Log on to the WebSphere Application Server administration console, expand Servers in the Navigation tree, and select Application Servers.

2. In the window on the right side, select the application server you want to configure (the default is server1).

3. After the window refreshes, ensure the Configuration tab is selected and scroll down to select Performance Monitoring Service.

4. Place a check mark in the Startup box, and for this example, select the Standard radio button.

5. Click Apply and follow the path to Save the configuration.

6. You might be required to restart WebSphere after saving the configuration.


• • • ••

White Paper


Launch the Class Loader Script

1. From a Windows command prompt, navigate to where the agent was installed (default is C:\Candle\CMA).

2. At the prompt, type setupCandleWAEnabler.bat.

3. After the command completes, a jar file is created in the agent directory (C:\Candle\CMA by default) named kwescl.<java_version>.jar. For this example, the jar file is kwescl.1.4.2.jar.

4. Write this down as you will need it to complete the agent configuration.

Select the Appropriate kweiuser.xml File

For the WebSphere Application Server agent, the Candle infrastructure uses a set of XML files to instrument your WebSphere Application Server. Three sample files are provided in the default agent directory (for Windows, it is C:\Candle\CMA): kweiuser_development.xml, kweiuser_certification.xml, and kweiuser_production.xml. A brief description of each is provided below:

• The kweiuser_development.xml file is mainly used in development and test environments where the maximum amount of data is collected. Maximum instrumentation is enabled as well. These files are not suitable for production environments because of the associated performance overhead.

• The kweiuser_certification.xml file is used in non-production environments and is targeted more toward those integration environments that might be used before bringing the application into production. A medium level of instrumentation is enabled, requiring less overhead.

• The kweiuser_production.xml file is used in production environments where you want minimal overhead and is the preferred file to use when installing on the same server as the J2EE management agent.

Each file contains XML tags related to a particular component of the workload analysis, along with default parameter values that align with the desired level of instrumentation for each file type. You can alter the values in these files if you want to, or you can leave them as-is. Refer to the official product documentation for complete details regarding the content of each file before altering any parameter values.

Starting the Agent

After you have decided which kweiuser file you will be using, you can now start the agent; however, the actual agent configuration is not quite finished. This set of steps lead you up to the final steps required prior to completing the configuration.

1. In the Manage Candle Services window, right-click WebSphere Application Server Agent and select Configure using defaults.


• • •••

White Paper


2. You are presented with a box asking if you want to update the kwe.xml file prior to the configuration of the agent. Click Yes and then OK.

3. After clicking OK, the kwe.xml file opens. For this example, the only line you edit is the very last one: WASAppServerRoot. In between the quotes, type the full path of where the WebSphere Application Server that you want to configure is installed (the default for Windows is C:\Program Files\WebSphere\AppServer). If you want to edit any of the other values included in this file, consult the official product documentation.

4. After editing, save the file and close it. Click Yes on the next box to configure the agent.

5. After the agent is configured, double-click in the Manage Candle Services window

to start the agent.

Changing the WebSphere Application Server Configuration

To enable the workload analysis piece of the agent, you must alter the WebSphere Application Server configuration. This can be performed a couple of ways: dynamically through a Take Action command or through the WebSphere Application Server administration console. This example uses the Take Action command because the chance for error is much less.:

1. To begin this final configuration step, log on to the CandleNet Portal (default user name is sysadmin, using the password that you specified during the CandleNet Portal installation).

2. Expand the navigation tree until you see the WebSphere Application Server subnode that you want to configure. See the following example:

3. Right-click the highlighted subnode and select Take Action.

4. You are presented with the Take Action box. In the Name drop-down, scroll until you reach the WAS Configuration Setup command and select it. The following Edit Argument Values window is displayed:


• • • ••

White Paper


a. In the first Value row, type Y to collect workload analysis data.

b. In the second Value row, type Y to collect garbage-collection data.

c. In the third Value row, type the name of the kweiuser.xml file. This file must be located in the agent install directory (C:\Candle\CMA for Windows).

5. After clicking OK, you are taken back to the Take Action dialog box. In the Destination Systems dialog box, highlight the WebSphere Application Server that you want to configure and click OK. If it completes successfully, a confirmation dialog box is displayed.

6. After the configuration is complete, restart your WebSphere Application Server. You can either do this manually or through a Take Action command in CandleNet Portal. The steps for restarting the WebSphere Application Server using the Take Action commands are covered next.

Restarting the WebSphere Application Server Using the Take Action Commands

1. Expand the navigation tree until you see the WebSphere Application Server subnode you want to configure.

2. Right-click the highlighted subnode and select Take Action.

3. Scroll down in the Name dialog box until you see the WAS Recycle Application Server command.

4. Select the recycle command and highlight the WebSphere Application Server that you want to recycle in the Destination Systems dialog box. Click OK.

5. The table at the bottom of the default WebSphere Application Server workspace (it should reflect that you highlighted the subnode to Take Action) reports the status of the recycled WebSphere Application Server. Refresh the window (F5) to ensure you are viewing the current status.


• • •••

White Paper


Creating SOA Workspaces in CandleNet Portal

For those users who are new to CandleNet Portal, this guide provides a step-by-step account of how to create CandleNet Portal workspaces that contain data spanning servers across an entire SOA infrastructure. Taking a top-down approach, this guide arms you with the concepts and terminology that are required to become familiar with CandleNet Portal and conclude with best-practice example workspaces to help provide you with an all-encompassing understanding of a basic SOA infrastructure.

Discussion points include the following:

• Concepts and terminology

• Deciding on a view layout

• Configuring the views

• Creating and modifying queries

• Attribute filtering

• Node grouping

• System filtering

The Important Concepts

Before starting into the details of creating workspaces, it is important that you become comfortable with the terminology used throughout this guide.

Views

A view is a single visual representation of data that is contained within a workspace. A view can consist of data represented within tables, pie charts, bar graphs, or it may contain a terminal session or a Web browser. Views can also be split and moved around at will, enhancing your ability to tailor the CandleNet Portal to your specific requirements.

Workspace

A workspace consists of a single view or a collection of views and serves as the primary viewing area for the CandleNet Portal. Each item located in the Navigator contains a workspace and can have more than one workspace associated with it.


• • • ••

White Paper


Navigator

By default, the Navigator is displayed in the upper left of the CandleNet Portal window and uses a standard tree structure to hierarchically organize and display the monitored servers according to platform. Each monitored node is listed under its respective platform, and under each node, the installed agent or agents are listed.

The purpose of the navigator is to not only provide you with an inventory of the monitored infrastructure components, but to also enable you to bring up different workspaces. Each node on the navigator has a set of workspaces associated with it, and by clicking each node, the CandleNet Portal switches to the default workspace associated with the selected node.

Creating a New Workspace

View Layout

There are several steps associated with creating a new workspace. This section walks you through each of the steps.


• • •••

White Paper


Node Selection

1. To begin, select the node for which you want to create a new workspace. For the purpose of this exercise, select the main Enterprise node to facilitate the viewing of data across different operating systems. View the default workspace for the Enterprise node by selecting it and clicking one time.

2. To ensure that the original workspace is not overwritten, save the workspace under a different name by selecting File > Save Workspace As in the top menu. Give the new workspace a new name that is meaningful so that you are less likely to forget the name.

Determine the Actual Layout

Before you decide how you want your views to be arranged in the workspace, you must become familiar with the following buttons, located in the upper-right corner of each view:

– The first button splits the selected view vertically.

– The second button splits the selected view horizontally.

– The third button maximizes the selected view.

– The fourth button removes the view.

To facilitate the layout creation process, destroy all of the views except the Navigator, views for which you can split and move around to achieve the layout you want.

Note: It is important that you first set up the layout you want before you add content to the views because the only way to make layout changes later is to destroy the views, which requires undoing work that you have already completed.

Deciding How to Display the Data

After you have created the layout, determine how the data in each view is represented. You have several choices at your disposal, all of which are contained in the toolbar.

The usefulness of each view is dependent on the data you have and how you want to see it displayed. Some views are better than others in different situations. Keeping this in mind, the examples highlight the situations where the different views are stronger or weaker in displaying data. Each view included in the toolbar.


• • • ••

White Paper


• Table – The table view is the simplest way to display data and is the preferred view to use when you have large quantities of data.

• Pie Chart – Select this view to create a pie chart for each row of data by taking the selected numerical data elements and giving them proportional representation. Limitations associated with the pie chart view include the following:

– Data gathered by some agents often does not support a pie chart, mainly because the data does not add up to 100%.

– Aggregating the information down to one record is often impossible, thus making the creation of a single pie chart inordinately difficult.

– When displaying multiple pie charts, the labels might begin to overlap one another.

• Bar Chart – The bar chart represents each data row as a set of bars, with each attribute consisting of a different colored bar. For example, if there were two rows, each with attributes A and B, the chart shows two bars for each row, with the rows for attribute A in one color and the rows for attribute B in a different color.

• Plot Chart – This chart plots data points across a timeline. This is a good option for displaying historical data.

• Circular Gauge – In an SOA-type environment, the use of this view might be limited, as data is forced to be displayed in a minimum and maximum type format.

• Linear Gauge – This view is similar to the circular gauge, with the minimum and maximum data represented in a more linear fashion.

• Notepad – This view is primarily used for the display and entry of text, which is particularly useful when complicated scripting of the workspace is needed.

• Message Log – This view of the CandleNet Portal message log is used to view situations and policies.

• Event Console – This view of the CandleNet Portal event console is used to view the events generated from situations and policies.

• Graphic View – This view is similar in nature to the Windows desktop where a set of icons is displayed against a wallpaper backdrop. Nodes can be viewed as icons by dragging and dropping them from the Navigator. The status is displayed by default.

• Take Action – This view is identical to the Take Action dialog box and allows you to select a predefined action from a drop-down menu, associate a command with the action, select the servers, and run the action.

• Terminal – The terminal window view allows a connection to be made to another server to run commands and scripts.

• Browser – This is a Web browser view.


• • •••

White Paper


After you determine the views that you want to include, click the view icon in the toolbar and then click again in the space you where you want the view to be displayed. This replaces the blank layout space with your selected view.

For this exercise, if you are presented with a box asking if you want to assign the query now select No. This is discussed in a later section.

Configuring the Views

After the views have been assigned to their respective position in the layout, you then configure the views. This section discusses the configuration for four view types: Table, Pie Chart, Bar Chart, and Plot Graph. The remaining views are not discussed because no configuration is required or the required configuration is minimal.

1. Right-click anywhere in the view and select Properties.

2. In the window that opens, click the button labeled Click here to assign a query (directly above the Description box). The Query Editor window opens.

3. On the left side of the Query Editor, a navigator is displayed that contains all the available default queries and is organized by agent, and then attribute group. Expand Agent and Attribute Group to see the associated queries. The following screen capture shows a picture of the Query Editor with the All_Workloads attribute Group expanded under the WebSphere Application Server agent.


• • • ••

White Paper


4. The details of the query are located within the Specification window. Each column in the table refers to an attribute and each row refers to the query logic used to filter the data. Columns that have checks in the check boxes on the first row are available to display, while columns that do not have checks are only being used for filtering and are not available to display. Note that you can filter out extraneous columns later, so having too much information is not a real problem at this point.

5. If the default query is acceptable, click OK to apply it to your view. If you want to modify the query, first duplicate it by right-clicking the query in the Navigator tree and selecting Create Another Query, and then modify the copy you just created. This prevents any other views dependent on this query from being altered as well.

Note: For more information regarding creating and modifying queries see Creating and Modifying Queries.

6. After clicking OK, you are returned to the Properties window. In this window, select the Filters tab, located directly to the right of the Query tab. In this window you see the same spreadsheet-style display you see in the Query Editor. From here, you can clear any of the columns that you do not want to display in your view. Columns that are grayed out cannot be selected. This is most likely because


• • •••

White Paper


of the type of data being used (for instance, string data cannot be used in a plot graph).

7. After you have applied the desired filters, click the Style tab, which controls the appearance of the view and which you can modify by selecting various parts of the mini-view on the left side of the tab.

– For chart views, you can alter how various pieces of the view are displayed, such as the value, legend, category, header and footer.

– For tables, there is an additional tab labeled Thresholds that enables you to set conditions for each cell in the table (for example, changing a cell color to match the associated situation).

8. Click OK when finished. After you are satisfied with your workspace, save it by selecting File > Save Workspace.

Creating and Modifying Queries

As described in the previous section, a query is a filter applied to an attribute table that limits the amount of data to display in a view. Every query is associated with an attribute table, and every attribute table is associated with an agent or a subagent. An example of the Query Editor is displayed below.


• • • ••

White Paper


On the left side, a list of agent nodes is displayed (such as QI Broker, Queue-Sharing Group, and UNIX), along with the associated children nodes representing actual attribute tables. In this example, the UNIX agent has attribute tables of Disk, Disk_Performance, User, and so forth. Each attribute table can have one or more queries; for example, as in this case, the attribute table Disk has the queries Disk Inodes and Disk Utilization, among others.

Every query associated with an attribute table can access all of the information contained within that table, even across multiple instances of that type of agent; however, each query is also limited to only that information contained within that particular attribute table. In the case of the Disk Inodes query, the query is at most only able to return the entire contents of the Unix Disk attribute table.

You might not want the entire attribute table to be displayed. If this is the case, you can use query filtering to focus on the following two items:

• Attribute values

• The systems from which information is being gathered

In the Query Editor example, attribute filters are specified in the Specification tab, whereas the system filters are specified in the Query Results Source tab.

Attribute Filters

Contained within the Specification tab is a spreadsheet-like table with named columns and numbered rows.

Each column represents an attribute from the attribute table, though not all of the attributes in the attribute table are represented in columns. For a complete listing of all available attributes and to add attributes to the query, click Add Attributes….


• • •••

White Paper


Clicking Add Attributes… brings up a dialog box on the right side listing all possible attributes. All of the currently visible attributes are blue, with all others being black. To make non-visible attributes available, highlight them in the dialog box, and then click the OK button. They are then displayed as part of the table. To remove attributes from the table, right-click the column name that you want to remove and select Delete.

• Each row in the Specification table represents a logical statement for filtering the data. The first row is always a set of check boxes, and each column is marked with a check mark. If you remove the check mark, the next time you save the query that column deleted.

• Each subsequent row is a logical function applied to each data record in the data set that determines if the query returns that record for visualization.

• Each cell can also contain a comparison operation for the attribute column it falls under, such as greater than, less than, or equal to. Comparisons within each individual row have a logical AND statement applied to create a conditional statement. A logical OR statement is then applied to all of the rows, that is, if a record returns true for the statement in a single row, it becomes part of the returned data set.


• • • ••

White Paper


When you click a single cell to add a comparison, two buttons are displayed in the selected cell, with a larger version of the contents of the cell displayed above the table, as shown below. In this example, the second cell in row 2 is selected.

The buttons that are displayed contain two sets of functions that vary depending on the type of attribute you are viewing. The available actions of the second button are dependent on the function that is selected using the first button. In this example, the attribute “Total


• • •••

White Paper


Virtual Memory (Kbytes)” is numerical data, and the following options are available under the first button.

Value of expression returns the value of the expression for comparison by using the second set of functions, which are your standard set of numerical comparison operations, as shown below.

These operators compare the value of the data against whatever value is placed in the cell itself. However, if the See if a value is within a range option is selected, a pop-up dialog box is displayed, requesting additional information, as shown below.


• • • ••

White Paper


After clicking OK, the available options in the second set of functions change.

Grouping

In some cases, especially in an SOA environment, you do not want to list all of the information record by record, but instead, the information is grouped according to certain categories and the data is summarized. To do this, click the Advanced… button on the Specification tab. After clicking that button, the following dialog box is displayed.

The Sort By tab allows you to sort the data for viewing by attribute. Select the attribute name from the drop-down box and select an ascending or descending sort.


• • •••

White Paper


The First/Last tab allows the data sets to be filtered by time and also allows only the first or last X records in the data set to be viewed. For grouping purposes, you are interested only in the Group By tab.


• • • ••

White Paper


In the Group By tab, you can choose an attribute by which to group the data. In this case, the System_Name attribute has been chosen. All of the data records that have the same exact System_Name value are grouped together, resulting in one and only one record for each different value of System_Name. The values for that record are not yet useful, as they only represent the values associated with the last recorded System_Name value. For the data to be useful, go back to the Specification tab and click the fx button next to the column title, as shown below.

Clicking the fx button brings up the grouping functions menu, allowing you to specify the function to be applied to that attribute. That function is then run on that attribute over the available set of data. Note that several limitations exist with regard to group data functions:

1. The function Count of group members has nothing to do with any single attribute, but rather requires an attribute column to hold the data. If a column is used for this computation, the contents of that column cannot be used for any other computation.

2. Each column can be used only one time and both the minimum and maximum group attribute values cannot be returned; it has to be either one or the other.

3. You cannot group and sort.


• • •••

White Paper


System Filtering

In the Query Editor window, click the Query Results Source tab to show the following screen:

By default, the Let system assign automatically radio button is selected. In this selection, all of the systems that have the associated agent installed are assigned individually. Note in the example that the arrows in the middle are grayed out, and there are no selections available on either of the lists on the right side. If you want to modify this, select the Let user assign explicitly radio button.


• • • ••

White Paper


The arrows are active and all of the available system lists (groups) for this attribute table are made visible. If you want to create a system list, click the Edit Managed System Lists, which brings up the window that is displayed on the following page.


• • •••

White Paper


In this window you can select the type of agent you want to create a list for, and then select from the buttons on the top left to create a new list or copy an existing list (if you have an existing list currently selected). You are then presented on the right with the following two lists:

• The Assigned list contains all systems that are currently a member of this list

• The Available Managed Systems list contains all systems that have the selected agent installed but are not part of the current list

You can move systems back and forth between the lists by using the arrow buttons in the middle. After creating a list and pressing OK, the list is now available for use in the Query Results Source tab for that agent type.


• • • ••

White Paper



• • •••

White Paper


SOA Workspace Example

Putting everything together from the previous sections, you can create a workspace focused on the visualization of an SOA environment.

This section provides a set of basic workspaces that you can use. The queries used to construct the workspaces are provided in a table in each section. Keep in mind that the workspaces contained here represent only a small fraction of the configuration options available in the CandleNet Portal.

Workspace 1: SOA Overall

This workspace gives you an overall view of how the selected systems in your environment are operating. The upper-left view shows the memory usage of all monitored UNIX systems in bar chart form, while the upper-right view shows the processor usage of all monitored UNIX systems, also in bar chart form.

The lower-left view shows the status of all monitored WebSphere Application Server installations in the SOA in a table format, while the lower-right view shows the status for all MQ deployments, also in a table view format. The associated queries are located directly beneath the examples.


• • • ••

White Paper


Query: UNIX > System > System Virtual Memory

Filter: Virtual Memory Percent Used

Query: UNIX > SMP_CPU

Group by: System_Name

Filter: AllQuery: WebSphere Application Servers for All Versions > Application_Server > Application_Server

Filter: Node Name, Server Name, Server Type, Status, % of Time Thread Count Exceeded Max in All Pools, Number of In-flight Workloads

Query: MQSeries > Managers > Queue Manager Status

Filter: All


• • •••

White Paper


Workspace 2: MQ Detail

Query: MQSERIES >Managers >Queue Manager Status

Filter: Monitored Queues, Open Queues, # Qs With High Depth, # of Qs Put-Inhib, # of Qs Get-Inhib

Query: MQSERIES >Channel_Statistics > Channel Performance by Type/Status

Filter: All

Query: MQSERIES >Queue_Statistics >Queue Statistics

Filter: Origin Node, Queue Name, % Full, Get Status, Put Status, Msgs Put per Sec, Msgs Read per Sec, Time to Zero Msgs (Secs), Time to Full Queue (Secs), QMgr Name, Host Name


• • • ••

White Paper


Workspace 3: WebSphere Application Server Detail

Query: WebSphere Application Servers for All Versions >Web_Applications >Web Applications

Filter: AllQuery: WebSphere Application Server >Thread_Pools >Thread Pools

Filter: AllQuery: WebSphere Application Servers for All Versions >Application_Server >Application Server

Filter: Origin Node, Node Name, Server Type, Version, Status, Percent of CPU Used, Average Number of Concurrently Live Sessions, % of Time ORB Thread Count Exceeded Maximum, % of Time WC Thread Count Exceeded Maximum, Connections Destroyed, CPU Milliseconds Used, Average Active Threads in All Pools, Average Threads in All Pools, % of Time Thread Count Exceeded Maximum in All Pools, Number of HTTP Sessions, Number of In-flight Workloads

Query: WebSphere Application Servers for All Versions >Servlets_JSPs >Servlets/JSPs

Filter: Origin Node, Web Application Name, Average Servlet Response Time, Node Name, Server Name, Servlet/JSP Name


• • •••

White Paper


Workspace 4: UNIX System Detail

Query: Unix >System >System Virtual Memory

Filter: Virtual Memory Percent Used

Query: Unix >SMP_CPU

Group By: System Name

Filter: CPU Busy (Percent)Query: Unix >Network >Network

Filter: Frames Received, Frames Transmitted

Query: Unix >Disk >Disk Utilization

Filter: Space Used PercentQuery: Unix >System >System

Filter: All


• • • ••

White Paper


Workspace 5: Windows System Detail

Query: Windows NT >NT_Processor

Group By: Server Name

Filter: % Processor Time

Query: Windows NT->Memory Allocation

Filter: Available kBytes

Query: Windows NT >NT_Logical_Disk > Logical Disk

Filter: % Free

Query: Windows NT > NT_Paging_File > Paging File

Filter: % Usage


• • •••

White Paper


Query: Windows NT >NT_System >System Overview

Filter: All


• • • ••

White Paper


Creating Situations in Tivoli OMEGAMON XE

This guide provides a step-by-step account of how to create Tivoli OMEGAMON XE situations. Situations are used to alert the operations staff of serious errors and problems in the environment. This section provides an example of how to create a situation that ensures that all the WebSphere Application Servers are running. Follow the steps in this guide to create other similar situations to monitor the important aspects of your environment.

Creating a New Situation

Begin by selecting a resource you want to monitor in the Navigator. In this case, a WebSphere Application Server Agent is selected. Be as specific as possible and select a lower-level resource in the Navigator. Right-click the resource and select Situations in the pop-up menu.


• • •••

White Paper


In the Situation Editor, select the Create new Situation icon in the toolbar.

Fill in the Name and Description fields in the Create Situation dialog box.


• • • ••

White Paper


The Select Attributes dialog box is displayed. Attributes are organized into groups that are typically associated with types of resources and specific attribute items. In the Group section, select Application_Server and the Status attribute item.

You are returned to the main situation editor window and a set of tabs is displayed. The Condition tab lets you specify when the situation generates an event. The condition functions work just like the filter functions described in Creating and Modifying Queries. In this case, set the condition to be true anytime the Status attribute is not equal to Running.

The Sampling interval determines how often the situation is evaluated. Setting small values gives a quicker indication but uses more system resources. In this example, the interval is set to 2 minutes.

Sound let you enable and specify a WAV sound file to play on the console when a situation is triggered. This example does not play a sound.

State sets the severity of the event that is sent to the Event Console and can be set to critical, warning, or informational.

Run at startup controls whether the situation is started automatically or manually. If selected, the situation is started automatically when OK or Apply is selected and when the


• • •••

White Paper


system is started. The situation must be started manually if Run at startup is not selected. In this example, it is selected.


• • • ••

White Paper


The Distribution tab determines the resources this situation monitors. In this example, all the application servers were selected in the Available Managed Systems section and moved to the Assigned section.

The Expert Advice tab is not shown, but it lets you specify text advice that is displayed when the situation is generated.


• • •••

White Paper


The Action tab is used to set up a predetermined action that you want the system to run when the situation is generated. This example does not define an action, but you can define an action to automatically restart the application server.


• • • ••

White Paper


When the situation is detected, an event appears in the Enterprise Event Console and the resource and parents of the resource are flagged in the Navigator. In this example, server2 is not running.


• • •••

White Paper


Configuring Tivoli Monitoring for Transaction Performance to Send Events to the Tivoli Enterprise Console

Perform the steps in this section to set up the forwarding of events from your Tivoli Monitoring for Transaction Performance management server to the Tivoli Enterprise Console. When complete, you can see events in Tivoli Enterprise Console that alert you when your management agents become unavailable, as well as when a threshold has been exceeded in your listening policies. For a complete list of events provided, refer to the official Tivoli Monitoring for Transaction Performance product documentation.

On the Tivoli Enterprise Console Server

Import the TransPerf.baroc file, which is located in the MS_home/config/tec directory on your Tivoli Monitoring for Transaction Performance management server (where MS_home is the directory path where the Tivoli Monitoring for Transaction Performance management server was installed).

On the Tivoli Monitoring for Transaction Performance Management Server

1. Navigate to the MS_home/config directory and locate the eif.conf file.

2. Edit the file to reflect the name of your Tivoli Enterprise Console server. The particular line you need to edit begins with the ServerLocation parameter. The default port for Windows-based servers is 5529.

3. If the Tivoli Enterprise Console server is located on a UNIX server, set ServerPort = 0.

4. Save the file and restart the management server.

5. When the restart is complete, run the following command on your Tivoli Enterprise Console server:

wcrtsrc –l TMTP TMTP

6. Now, when you create your listening policy, you can select the Tivoli Enterprise Console option when defining your response levels.


• • • ••

White Paper


Management of Service-Oriented Architecture â€” IBM Tivoli SOA

Documents