Introducing IBM Tivoli Monitoring for Web Infrastructure

Transcription

1 Front cover Introducing IBM Tivoli Monitoring for Web Infrastructure Gain centralized control of all the Web servers in the enterprise Pro-actively manage Web server resources Report Web server availability and performance Morten Moeller Edson Manoel Shajeer K. Mohammed Massimiliano Parlione ibm.com/redbooks

2

3 International Technical Support Organization Introducing IBM Tivoli Monitoring for Web Infrastructure December 2002 SG

4 Note: Before using this information and the product it supports, read the information in Notices on page xiii. First Edition (December 2002) This edition applies to Version 5.1 for the IBM Tivoli Monitoring for Web Infrastructure (product number 5724-C01). Copyright International Business Machines Corporation All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

5 Contents Figures vii Tables xi Notices xiii Trademarks xiv Preface xv The team that wrote this redbook xvi Become a published author xvii Comments welcome xvii Chapter 1. Managing your e-business infrastructure e-business applications - complex layers of services Managing e-business applications Architecting e-business applications infrastructures Basic products used to facilitate e-business applications Managing e-business applications using Tivoli Tivoli product structure IBM Tivoli Monitoring for Web Infrastructure Summary Chapter 2. Implementing Web Infrastructure Monitoring Installing an ITM module Plan your management domain Check prerequisite software and patches Choose the installation options Verify the Installation Configuring the management domain Adding roles for administrators and users Installing and linking Java Runtime Environment on endpoints Configuring the Web servers for monitoring Creating managed application objects Deploying monitors Creating profile managers and profiles Adding subscribers to the profile managers Adding default resource models to profiles Distributing profiles Operating Tivoli Monitoring for Web Infrastructure Copyright IBM Corp All rights reserved. iii

6 2.4.1 Actions available to Apache, iplanet and IIS objects Functions provided by WebSphere Application Server objects Chapter 3. Real-time monitoring Working with the Web Health Console Configuration Operating the Web Health Console Working with Tivoli Enterprise Console IBM Tivoli Monitoring for Web Infrastructure events and rules Working with Tivoli Business Systems Manager Tivoli Business Systems Manager event flow Setting up Tivoli Business Systems Manager integration Resource discovery Using Tivoli Business Systems Manager Chapter 4. Extending the monitoring solution Customizing resource model runtime settings Apache management automation An Apache server management scenario Standard automation using default resource models and tasks Advanced automation - building a new resource model Chapter 5. Troubleshooting Troubleshooting Web Infrastructure modules Endpoint architecture Logfiles Tracing Some common problems and solutions Resource Models development Chapter 6. Management reporting Overview of Tivoli Enterprise Data Warehouse TEDW concepts and components Monitoring process data flow Install and configure the Warehouse components Installing and configuring the ITM Warehouse Support Installing and Configuring the Warehouse modules Setting up Web Infrastructure Warehouse modules ITM for Web Infrastructure reports Working with reports Defining your own reports Appendix A. Resource models context parameters Apache HTTP server context parameters iv Introducing IBM Tivoli Monitoring for Web Infrastructure

7 IIS context parameters iplanet context parameters WebSphere Application Server context parameters Appendix B. Patterns for e-business Introduction to Patterns for e-business The Patterns for e-business layered asset model How to use the Patterns for e-business Appendix C. Additional material Locating the Web material Using the Web material System requirements for downloading the Web material How to use the Web material Abbreviations and acronyms Related publications IBM Redbooks Other resources Referenced Web sites How to get IBM Redbooks IBM Redbooks collections Index Contents v

8 vi Introducing IBM Tivoli Monitoring for Web Infrastructure

9 Figures 1-1 Growing infrastructural complexity Layers of service The ITIL Service Management disciplines Key relationships between Service Management disciplines A typical e-business application infrastructure e-business solution specific service layers Logical view of an e-business solution A typical Tivoli managed e-business application infrastructure Tivoli Management Solutions Tivoli s Performance and Availability product structure Install product dialog DMlinkJRE task dialog Tivoli Desktop after Installing all modules Create Apache HTTP Server managed application object Policy region: Monitoring for Apache HTTP Server Create iplanet Web server object Policy region: Monitoring for iplanet Web server Create Internet Information Server object Policy region: Monitoring for IIS Web server Create WSAdministrationServer objects Policy region: Monitoring for WebSphere Application Server Create WSApplication Server object Monitoring for WebSphere Application Server Using the Apache module with the Web Health Console Event flow for Tivoli Business Systems Manager integration TBSM database GEMLookupCID rows Tivoli TBSM Task Server WebSphere module TBSM discovery task WebSphere discovery task module TBSM Console after the discovery process Apache starting and stopping from the TBSM Console Internet Information Server starting and stopping iplanet Web server starting and stopping from the TBSM Console WebSphere Administration Server management from TBSM console WebSphere task: List Application Servers from the TBSM Console WebSphere Application Server management from the TBSM console Resource models, parameters and profiles Profile properties Copyright IBM Corp All rights reserved. vii

10 4-3 Edit resource model Indications and actions Resource model parameters Scheduling Resource model logging Apache server automated management scenario logical design ApacheAutomation profile Create Apache server automation task dialog Generic executable for a task details Simple Rule Window Actions in rule Edit Arguments Renaming ApacheServerStopped event The new event ApacheServerReinitialized Apache server configuration change resource model Endpoint architecture for IBM Tivoli Monitoring for Web Infrastructure A typical TEDW environment ITM for Web Infrastructure data flow Installation scenario Installing warehouse support RIM setup options Data logging Path to the installation media for the ITM Generic ETL1 program ITM Generic ETL1 program installation Installation summary window IBM Tivoli Monitoring Generic ETL1 Sources AMX_ITM_RIM_Source user ID information IBM Tivoli Monitoring Generic ETL1 Target AMX_TWH_CDW_Target user ID information Schedule AMX_c05_ETL1_Process Schedule configuration for AMX_c05_ETL1_Process Promoting scheduled processes to Production status Path to the installation media for the Apache ETL program Apache ETL programs installation Installation Summary Window IBM Tivoli Monitoring for Web Infrastructure ETL Sources GWA_TWH_CDW_Source user ID information IBM Tivoli Monitoring for Web Infrastructure ETL Targets GWA_TWH_MART_Target user ID information Scheduling GWA_m05_CleanDataMart_Process Schedule configuration for GWA_m05_CleanDataMart_Process Promoting scheduled ETL processes to Production status Running reports from IBM Console viii Introducing IBM Tivoli Monitoring for Web Infrastructure

11 6-28 Manage Data Marts B-1 Patterns layered asset model B-2 Pattern representation of a Custom design B-3 Custom design Figures ix

12 x Introducing IBM Tivoli Monitoring for Web Infrastructure

13 Tables 2-1 Required prerequisite software Optional Tivoli components Tivoli roles for IBM Tivoli Monitoring for Web Infrastructure modules Default managed resources and command lines Default resource models Functions provided by Web server modules Task Library WebSphere tasks Web Health console configuration files Web server modules baroc files WebSphere Application Server module baroc files Web server module rule set files WebSphere Application Server module rule set files TBSM discovery script for the Web server modules Module Directory Measurement code Warehouse Source Modules Warehouse Target Modules Warehouse processes Warehouse processes and components Report names and descriptions Default data marts Default Star Schemas Default time filter names and values A-1 Apache context variables A-2 IIS context variables A-3 iplanet Context Variables A-4 iwebsphere Context Variables B-1 Business patterns B-2 Integration patterns B-3 Composite patterns Copyright IBM Corp All rights reserved. xi

14 xii Introducing IBM Tivoli Monitoring for Web Infrastructure

15 Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-ibm product, program, or service. IBM may have patents or pending patent applications covering subject matter described 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: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-ibm Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-ibm products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-ibm products. Questions on the capabilities of non-ibm products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces. Copyright IBM Corp All rights reserved. xiii

16 Trademarks The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: AIX CICS DB2 DB2 Universal Database IBM IBM eserver IMS iseries OS/400 Perform Redbooks(logo) SecureWay SP Tivoli Tivoli Enterprise Tivoli Enterprise Console Tivoli Management Environment TME WebSphere The following terms are trademarks of International Business Machines Corporation and Lotus Development Corporation in the United States, other countries, or both: Notes The following terms are trademarks of other companies: ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company, product, and service names may be trademarks or service marks of others. xiv Introducing IBM Tivoli Monitoring for Web Infrastructure

17 Preface This IBM Redbook describes the IBM Tivoli Monitoring for Web Infrastructure Version 5.1 product. This product provides solutions for managing Apache, Sun iplanet, and Microsoft Internet Information Servers as well as IBM WebSphere Application Server environments as part of an overall enterprise management solution. This redbook will help you install, configure, and use the Monitoring for Web Infrastructure product in conjunction with other Tivoli products, such as the base IBM Tivoli Monitoring product, Tivoli Enterprise Console, Inventory, Business Systems Manager, and the Tivoli Enterprise Data Warehouse. IBM Tivoli Monitoring for Web Infrastructure is one of several solutions that provides management of key components of business-critical application environments. The use of the IBM Tivoli Monitoring family of products in conjunction with other IBM Tivoli system management products provides an integrated and end-to-end solution for today s enterprises. This book is structured as follows: Chapter 1, Managing your e-business infrastructure on page 1 includes an overview of Web servers and application servers, the roles they play in an e-business environment, and the management challenges they raise. It then provides an overview of IBM Tivoli Monitoring for Web Infrastructure and the solution it provides. Chapter 2, Implementing Web Infrastructure Monitoring on page 25 provides an overview of the installation procedures, as well as detailed information about performing the initial configuration of the product and how to start using its basic functions. Chapter 3, Real-time monitoring on page 57 describes the various options for real-time monitoring of your environment, including the use of the Web Health Console, Tivoli Enterprise Console, and Tivoli Business Systems Manager. Chapter 4, Extending the monitoring solution on page 79 addresses the resource models provided by IBM Tivoli Monitoring for Web Infrastructure and provides a simple example of how they could be customized to provide more advanced capabilities. Chapter 5, Troubleshooting on page 113 provides useful information related to problem determination and troubleshooting. Copyright IBM Corp All rights reserved. xv

18 Chapter 6, Management reporting on page 119 discusses historical reporting in detail by using the Tivoli Enterprise Data Warehouse. The team that wrote this redbook This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center. Morten Moeller is a Project Leader at the International Technical Support Organization, Austin Center. He applies his extensive field experience as an IBM Certified Consulting IT Specialist to his work at the ITSO where he writes on all areas of Systems Management. Before joining the ITSO, Morten worked in the Professional Services Organization of IBM Denmark as a Distributed Systems Management Specialist where he was involved in numerous projects designing and implementing systems management solutions for major customers in the manufacturing and financial industries. Edson Manoel is a Software Engineer at IBM Corporation - International Technical Support Organization, Austin Center. He applies his extensive field experience as an IT Specialist to his work at the ITSO in the Systems Management area. Prior to joining the ITSO, Edson worked in the Software Group as a Tivoli Technology Ambassador and in IBM Brazil Professional Services Organization as a Certified IT Specialist. He was involved in numerous projects, designing and implementing systems management solutions for IBM customers and Business Partners. Edson holds a bachelor s degree in Applied Mathematics from Universidade de Sao Paulo, Brazil. Shajeer K. Mohammed is a Senior Software Engineer at the IBM Software Labs, India. He has been working with IBM for five years, mostly designing, developing and maintaining systems management applications across multiple operating systems. He holds a bachelor s degree in Computer Engineering from Karnatak University. Currently he is developing Distributed Monitoring for operating systems on Tivoli Framework. Massimiliano Parlione is a Software Engineer in the IBM-Tivoli Lab in Rome, Italy. He has been with IBM-Tivoli since April He worked on the team that developed and designed TMX4J (Tivoli Java Management Extensions) and TWCM (Tivoli Web Component Manager). He is currently working on the OS/400 porting of the IBM Tivoli Monitoring product. Before joining IBM, Mr. Parlione worked as an independent Consultant for the Italian Research Council (CNR) and as an employee of the Regione Marche regional government. He received his degree in Computer Science from the University of L'Aquila, Italy, in July 1995 and a doctorate in Computer Science from the University "La Sapienza" of Rome in April xvi Introducing IBM Tivoli Monitoring for Web Infrastructure

19 Thanks to the following people for their contributions to this project: Budi Darmawan, Bart Jacob International Technical Support Organization, Austin Center Marco De Gregorio Tivoli Systems, Rome Cheryl Thrailkill Tivoli Systems, Austin Scott L Mitchell IBM, Raleigh Amol B Mahamuni, IBM Software Labs, India Become a published author Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.html Comments welcome Your comments are important to us! We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at: ibm.com/redbooks Send your comments in an Internet note to: [email protected] Preface xvii

20 Mail your comments to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip Burnet Road Austin, Texas xviii Introducing IBM Tivoli Monitoring for Web Infrastructure

21 1 Chapter 1. Managing your e-business infrastructure IBM Tivoli Monitoring for Web Infrastructure is one of a family of solutions based on the IBM Tivoli Monitoring product. IBM Tivoli Monitoring evolved from the Tivoli Distributed Monitoring product. With its new architecture based on resource models, IBM Tivoli Monitoring provides a solid foundation for the development of management solutions addressing the complex needs of today s IT infrastructures. A set of proactive analysis components (PACs) built on top of IBM Tivoli Monitoring provide a comprehensive set of solutions for companies facing the challenge of becoming e-businesses. These PACs are delivered through a set of offerings, that currently include: IBM Tivoli Monitoring for Applications IBM Tivoli Monitoring for Business Integration IBM Tivoli Monitoring for Databases IBM Tivoli Monitoring for Messaging and Collaboration IBM Tivoli Monitoring for Web Infrastructure The subject of this document IBM Tivoli Monitoring for Web Infrastructure includes proactive analysis components for the most common HTTP servers: IBM HTTP Server, Microsoft Internet Information Server (IIS), and Sun iplanet Server, as well as components for IBM WebSphere Application Server (WAS). Combined, these components will help to ensure the availability and performance of critical applications in an e-business environment. Copyright IBM Corp All rights reserved. 1

22 The capabilities of the PACs include: Auto-discovery of the resources to be monitored Problem identification, notification and correction Automated best practices for management and operations Historical reporting through a centralized data warehouse IBM Tivoli Monitoring for Web Infrastructure provides enhanced capabilities over the predecessor products, Tivoli Manager for WebSphere Application Server 1.1, in addition to brand new capabilities related to managing Web servers. Let s begin by providing a short description of the challenges of e-business provisioning, in order to identify the management needs and issues related to provisioning e-business applications. 1.1 e-business applications - complex layers of services The complexity of a modern e-business solution is much higher than was the case for the standard terminal processing oriented systems of the seventies and eighties, as illustrated in Figure 1-1. However, despite major revisions, especially during the turn of the last century, many of the legacy systems are still the bread-and-butter of many enterprises, and the e-business solutions in these environments are designed to front-end these mainframe oriented application complexes. 2 Introducing IBM Tivoli Monitoring for Web Infrastructure

23 Business Systems Databases Business Systems Applications Business Systems Front End Figure 1-1 Growing infrastructural complexity The complex infrastructure needed to facilitate e-business solutions has more or less been dictated by requirements for standardization of client run-time environments in order to allow any standard browser to access the e-business sites. In addition, the application runtime technologies plays a major role, since these must ensure platform independence and seamless integration to the legacy back-end systems, either directly to the mainframe or through the server part of the old client-server solution. Furthermore, making the applications accessible from anywhere in the world by any person on the planet, brings some security (authentication, authorization, and integrity) issues, that did not need addressing in the old client-server systems, since all clients were well known entities in the intra-company network. Because of the central role that the Web and application servers play within a business and the fact that it is supported (and typically deployed) across a variety of platforms across the enterprise, there are several major challenges to managing the e-business infrastructure. Some of these are: Chapter 1. Managing your e-business infrastructure 3

24 Managing Web and application servers on multiple platforms in a consistent manner from a central console Defining the e-business infrastructure from one central console Monitoring your Web resources (sites and applications) to know when problems have, or are about to, occur Taking corrective actions when a problem is detected in a platform independent way Gathering data across all e-business environments to analyze events, messages and metrics The degree of complexity of e-business infrastructure system management is directly proportional to the size of the infrastructure you are trying to manage. In its simplest form, an e-business infrastructure is comprised of a single Web server and its resources, but can grow to hundreds or even thousands of Web and application servers spread throughout the enterprise. To add to the complexity, the e-business infrastructure may span many platforms with different networks protocols, hardware, operating systems and applications. Each platform possesses its unique and specific systems management needs and requirements, not to mention a varying level of support for the administrative tools and interfaces. Every component in the e-business infrastructure is a potential show-stopper, bottleneck or even single-point-of-failure. Each and every one of them provides specialized services needed to facilitate the e-business application system. The term application systems is used deliberately to enforce the point that no single component by itself provides a total solution - the application is pieced together by a combination of standard off-the-shelf components and home-grown components. The standard components provide general services such as session control, authentication and access control, messaging, database access and the home-grown components adds the application logic needed to glue all the different bits and pieces together to perform the specific functions for that application system. On an enterprise level, chances are, that many of the home-grown components may be promoted to standard status to ensure specific company standards or policies. At a first glance, breaking the e-business application up into a many specialized services may be regarded as counter productive, and very expensive to implement. However specialization allows for sharing of common components, such as Web-, application-, security-, and database servers between more e-business application systems, and it is key to ensuring availability and performance of the application system as a whole by allowing for duplication and distribution of selected components to meet specific resource requirements or increase the performance of the application systems as a whole. In addition, this 4 Introducing IBM Tivoli Monitoring for Web Infrastructure

25 itemizing of the total solution allows for almost seamless adoption of new technologies for selected areas without exposing the total system to change. Whether the components in the e-business system are commercial, standard, or application specific, each of them will most likely require the services of other general services, such as communication facilities, storage space, processing power, and the computers in which they run need electrical power, shelter from rain and sun, access security, and perhaps even cooling. As it turns out, the e-business application relies on several layers of services that may be provided internally or by external companies. This is illustrated in Figure 1-2. Figure 1-2 Layers of service As a matter of fact, it is not exactly the e-business application that relies on the services depicted above, the correct notion is that all the individual components (Web-servers, database servers, application servers, lines, routers, hubs, switches and so forth) each relies on underlying services provided by some other component. By opening up the components, this can be broken down even further, but that is beyond this discussion. The point is that the e-business solution is exactly as solid, robust, and stable as the weakest link of the chain of services that make up the entire solution, and since the bottom line results of an enterprise my be drastically effected by the quality of the e-business solutions provided, a worst case scenario may prove that a power failure in Hong Kong may impact the sales figures in Greece, and that increased surface activity on the sun may result in satellite communication problems that prevents car rental in Chattanooga. While mankind cannot prevent increased activity of the sun or wind (yet), there are a number of technologies available to allow for continuing, centralized monitoring and surveillance of the e-business solution components. These technologies will help manage the IT resources, that are part of the e-business solution. Some of these technologies may even be applied to manage the non-it resources such as power, cooling, and access control. Chapter 1. Managing your e-business infrastructure 5

26 However, since each layer in any component is specialized, and by nature different from the others, they require different types of management. In addition, from a management point of view, the top layer of any component is the most interesting, since it s the layer that provides the unique service that is required by that particular component. For a Web server, the top layer is the HTTP server itself. This is the mission critical layer, even though it needs networking, operating system, hardware, and power to operate. On the other hand, an e-business application server, although it also may have a Web server installed, because this is needed to communicate with the dedicated Web Server, the mission critical layer is the application server, and the Web server is considered secondary in this case, just like operating system, power, and networking. This said, all the underlying services are needed and must operate flawlessly in order for the top layer to provide it s services. It is much like driving a car you monitor the speedometer on a regular basis, or constantly, in order to avoid penalties by violating the changing speed limits, but the fuel indicator is only checked from time to time, or when the indicator alters you with a red or yellow light, in order for you to be able to perform preventive maintenance by filling up the tank Managing e-business applications Specialized functions require specialized management, and general functions require general management. From the above, it is obvious that the management of the operating system, hardware layer, and networking layer may be general, since it is used by most of the components of the e-business infrastructure. On the other hand, a management tool for Web application servers might not be very well suited for managing the database server. Up until now the term managing has been widely used, but not yet explained or defined. Control over and management of the computer system and its vital components is critical to the continuing operation of the system, and thereby the timely availability of the services/functions provided by the system. This includes controlling both physical and logical access to the system, to prevent unauthorized modifications to the core components, and monitoring the availability of the systems as a whole as well as the performance and capacity usage of the individual resources such as disk space, networking equipment, memory, and processor usage. Of course these control and monitoring activities have to be performed in a cost-effective way so the cost of controlling any resource does not become higher than the cost of the resource itself. It does not make much business sense to spend $1000 to manage a $200 hard disk, unless the data on that hard disk represents real value to the business in excess of $1000. Planning for recovery of the systems in case of a disaster also needs to be addressed, since being without computer systems for days or weeks may have a huge impact on the ability to conduct business. 6 Introducing IBM Tivoli Monitoring for Web Infrastructure

27 To successfully manage and control computer systems there still is one important aspect that has to be covered. We have mentioned various hardware and software components that collectively provides a service, but which components are part of the IT infrastructure, where are they, and how do they relate to one another? A prerequisite for successful management is the detailed knowledge of which components to manage, how the components interrelate, and how these components may be manipulated in order to control their behavior. In addition, now, that IT has become an integral part of doing business, it is equally important, from an IT management point of view, to know which commitments we have made with respect to availability and performance of the e-business solutions, and what commitments our sub-contractors have made to us. And for planning and prioritization purposes it is vital to combine our knowledge about the components in the infrastructure with the commitments we have made in order to assess and manage the impact of component malfunction or resource shortage. In short, in a modern e-business oriented environment, one of the most important management tasks is to control and manage the Service Catalog in which all the provisioned services are defined and described, and the Service Level Agreements, in which the commitments of the IT department are spelled out. For the purposes of this discussion, we will turn to the widely recognized Information Technology Infrastructure Library (ITIL). The IT Infrastructure Library was originally developed by the British Government Agency Central Computer and Telecommunications Agency (CCTA), but has over the past decade or more gained acceptance in the private sector. One of the reasons behind this acceptance is, that most IT organizations, who are met with requirements to promise or guarantee performance and availability, agree that there is no point in agreeing to deliver a service at a specific level if the basic tools and processes needed to deploy, manage, monitor, correct, and report the service level achieved have not been established. The ITIL groups all of these activities into two major areas, Service Delivery and Service Support, as shown in Figure 1-3. Chapter 1. Managing your e-business infrastructure 7

28 Figure 1-3 The ITIL Service Management disciplines The primary objectives of the Service Delivery discipline are proactive, and consists primarily of planning and ensuring that the service is delivered according to plan, which is the Service Level Agreement. In order to make this happen, the tasks described in the following have to be accomplished. Service Delivery Within ITIL, the pro-active disciplines are grouped in the Service Delivery area: Service Level Management Service Level Management involves managing customer expectations and negotiating Service Level Agreements. This involves identifying customer requirements and determining how these can best be met within the agreed-upon budget. Work together will all IT disciplines and departments to plan and ensure delivery of services. This involves setting measurable performance targets, monitoring performance, and taking action when targets are not met. Cost Management Cost Management consists of registering and maintaining cost accounts related to the use of IT services and delivering cost statistics and reports to Service Level Management to assist in obtaining the correct balance between 8 Introducing IBM Tivoli Monitoring for Web Infrastructure

29 service cost and delivery. It also means assisting in pricing the services in the Service Catalog and Service Level Agreements. Contingency Planning Contingency Planning plans and ensures the continuing delivery or minimum outage of the service by reducing the impact of disasters, emergencies, and major incidents. This work is done in close collaboration with the company s business continuity management, which is responsible for protecting all aspects of the company s business including IT. Capacity Management Capacity Management plans and ensures that adequate capacity with the expected performance characteristics is available to support the service delivery. It delivers capacity usage, performance, and workload management statistics as well as trend analysis to Service Level Management. Availability Management Availability Management means planning and ensuring the overall availability of the services and providing management information in the form of availability statistics, including security violations, to Service Level Management. Even though not explicitly mentioned in the ITIL definition, for this discussion, content management is included in this discipline. This discipline may also include negotiating underpinning contracts with external suppliers and the definition of maintenance windows and recovery times. The disciplines in the Service Support group are mainly reactive and are concerned with implementing the plans and providing management information regarding the levels of service achieved. Service Support The re-active disciplines that are considered part of the Service Support group are: Configuration Management Configuration Management is responsible for registering all components in the IT service, including customers, contracts, SLAs, hardware and software components, and more, and maintain a repository of configurable attributes and relationships between the components. Help Desk The Help Desk acts at the main point-of-contact for users of the service. It registers incidents, allocates severity, and coordinates the efforts of support teams to ensure timely and correct problems resolution. Chapter 1. Managing your e-business infrastructure 9

30 Escalation times are noted in the SLA and, as such, are agreed on between the customer and the IT department. It provides statistics to Service Level Management to demonstrate the service levels achieved. Problem Management Problem Management implements and uses procedures to perform problem diagnosis and identify solutions that correct problems. It registers solutions in the configuration repository. Escalation times should be agreed upon internally with Service Level Management during the SLA negotiation. It provides problem resolution statistics to support Service Level Management. Change Management Change Management plans and ensures that the impact of a change to any component of a service is well known and that the implications regarding service level achievements are minimized. This includes changes to the SLA documents and the Service Catalog as well as organizational changes and changes to hardware and software components. Software Control and Distribution It is the responsibility of Software Control and Distribution to manage the master software repository and deploy software components of services. It deploys changes at the request of Change Management and provides management reports regarding deployment. 10 Introducing IBM Tivoli Monitoring for Web Infrastructure

31 The key relationships among the disciplines are shown in Figure 1-4. Figure 1-4 Key relationships between Service Management disciplines For the remainder of this discussion, we limit ourselves to discussing Capacity and Availability Management of the e-business solutions. Contrary to the other disciplines which are considered common for all types of services provided by the IT organization, the e-business solutions provide special challenges to management due to their high visibility and importance to the bottom line business results, their level of distribution, and the special security issues that characterizes the Internet Architecting e-business applications infrastructures In a typical e-business environment, the application infrastructure consists of three separate tiers, and the communication between these are restricted. These tiers are typically: Demilitarized zone This is the tier accessible by all the external users of the applications. This tier functions as the gatekeeper to the entire system, and functions such as Chapter 1. Managing your e-business infrastructure 11

32 access control, and intrusion detection are enforced here. The only other part of the intra-company network that the DMZ can talk to is the Application Tier. Application Tier This is usually implemented as a dedicated part of the network where the application servers reside. End-user requests are routed from the DMZ to the specific servers in this tier, where they are serviced. In case the applications need to use resources from, for example, company wide databases, these are requested from the back-end tier, where all the secured company IT assets reside. As the case was for communication between the DMZ and the Application Tier, the communication between the Application Tier and the back-end systems is established through firewalls and using well-known connection ports. This helps ensure that only known transactions from known machines can communicate from the outside with the company databases or legacy transaction systems such as CICS or IMS. Apart from specific application servers, this tier also hosts load balancing devices and other infrastructural components such as MQ Servers needed to implement a given application architecture. The Back-end Tier This is where all the vital company resources and IT-assets reside. External access to these resources from is only possible through the DMZ and the Application Tier. 12 Introducing IBM Tivoli Monitoring for Web Infrastructure

33 firewall Demillitarized Zone firewall Application Tier firewall Back-end Authentication Access control Intrusion detection... Application hosting/serving (Web- and appliaction servers) Load Balancing Distributed resource servers (MQ, Database etc.) Gateways to Back-end or external resources (MQ, Database etc.)... Back-end and legacy recources (Databases, transactions, etc.) Infrastructural resource servers (MQ, Database etc.) Gateways to external resources... firewall Internal customer segment Internal customer segment Company Intranet Resource sharing... Figure 1-5 A typical e-business application infrastructure This model architecture is a proven way providing secure, scalable, high-availability external access to company data with a minimum of exposure to security violations. However the actual components application servers and infrastructural resources may vary depending upon the nature of the applications, company policies, the requirements to availability and performance, and the capabilities of the technologies used. In case you are in the e-business hosting area, or you have to support multiple Lines-Of-Business that require strict separation, the conceptual architecture shown in Figure 1-5 may be even more complicated. In these situations, one or more of the tiers may have to be duplicated in order to provide the required separation. In addition, the Back-end tier may even be established remotely (relative to the application tier). This is very common when the e-business application hosting is outsourced to an external vendor, such as IBM Global Services. To help designing the most adequate architecture for a specific set of e-business applications, IBM has published a set of e-business patterns that may be used to speed up the process of developing e-business applications and deploying the infrastructure to host these. Chapter 1. Managing your e-business infrastructure 13

34 The concept behind these e-business patterns is to reuse tested and proven architectures with as little modifications as needed. IBM has gathered experiences from more than 20,000 engagements and compiled these into a set of guidelines and associated these with links in order to allow a solution architect to start with a problem and a vision for the solution, and then find a pattern that fits that vision. Then, by drilling down using the patterns process, the architect can further define the additional functional pieces that the application will need to succeed. Finally, the architect can build the application using coding techniques outlined in the associated guidelines. Further details on e-business patterns may be found in Appendix B, Patterns for e-business on page 171. For a full understanding of the relationships between the Composite, the Business, and the Integration patterns, please review the book Patterns for e-business: A strategy for Reuse by Jonathan Adams, Srinivas Koushik, Guru Vasudeva, George Galambos, ISBN: Basic products used to facilitate e-business applications So far, we may conclude that building an e-business solution is like building a vehicle. We want to provide the user with a standard, easy-to-use interface that fulfills the needs of the user and has a common look-and-feel to it; we want to use as many standard components as possible to keep costs down and be able to interchange them seamlessly; we want it to be reliable, and available at all times with a minimum of maintenance; and we want to build in unique features differentiators that make the user choose our product over that of the competitors. The main difference between the vehicle and the e-business solution is that we own and control the solution, the buyer owns and manages the vehicle. The vehicle owner decides when to have the oil changed and when to fill up the fuel tank or adjust the tire pressure. The vehicle owner also decides when to take the vehicle in for a tune-up, when to add chrome fenders and alloy wheels to make the vehicle look better, and when to sell it. The user of and e-business site has none of those choices. At the end of the day, we, as owners of the e-business solution, decide when to rework the user interface to make it look better, when to add resources to increase performance, and ultimately, when to obsolete the solution. This gives us a few advantages over the car manufacturer, in the sense that we can modify the product seamlessly by adding or removing components as needed in order to align the performance with the requirements and adjust the functionality of the product as competition toughens or we engage in new alliances. 14 Introducing IBM Tivoli Monitoring for Web Infrastructure

35 No-matter if the e-business solution front-ends legacy systems or it is a brand new application developed using all the modern, state-of-the-art development tools, an e-business solution may be characterized by three specific layers of services that work together to provide the unique functionality necessary to allow the applications to be used in an Internet environment. Figure 1-6 e-business solution specific service layers The presentation layer needs to be a commonly available tool, that most likely is present on all the machines used by users of the e-business solution. It should support the use of modern development technologies, such as XML, JavaScript and HTML pages. Usually this is referred to as the Browser. The standard communication protocols used to provide connectivity using the Internet is TCP/IP, HTTP and HTTPS. These protocols must be, and most likely are, supported by both client and server machines. The Transformation services are responsible for receiving client requests and transforming these into business transactions that in turn are served by the Solution Server. In addition, it is the responsibility of the Transformation Service to receive results from the Solution Server, and convey them back to the client, in a format that can be handled by the Browser. In e-business solutions that do not interact with legacy systems, the Transformation and Solution Server services may be implemented in the same application, but most likely they are split into two or more dedicated services. This is a very simple representation of the functions that takes place in the transformation service. Among other functions that need to be performed are identification, authentication and authorization control, load balancing, and transaction control. Dedicated servers for each of these functions are usually implemented to provide a robust and scalable e-business environment. In addition some of these are placed in a dedicated network segment the demilitarized zone which, from the point of view of the e-business owner, is fully controlled, and in which client requests are received by well-known, secure Chapter 1. Managing your e-business infrastructure 15

36 systems and passed on to the enterprise network, also known as the intranet. This architecture is used to increase security by avoiding transactions from un-known machines to reach the enterprise network, thereby minimizing the exposure of enterprise data and the risk of hacking. To facilitate secure communication between the DMZ and the intranet, a set of Web servers are usually implemented, and identification, authentication, and authorization are typically handled by a LDAP Server. Browser firewall Web Server (Load Balancer) LDAP Server Web Server Browser firewall firewall Application Server firewall Databases Business Logic Figure 1-7 Logical view of an e-business solution The infrastructure depicted in Figure 1-7 contains all components required to implement a secure e-business solution allowing anyone from anywhere to access and do business with the enterprise. For more information on e-business architectures, please refer to the redbook User-to-Business Patterns for Topology 1 and 2 using WebSphere Advanced Edition, SG , which can be downloaded from the Web site: Tivoli and IBM provides some of the most widely used products to implement the e-business infrastructure. These are: 16 Introducing IBM Tivoli Monitoring for Web Infrastructure

37 IBM HTTP Server Communication and transaction control Tivoli SecureWay Policy Director Identification, authentication and authorization IBM WebSphere Application Server Web application hosting, responsible for the Transformation services IBM WebSphere Edge Server Web application firewalling, load-balancing, Web hosting, responsible for the Transformation services 1.2 Managing e-business applications using Tivoli Even though the e-business patterns helps designing the e-business applications, and breaking them down into functional units that may be implemented in different tiers of the architecture using different hardware and software technologies, the patterns provide little assistance on how to manage these application complexes. Luckily this gap is filled out by solutions from Tivoli Systems. When designing the systems management infrastructure, that is needed to manage the e-business applications, it must be kept in mind that the determining factor for the application architecture is the nature of the application itself. This determines the application infrastructure and the technologies used. However, it does not hurt, if the solution architect consults with systems management specialists while designing the application. The systems management solution has, more or less, to play by the rules set up by the application, and will ideally manage the various application resources seamlessly, without any impact to the e-business application, while observing the company policies on networking use, security, and so on. Management of e-business applications are therefore best achieved by establishing yet another networking tier, parallel to the application tier, in which all the systems management components can be hosted without influencing the applications. Naturally, since the management applications have to communicate with the resources that need to be managed, the two meet on the networking wires, and on the machines hosting the various e-business application resources. Chapter 1. Managing your e-business infrastructure 17

38 Using the Tivoli product set, we recommend that you establish all the central components in the Management tier, and have a few proxies and agents present in the DMZ and Application tiers, as shown in Figure 1-8. Distributed Sys. Mgmt. agents Tivoli Gateway Tivoli Endpoint ITM Monitoring Engine... Distributed Sys. Mgmt. agents Tivoli Gateway Tivoli Endpoint ITM Monitoring Engine... Internal customer segment firewall Demillitarized Zone firewall Application Tier firewall Back-end firewall Distributed Sys. Mgmt. agents Tivoli Gateway Tivoli Endpoint ITM Monitoring Engine... Internal customer segment Mangement Tier Figure 1-8 A typical Tivoli managed e-business application infrastructure Central Sys. Mgmt. resources Tivoli TMR TEC Server TBSM Server Tivoli Data Warehouse Server... Distributed Sys. Mgmt. agents Tivoli Gateway Tivoli Endpoint ITM Monitoring Engine... Implementing the management infrastructure in this fashion, there is a minimal interference between the application and the management systems, and the access to/from the various network segments is manageable since the communication flows between a limited number of nodes using well-known communication ports. IBM s Tivoli management products have been developed with the total environment in mind. The IBM Tivoli Monitoring product provides the basis for proactive monitoring, analysis, and automated problem resolution. As you will see, IBM Tivoli Monitoring for Web Infrastructure provides an enterprise management solution for both the Web and application server environments. The PACS that make up this product provide solutions that are integrated with other Tivoli management products and provide a key piece to the goal of a consistent, end-to-end management solution for the enterprise. 18 Introducing IBM Tivoli Monitoring for Web Infrastructure

39 By utilizing the product offerings such as IBM Tivoli Monitoring for Web Infrastructure, a comprehensive and fully integrated management solution can be rapidly deployed and provide a very attractive return on investment. 1.3 Tivoli product structure Let s take a look at how Tivoli solutions provide comprehensive systems management for the enterprise and how the IBM Tivoli Monitoring for Web Infrastructure product fits into the overall architecture. The Tivoli solutions are generally organized into categories as shown in Figure 1-9. Business Systems Management Performance and Availability Configuration and Operations Storage Security Common Infrastructure/Services Figure 1-9 Tivoli Management Solutions Underlying the Tivoli solution set is a group of common services and infrastructure that provide consistency across Tivoli management applications as well as enabling integration. Within the Tivoli product family, there are specific solutions that target four primary disciplines of systems management: Performance and Availability Configuration and Operations Storage Management Security Products within each of these areas have been made available over the years and, though they continue to be enhanced, have become accepted solutions in enterprises around the world. With these core capabilities in place, IBM has been Chapter 1. Managing your e-business infrastructure 19

40 able to focus on building applications that take advantage of these pillars to provide true business systems management solutions. A typical business application depends not only on the hardware and networking, but also on software ranging from the operating system to middleware, such as databases, Web servers and messaging, to the applications themselves. A suite of solutions such as the IBM Tivoli Monitoring for... products, allows an IT department to provide management of the entire business system in a consistent way, from a central site, using an integrated set of tools. By utilizing an end-to-end set of solutions built on a common foundation, enterprises can manage the ever increasing complexity of their IT infrastructure with reduced staff and increased efficiency. Within the performance and availability pillar in Figure 1-9 on page 19, three functional areas are used to organize and coordinate the functions provided by Tivoli products. These areas are shown in Figure predict, optimize, analyze, account, report Business Impact Management Line of Business views, workflow, business process integration cross dicipline analysis, predict, optimizew, analyze, account, report Event Correlation and Automation Cross system & domain root cause analysis Monitor Systems and Applications Discover, collect metrics, probe (e.g. user experience), perform local analysis, filter, concentrate, determine root cause, take automated action Rapid time to value Open architecture May be deployed independently Out of box best practices Ease of use Superior value with a fully integrated solution Quality Processes, roles, and metrics Rapid problem response Figure 1-10 Tivoli s Performance and Availability product structure At the lower level, there are monitoring products and technologies such as IBM Tivoli Monitoring and its resource models. At this layer, Tivoli applications monitor the hardware and software and provide automated corrective actions whenever possible. At the next level is event correlation and automation. As problems occur that can not be resolved at the monitoring level, event notifications are generated and sent to a correlation engine such as Tivoli Enterprise Console. The correlation engine at this point can analyze problem notifications (events) coming from multiple components and either automate corrective actions or provide the necessary information to operators who can initiate corrective actions. 20 Introducing IBM Tivoli Monitoring for Web Infrastructure

41 The third tier in this structure is called Business Impact Management. It is important to know that a component or related set of components have failed as reported by the monitors in the first layer. Likewise, in the second layer it is valuable to understand how a single failure may cause problems in related components. For instance, a router being down, could cause database clients to generate errors if they cannot access the database server. But the third layer, Business Impact Management, is the most valuable of all, as it provides an insight into how a component failure may be affecting the business as a whole. When the router failure mentioned above occurs, it is important to understand exactly what line of business applications will be affected and how to reduce the impact of that failure on the business. Tivoli Business System Manager (TBSM) provides this capability. IBM Tivoli Monitoring for Web Infrastructure currently focuses primarily on the Performance, Availability, Configuration and Operations aspect of managing a Web infrastructure. However, Tivoli storage management and security management products can also be used to help ensue the integrity of Web and application servers. 1.4 IBM Tivoli Monitoring for Web Infrastructure In this section, we provide an overview of the functions and capabilities of the IBM Tivoli Monitoring for Web Infrastructure product. IBM Tivoli Monitoring for Web Infrastructure Version 5.1 includes four PACs: Monitoring for IBM HTTP Server Monitoring for Microsoft Internet Information Server Monitoring for Sun iplanet Server Monitoring for WebSphere Application Server The four PACs provides similar management functions for the supported Web and application servers. However, due to technological differences between the managed components, some of the functions described here may or may not be applicable to any specific server. The PACs facilitates the management of Web and application server instances on Tivoli Management Framework endpoints. The PACs provide the ability to register a set of Web and application servers, to collect their configurations in order to manage them. Once you have registered your resources, you can use the resource models and management functions of the appropriate Tivoli Monitoring for Web Infrastructure PAC to: Chapter 1. Managing your e-business infrastructure 21

42 Start, stop, restart, and retrieve the status of your servers, and retrieve the status of the related virtual hosts and applications Monitor key performance and availability of virtual hosts and applications run by each server Forward Tivoli Monitoring for Web Infrastructure PAC events to the IBM Tivoli Enterprise Console Forward Tivoli Monitoring for Web Infrastructure PAC events to Tivoli Business Systems Manager Store historical data on Tivoli Enterprise Data Warehouse To ensure that you are managing all IBM Tivoli Monitoring for Web Infrastructure resources available, the PACs provide a discovery function that finds the applications and virtual hosts hosted by the servers. As the discovery function finds new IBM Tivoli Monitoring for Web Infrastructure resources, they are added to your Tivoli configuration. IBM Tivoli Monitoring for Web Infrastructure provides management functionality in three major areas: Availability management Tivoli Monitoring for Web Infrastructure PACs provide resource models, or groups of monitors, that periodically check the status of your Web server components: the Web server and its virtual hosts. The status can be either active (operational) or inactive (non-operational). You can customize the resource models to meet your local requirements. Performance management The PACs resource models enable you to measure and report the performance of the virtual hosts run by your Web server resources, to identify bottlenecks and potential problems in your Web infrastructure. For example, you can measure: For Web servers the main performance metrics are: Traffic Access Error conditions For WebSphere Application Server some of the key performance metrics available are: Enterprise JavaBean (EJB) performance Database connection pool performance JVM Runtime Performance Servlets/JSP Performance 22 Introducing IBM Tivoli Monitoring for Web Infrastructure

43 Operations Tivoli Monitoring for Web Infrastructure PACs enables you to manage your Web and application server resources on a scheduled basis. You can: Start, stop, and restart your servers Check the status and retrieve information about your Web server instances and virtual hosts Retrieve and delete trace log files (WebSphere only) IBM Tivoli Monitoring for Web Infrastructure event rules manage the information presented on your event console. These rules remove duplicate and harmless events and correlate events to close events that are no longer relevant. IBM Tivoli Monitoring for Web Infrastructure event reporting functions support standard Tivoli event filtering, which you can use to reduce the number of events sent to your events server, in addition to forwarding events to Tivoli Enterprise Console. 1.5 Summary This chapter has provided an overview of the IBM Tivoli Monitoring for Web Infrastructure product. This product consists of four related components for managing Web infrastructures consisting of IBM HTTP Server, Microsoft Internet Information Server, Sun iplanet Server, and IBM WebSphere Application Server. Most enterprises today are using Web based middleware for new applications as well as for front-ending or integrating new applications and their legacy applications. As Web based middleware becomes an integral part of most IT environments and mission critical applications come to depend upon it, the management of these complex environments is critical to a business success. Tivoli software from IBM provides the infrastructure and end-to-end solutions for managing all of the critical components of today s e-business environments. Chapter 1. Managing your e-business infrastructure 23

44 24 Introducing IBM Tivoli Monitoring for Web Infrastructure

45 2 Chapter 2. Implementing Web Infrastructure Monitoring This chapter will outline the tasks needed to install, configure, and deploy IBM Tivoli Monitoring for Web Infrastructure. The content provided here will summarize the information needed to successfully deploy the various modules contained in the product and provides additional information which is not found in the product release notes, or the IBM Tivoli Monitoring for Web Infrastructure Installation Guide, GC , which is delivered with the product. Please refer to these two publications for basic information on installation and customization of a IBM Tivoli Monitoring for Web Infrastructure module. Most of the information that relates to these activities is available there. Installation of an IBM Tivoli Monitoring module implies planning, and completing the basic Tivoli installation of the module, all of which is discussed in Installing an ITM module on page 26. Refer to 2.2.3, Configuring the Web servers for monitoring on page 36 for a discussion of how to define Web servers to the Tivoli infrastructure, and refer to 2.2.4, Creating managed application objects on page 38 for details on how to start monitoring the Web servers. Copyright IBM Corp All rights reserved. 25

46 2.1 Installing an ITM module In this section we will discuss how to plan for and perform the actual installation of the IBM Tivoli Monitoring for Web Infrastructure modules. In order to install any IBM Tivoli Monitoring for... module you need to complete the following steps: 1. Plan your management domain 2. Check prerequisite software and patches 3. Choose the installation options 4. Verify the Installation To help planning, you should be aware, that when managing Web servers through IBM Tivoli Monitoring for Web Infrastructure you will have to deal with two types of objects in the Tivoli environment. The reason for this is that you may have multiple instances of Web servers implemented on the same system, and in order for Tivoli to be able to differentiate between them, separate managed application objects needs to be known to Tivoli in addition to the endpoint definitions. The two types of Tivoli objects are: The managed object This represents the system (hardware and operating system) on top of which the Web server is installed. Typically, the managed object is synonymous to the endpoint running on the system, but in some cases, it may be a managed node. The managed application object This is the term we prefer to use instead of the official proxy managed node. The managed application object represents a specific instance of a Web server, and should be the target of all IBM Tivoli Monitoring for Web Infrastructure related profile distributions Plan your management domain Creating a plan of your management domain will assist in easy configuration and deployment of your IBM Tivoli Monitoring for Web Infrastructure modules. The Tivoli environment has to be made up of at least one managed node. This principal managed node is called the TMR server. You can have TMR servers, managed nodes, gateways, endpoints and managed application objects, referred to as proxy managed nodes in the official IBM Tivoli Monitoring for Web Infrastructure documentation, in your environment. Please refer to Tivoli Management Framework Users Guide, GC , for more details. 26 Introducing IBM Tivoli Monitoring for Web Infrastructure

47 You should create a list which contains the following information. Name of the machine The type of resource on that machine. It can be an endpoint, a managed node, or a managed application. Operating system User name and password Destination of installed files For managed application objects you should also note the object names and the object types. The managed object name will have the name of the Web servers that you need to monitor and the object type will have the type of the Web server Check prerequisite software and patches To make sure that all the prerequisites that need to be in place before starting the installation, consult the Release Notes, which are distributed with each IBM Tivoli Monitoring for Web Infrastructure module. The prerequisites, as they were at the time of writing this book, are listed in Table 2-1. Table 2-1 Required prerequisite software Product Release Required Patches Tivoli Management Framework Tivoli Management Framework Tivoli Management Framework. IBM Tivoli Monitoring IBM Tivoli Monitoring Component Services Revision A or B , 62 (for Linux support) 21 (for Linux support) 9 (for Linux support) only for Apache HTTP Server 71 (for Linux support) SEV1 defect # is outstanding against this patch. 32, 43, 66 (for database support issues) Fix Package 2 (includes required patch 67) 76 (for Apache HTTP Server, Internet Information Server and iplanet Web Server) Chapter 2. Implementing Web Infrastructure Monitoring 27

48 In addition, you may choose to install one or more of the following, related Tivoli components (Table 2-2). Table 2-2 Optional Tivoli components Product Release Required Patches Web Health Console Tivoli Enterprise Data Warehouse Tivoli Enterprise Console Tivoli Business Systems Manager Tivoli Event Enablement Software used in the lab The software level that we used in our ITSO lab environment, related to the above requirements are: Tivoli Management Framework Version 3.7B, upgrade to Tivoli Management Framework version 3.7.1, with the following patches applied: TMF TMF TMF-0075 Important: The above software level gives an endpoint level of 101, which can be verified using the wadminep <ep_name> view_version command. It is important that you do not use endpoint level 98, because there is a problem in MDist distribution related to that level. The lab environment included several Java related components from the Tivoli Management Framework Version 3.7B and CDs all found in the JAVA subdirectory of the CD used to enable MDist monitoring GUI with the following product and patches: Tivoli Java Client Framework 3.7 Tivoli Java Client Framework Java for Tivoli 3.7 Tivoli Java RDBMS Interface Module (JRIM) 3.7 Tivoli Java RDBMS Interface Module (JRIM) JavaHelp for Tivoli 3.7 JavaHelp for Tivoli Swing for Tivoli 3.7 Swing for Tivoli Tivoli MDist2 Graphical User Interface 28 Introducing IBM Tivoli Monitoring for Web Infrastructure

49 Tivoli MDist2 Graphical User Interface Maintenance Release Tivoli MDist2 Graphical User Interface Patch The IBM Tivoli Monitoring that is required is Version In the lab, we used a pre-release (beta) version. IBM Tivoli Monitoring Component Services Version is also a pre-release (beta) version. Java support On the endpoints, the resource models deployed with the IBM Tivoli Monitoring for Web Infrastructure monitors are written in JavaScript, and the providers are written in Java. This requires that Java Runtime Environment (JRE) Version is installed on all endpoints to be managed. The following links are the image of the JRE that we used. These links require that you to register with the IBM developerworks community. For AIX, we use the JRE from the IBM developerworks: For Windows, we use JRE from the WebSphere technology preview: Additional components In addition to the required products and patches, the ITSO lab environment included other Tivoli products that may be integrated to the IBM Tivoli Monitoring for Web Infrastructure modules, in order to provide additional functions. In the lab environment, the following was implemented: Tivoli Enterprise Console (TEC) to provide centralized event management capabilities. The version of Tivoli Enterprise Console used was Version with the following components: Tivoli Enterprise Console Server Tivoli Enterprise Console Console Tivoli Enterprise Console User Interface Server Tivoli Enterprise Console fixpack 2 Tivoli Business Systems Manager (TBSM) Distributed Edition to provide business level monitoring. The TBSM implementation included the Event Enablement feature. Tivoli Enterprise Data Warehouse (TEDW) to provide centralized reporting capabilities. IBM Tivoli Monitoring Extension for Tivoli Enterprise Data Warehouse to enable the IBM Tivoli Monitoring for Web Infrastructure modules to collect and store data used by TEDW. The IBM Tivoli Monitoring Extension for Tivoli Chapter 2. Implementing Web Infrastructure Monitoring 29

50 Enterprise Data Warehouse was installed from the IBM Tivoli Monitoring Version CDROM Installation media structure The IBM Tivoli Monitoring for Web Infrastructure product CD comes with several components. These reside on the CD in the following sub-directories: HCONSOLE PRODUCT TBSM UNINSTALL WORKBENCH tedw_apps_etl Health Console installation Main product installation directory, used for fresh install of the product Tivoli Business Systems Manager integration installation directory Product uninstallation script Source file for use with IBM Tivoli Monitoring Workbench to modify and create resource model Tivoli Enterprise Data Warehouse integration installation directory Miscellaneous checks You should make sure that you have configured your TMR server with the correct network settings and given your administrator all the required roles and permissions. In particular, check the following: Communication issues Name resolution: Verify that your DNS servers are reachable throughout the infrastructure, even in the DMZ. You should have a valid host name and unique domain name for all managed nodes and endpoints you create. Single port BDT: This service limits the number of target ports that are required for the Tivoli environment to operate. When the single port BDT option is set, the outbound port used will be the configured BDT port (default 9401). Firewall ports: Configure the ports used for Tivoli management communications. Please check that you use Tivoli relay functions to navigate across multiple security zones and limit Tivoli communications to uni-directional transactions. See Tivoli enterprise management across Firewalls, SG , for more information. Permissions and privileges Unix: On UNIX, the user who installs the product must have root privileges. Tivoli recommends that you log on as root on UNIX. Windows: On Windows, the user who installs the product must have membership in the Administrators group. Tivoli recommends that you log on as Administrator on Windows. 30 Introducing IBM Tivoli Monitoring for Web Infrastructure

51 Security issues SSL: Tivoli Management Framework supports SSL encryption on oserv-to-oserv communication channels. The Web Health Console does not run under Tivoli Management Framework and has unique mechanisms for communicating with the other components across or within a firewall. See the Enabling Secure Socket Layer Support for the Web Health Console topic in IBM Tivoli Monitoring User s Guide, SH , for more information. Backup and recovery Tivoli database: You should back up or restore databases using the wbkupdb command or using the Tivoli desktop. Make sure that The Tivoli Management Framework must be running on the TMR server and on the managed node whose database is being restored. See the Tivoli Management Framework Reference Manual, SC , for a description of all the capabilities of the wbkupdb command. Tivoli files: It would be a good idea to use any archival software like pkzip or tar to make an archive of your Tivoli installation directory before you install any IBM Tivoli Monitoring for Web Infrastructure modules Choose the installation options IBM Tivoli Monitoring for Web Infrastructure modules may be installed in either of three ways. Choose the option in the product installer that meets your requirements: Easy install using the installation wizard You can use the typical installation if you do not need to modify the default installation parameters or you do not need to use the planner tool. You must accept the default directory paths in this installation method. You can use the custom installation option if you have a larger, more complex Tivoli environment. You can use an installation wizard and related planner tool to install IBM Tivoli Monitoring for Web Infrastructure. This will, among other things, allow you to export a custom installation plan to be imported in a later installation session, in order to reuse its specifications. Automatic installation in an existing Tivoli environment Tivoli Software Installation Service (SIS) may also be used to install IBM Tivoli Monitoring for Web Infrastructure and other Tivoli products onto your existing Tivoli environment. SIS can install multiple Tivoli products on multiple systems in parallel. Prior to the actual installation, SIS performs product prerequisite checks and, if defined, user-specified prerequisite checks, ensuring as few install failures as possible. SIS also creates an installation repository into which you can import the installation image of one or more Tivoli products for details of the platforms on which the Software Installation Service can run. Chapter 2. Implementing Web Infrastructure Monitoring 31

52 For instructions on installing and using this product, refer to the Tivoli Software Installation Service Users Guide and the Tivoli Software Installation Service Release Notes. Manual install through an existing Tivoli environment You can use the command line interface winstall or the Tivoli desktop to install IBM Tivoli Monitoring for Web Infrastructure. This method is same as that of installing any other Tivoli product. If you are using this method make sure that all the required patches are installed prior to installing the IBM Tivoli Monitoring for Web Infrastructure. In our environment, we installed the product manually through an existing Tivoli environment by using the Tivoli desktop. This was achieved by loading the product CDROM and selecting Desktop -> Install -> Install Product, from the Tivoli desktop. The install product dialog shows the products available, as shown in Figure 2-1. Figure 2-1 Install product dialog You need to install the product at the TMR server and all the gateways in your environment where IBM Tivoli Monitoring for Web Infrastructure modules will be 32 Introducing IBM Tivoli Monitoring for Web Infrastructure

53 used. Click Install and the product installation screen will show the action that will be performed. Then click Continue Install. When the installation is completed, click Close Verify the Installation Once you have completed the process of installing, you should confirm that the files were copied and no error was reported. You can issue the wlsinst -p command and verify that the output includes at least one of the entries shown below - corresponding to the IBM Tivoli Monitoring for Web Infrastructure module(s) you have installed. Example 2-1 wlsinst -p... IBM Tivoli Monitoring for Web Infrastructure WebSphere Application Server IBM Tivoli Monitoring for Web Infrastructure, Version Apache HTTP Server IBM Tivoli Monitoring for Web Infrastructure, Version Internet Information Server IBM Tivoli Monitoring for Web Infrastructure, Version iplanet Web server... The installation of the appropriate IBM Tivoli Monitoring for Web Infrastructure modules is now complete, and it is time to perform some basic configuration in order to make the products operational. 2.2 Configuring the management domain This section provides information about how to customize the newly installed IBM Tivoli Monitoring for Web Infrastructure modules in order to make them operational. This requires managed application objects for the Web servers in the management domain to be defined, and in various authentication and runtime environment related post-installation activities needs to be performed. To configure the IBM Tivoli Monitoring for Web Infrastructure modules for a particular environment, the following tasks needs to be completed: 1. Adding roles for administrators and users 2. Installing and linking Java Runtime Environment on endpoints 3. Configuring the Web servers for monitoring Chapter 2. Implementing Web Infrastructure Monitoring 33

54 4. Creating managed application objects Adding roles for administrators and users During the installation process of each IBM Tivoli Monitoring for Web Infrastructure module, three hierarchical roles are created. Table 2-3 Tivoli roles for IBM Tivoli Monitoring for Web Infrastructure modules module authorization super admin user Apache apachewebserver_ super apachewebserver_ admin apachewebserver_ user iplanet iplanetwebserver_ super iplanetwebserver_ admin iplanetwebserver_ user IIS iiswebserver_ super iiswebserver_ admin iiswebserver_ user WebSphere WebSphereappsvr _ super WebSphereappsvr _ admin WebSphereappsvr _ user To perform operations on Tivoli Monitoring for Web Infrastructure module, a Tivoli administrator must be assigned at least one of the roles in Table 2-3. The administrator should also have the required Tivoli authority to successfully run any tasks and processes. The following characterize the roles divisions. The module_name refers to the actual IBM Tivoli Monitoring for Web Infrastructure module: <module_name>webserver_super Assign Tivoli roles and resources based on the policy region structure. <module_name>webserver_admin Perform day-to-day maintenance and monitoring. <module_name>webserver_user Perform operation of the Tivoli environment, need the ability to check basic health of the Web Infrastructure. You can update the TMR roles for your region using the Tivoli desktop by adding the required TMR role for the administrators. To do this, double-click on the Administrators icon on the Tivoli desktop to the Administrator window. Right-click on an administrator icon, select Edit Resource Roles or Edit TMR Roles. 34 Introducing IBM Tivoli Monitoring for Web Infrastructure

55 You can also update the resource roles of an administrator by using the wsetadmin command line interface. Attention: The administrator must restart the Tivoli desktop for the changes to take effect Installing and linking Java Runtime Environment on endpoints IBM Tivoli Monitoring for Web Infrastructure requires your endpoints have Java Runtime Environment (JRE), Version 1.3, or higher installed. If a Java Runtime Environment currently is not installed on the endpoint, one can be installed from the IBM Tivoli Monitoring product CD either manually, by running the wdmdistrib J command, or through the use of Tivoli Software Installation Service (SIS). If you have just installed Java Runtime Environment or if you have an existing Java Runtime Environment you need to link it to the IBM Tivoli Monitoring using the DMLinkJre IBM Tivoli Monitoring task. This task can be executed on multiple endpoints simultaneously, if all these endpoints has the JRE installed in the same directory. You may want to run this task separately for each platform as they have different installation conventions. These are the steps needed to link a JRE to IBM Tivoli Monitoring: 1. Select Desktop -> Navigator, to open the Navigator window. From here, go to the bottom of the Navigator window, and check the Task Library check-box. 2. Open the IBM Tivoli Monitoring Tasks task library by selecting it from the Resources pane. 3. Run the DMLinkJre task. Specify the endpoints for the Execute Task dialog, you need to execute selectively to all endpoint objects that has the same JRE installation directory. You can also identify endpoints using one or more profile managers. The endpoints that needs the JRE to be linked are the systems that have Web servers running, which you want to monitor and manage through IBM Tivoli Monitoring for Web Infrastructure modules. Click Execute. Note: Ensure that the path where JRE is physically installed, is the same on all selected endpoints. 4. On the DMLinkJre dialog shown in Figure 2-2, enter the complete path where JRE is installed (this is the path where the bin/java command exists). Chapter 2. Implementing Web Infrastructure Monitoring 35

56 Figure 2-2 DMlinkJRE task dialog 5. Click Set & Execute. JRE will be linked to the product on all selected endpoints Configuring the Web servers for monitoring This section discusses the various configuration options that need to be manipulated to enable on your Web servers for being monitored. Important: Please remember that before attempting to use IBM Tivoli Monitoring for Web Infrastructure module resource models for monitoring Web servers, the systems hosting the Web servers must have a Tivoli endpoint installed and operational. For more details on configuring the Web servers for IBM Tivoli Monitoring for Web Infrastructure, see the IBM Tivoli Monitoring for Web Infrastructure User s Guide relevant to your combination of Web server(s). The following provides configuration details relative to the supported Web servers. Apache HTTP Server The following applies to any systems hosting an Apache HTTP Server that you want to manage with IBM Tivoli Monitoring for Web Infrastructure: Apache HTTP Server: Apache HTTP Server Version 1.3 or higher must be installed. You must ensure that every virtual host on you Apache HTTP Server has a directive ServerName. The ServerName should include the fully qualified domain name. 36 Introducing IBM Tivoli Monitoring for Web Infrastructure

57 Every virtual host has logging enabled and uses either the common log format (which is the default), or the W3C (combined) format, and uses a different accesslog file. See the IBM Tivoli Monitoring for Web Infrastructure Apache HTTP Server User s Guide, SH for more detailed information. iplanet Web server The following applies to any systems hosting Sun iplanet Web server that you want to manage with IBM Tivoli Monitoring for Web Infrastructure: iplanet Server: Sun iplanet Web server Version 6.0 sp2 or higher must be installed. You should configure iplanet SNMP to be able to monitor your iplanet Web servers and virtual servers. You can configure the SNMP agent to use a port or community name different from the default - public. See the iplanet Web server, Enterprise Edition Administrator s Guide and IBM Tivoli Monitoring for Web Infrastructure iplanet Server User s Guide, SH , for more detailed information. Tip: It is advisable to have SNMP installed and configured on the machine, before you install iplanet Web server. Internet Information Server The following applies to any systems hosting Microsoft Internet Information Server (ISS) that you want to manage with IBM Tivoli Monitoring for Web Infrastructure: Internet Information Server: Microsoft Internet Information Server, Version 4 or 5, must be installed. You have to install Windows Management Instrumentation (WMI) if the machine on which you are running Internet Information Server is a Windows NT 4.0. WebSphere Application Server The following applies to any systems hosting IBM WebSphere Application Server (WAS) that you want to manage with IBM Tivoli Monitoring for WebSphere Application Server: IBM WebSphere Application Server Version or higher must be installed. IBM Tivoli Monitoring for WebSphere Application Server supports only one installation of WebSphere Application Server on a host. IBM Tivoli Monitoring for WebSphere Application Server requires a WebSphere administration server to be on the managed endpoint. If security is enabled for IBM WebSphere Application Server, you should create a security properties file for the wscp client so that it can be authenticated by the server. You can copy the sas.client.props file in Chapter 2. Implementing Web Infrastructure Monitoring 37

58 $WAS_HOME/Properties directory to sas.wscp.prop and add the following lines to it. $WAS_HOME is the directory where you have installed your Web Sphere Application Server: com.ibm.corba.loginsource=properties com.ibm.corba.loginuserid=<userid> com.ibm.corba.loginpassword=<password> Where, <userid> is the IBM WebSphere Application Server user ID and <password> is the password for the user. To monitor performance data for your IBM WebSphere administration and application servers, you must enable IBM WebSphere Application Server to collect performance data. Each performance category has an instrumentation level, which determines which counters are collected for the category. You can change the instrumentation levels using the IBM WebSphere Application Server Resource Analyzer. On the Resource Analyzer window you need to do the following: a. Right-click an application server instance and choose Monitoring Settings from the pop-up menu to display the Performance Monitoring Settings window. b. Click a resource and choose None, Low, Medium, High or Maximum from the pop-up icon. The color associated with the chosen instrumentation level is added to the instrumentation icon. c. Click OK to apply the chosen setting. Click Cancel to undo any changes and revert to the previous setting. You should enable the Java Virtual Machine Profiler Interface (JVMPI) to improve performance analysis. The JVMPI is available on the Windows, AIX, and Solaris platforms. You do not need to enable JVMPI data reporting to use the resource models included with IBM Tivoli Monitoring for WebSphere Application Server. See the IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server User s Guide, SC , for more detailed information Creating managed application objects Before starting to manage Web server resources, these must first be registered in the Tivoli environment. This registration is achieved by creating specific Web server objects in any policy region. When installing IBM Tivoli Monitoring for Web Infrastructure, a default policy region corresponding to the IBM Tivoli Monitoring for Web Infrastructure module is automatically created. Figure 2-3 shows the default policy regions created for specific IBM Tivoli Monitoring for Web Infrastructure components. These are: Monitoring for Apache HTTP Server 38 Introducing IBM Tivoli Monitoring for Web Infrastructure

59 Monitoring for iplanet Web server Monitoring for Internet Information Server WebSphere Administration Servers WebSphere Application Servers WebSphere Application Servers with EJBs WebSphere Application Servers with Servlets Figure 2-3 Tivoli Desktop after Installing all modules Normally, managed application objects are created in the default policy regions. If you want to create the managed application objects in a different policy region, you must first add the relevant IBM Tivoli Monitoring for Web Infrastructure managed resource to the list of resources, supported by the specific policy region. You can create the managed application objects inside the policy region by using the Tivoli desktop for running the appropriate command from the command line. The module-specific commands are shown in Table 2-4. Chapter 2. Implementing Web Infrastructure Monitoring 39

60 Listed below are some points which should be noted before creating managed application objects: From the command line, you can create managed application objects only in the default policy region for that particular IBM Tivoli Monitoring for Web Infrastructure module. You can only specify managed applications and endpoints belonging to the current Tivoli management region, not to interconnected Tivoli management regions. For IBM Tivoli Monitoring for WebSphere Application Server objects you can also use the Discovery task to create the managed application objects. Table 2-4 Default managed resources and command lines Web server Managed Resource Command Apache ApacheWebServer wapachews iplanet IPlanetWebServer wiplanetws IIS IISWebServer wiisws WebSphere WSApplicationServer WSAdministrationServer wwebsphere For details on using the commands, please refer to IBM Tivoli Monitoring for Web Infrastructure Reference Guide, GC If all the parameters supplied to the command line or the Tivoli Desktop is correct, then a Web server object icon is added to the policy region window. The following will provide details on creating managed application objects for each specific Web server type currently supported by IBM Tivoli Monitoring for Web Infrastructure. Create Apache HTTP Server managed application objects Follow the steps outlined below to create an Apache HTTP Server managed application object from the Tivoli desktop: 1. From the Monitoring for Apache HTTP Server policy region or from the policy region which you have configured select Create ->ApacheWebServer to display the Create Apache HTTP Server objects dialog, shown in Figure Introducing IBM Tivoli Monitoring for Web Infrastructure

61 Figure 2-4 Create Apache HTTP Server managed application object 2. Enter the label of the managed node where the object is to be located, or click Managed Nodes to select one from the list. Typically the TMR server is used. 3. Enter the label of the endpoint where the Apache HTTP Server is located, or click Endpoints to select one from the list. 4. Select the Apache HTTP Server subtype, standard or IBM (the default value for the configuration file is automatically updated). a. If you selected IBM, then specify whether or not it is an administration server. 5. Select the configuration file, including the complete path, used by the Apache HTTP Server, if it is different from the default. 6. To create another Apache HTTP Server object select Create and repeat the above steps; otherwise, select Create & Close. 7. A dialog box with a message informing you that the object was created on the managed node that you specified is displayed. 8. Click OK. The Apache HTTP Server managed application object icon is added to the policy region window, with the name in the format ApacheWebServern@endpoint_label as shown in Figure 2-5. Chapter 2. Implementing Web Infrastructure Monitoring 41

62 Figure 2-5 Policy region: Monitoring for Apache HTTP Server Create iplanet Web server managed application objects Follow the steps outlined below to create an iplanet Web server managed application object from the Tivoli desktop. 1. From the Monitoring for iplanet Web server policy region or from the policy region which you have configured, select Create ->IPlanetWebServer to display the Create iplanet Web server objects dialog, shown in Figure 2-6. Figure 2-6 Create iplanet Web server object 42 Introducing IBM Tivoli Monitoring for Web Infrastructure

63 2. Enter the label of the managed node where the object is to be located, or click Managed Nodes to select one from the list. 3. Enter the label of the endpoint where the iplanet Web server is located, or click Endpoints to select one from the list. 4. Enter the iplanet Web server installation directory, for example: /usr/iplanet/servers 5. Modify the iplanet SNMP agent port if different from the default (161). 6. Modify the iplanet SNMP community if different from the default (public). 7. To create other iplanet Web server managed application objects on a different endpoint select Create and repeat the above steps; otherwise, select Create & Close. 8. A dialog box with a message informing you that the object was created on the managed node that you specified is displayed. 9. Click OK. The iplanet Web server object icon is added to the policy region window, with the name in the format iplanetwebservern@endpoint_label as shown in Figure 2-7. Figure 2-7 Policy region: Monitoring for iplanet Web server Create IIS managed application objects Follow the steps outlined below to create Internet Information Server managed application object from the Tivoli desktop. 1. From the Monitoring for Internet Information Server policy region or from the policy region which you have configured, select Create ->IISWebServer to display the Create Internet Information Server objects dialog, shown in Figure 2-8. Chapter 2. Implementing Web Infrastructure Monitoring 43

64 Figure 2-8 Create Internet Information Server object 2. Enter the label of the managed node where the object is to be located, or click Managed Nodes to select one label from the list. 3. Enter the label of the endpoint where the Internet Information Server is located, or click Endpoints to select one label from the list. 4. Click Create & Close or Create to create the Internet Information Server managed application object that you defined. 5. A dialog box with a message informing you that the object was created on the managed node that you specified is displayed Click OK to dismiss the information dialog box. The Internet Information Server object icon is added to the policy region window, with the name format IISWebServer@endpoint_label as shown in Figure 2-9. Figure 2-9 Policy region: Monitoring for IIS Web server 44 Introducing IBM Tivoli Monitoring for Web Infrastructure

65 Create Web Sphere managed application objects The WebSphere managed application objects create differently from the other Web server objects previously discussed. In order to manage WebSphere Application Servers, two types of WebSphere managed application objects need to be defined. They are: WebSphere Administration Server managed application object WebSphere Application Server managed application object We first need to create WebSphere Administration Server managed application object and then create WebSphere Application Server managed application objects. To create both the objects, start from the Monitoring for WebSphere Application Server policy region or from the policy region which you have configured. Select Create, and then select WSAdministrationServer or WSApplicationServer. 1. If you selected WSAdministrationServer, complete the following fields on the Create WSAdministrationServer dialog box shown in Figure Figure 2-10 Create WSAdministrationServer objects Node name (Required): Type the name of the node for the IBM WebSphere Administration Server that this object will represent. Chapter 2. Implementing Web Infrastructure Monitoring 45

66 Fully qualified host name (Required): Type the fully qualified host name for the IBM WebSphere Administration Server. Endpoint name (Required): Select the Tivoli endpoint on which the IBM WebSphere Administration Server is running. Managed node name: Type the name of the managed node where you want to create the object. WebSphere admin port: Type the port number used to open a communication channel with the IBM WebSphere Administration Server. The default value is 900. WebSphere version (Required): Type the version of IBM WebSphere Application Server running on the endpoint. WebSphere Security Enabled: Specify whether or not WebSphere security is enabled on the endpoint. If security is enabled, provide the name of the security properties files in the WebSphere Security Properties File field. WebSphere Security Properties File: Type the name of the security properties file. If you enter only the file name, and not the full path, the file is assumed to be in the $WAS_HOME/properties directory on the endpoint. WebSphere Install Path (Required): Type the full path to the directory on the endpoint where IBM WebSphere Application Server is installed. This value can contain spaces. WebSphere OS Type: Type the operating system running on the endpoint. 2. Click Set & Execute. The WebSphere Administration Server managed application object icon is added to the policy region window, with the name format Monitoring for WebSphere Application Server@endpoint_label as shown in Figure Introducing IBM Tivoli Monitoring for Web Infrastructure

67 Figure 2-11 Policy region: Monitoring for WebSphere Application Server To create the WebSphere Application Server managed application object do the following: 1. Click Create->WSApplicationServer from the menu. You have to complete the Create WSApplicationServer dialog box shown in Figure Chapter 2. Implementing Web Infrastructure Monitoring 47

68 Figure 2-12 Create WSApplication Server object Application server name (Required): Type the application server name for this object. Administration server label (Required): Type the Tivoli object label for the existing IBM WebSphere administration server object with which this application server object is associated. You have type in the complete name for the WebSphere Administration object which is like: Monitoring for WebSphere Application Endpoint name (Required): Select the Tivoli endpoint on which the IBM WebSphere application server is running. Has Web module: Select this if the IBM WebSphere Application Server is using the Web Module and is capable of hosting servlets. Has EJB module: Select this if the IBM WebSphere Application Server is using the Enterprise JavaBeans (EJB) module and is capable of hosting EJBs. Managed node name: Type the name of the managed node where you want to create the object. 2. Click Set & Execute. The WebSphere Application Server managed application object icon is added to the policy region window, with the name format Monitoring for WebSphere Application Server as shown in Figure Introducing IBM Tivoli Monitoring for Web Infrastructure

69 Tip: If you need to delete the WebSphere Application Server managed application object, drag the Icon to the main Tivoli desktop and use Edit->Delete menu option. Figure 2-13 Monitoring for WebSphere Application Server 2.3 Deploying monitors This section discusses deploying IBM Tivoli Monitoring for Web Infrastructure monitors or resource models in your management domain. The list below provides an overview of the topics discussed here: Creating profile managers and profiles Adding subscribers to the profile managers Adding default resource models to profiles Distributing profiles Creating profile managers and profiles In order to manage Web server resources it is required to create profile managers and profiles. This will help organize and distribute resource models. A monitoring profile may be regarded as a group of customized resource models that can be distributed, downloaded or pushed, to a subscribed, marked to receive, managed resource in a profile manager. The profile manager can be created using the wcrtprfmgr command or the Tivoli desktop. Once the profile manager exists, profiles must be created. This can be achieved using the wcrtprf command or the Tivoli desktop. The profile should be set up to include Tmw2kProfile managed resource types. See the IBM Tivoli Chapter 2. Implementing Web Infrastructure Monitoring 49

70 Monitoring User s Guide, SH , about how to create profile managers, profiles, and subscribers Adding subscribers to the profile managers The subscribers of a profile manager determines which systems will be monitored when a profile within the profile manager is distributed. To add a subscriber to a profile manager, run the wsub command or use the Tivoli desktop. The subscribers for IBM Tivoli Monitoring for Web Infrastructure would be the managed application objects which were created as part of the configuration of the Web Infrastructure monitoring environment, discussed in 2.2.4, Creating managed application objects on page Adding default resource models to profiles A resource model is used to monitor, capture, and return information about multiple resources and applications. When adding resource models to a profile, these are chosen based on the type of resources that are being monitored. We recommend that you group all of the resource models to be distributed to the same endpoint or managed application object in a single profile, because the distribution occurs on a per-profile basis. During the initial for the first time deployment of any resource model of IBM Tivoli Monitoring for Web Infrastructure, we recommend that you use default values, therefore, not modifying the resource model. This will help verify that the resource model deployment is successful and that the Web servers are managable. Please refer to Chapter 4, Extending the monitoring solution on page 79 for a discussion of how to customize resource models for particular needs. Resource models may be added to a profile through the Tivoli desktop or by using the wdmeditprf command. During installation of a IBM Tivoli Monitoring for Web Infrastructure module, the resource models shown in Table 2-5 are defined to the Tivoli environment. The functionality of each resource model is self-explanatory, deduced from the name of the resource model itself. Table 2-5 Default resource models Module Name Apache Supported Operating System aix4-r1\linux-ix86\solari s2\w32-ix86 Resource Models Apache performance Apache server availability Apache Web site availability 50 Introducing IBM Tivoli Monitoring for Web Infrastructure

71 Module Name Supported Operating System Resource Models iplanet solaris2\w32-ix86 iplanet Web server availability iplanet Web server load iplanet Web server performance iplanet virtual server availability iplanet virtual server performance Internet Information Server WebSphere Application Server w32-ix86 aix4-r1\hpux10\linux-ix8 6\solaris2\w32-ix86 Internet Information Server Active Server Pages Performance Internet Information Server Web site performance Internet Information Server Availability Internet Information Server Web Site Availability WebSphereAS Administration Server Status WebSphereAS Application Server Status WebSphereAS DB Pools WebSphereAS EJBs WebSphereAS HTTP Sessions WebSphereAS JVM WebSphereAS Thread Pools WebSphereAS Transactions WebSphereAS Web Applications Distributing profiles IBM Tivoli Monitoring uses Multiplexed Distribution (MDist2) to perform asynchronous profile data transfers through a hierarchy of repeaters. Before deploying the monitors to the managed application objects, make sure that the following steps have been completed: 1. Profile manager(s) and profile(s) have been created. Chapter 2. Implementing Web Infrastructure Monitoring 51

72 2. Subscriber(s) have been added to profile manager(s). 3. Resource model(s) have been added to profile(s). 4. It has been confirmed that the ITM engine is running on the endpoint. The wdmlseng command may be used for this purpose. 5. Java Runtime Environment, Version 1.3 or higher, is available on the endpoint. Having verified all of this, use the wdmdistrib command or the Tivoli desktop to distribute a profile to the subscribers of the profile manager. If the distribution fails, a new profile manager, which includes a copy of the profile that was the object of distribution, will be created; otherwise, the distribution was successful. The new profile manager is named according to the following conventions <OriginalProfileName>_Push_Failed_Bad_Intepreter <OriginalProfileName> is the name of the profile that you are distributing when the error occurred. The failed distribution is due to a Bad_Interpreter error. The AMW089E error message is displayed, indicating that the resource model type is not compatible with the endpoint operating system. For example, you might have distributed a Windows resource model to a UNIX endpoint, or vice versa. OriginalProfileName_Distribution_Failed <OriginalProfileName> is the name of the profile that you were distributing when the error occurred. The failed distribution is due to any other error, apart from a Bad_Interpreter error. You can rerun a failed distribution by adding subscribers to the failed profile manager, correcting the error of the previous distribution and distributing it again. 2.4 Operating Tivoli Monitoring for Web Infrastructure Besides providing resource models that are used to monitor resources at the Web and Application servers, IBM Tivoli Monitoring for Web Infrastructure provides specialized tasks used to operate the servers from central site. Examples of such tasks are starting, stopping, status checking, and configuring the servers, This section provides information about the functions provided by the IBM Tivoli Monitoring for Web Infrastructure modules in order to facilitate central operation of the environment. 52 Introducing IBM Tivoli Monitoring for Web Infrastructure

73 The following is split into two areas, one for the Web server; and the other for the Application Server. For more details about how to work with each IBM Tivoli Monitoring for Web Infrastructure module object, see the relevant User s Guide for each module. The following topics are covered in this section. Actions available to Apache, iplanet and IIS objects Functions provided by WebSphere Application Server objects Actions available to Apache, iplanet and IIS objects You can right-click the managed application object, and select any actions shown in Table 2-6 from the pop-up menu. Table 2-6 Functions provided by Web server modules Function Apache iplanet IIS Show properties Yes Yes Yes Refresh Yes Yes Yes Check the Web server status Yes Yes Yes Check the Web site status Yes - Yes Start, stop, or restart a server Yes Yes Yes Start or stop a virtual server - Yes - Check the status of a virtual server - Yes - Start or stop a hosted Web site - - Yes Note: Not all information is refreshed in the following cases: If you change installation path, PID file path, Configuration file path or endpoint label, then you need to delete and recreate the Apache HTTP Server object. If you change the SNMP information or the installation path, then you need to delete and recreate the iplanet Web server object. The followings tasks are available for managing the Web server when you install IBM Tivoli Monitoring for Web Infrastructure. The operational target, where the task should be run, for each task is the corresponding managed application object. On the Tivoli desktop each set of tasks is available in the default policy region for each module. Chapter 2. Implementing Web Infrastructure Monitoring 53

74 Table 2-7 Task Library Task library Required Authority Task Name Monitoring for Apache Web server Tasks Monitoring for iplanet Web Server Tasks Monitoring for Internet Information Server Tasks apachewebserver_user iplanetwebserver_admin iiswebserver_admin Start Stop Start Stop Start Site Stop Site Start Stop Start Site Stop Site Functions provided by WebSphere Application Server objects When right-clicking on a WebSphere Application Server managed application object the following options are available on the popup menu. Operator Check the status of an object Start Server Stop server List application servers Diagnostics -> Tivoli Logs View endpoint Callback log files In addition IBM Tivoli Monitoring for WebSphere Application Server provides four different sets of task for easy administration. Listed below are the various tasks. WebSphere Event Tasks WebSphere Administration Server Tasks WebSphere Application Server Tasks WebSphere Application Server Utility Tasks The Table 2-8 describes each set of tasks and their associated command name. The endpoint for each task would be WebSphere Administration Server managed application object or a WebSphere Application Server managed 54 Introducing IBM Tivoli Monitoring for Web Infrastructure

75 application object. On the Tivoli desktop each set of tasks is available in separate task libraries in the policy region Monitoring for WebSphere Application Server. Table 2-8 WebSphere tasks Command Name Description WebSphere Event Tasks Configure_Event_Server Configure_WebSphere_TEC_Adapt er Display_WebSphere_TEC_Adapter _Configuration Start_WebSphere_TEC_Adapter Stop_WebSphere_TEC_Adapter Configures an event server for IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server, starts and stops the event server, and imports the Tivoli Business Systems Manager rules, if appropriate. Configures and starts the IBM WebSphere Application Server Tivoli Enterprise Console adapter. The adapter is used to ensure that IBM WebSphere FATAL, ERROR, AUDIT, WARNING, and TERMINATE messages (SeriousEvents) are forwarded to the Tivoli Enterprise Console. Displays the configuration settings for the IBM WebSphere Application Server Tivoli Enterprise Console adapter. Starts the IBM WebSphere Application Server Tivoli Enterprise Console adapter, which is needed to forward events to the Tivoli Enterprise Console and Tivoli Business Systems Manager. Stops the IBM WebSphere Application Server Tivoli Enterprise Console adapter. WebSphere Administration Server Tasks Administration_Server_Status Displays the status of the WebSphere administration server. List_Application_Servers Start_Administration_Server Stop_Administration_Server Lists the application servers currently defined on the WebSphere node. Starts the administration server on the WebSphere node. Stops the administration server on the WebSphere node. WebSphere Application Server Tasks Chapter 2. Implementing Web Infrastructure Monitoring 55

76 Command Name Application_Server_Status Start_Application_Server Stop_Application_Server Description Returns the status of the application server on the WebSphere node. Starts the application server Stops the application server. WebSphere Application Server Utility tasks Delete_WebSphere_Trace_Logs Discovery List_WebSphere_Trace_Logs WebSphere_TBSM_Discovery_Eve nts Deletes all trace logs on the selected endpoint. Also deletes any logs created on managed nodes. Discovers the WebSphere administration and application server resources that can be managed using IBM Tivoli Monitoring for Web Infrastructure WebSphere Application Server. Returns a list of trace logs on the specified endpoint or managed node. Sends a DISCOVER event to Tivoli Business Systems Manager for each IBM WebSphere administration server and application server that IBM Tivoli Monitoring for Web Infrastructure WebSphere Application Server discovered (or is currently managing). 56 Introducing IBM Tivoli Monitoring for Web Infrastructure

77 3 Chapter 3. Real-time monitoring The discussion in this chapter covers the implementation of real-time monitoring with IBM Tivoli Monitoring for Web Infrastructure through the Web Health Console and demonstrates how it can be extended to include event correlation and business impact analysis using Tivoli Enterprise Console (TEC) and Tivoli Business Systems Manager (TBSM). The discussion consists of: Working with the Web Health Console on page 58 Working with Tivoli Enterprise Console on page 60 Working with Tivoli Business Systems Manager on page 64 Copyright IBM Corp All rights reserved. 57

78 3.1 Working with the Web Health Console You can use the Web Health Console to display, check, and analyze the status and health of any endpoint provided that monitoring has been activated on the endpoint by means of profiles and resource models. The endpoint status reflects the state of the endpoint displayed on the Web Health Console, such as running or stopped. Health is a numeric value determined by resource model settings. The typical settings include required occurrences, cycle times, thresholds, and parameters for indications. These are defined when the resource model is created in the IBM Tivoli Monitoring Workbench. You can also use the Web Health Console to work with data from an endpoint that is logged to the IBM Tivoli Monitoring database Configuration If your IBM Tivoli Monitoring for Web Infrastructure module has been installed using rapid deployment, you can use the Web Health Console without any additional configuration. If you have used any other method to install your IBM Tivoli Monitoring for Web Infrastructure module, then you need to configure the Web Health Console to view events as follows: 1. Insert the product CD-ROM in the CD-ROM drive and switch to the /HCONSOLE directory, where the following files in Table 3-1 relevant to your modules are located: Table 3-1 Web Health console configuration files Module Name Apache iplanet Internet Information Server File names Apache_Performance.class, Apache_ServerAvailability.class, Apache_WebSiteAvailability.class iplanet_virtualserveravailability.class, iplanet_serveravailability.class, iplanet_serverload.class, iplanet_serverperformance.class, iplanet_virtualserverperformance.class IIS_ASPPerformance.class, IIS_General.class, IIS_ServerAvailability.class, IIS_WebSiteAvailability.class 58 Introducing IBM Tivoli Monitoring for Web Infrastructure

79 Module Name WebSphere Application Server File names WebSphereAS_AdminServerStatus_10.class, WebSphereAS_ApplicationServerStatus_10.clas s, WebSphereAS_DBPools_10.class, WebSphereAS_EJBs_10.class, WebSphereAS_HTTP_Sessions_10.class, WebSphereAS_JVMRuntime_10.class, WebSphereAS_ThreadPool_10.class, WebSphereAS_Transactions_10.class, WebSphereAS_WebApps_10.class 2. Copy the relevant files from Table 3-1 for your IBM Tivoli Monitoring for Web Infrastructure module to the following directory on the server where the Web Health Console is installed: <WHC_dir>/installedApps/dm.ear/dm.war/WEB-INF/classes/com/tivoli /DmForNt/resources <WHC_dir> is the directory where you installed the Web Health Console. 3. Stop and restart the Web Health Console. Once the Web Health Console has been configured, you can connect the Web Health Console to any TiMR server or managed node and configure it to monitor any or all of the endpoints that are found in that region. The Web Health Console does not have to be within the region itself, although it may. To connect to the Web Health Console you need access to the server on which the Web Health Console server is installed and the TMR at which you want to monitor health. All user management and security is handled through the Tivoli Management Environment. This includes creating users and passwords, as well as assigning authority Operating the Web Health Console To activate the online monitoring of the health of a resource you have to login to the Web Health Console. Use the following steps if you are logging in to the Web Health Console for the first time: 1. Open your browser and type the following in the address field: Where, <server_name> is the fully qualified host name, or the IP address, of the server hosting the Web Health Console. 2. The first time you login to the Web Health Console, the Preferences view is displayed. You must populate the Selected Endpoint list before you can access any other Web Health Console views. When you login subsequently, the endpoint list is automatically loaded. Chapter 3. Real-time monitoring 59

80 3. Select the endpoints that you want to monitor and choose the Endpoint Health view. This is the most detailed view of the health of an endpoint. In this view, the following information is displayed: The health and status of all resource models installed on the endpoint The health of the indications that make up the resource model and historical data To view the data, use the theoretical view option. Figure 3-1 shows an example of real time monitoring of an Apache server. Figure 3-1 Using the Apache module with the Web Health Console 3.2 Working with Tivoli Enterprise Console Tivoli Enterprise Console (TEC) has been designed to receive events from multiple sources and processes these in order to correlate and aggregate them, and issues pre-defined (corrective) actions based on the processing. TEC works on the basis of events and rules. TEC events are defined in object-oriented definition files called baroc files. In this, events are defined hierarchically according to type. Each event type is 60 Introducing IBM Tivoli Monitoring for Web Infrastructure

81 called an event class. When TEC receives an event, it parses the event to determine the event class and then applies the class definition to parse the rest of the event. When the parsing is successful, the event is stored in the TEC database. When a new event is stored, a timer expires or a field, known in TEC terminology as a slot, is changed, TEC evaluates a set of rules to be applied to the event. These rules are stored in ruleset files, which are written in Prolog language. When a matching rule is found the action part of the rule gets executed. These rules enable events to be correlated and aggregated. Rules also enable automatic responses to certain conditions, usually these are corrective actions. In IBM Tivoli Monitoring for Web Infrastructure perspective, Web server and application server specific events are generated by the resource models provided by each of the IBM Tivoli Monitoring for Web Infrastructure modules. The events are defined to TEC and a set of predefined rules exists to correlate and process the events. To setup a TEC environment capable of receiving Web and application server related events from the IBM Tivoli Monitoring for Web Infrastructure environment, the following software has to be installed: Tivoli Enterprise Console Server Tivoli Enterprise Console Console Tivoli Enterprise Console User Interface Server Tivoli Enterprise Console Adapter Configuration Facility Tivoli Enterprise Console EIF TSC also uses a RDBMS system DB2 in the ITSO lab environment in which events are stored. Please refer to Tivoli Enterprise Console Reference Manual, GC , for further details on TEC installation and use IBM Tivoli Monitoring for Web Infrastructure events and rules In order to define the IBM Tivoli Monitoring for Web Infrastructure related events and rules to the TEC, the proper definition files have to be imported into the TEC environment. The IBM Tivoli Monitoring for Web Infrastructure events and rules are described in files which have baroc and rls file extensions. All the files can be found in the <TIVDIR>/bin/generic_unix/TME subdirectory (TMEDIR hereafter), where <TIVDIR> represents the directory in which the Tivoli Enterprise Console Server code is installed. Event definition files The locations and file names of the baroc files used by the different IBM Tivoli Monitoring for Web Infrastructure modules are listed in the following two tables. Chapter 3. Real-time monitoring 61

82 The approach followed by the three Web server modules (Apache HTTP Server, Internet Information Server and iplanet) differs from the approach followed by the WebSphere module. Web server baroc files The Web server modules all have a baroc file for each resource model as shown in Table 3-2. Table 3-2 Web server modules baroc files Module Name Baroc File Name <TMEDIR>/Apache/tec/Apache_Performance.baroc Apache HTTP Server <TMEDIR>/Apache/tec/Apache_ServerAvailability.baroc <TMEDIR>/tec/Apache_WebSiteAvailability.baroc <TMEDIR>/IIS/tec/IIS_ASPPerformance.baroc Internet Information Server <TMEDIR>/IIS/tec/IIS_General.baroc <TMEDIR>/IIS/tec/IIS_ServerAvailability.baroc <TMEDIR>/IIS/tec/IIS_WebSiteAvailability.baroc <TMEDIR>/IPlanet/tec/iPlanet_ServerAvailability.baroc <TMEDIR>/IPlanet/tec/iPlanet_ServerLoad.baroc iplanet Web Server <TMEDIR>/iPlanet_ServerPerformance.baroc <TMEDIR>/iPlanet_VirtualServerAvailability.baroc Application server baroc files The IBM Tivoli Monitoring for WebSphere Application Server module has a single baroc file for all the events originating from all the resource models and another baroc file, which holds definitions of events forwarded to the Tivoli Enterprise Console directly from the WebSphere Application Server as shown in Table 3-3. Table 3-3 WebSphere Application Server module baroc files Module Name <TMEDIR>/iPlanet_VirtualServerPerformance.baroc Baroc File Name WebSphere Application Server <TMEDIR>/WSAPPSVR/tec/itmwas_dm_events.baroc (Contains Resource Models event definitions) <TMEDIR>/WSAPPSVR/tec/itmwas_events.baroc (Contains WebSphere Application Server event definitions) 62 Introducing IBM Tivoli Monitoring for Web Infrastructure

83 Rules All three Web server modules, namely Apache HTTP Server, Internet Information Server and iplanet Web server, use a rule set file to forward events from the Tivoli Enterprise Console to the Tivoli Business Systems Manager. The specific file names are listed Table 3-4. Table 3-4 Web server module rule set files Module Name Apache HTTP Server Internet Information Server iplanet Web Server Rule File Name <TMEDIR>/Apache/tec/itmapache_tbsm_forward.rls <TMEDIR>/IIS/tec/itmiis_tbsm_forward.rls <TMEDIR>/IPlanet/tec/itmiplanet_tbsm_forward.rls To forward events originating from the WebSphere Application Server to TBMS, two rule set files are used. One specific rule set file defines rules specific to events originating directly from WebSphere Application Servers, and another holds rules for events sent to TEC by the resource models monitoring the WebSphere Application Servers. The names of these rule set files are listed in Table 3-5. Table 3-5 WebSphere Application Server module rule set files Module Name WebSphere Application Server Rule File Name <TMEDIR>/WSAPPSVR/tec/itmwas_events.rls <TMEDIR>/WSAPPSVR/tec/itmwas_forward_tbsm.rls <TMEDIR>/WSAPPSVR/tec/itmwas_monitors.rls To start using TEC for IBM Tivoli Monitoring for Web Infrastructure, an active rule base, named ITMWAS1, was created in the ITSO lab environment. The ITMWAS1 rule base contains all the baroc files and rules required for the basic IBM Tivoli Monitoring product as well as the definitions needed for the IBM Tivoli Monitoring for Web Infrastructure modules. Note that the rules for the IBM Tivoli Monitoring for Web Infrastructure modules relies on class definitions supplied by the Tmw2k.baroc file, which is delivered as part of the IBM Tivoli Monitoring product. This baroc file needs to be installed prior to the baroc files for the IBM Tivoli Monitoring for Web Infrastructure modules you want to use. The steps needed to create the ITMWAS1 rule base are: 1. Import the required IBM Tivoli Monitoring definitions: a. Use the TEC Server object on the Tivoli Desktop or the wcrtrb command to create a new, temporary rule base. Once the temporary rule base is Chapter 3. Real-time monitoring 63

84 successfully tested, we will be copy it to the production rule base, ITMWAS1. We named the temporary rule base ITM. b. Execute the installation script to import the basic ITM definitions into the newly created rule base: $BINDIR/TMNT_TEC/dmae_tec_inst.sh ITM Note: It is not required to load the baroc files for all the IBM Tivoli Monitoring resource models if there is not any interest in monitoring the basic resources on all the operating systems supported. In this case it is only required to load the Tmw2k.baroc file and the two rule set files dmae_events.rls and hb_events.rls (available in the directory $BINDIR/TMNT_TEC) in our ITM rulebase using the wrb command. 2. Add support for each Web server module. a. Manually load all the baroc files listed in Table 3-2 on page 62 with the command: wrb -imprbclass <baroc file name> ITM b. Manually load all the rule set files listed in Table 3-3 on page 62 with the command: wrb -imprbrule <rule file name> ITM 3. Add support for the IBM Tivoli Monitoring for WebSphere Application Server module. a. Run the task WebSphere Event Tasks -> Configure Event Server Task available in the Monitoring for WebSphere Application Server Policy Region. Choose to create a new rule base from an existing one (that is, ITM rule base) and name it ITMWAS1 from the existing ITM rule base. Select the option to compile an load the rule base ITWAS1 before executing the task. For further details see the IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server User s Guide, SC Optionally remove the temporary rulebase ITM by using the TEC Server object on the Tivoli Desktop, or the wdelrb command. At the end of this process the rule base ITWAS1 should be the active rule base. 3.3 Working with Tivoli Business Systems Manager Tivoli Business Systems Manager gives the operation and business executives a graphical interface to quickly see and understand the health of the IT infrastructure they are using or managing. Tivoli Business Systems Manager shows business executives how individual components or resources affect a 64 Introducing IBM Tivoli Monitoring for Web Infrastructure

85 business function. Tivoli Business Systems Manager also shows the operation personnel what business functions are affected by an outage of a single component. In Tivoli Business Systems Manager, the business function is represented by a Line of Business resources. Tivoli Business Systems Manager collects information of resources status from various part of the enterprise. It gets feeds from the mainframe environment, job scheduling subsystem, Tivoli Framework, network management software or other third party applications. It processes all events from those feeds and shows an integrated view of an enterprise. Related to IBM Tivoli Monitoring for Web Infrastructure, Tivoli Business Systems Manager can show the status of the Web servers and the status of the WebSphere Application Server resources as they relate to a business function. IBM Tivoli Monitoring for Web Infrastructure generates events through the resource models and TEC adapters. These events go through TEC where specialized TEC rules are used to forward the information to Tivoli Business Systems Manager. In turn, Tivoli Business Systems Manager processes these events to show the Web servers and WebSphere Application server resources status Tivoli Business Systems Manager event flow A detailed event flow for Tivoli Business Systems Manager integration are shown in Figure 3-2. Chapter 3. Real-time monitoring 65

86 endpoint TMR ITM monitors TEC adapter wruntask TBSM database Event Server ruleset script ihstttec TEC server task server (ihscts) 2 event enablement 3 (ihstdmai) 5 Database server TBSM agent listener Figure 3-2 Event flow for Tivoli Business Systems Manager integration The process flow can be described as: 1. Events are generated by the ITM resource model or TEC adapter. These events are sent to the TEC event server for processing. 2. The TEC event server compares the event against criteria on the rules that it has. Specific rulesets for Tivoli Business Systems Manager forwarding for the Web server modules are: itmapache_tbsm_forward.rls itmiis_tbsm_forward.rls and itmiplanet_tbsm_forward.rls (see Table 3-4 on page 63) While the rules for the WebSphere module is called: itmwas_forward_tbsm.rls (see Table 3-5 on page 63) 66 Introducing IBM Tivoli Monitoring for Web Infrastructure

87 In the $BINDIR/TME/TEC/scripts directory these rulesets invoke the forwarding scripts: itmapache_tbsm_forward.sh itmiis_tbsm_forward.sh itmiplanet_tbsm_forward.sh itmwas_send_to_tbsm.sh In turn, all these scripts invoke the ihstttec command to forward the event information to the event enablement process. 3. The event enablement sends the formatted event to the agent listener which resides in the Tivoli Business Systems Manager database server. The agent listener evaluates the event and stores the event in the Tivoli Business Systems Manager database. 4. The Tivoli Business Systems Manager console is informed of the event and the status of monitored objects are changed accordingly. 5. When an operator invokes an operational tasks from clicking the context menu of any IBM Tivoli Monitoring for Web Infrastructure resources, a request is sent to the task server process. 6. The task server executes the operational task using wruntask command Setting up Tivoli Business Systems Manager integration In this section we describe how to configure the integration between the TEC Server and the TBSM Server. To enable events forwarding from TEC to TBSM the Tivoli Enterprise Console Adapter should be installed on the TEC Server, while to view the events the TBSM Console should be installed. We installed the following software to setup our TBSM environment: Tivoli Business Systems Manager 1.5 The TBSM patch 1.5-BSM-0024 The TBSM patch 1.5-BSM-0029 The TBSM patch 1.5-BSM-0035 Tivoli Business Systems Manager Event Enablement 1.5 The TBSM patch 1.5-BSM-0032 The TBSM patch 1.5-BSM-0038 TBSM Console TBSM patch 1.5-BSM The TBSM Console does not require a dedicated machine. It can be installed on any machine. We used the TEC environment described in 3.2, Working with Tivoli Enterprise Console on page 60. Chapter 3. Real-time monitoring 67

88 To configure the TBSM to handle IBM Tivoli Monitoring for Web Infrastructure events and enable the TEC server to forward these events, the following is required: 1. On the TBSM Database Server run the install.bat batch file available in the CD-ROM of each IBM Tivoli Monitoring for Web Infrastructure module in the TBSM directory. Note that this process could take some time. The installation will copy the uninstallation program and start the initialization scripts itm<module>_tbms_init.sh, where the placeholder module depends on the module we are installing. At the end of the installation process the table GEMLookupCID contains the rows shown in Figure 3-3. Figure 3-3 TBSM database GEMLookupCID rows The data in the GEMLookupCID table is added during the installation. Note that the time required by the installation process of each module depends on the number of rows. Tip: To start the SQL Query analyzer either type isqlw from the MS DOS prompt or use the Windows Start menu (Programs -> Microsoft SQL Server 7.0 -> Query Analyzer). Then type the following query: select * from GEMLookupCID order by cid DESC 2. On the TBSM database server, connect the Agent Listener with the event enablement system, so the event from TEC starts flowing into TBSM. Perform this using the command: gemeeconfig -a <eehost>. Restart the Agent 68 Introducing IBM Tivoli Monitoring for Web Infrastructure

89 Listener service afterward. To check the connection use the gemeeconfig command again. Example 3-1 Configuring the TBSM in the ITSO environment C:\>gemeeconfig -a x220svr Adding Event Enabler ibmtiv2 New Event Enablement definition created. C:\>net stop Tivoli BSM Agent Listener The Tivoli BSM Agent Listener service is stopping. The Tivoli BSM Agent Listener service was stopped successfully. C:\>net start Tivoli BSM Agent Listener The Tivoli BSM Agent Listener service is starting. The Tivoli BSM Agent Listener service was started successfully. c:>gemeeconfig Listing configured Event Enablers: Event Enabler: x220svr Connection Status: Connected Enabled for connection at startup. Port: Default Port RetryTime: Default MaxWaitTime: Default Done. 3. On the TEC server, for each Web server module, import the module specific rule base by running the following command: wrb imptgtrule itm<module name>_tbsm_forward EventServer <rule base> 4. Load and compile the rule base either through the icon or through the commands wcomprules <rule base> and wloadrb <rule base>. These commands have to be executed on the TEC Server. Example 3-2 shows the complete commands. Example 3-2 Importing and compiling the rule base bash$ wrb imptgtrule itmiplanet_tbsm_forward EventServer ITMWAS1 bash$ wrb imptgtrule itmapache_tbsm_forward EventServer ITMWAS1 bash$ wrb imptgtrule itmiis_tbsm_forward EventServer ITMWAS1 bash$ bash$ wcomprules ITMWAS1 bash$ wloadrb ITMWAS1 5. On the TEC Server, copy the scripts that forwards events to TBSM from the <TIVDIR>/bin/generic_unix/TME directory (TMEDIR hereafter) to the $BINDIR/<interp>/TME/TEC/scripts/ directory (where the value of the Chapter 3. Real-time monitoring 69

90 <interp> placeholder depends on the architecture where the TEC server is installed 1 ): <TMEDIR>/Apache/tec/itmapache_tbsm_forward.sh <TMEDIR>/IIS/tec/itmiis_tbsm_forward.sh <TMEDIR>/IPlanet/tec/itmiplanet_tbsm_forward.sh Note: This step is required if the process followed to install the TBSM is the manual method (see Example 3-2 on page 69) as described in IBM Tivoli Monitoring for Web Infrastructure Apache HTTP Server User s Guide, SH , IBM Tivoli Monitoring for Web Infrastructure Internet Information Server User s Guide, SH and IBM Tivoli Monitoring for Web Infrastructure iplanet Server User s Guide, SH In any case the directory $BINDIR/<interp>/TME/TEC/scripts/ should contain all the scripts required to forward the TEC events to TBSM. Example 3-3 ITSO environment TEC to TBSM forwarding scripts The directory content of c:/tivoli/bin/w32-ix86/tme/tec/scripts/ on the TEC server x220svr is: TEC_Send_Mail.sh itmapache_tbsm_forward.sh itmiis_tbsm_forward.sh itmiplanet_tbsm_forward.sh itmwas_send_to_tbsm.sh 6. In case the TEC Server is installed on a Windows 2000 system, you are required to change the log on user for the Tivoli BSM Task Server service from LocalSystem to Administrator. If you fail to do this, errors might occur when a user tries to invoke the tasks defined by the IBM Tivoli Monitoring for Web Infrastructure modules from the TBSM Console. This change is quite straightforward and involves the following: a. Stop the Tivoli BSM Task Server service with the command: net stop Tivoli BSM Task Server b. Change the Log on user from LocalSystem to Administrator (as shown in Figure 3-4). c. Restart the Tivoli BSM Task Server service with the command with the command: net start Tivoli BSM Task Server 1 the interp could be w32-ix86 on win32 architectures, os400 on iseries architectures, and so on. 70 Introducing IBM Tivoli Monitoring for Web Infrastructure

91 Figure 3-4 Tivoli TBSM Task Server Resource discovery To discover the resources that are available for each IBM Tivoli Monitoring for Web Infrastructure module, you are required to run a script for each Web server module and execute a task for the WebSphere module. Discovery of Web server resources Each Web server module installs a script file on the TEC server in the <TIVDIR>/bin/generic_unix/TME subdirectory (TMEDIR hereafter). The relevant scripts should be executed in order to discover the Web server resources available in the current Tivoli Management Region. Table 3-6 TBSM discovery script for the Web server modules Module Name Apache Internet Information Server iplanet TBSM Discovery script <TMEDIR>/Apache/tec/itmapache_tbsm_discovery.sh <TMEDIR>/IIS/tec/itmiis_tbsm_discovery.sh <TMEDIR>/IPlanet/tec/itmiplanet_tbsm_discovery.sh Discovery of WebSphere resources As far as the WebSphere module is concerned the discovery process consists of running a task named Send_WebSphere_Discovery_Events_to_TBSM, which may be found in the WebSphere Application Server Utility Tasks task library. Chapter 3. Real-time monitoring 71

92 Figure 3-5 WebSphere module TBSM discovery task When executed, the Send_WebSphere_Discovery_Events_to_TBSM task invokes the script <TMEDIR>/WSAPPSVR/tasks/itmwas_tbsm_discovery.sh. The script output is displayed in Figure 3-6. Figure 3-6 WebSphere discovery task module 72 Introducing IBM Tivoli Monitoring for Web Infrastructure

93 Figure 3-7 shows the resources displayed by the TBSM Console in our environment at the end of the discovering process for the Web server and WebSphere modules. Figure 3-7 TBSM Console after the discovery process Using Tivoli Business Systems Manager The TBSM Console can be used to start and stop the Apache HTTP Server, Internet Information Server, WebSphere Applications servers and their Administration servers as well. In addition, it is possible to verify the WebSphere status of both the Administration Server and the Application Server. The Apache Administration server and the Web server can be started and stopped through the TBSM console as shown in Figure 3-8. At the time of this writing, there is no way to distinguish between an Administration server and a Web server from the TBSM Console. Chapter 3. Real-time monitoring 73

94 Figure 3-8 Apache starting and stopping from the TBSM Console The Internet Information Server can be started and stopped through the TBSM console as shown in Figure 3-9. Figure 3-9 Internet Information Server starting and stopping The iplanet administration server and the Web server can be started and stopped through the TBSM console as shown in Figure At the time of this writing there is no way to distinguish between an administration server and a Web server with the TBSM Console. 74 Introducing IBM Tivoli Monitoring for Web Infrastructure

95 Figure 3-10 iplanet Web server starting and stopping from the TBSM Console The WebSphere Administration Server can be started and stopped. Moreover, it is possible to check the Application Server status and collect a list of all the applications servers managed. Figure 3-11 WebSphere Administration Server management from TBSM console In our environment the execution of the operational task: List_Application_Servers on the WSAdministrationServer 4.0.X: Monitoring for Chapter 3. Real-time monitoring 75

96 WebSphere Application object shows the result in Figure Figure 3-12 WebSphere task: List Application Servers from the TBSM Console The WebSphere Application Server can be started and stopped. Moreover, it is possible to check the status as shown in Figure Introducing IBM Tivoli Monitoring for Web Infrastructure

97 Figure 3-13 WebSphere Application Server management from the TBSM console For more information on Tivoli Business Systems Manager and its usage, refer to the following redbooks: Tivoli Business Systems Manager - A Complete End-to-End Management Solution, SG Tivoli Business Systems Manager - An Implementation Case Study, SG Chapter 3. Real-time monitoring 77

98 78 Introducing IBM Tivoli Monitoring for Web Infrastructure

99 4 Chapter 4. Extending the monitoring solution The monitoring solution provided by IBM Tivoli Monitoring for Web Infrastructure may be extended by modifying the resource models provided by default, or by writing new resource models. Although the default resource models or the ones supplied with a specific product are sufficient in most cases, during implementation of a product, we are often faced with a requirement to perform a monitoring that is slightly different from what is supplied. Modifying existing or creating new resource models is normally only required if a specific monitoring feature is not provided by the standard resource model, or if is needed to add new features and functionality. Resource models may be created from scratch or and existing resource model may be copied and modified. It is a good idea to make a copy of the original file before customizing it, that way you can always revert back to the original if needed. Copyright IBM Corp All rights reserved. 79

100 Figure 4-1 Resource models, parameters and profiles. Figure 4-1 shows the various components of a resource model in a nutshell and the relative skills needed to modify each component. All the circles marked with 1 indicate resource model runtime settings, which can be modified when specifying resource model use in a Tmw2k profile through the Tivoli Desktop. You need to know about Tivoli tasks and some scripting knowledge to work with squares marked 2. To work with the resource models themselves, symbolized by the cross marked 3, and to modify the inner workings, decision tree, mof file settings, logic, and so on for a resource model, you have to use the Tivoli provided IBM Tivoli Monitoring WorkBench, and this requires in most cases programming skills and a good understanding of the CIM model. 4.1 Customizing resource model runtime settings In this section we will briefly touch upon the topic of manipulating the default runtime settings (thresholds, cycle times, etc.) for the resource models. This level of customizing is by far the most commonly used to control the behavior of the resource models and is available through the Tivoli Desktop. Please refer to the redbook IBM Tivoli Monitoring Version 5.1: Advanced Resource Monitoring, SG , for more details about how to manipulate resource models through the Tivoli Desktop. The runtime settings for a resource model falls into two categories. Profile properties that apply to all resource models within a profile, and resource model properties that apply only to specific instances resource models within a profile. 80 Introducing IBM Tivoli Monitoring for Web Infrastructure

101 The only runtime settings that are defined on the profile level are the event properties, which determines whether of not the resource models are enabled to forward events to TEC and TBSM. For each individual resource models in a profile, the following runtime settings may be specified as attributes to that particular instance of a resource model: Thresholds and cycle time Indications Parameters Schedule Logging Profile properties If your resource models need to send the TEC or TBSM events, then these functions must be enabled. From the Tivoli Desktop, open the profile and select Edit->Properties to set the TBSM and TEC options. Figure 4-2 shows an example of enabling the TEC events using the secure delivery method for a profile name IIS, which is located in the Redbook profile manager. Figure 4-2 Profile properties Using Apache Server availability as an example, the following paragraphs will show you how to work with the various parameters to setup and modify the runtime settings of a resource model. Chapter 4. Extending the monitoring solution 81

102 Thresholds and cycle time Each resource model defines one or more thresholds. A threshold is a named property of the resource with a default value which you can modify in the customizing phase. Typically, the value specified for a threshold represents a significant reference level of a performance related entity, which, if exceeded or not reached, a system administrator might want to know about. As we can see from Figure 4-3, the Apache Server availability resource model does not have any parameters and nothing has to be configured. If you are working with any resource models which have thresholds, then they are modified in this dialog. Figure 4-3 Edit resource model Cycle time is the interval at which the resource model would be run on the endpoint. In our example we have set the cycle time to be 300 seconds. Indications and actions Each resource model triggers an indication if certain conditions defined by the resource model s thresholds are not satisfied during the monitoring cycle. Each resource model has its own algorithm to determine which combinations of thresholds should generate an indication. When indications occur and generates events, actions, defined to the resource model through the customization of the profile, may be invoked. Such responses 82 Introducing IBM Tivoli Monitoring for Web Infrastructure

103 may include sending a TEC or TBSM event, or executing built-in or pre-defined tasks. A set of pre-defined tasks can be found in the IBM Tivoli Monitoring Utility task library, and one of the tasks here, dmae_mn_send_notice, may be used to send a notice in response to an event. Notices are sent to the TMR Bulletin Board. You can also select one or more Tivoli Framework tasks to perform when an indication generates an event. These tasks can access the event name and thresholds by accessing the environment variables. Each resource model has default indication values preset. If you have specific requirements for which these thresholds are not appropriate; you can adjust the following values as needed: Number of occurrences Number of holes Send TEC events or not Send TBSM events or not Severity Built-in tasks Figure 4-4 Indications and actions Figure 4-4 shows the various options available for indications and actions for the resource model. In our example we have the following values: Number of occurrences 1 Number of holes 0 Send TEC events or not Yes Chapter 4. Extending the monitoring solution 83

104 Send TBSM events or not Severity Built-in tasks No Critical Start Apache Server Parameters The parameters of a resource model allows administrators and users to optimize the monitoring process. Some resource models have one or more parameters some have none. Each parameter can take the form of a list of strings, a list of numeric values, a boolean list of predetermined values from which you can make any combination of selections, or a choice list of mutually exclusive alternatives. As we can see from Figure 4-3 on page 82, the Apache Server availability has no parameters and no setting is needed. If you are working with resource models that accept parameters, you will have to configure them from this dialog box by clicking Parameters. This will display a dialog, similar to the one shown in Figure 4-5. Figure 4-5 Resource model parameters Schedule The scheduling rules enable definition of the time periods on specific weekdays during which monitoring takes place. The overall collection period may be divided 84 Introducing IBM Tivoli Monitoring for Web Infrastructure

105 into active and inactive intervals by applying one or more schedule rules. Figure 4-6 shows the various scheduling options available for Apache Server availability resource model. In our example we have choosen the always option. This option will continuously monitor the Apache Server availability. Figure 4-6 Scheduling Logging Resource models support data logging in order to collect and store monitoring data in a local database. The types of data that can be logged are RAW, TEDW and aggregated data. Figure 4-7 shows the various logging options available for the resource model. In our example we have enabled logging for RAW data and TEDW. Note: Please note that you can log data in either aggregated format, or RAW and/or TEDW format not all three at the same time. Chapter 4. Extending the monitoring solution 85

106 Figure 4-7 Resource model logging 4.2 Apache management automation This section describes a scenario for managing an Apache server, and provides two solutions for its automation An Apache server management scenario Every time a new Web site 1 is added to an Apache HTTP Server, the Apache Web server object in the Tivoli environment must be manually refreshed, and the profile managing the Apache server must be re-distributed in order to monitor the availability and the performance of this new Web site. 1 through the VirtualHost directive 86 Introducing IBM Tivoli Monitoring for Web Infrastructure

107 Note: An Apache Web site availability resource model configured to monitor all the Web sites will actually monitor the Web sites available at the moment it was pushed on the managed object. This means that it will monitor the Web sites stored in the managed object at the time of the last refresh. The Web site names and other basic information will be passed to the resource models through context parameters. See Appendix A, Resource models context parameters on page 165 for further details. It would be nice, if the tasks to modify/enable/activate monitoring of the Apache HTTP Servers new Web sites were executed automatically based on changes to the Apache configuration file. To achieve this, we need to: 1. Discover changes to the Apache configuration file 2. Perform the Tivoli monitoring related actions: a. Discover the new Web site by sending a refresh command. b. Re-distribute the profile to start monitoring the new Web site. The automation of this process may be implemented more or less sophisticated. Section 4.2.2, Standard automation using default resource models and tasks on page 88 describes the easy, simple approach by using Tivoli tasks to perform the discover and re-distribute tasks triggered by any change to the Apache server configuration file, usually httpd.conf. These tasks do not include error checking to verify the operational status of the Apache HTTP Server. A more sophisticates approach using a new resource model is presented in 4.2.3, Advanced automation - building a new resource model on page 96. In this, the Tivoli Workbench is used to develop an new resource model, which will help achieve the same objective. However, in this case, the Apache Web server object will be refreshed only if the Apache HTTP server has been restarted, and therefore, the new Web site has been activated. In this way, monitoring of a Web site, which is not already available in the active Web server, is avoided. In order to achieve this, we need to combine the discover, and re-distribute actions with the monitoring of the Apache server availability, making sure that the Apache HTTP server is up and running, and integrate the two. Integration is done at a low-level by combining the two in a new resource model. A logical design of the automation scenario is provided in Figure 4-8. Chapter 4. Extending the monitoring solution 87

108 Figure 4-8 Apache server automated management scenario logical design To understand the solutions provided in the following sections, it is important to understand that the resource models execute at the systems hosting the Apache server. The tasks needed to discover new Web sites and distribute the monitoring profiles must be executed on a managed node or the TMR server. Therefore, it is necessary find a way to let the resource models signal the need for re-discovery and distribution to a central site, from which the proper tasks may be invoked. This signaling mechanism is implemented using events that will be caught by TEC, and here they will trigger a rule, which invokes the needed tasks as response to the resource model events Standard automation using default resource models and tasks To automate the monitoring of the Apache HTTP server Web sites based on changes to the Apache configuration file, we need to perform the steps given below: Create a Tmw2k profile including the Apache resource models. Create the tasks necessary to discover and distribute the profile. Create TEC rules to allow task execution based on events send from the resource models. Note: The first time the automatization is performed, the profile has to be distributed manually and all subscribers needed to be manually added to the profile manager that is the target of the distribution. 88 Introducing IBM Tivoli Monitoring for Web Infrastructure

109 Profile creation We will create a new profile for IBM Tivoli Monitoring called ApacheAutomation. This profile will hold the resource models needed for the automation. To create a profile, complete the following steps: 1. Create a new Tmw2k profile. 2. Add a Unix-Linux File resource model to monitor. Edit the parameters to monitor the Apache HTTP server config file. In our example we monitor the file /usr/httpserver/conf/httpd.conf. 3. Enable Send TEC events for the Unix-Linux File resource model by clicking on the indications button on the Edit Resource Model dialog. 4. Add Apache Web site Availability and the Apache Performance resource models to this profile. Based on your choice you may or may not enable TEC events for these two resource models. The completed profile should be similar to the one shown in Figure 4-9. Figure 4-9 ApacheAutomation profile Chapter 4. Extending the monitoring solution 89

110 Task creation To perform the actual refresh of the Apache HTTP server and profile distribution from the TMR (or a managed node) a Tivoli task needs to be created. This will be invoked from TEC when the Apache configuration file changed event is received. In our example, the task is named refresh_task. The following steps will explain the details of task creation and the inner workings of the task. 1. Create a shell script with the code as show in Example 4-3 on page 91. The name of the script does not matter, but in our example the name is apache_auto.sh. The script performs the following actions: a. Receive the endpoint name, the fully qualified configuration file name, and the profile name respectively in the invocation parameter string. Note that the parameters order is important and should be the same when you create the arguments for the Tasks in the TEC rule. b. Find the object ID on the specified Apache Web Server object specified in the input parameters. This is performed by means of the wlookup -ar ApacheWebServer command, which retrieves all the available instances as shown below. Example 4-1 Retrieving the ApacheWebServer objects wlookup -ar ApacheWebServer ApacheWebServer1@colt187 ApacheWebServer1@dolphin ApacheWebServer1@frankfurt ApacheWebServer2@colt187 ApacheWebServer2@dolphin #Apache::WebServer# #Apache::WebServer# #Apache::WebServer# #Apache::WebServer# #Apache::WebServer# c. Find the value for the attribute ServerInstance for each ApacheWebServer instance returned by the wlookup command. The value of ServerInstance attribute can be found using the idlattr command. In this way, the list of the properties collected during the discovery process can be used to find the path to the configuration file and the endpoint name. Example 4-2 ServerInstance attribute value in an ApacheWebServer@colt187 idlattr -tg ServerInstance Apache_defs::WebServerInfo { "5.1" "ibm" "/usr/httpserver" "/usr/httpserver/conf/httpd.conf" "/usr/httpserver/logs/httpd.pid" "1.3" "colt187" TRUE } d. In case the configuration file name and the endpoint name retrieved in the previous step are equal to the ones received in the input parameters, the ApacheWebServer object instance will be refreshed through the wapachews command. 90 Introducing IBM Tivoli Monitoring for Web Infrastructure

111 e. Finally, the profile is then distributed to the ApacheWebServer object received in input parameters. The distribution is facilitated by the wdmdistrib command. The complete script is shown in Example 4-3. Example 4-3 Shell script apache_auto.sh #!/bin/sh wlookup -ar ApacheWebServer awk -v endpoint=$1 -v configfile=$2 -v profile=$3 '/Apache::WebServer/{ sharppos=match($2,/#/) oid=substr($2,0,sharppos-1) "idlattr -tg " oid " ServerInstance Apache_defs::WebServerInfo" getline serverinstanceattribute split(serverinstanceattribute,sia,"\" \"") currentconfigfile=sia[4] # httpd.conf filename split(sia[7],temp,"\"") # to handle FALSE or TRUE at the end currentendpoint=temp[1] # endpoint name if ((endpoint==currentendpoint)&&(configfile==currentconfigfile)) { "wapachews -p " $1 " refresh" getline output "wdmdistrib -p " profile getline output } }' 2. Create a new task library or open an existing one, in order to create a task. The task logic will be created by referencing the script created in the previous step: a. From the task library dialog click Create->Task to create a new task. In our example we created the task in the task library named IBM Tivoli Monitoring Tasks. b. On the Create Task dialog select the following; please see the details in Figure Task name refresh_task Platforms supported Generic Roles required to execute the task user Chapter 4. Extending the monitoring solution 91

112 Figure 4-10 Create Apache server automation task dialog c. When selecting Generic, Tivoli will present a prompt to enter the following: The On Host is the name of the server on which the script is stored and Path to File is the complete path to the script created in Step 2 on page 91. Figure 4-11 shows the specifications used in our example. On Host x220svr Path to file C:\Tivoli\Scripts\apache_auto.sh Figure 4-11 Generic executable for a task details TEC Rule Creation The discovery and distribution task needs to be executed at a managed node or the TMR server. Tivoli Enterprise Console is used to automate the task 92 Introducing IBM Tivoli Monitoring for Web Infrastructure

113 invocation, based on events received from the resource models. Using TEC rules the invocation of a task may be linked to reception of specific events. The following describes the steps needed to facilitate this: 1. Create a new TEC rule in the ITMWAS1 rule base. The name of the rule used in our example is Apache_Rule. a. Create a new rule in the ITMWAS1 rule base using the Tivoli desktop by opening the rule base and selecting Edit Rules. b. Define a new rule from the T/EC Rule Base: ITMWAS1 dialog. Click Rule Set -> New Rule Set and type the name of the new rule Apache_Rule - in the Set Name field. c. To specify the logic of the rule, click Rule->New Rule->Simple in the Rule Set: Apache_Rule dialog. This will open yet another dialog Simple Rule: New Simple Rule, as shown in Figure Figure 4-12 Simple Rule Window d. Click on Event Class and add the following events: FileChanged e. Click OK on the Select Class dialog to close it. f. Click Actions, and the Actions in Rule: New Simple Rule dialog will appear, as shown in Figure In this dialog, specify the following: When to Run When event is received Actions Launch a Task Chapter 4. Extending the monitoring solution 93

114 Figure 4-13 Actions in rule g. Click Edit Task and select refresh_task. h. Click on Edit Arguments and fill in the following values for Selected Attributes. Please refer to Figure 4-14, which shows the details: adapter_host pathname profilename 94 Introducing IBM Tivoli Monitoring for Web Infrastructure

115 Figure 4-14 Edit Arguments i. Click OK and close the Edit Arguments dialog. Important: The order of the arguments should be the same order in which you use them in the shell script. j. Click OK and close the Actions in Rule dialog. k. Click OK and close the Simple Rule dialog. l. Close the rule dialog. m. Save the rule base. n. Now, import the new rule into the ITMWAS1 rule base. This may easily be done from a command line using the wrb command: wrb -imptgtrule <rule_name> <EventServer_Name> <rule_basename> Using the names in our example, the command is: wrb -imptgtrule Apache_Rule EventServer ITMWAS1 o. Compile and load the ITMWAS1 rule base with the new Apache_Rule from the Tivoli desktop. Chapter 4. Extending the monitoring solution 95

116 p. To make sure that our rules have been created correctly, edit the Apache_rule.rls file and make sure its content resembles the rule shown in Example 4-4. Example 4-4 Contents of Apache_Rule rule file /*****rule2:new Simple Rule*****/ rule: plain_rule2_5: (event: _ev2 of_class within ['FileChanged'] where [ adapter_host: _ev2_adapter_host, pathname: _ev2_pathname, profilename: _ev2_profilename ], reception_action: action0: ( (exec_task(_ev2, refresh_task, ' -l "IBM Tivoli Monitoring Tasks" -h "x220svr" -a "%s" -a "%s" -a "%s"', [_ev2_adapter_host,_ev2_pathname,_ev2_profilename], 'YES')) ) ). The final step needed to automate the monitoring of new Web sites hosted by Apache HTTP servers is to distribute the profile containing the Apache resource models, to the Apache HTTP server managed object. This task is usually performed from the Tivoli desktop, but the wdmdistrib command is a valid alternative. Once the profile has been distributed to all the Apache HTTP server managed objects, monitoring of new Web sites will be automatically enabled without any user intervention Advanced automation - building a new resource model The standard automation solution for automating Web site monitoring for sites hosted by Apache HTTP servers works fine if the Apache server is operational, when the FileChanged resource model discovers changes to the configuration file and kicks-off the automation process. This is, however, not always the case. The HTTP site administrator will normally stop and start the HTTP server after having changed the configuration, in order to verify that the new configuration settings work. There is, therefore, a chance, that the server is not operational when the automation process is invoked, therefore the automation process will not be able to communicate with the Web server, and will not complete successfully; and since the configuration file change has been caught already, the automation process will not be invoked again until new changes are applied to the configuration file. To avoid missing an update because the server is down, we need to build some more resilience into the automation solution, by combining functions from the FileChanged and Apache_ServerAvailability resource models. 96 Introducing IBM Tivoli Monitoring for Web Infrastructure

117 Manipulating resource models through the Workbench requires some basic knowledge of the components of a resource model. In brief, a resource model is a monitoring model that contains the program scheme necessary to determine what data is to be accessed from an endpoint and how this data is to be handled. The major components of a resource model are: The configuration file The MOF file The decision tree file The message catalog for building events to be sent to the TEC and TBSM In addition, the resource model may include: Class files to interface with the native library The native library All of these files are transferred to the endpoint at the time of profile distribution. At this time, a set of parameters controlling the overall behavior, not the logic, of the resource model is transferred as well. These parameters are defined as part of the Tmw2k profiles, which reference the resource models for the specific type of resource that is the target of monitoring. The parameters can be user defined or context parameters passed by the object representing a specific Web server. The values for context parameters are collected during the discovery process. Therefore, any changes to the configuration of the Web server object will only be reflected into the managed object after a refresh, and in the actual monitoring only after redistribution of the profile, therefore, the need for both re-discovery and re-distribution in the automation solution. The MOF file contains the particular resource model's class description and event definitions according to the CIM specification. The configuration details of the resource model are obtained by the engine from the configuration file. These configuration details include resource model name, platform name, name of the decision tree file, and names of the MOF files used. The decision tree file (VB script or JavaScript for Windows platform and only JavaScript for UNIX/LINUX platforms) contains both the initialization settings for the resource model and the algorithm that is used by the IBM Tivoli Monitoring analyzer to determine if a problem is encountered in the resources monitored by the resource model. For more details on the internals of resource models, refer to the redbook IBM Tivoli Monitoring Version 5.1: Advanced Resource Monitoring, SG Modifying a resource model In this section, a sample for building a new resource model for the Apache automation scenario is provided. The existing Apache_ServerAvailability resource model will be used as the base reference and will be used to create a new resource model named ApacheChangeConfiguration, without replacing the existing Apache_ServerAvailability resource model. Chapter 4. Extending the monitoring solution 97

118 Using the Workbench, the following outlines the steps needed to create the ApacheChangeConfiguration resource model: 1. Make a copy of Apache_ServerAvailability.dmjsws file as ApacheServerConfigurationChange.dmjsws. On the IBM Tivoli Monitoring workbench window, click File -> Open and open ApacheServerConfigurationChange.dmjsws. 2. The ApacheWebserverAvailability_unix.mof will be used in the new resource model. To generate this file, click Build-> Export Mof and save the file as ApacheWebserverAvailability_unix.mof. 3. The DMXFile.tar and DMXFile.mof files needs to be extracted, in order to be used in the new resource model. This two files represent the provider: a. From the Workbench, click File -> Open and open DMXFile.dmjsws. b. On the first pane, click Dependencies->All and expand the tree. Next right-click DMXFile.tar and select Extract and save the file. Repeat the extract for the DMXFile.mof file. 4. To change the resource model name right-click Apache_ServerAvailability and select modify. In the General Settings dialog box modify the following: Internal Name ApacheServerConfigurationChange Descriptive Name Description Apache Server Configuration Change This resource model monitors the changes in the configuration file and verifies whether Apache Web server is up and running. In case the configuration file has been changed and the Web server is restarted, an event that the Web server has been re-initiliazed is sent. Supported Platforms Select solaris2/aix4r1/linux-ix86 5. The Unix-Linux file resource model has to be merged into the new resource model. This is achieved by using the MOF compiler, from a command line using following syntax. mofcomp -n:root\cimv2 <mof_filename> The complete command and its output is shown in Example 4-5. Note: DMXFile.mof should be a DOS type file containing CRLF. UNIX type files will not be processed by a MOF Compiler. Example 4-5 MOF compilation C:\mofcomp -n:root\cimv2 DMXFile.mof Microsoft (R) 32-bit MOF Compiler Version Copyright (c) Microsoft Corp All rights reserved. 98 Introducing IBM Tivoli Monitoring for Web Infrastructure

119 Parsing MOF file: DMXFile.mof MOF file has been successfully parsed Storing data in the repository... Done! 6. Go back to the Workbench and expand Dynamic Model. Right-click CIM Classes. Select Add from the popup menu. a. On the Connect to namespace dialog, enter root\cimv2. Click OK. b. Click OK on the WMI Tivoli Workbench Login dialog to login as the current user to open the Dynamic Model dialog and do the following: i. From the WMI Class browser list select DMXFile. ii. Enter File in Use Alias text field. iii. From the Class Properties Available add pathname, size, accesstime, modificationtime, changetime, crc32 to the Selected list. iv. Click OK and close the Dynamic Model dialog. 7. All TEC events should have unique event names. To differentiate events from the new ApacheConfigurationChange resource model from the ones sent from the Apache_ServerAvailability resource model, it is necessary to modify the existing event name and also create a new event. The following outlines the steps needed to modify and create events in the new resource model. Once these steps have been completed, the Events dialog will look similar to the one shown in Figure a. To modify the existing event, expand Events, right-click Apache_EV_ServerStopped and select Modify from the context menu. b. From the Events dialog, modify the Internal Name to ApacheServerReinitialized. Also change the Descriptive Name, Message and Description, to describe the new event. c. To create a new event, right-click Events and select Add from the context menu. i. Enter ApacheServerStopped in the Internal Name field. ii. Click Add, to add the attributes. On the Adding Event Attribute dialog, add ServerName, application_version, application_oid, application_class, application_label and pathname as STRING types. Click OK and close Adding Event Attribute dialog. iii. Select ServerName in the Attributes list and click Key. This would make ServerName the Key for the aggregation settings. iv. Select Clearing Event v. Select Send to TEC as the notification method. Chapter 4. Extending the monitoring solution 99

120 vi. Add Descriptive Name, Message and Description, to describe the new event. vii. Click OK and close the Events dialog. Figure 4-15 Renaming ApacheServerStopped event 8. Create a new event named ApacheServerReinitialized by clicking on the Events node on the left-hand pane. Select the Add option and create the event named ApacheServerReinitialized. This event will contain the following String properties: servername application_version application_oid application_class application_label pathname It will aggregate according to the ServerName property. The events will be forwarded to TEC and it will be cleared. The severity level is WARNING. The event structure is shown in Figure Introducing IBM Tivoli Monitoring for Web Infrastructure

121 Figure 4-16 The new event ApacheServerReinitialized 9. Finally, add the dependencies for the new resource model. To do this expand Dependencies and right-click aix4-r1. Select Add from the context menu and add libdmxfile.a (aix4-1 only) or libdmxfile.a (for linux-ix86 and solaris2), DMXFile.tar, DMXFile.mof and the ApacheWebserverAvailability_unix.mof mof file. Repeat this for linux-ix86 and solaris2. Once all the above steps have been completed, the contents of Workbench will look similar to Figure Chapter 4. Extending the monitoring solution 101

122 Figure 4-17 Apache server configuration change resource model The next step is to update the logic of the javascript code that implements the decision tree script in the resource model. Using the Workbench, new code is added to the VisitTree section of the script, and the checkfiles and init functions are updated to support the new function. Basically the ApacheConfigurationChange resource model will implement the same algorithm as implemented by the Apache_WebSiteAvailability resource model. In this case, a the new event should be fired when the fully qualified Apache configuration file has been modified and the pid file has been changed 2. If both of these two conditions occur, and the Web server is running, the event ApacheServerReinitialized will be fired. 2 Note that a change in the pid file means that the Apache Web server has been restarted. 102 Introducing IBM Tivoli Monitoring for Web Infrastructure

123 Note: The fully qualified Apache configuration file name and the fully qualified pid file name are context parameters passed to the resource model by the Apache object. The system administrator should not configure any external parameters. The values for these two parameters are collected as shown in Example 4-6. Notice in order to have the DMXFile provider to work inside our new resource model, we must pass the two Apache files as parameters. This is achieved by creating a parameter FileList programmatically and associating it to the File class. Example 4-6 the ApacheConfigurationChange init function function Init(Svc) { Svc.Trace(2,"Entering Init"); var retcode = 0; Svc.Trace(2, "Apache_ServerAvailability ---> Start Init"); if (! Svc.ExistContextProperty("WEB_SERVER_VERSION")) { Svc.Trace(0, "Apache_ServerAvailability ---> Init - The Application Context is empty or not valid. Exiting with error code 801."); // > Engine will display error code on health console and end RM retcode = 801; } //ITSO httpdconfpathname=svc.getcontextproperty("web_server_config_pathname"); Svc.Trace(2, "ITSO Context configuration file " + httpdconfpathname); pidfilename=svc.getcontextproperty("web_server_pid_file_path"); Svc.Trace(2, "ITSO Context pid file " + pidfilename); Svc.DefineStrParameter ("FileList", httpdconfpathname+","+pidfilename); Svc.AssociateParameterToClass ("FileList","File"); dimension= Svc.GetStrParameterCount("FileList"); for (k=0; k < dimension ; k++) { check [k]= -5 ; ctime [k]= -5 ; mtime [k]= -5 ; } } Svc.Trace(2,"Exiting Init"); return (retcode); Chapter 4. Extending the monitoring solution 103

124 The file monitoring activity is performed by the checkfiles function. This function is a simplified version of the File resource model VisitTree function. In this case instead of monitoring two user defined parameters, it will monitor the Apache configuration and pid files. If the configuration file has been changed, a boolean variable named httpdconfpathchanged will be set to true. In the same way, if a the pid file has been changed (due to a Web server restart), a boolean variable named pidfilechanged will be set to true. For further details see the source code in Example 4-7. Example 4-7 the ApacheConfigurationChange checkfiles function function checkfiles(svc) { Svc.Trace(2,"Apache_ServerAvailability ---> checkfiles - Begin"); filelen = Svc.GetStrParameterCount("FileList"); Svc.Trace(2, "ITSO File Length" + filelen ); flagevent=0; if (flagfirsttime) { instancesf=svc.getnumofinst("file"); for(i=0; i < instancesf; i++) { numsize = Svc.GetNumProperty ("File",i,"size"); nummodificationtime = Svc.GetNumProperty ("File",i,"modificationTime"); numchangetime = Svc.GetNumProperty ("File",i,"changeTime"); numcrc32 = Svc.GetNumProperty ("File",i,"crc32"); strpathname = Svc.GetStrProperty ("File",i,"pathName"); strnumsize= numsize+""; strnummodificationtime = nummodificationtime+""; strnumchangetime = numchangetime+""; strnumcrc32 = numcrc32+""; Svc.Trace(3, "end Get attributes"); for(j=0; j < filelen; j++ ) { strtmpfile = Svc.GetStrParameter("FileList", j); Svc.Trace(2,"ITSO verifying whether " +strpathname + " should be initialized " + strtmpfile); if ( strpathname.equals(strtmpfile)) { Svc.Trace(2,"ITSO Initializing " +strpathname + " values"); check[ j] = numcrc32; ctime [ j]= numchangetime; mtime[j]= nummodificationtime; j = filelen; Svc.Trace(2,"ITSO End Initializing " +strpathname + " values"); } } } flagfirsttime=false; } //if else { 104 Introducing IBM Tivoli Monitoring for Web Infrastructure

125 instancesf=svc.getnumofinst("file"); for(i=0;i < instancesf;i++) { numsize = Svc.GetNumProperty ("File",i,"size"); nummodificationtime = Svc.GetNumProperty ("File",i,"modificationTime"); numchangetime = Svc.GetNumProperty ("File",i,"changeTime"); numcrc32 = Svc.GetNumProperty ("File",i,"crc32"); strpathname = Svc.GetStrProperty ("File",i,"pathName"); strnumsize= numsize+""; strnummodificationtime = nummodificationtime+""; strnumchangetime = numchangetime+""; strnumcrc32 = numcrc32+""; ); //ITSO Svc.Trace(2, "ITSO Analyzing the " + strpathname + " file"); Svc.Trace(2, "ITSO The modification time is " + strnummodificationtime Svc.Trace(2, "ITSO The change time is " + strnumchangetime ); for(j=0; j < filelen; j++ ) { strtmpfile = Svc.GetStrParameter("FileList", j); Svc.Trace(2, "ITSO working with " + strtmpfile + " file"); Svc.Trace(2, "ITSO comparing with " + strpathname + " file"); if ( strpathname.equals(strtmpfile)) { Svc.Trace(2, "ITSO the comparison between strpathname=" + strpathname + " and strtmpfile=" + strtmpfile + " succeeded"); if (( numchangetime!= ctime[ j] ) && ( numchangetime!= -1 )) { Svc.Trace(2,"ITSO File " + strtmpfile + " changed"); ctime[ j]= numchangetime; flagevent = 2; if ((nummodificationtime!= mtime[ j] ) && (nummodificationtime!= -1 )) { Svc.Trace(2,"ITSO File " + strpathname + " modified"); mtime[j]= nummodificationtime; flagevent = 1; } //if } //if if ((numcrc32!= check[j] ) && (numcrc32!= -1)) { check[j]= numcrc32; flagevent = 1; } //if Svc.Trace(2,"ITSO The flag Event is " + flagevent); switch ( flagevent ) { case 1 : Svc.Trace(2,"ITSO Comparing strtmpfile=" + strtmpfile + " with httpdconfpathname " + httpdconfpathname); if (strtmpfile.equals(httpdconfpathname)) { Chapter 4. Extending the monitoring solution 105

126 Svc.Trace(2, "ITSO the " + httpdconfpathname + " has been changed"); httpdconfpathchanged=true; } Svc.Trace(2,"ITSO Comparing strtmpfile=" + strtmpfile + " with pidfilename" + pidfilename); if (strtmpfile.equals(pidfilename)) { Svc.Trace(2, "ITSO the " + pidfilename + " has been changed"); pidfilechanged=true; } break; case 2 : // File attribute change, nothing to do in this case break; default : Svc.Trace(2, "ITSO No changes"); break; } //switch flagevent = 0; } //if } // for } //for } Svc.Trace(2,"Apache_ServerAvailability ---> checkfiles - End"); } The VisitTree function will call checkfiles and use the flags httpdconfpathname and pidfilename to verify whether these two files have been changed or not. If they are, and the current Web server status is active, the ApacheServerReinitialized event will be fired, and the two flags will be reset. Except for this, the ApacheServerConfigurationChange resource model VisitTree has the same structure of the Apache_WebServerAvailability resource model. Example 4-8 The ApacheConfigurationChange VisitTree function function VisitTree(Svc) { Svc.Trace(2,"Apache_ServerAvailability ---> VisitTree - Begin"); checkfiles(svc); //variables definition section var retcode = 0; var VNumSrvInst; var i; var strservername; var strserverstatus; var strapplicationversion, strapplicationoid, strapplicationclass, strapplicationlabel; 106 Introducing IBM Tivoli Monitoring for Web Infrastructure

127 var hproptable; //properties table creation hproptable = Svc.CreateMap(); // For TBSM - begin //application version (retrieved from the context variable WEB_SERVER_VERSION) strapplicationversion = Svc.GetContextProperty("WEB_SERVER_VERSION"); Svc.Trace(2, "Apache_ServerAvailability ---> VisitTree - strapplicationversion extracted from context variable WEB_SERVER_VERSION: " + strapplicationversion); //application proxy class (retrieved from the context variable WEB_SERVER_APPLICATION_CLASS) strapplicationclass = Svc.GetContextProperty("WEB_SERVER_APPLICATION_CLASS"); Svc.Trace(2, "Apache_ServerAvailability ---> VisitTree - strapplicationclass extracted from context variable WEB_SERVER_APPLICATION_CLASS: " + strapplicationclass); //application proxy label (retrieved from the context variable WEB_SERVER_APP_PROXY) strapplicationlabel = Svc.GetContextProperty("WEB_SERVER_APP_PROXY"); Svc.Trace(2, "Apache_ServerAvailability ---> VisitTree - strapplicationlabel extracted from context variable WEB_SERVER_APP_PROXY: " + strapplicationlabel); //application proxy OID (made up of CLASS:LABEL) strapplicationoid = strapplicationclass + ":" + strapplicationlabel; Svc.Trace(2, "Apache_ServerAvailability ---> VisitTree - strapplicationoid made up with CLASS:LABEL: " + strapplicationoid); // For TBSM - end //class ApacheWebServerAvailability VNumSrvInst = Svc.GetNumOfInst("ApacheWebServerAvailability"); Svc.Trace(2, "Apache_ServerAvailability ---> VisitTree - Number of instances for class ApacheWebServerAvailability: " + VNumSrvInst); if (VNumSrvInst == 0) { // No instancies returned means that the Application Context does not contain the PID file path. // Probably the ApacheWebServer object configuration must be refreshed because inconsistent. Svc.Trace(0,"Apache_ServerAvailability ---> VisitTree - Unable to find the path to the Apache instance PID file. Exiting with error code: 203"); // > Engine will display error code on health console and end RM Chapter 4. Extending the monitoring solution 107

128 } return (203); for (i=0; i<vnumsrvinst; ++i) { //initialization of properties table Svc.RemoveMapAll(hPropTable ); //server name (retrieved from the context variable WEB_SERVER_APP_PROXY) strservername = Svc.GetContextProperty("WEB_SERVER_APP_PROXY"); Svc.Trace(2, "Apache_ServerAvailability ---> VisitTree - ServerName extracted from context variable WEB_SERVER_APP_PROXY: " + strservername); // For TBSM - begin Svc.SetMapStrElement(hPropTable, "application_version", strapplicationversion ); Svc.SetMapStrElement(hPropTable, "application_class", strapplicationclass ); Svc.SetMapStrElement(hPropTable, "application_label", strapplicationlabel ); Svc.SetMapStrElement(hPropTable, "application_oid", strapplicationoid ); Svc.SetMapStrElement(hPropTable,"pathname", httpdconfpathname); // For TBSM - end //server status string strserverstatus = Svc.GetStrProperty("ApacheWebServerAvailability", i, "WebServerStatus"); Svc.Trace(2, "Apache_ServerAvailability ---> VisitTree - ServerStatus: " + strserverstatus); Svc.SetMapStrElement(hPropTable, "ServerName", strservername ); Svc.Trace(2, "ITSO The pidfilechanged status is " + pidfilechanged); Svc.Trace(2, "ITSO The httpdconfpathchanged is " + httpdconfpathchanged); if ( strserverstatus == "Running" ) { Svc.Trace(2, "ITSO starting check for changes in the files"); if ( (pidfilechanged) && (httpdconfpathchanged) ) { Svc.Trace(2, "ITSO going to send the ApacheServerReinitialized event"); Svc.SendEventEx("ApacheServerReinitialized", hproptable); pidfilechanged=false; httpdconfpathchanged=false; } Svc.SetMapNumElement(hPropTable, "GWA_Server_running", 100); Svc.SetMapNumElement(hPropTable, "GWA_Server_stopped", 0); } if ( strserverstatus == "Not Running" ) 108 Introducing IBM Tivoli Monitoring for Web Infrastructure

129 { } //an event is sent if the server is stopped Svc.SendEventEx("ApacheServerStopped", hproptable); Svc.SetMapNumElement(hPropTable, "GWA_Server_running", 0); Svc.SetMapNumElement(hPropTable, "GWA_Server_stopped", 100); } Svc.LogInstEx("Availability", "Server", hproptable); //properties tables deallocation Svc.DestroyMap(hPropTable); Svc.Trace(2,"Apache_ServerAvailability ---> VisitTree - End"); } return (retcode ); Save the ApacheServerConfigurationChange.dmjsws file. Click Build->Build Package to create the resource model ApacheServerConfigurationChange.tar file, and click Build->Build TEC Baroc to generate the ApacheServerConfigurationChange.baroc file for use by TEC. For instructions about how to obtain a copy of the completed resource model, refer to Appendix C, Additional material on page 181. Putting the new resource model into production The final step is to add the new resource model to IBM Tivoli Monitoring environment by using the wdmrm -add <filename> command as shown in Example 4-9. Example 4-9 Add resource model. wdmrm -add ApacheServerConfigurationChange.tar IBM Tivoli Monitoring - Adding new resource model Copying ApacheServerConfigurationChange.cat msgfile... Copying ApacheServerConfigurationChange.cat zipfile... IBM Tivoli Monitoring - Resource model utility Parsing configuration file ApacheServerConfigurationChange.conf... Configuration file successfully parsed. the resource ApacheServerConfigurationChange already exists, checking of version number... Chapter 4. Extending the monitoring solution 109

130 Checking for event redefinition... Starting resource ApacheServerConfigurationChange registration... the resource ApacheServerConfigurationChange has been successfully stored. Registration completed. Installation completed. In order to use the newly added ApacheConfigurationChange resource model, complete the following four steps, in order to prepare the TEC environment to receive the new event, and set up a profile to be distributes to the Apache server managed objects. 1. Import the ApacheServerConfigurationChange.baroc into a ruleset in TEC environment with the wrb command as shown in following example. Example 4-10 Importing the new baroc file wrb -imprbclass ApacheServerConfigurationChange.baroc ITMWAS1 2. Create a new rule where the event that will trigger the task execution is the ApacheServerReinitialized event and import it as described in Example 4-4 on page 96. Compile and load the ITMWAS1 ruleset. 3. Create a profile as described in Standard automation using default resource models and tasks on page 88, referencing this resource model and the Apache_WebSiteAvailability resource models. 4. Distribute the new profile to the Apache object(s) representing the managed Web server(s). With this new Resource model, the Apache object will be refreshed only if there is a change in the configuration file followed by a Web server restart. In this way the Apache object will be upgraded only when the new configuration has been activated at the Apache Web server, and not while the system administrator is working on the configuration file. In order to create a similar automation solution to refresh the iplanet object and push a profile containing the iplanet_virtualserveravailability resource model with the iplanet_prm_virtualserver parameter set to ALL (in such a way that it monitors all the configured Virtual Servers), we need to develop a new MOF file, a new Instrumentation Library Type (ILT) and a new provider that can verify whether a new Web site has been added or an existing one has been modified. The iplanet Web server creates a new directory for each Web site, for example, C:\iPlanet\Servers\https1-hannover1. Each of these directories contains a server.xml file in the config subdirectory. Therefore, this provider should return a list of all the fully qualified server.xml files available in the Servers subdirectory with their modification date. In turn, the ILT should enumerate them and a modified iplanetserveravailability resource model should verify whether there is a new occurrence of server.xml or some of them have been modified. If so, a 110 Introducing IBM Tivoli Monitoring for Web Infrastructure

131 new event such as iplanetserverreinitialized will be fired, a specific TEC rule will be applied in order to trigger the execution of a task based on a script, similar to the one described in Example 4-3 on page 91, to refresh the iplanet object and push the profile on the same iplanet application object. As far as the IIS Web server is concerned, to verify whether new Web site has been added or modified, you are required to develop a native provider that can access the IIS Metabase. This provider could be used to create a new resource model based on IIS_ServerAvailability resource model. The new resource model will fire a IISReinitialized event when a configuration change occurs. In this case a specific TEC rule will be applied in order to trigger the execution of a task based on a script similar to the one described in Example 4-3 on page 91 to refresh the IIS object and push the profile on the same IIS application object. Further details about developing a MOF file, an Instrumentation Library Type component and a provider the can be found in the IBM Tivoli Monitoring Workbench 5.1 User s Guide, SH Chapter 4. Extending the monitoring solution 111

132 112 Introducing IBM Tivoli Monitoring for Web Infrastructure

133 5 Chapter 5. Troubleshooting The goal of this chapter is to provide some tools and tips that will help turn the art of troubleshooting into a science. We will be focussing only on IBM Tivoli Monitoring for Web Infrastructure related issues. Problems with IBM Tivoli Monitoring for Web Infrastructure would range from the endpoint to all the way to any component in your Tivoli environment. There are lot of guides available to troubleshoot your Tivoli environment. Copyright IBM Corp All rights reserved. 113

134 5.1 Troubleshooting Web Infrastructure modules In case your IBM Tivoli Monitoring for Web Infrastructure monitors, implemented through the resource models that have been distributed to the selected managed application objects, do not work as expected, and you do not see events in the Tivoli Enterprise Console or Tivoli Business Systems Manager, you will have to enable the traces and read your log files to troubleshoot Endpoint architecture In this section, we will explain the product structure to help you perform problem determination. Understanding of the structure is critical in finding where things are broken and possibly fixing them. The IBM Tivoli Monitoring for Web Infrastructure is based largely on the IBM Tivoli Monitoring product structure. The structure of the product at the endpoint is shown in Figure 5-1. lcfd Tivoli Endpoint Tmw2k_ep Endpoint method Tmw2k ITM Engine Resource models Visual Basic or JavaScript CIM layer WMI or Touchpoint M12JavaProvider out of process provider ILT Manager for Java with ILTs Figure 5-1 Endpoint architecture for IBM Tivoli Monitoring for Web Infrastructure From Figure 5-1, we can see: The core structure of the IBM Tivoli Monitoring product uses the Common Information Model (CIM) management structure. In a Windows platform, this is implemented using Windows Management Interface (WMI) which is installed by default in Windows 2000 and higher. In other platforms, Tivoli 114 Introducing IBM Tivoli Monitoring for Web Infrastructure

135 creates a CIM-like layer that is written in pure Java that provides the CIM services; this layer is called Touchpoint. The monitoring engine is called tmw2k (based on the Tivoli Manager for Windows 2000) which can be started and stopped by the Tivoli endpoint code. The tmw2k engine uses resource models that are downloaded from the gateway when a Tmw2kProfile is distributed. The resource model generally consists of: mof files code, written in java scripts for the IBM Tivoli Monitoring for Databases jar files for the Java monitors The resource model mof files are compiled and stored. The code part of a resource model has specific subroutines: Init, VisitTree... The resource model extract data using an Out-of-process data provider to the Windows management infrastructure. For a Java based provider, Tivoli uses a program called M12JavaProvider. This process will interact with the actual resources to provide data for specific metrics that the resource model requires. Some of this data is acquired directly from the Java program, some invokes a command line shell program or other mechanism. The ILTs are processes that actually access the resources for monitoring metrics. There are several types of ILTs that Tivoli provides Logfiles When trying to resolve problems you should start by looking at the log file, if there is one. Log files are written in a readable format and stored in the server and the endpoints. The <Tivoli-Install-Directory>\db\<TMR-Server>.db\AMW\logs which will be referred as $DBDIR/AMW/logs is the log directory for managed nodes and servers. Here <Tivoli-Install-Directory> is the directory where you have installed the framework and <TMR-Server> is the name of your TMR Server. The log files on the server are named as msg_<component>.log and the trace files are called as trace_<component>.log. For endpoint logs the directory is $LCF_DATDIR/LCFNEW/AMW/logs on UNIX endpoints, while on Windows endpoints the logs directory is $LCF_DATDIR/LCFNEW/Tmw2k/. If the problem cannot be resolved from the log file, then the trace file needs to be provided to Customer Support. This file $DBDIR/AMW/logs/<profile-name>.log contains the status of the profile distribution to an endpoint. The <profile-name> is the name of the profile you have pushed to the endpoint. Chapter 5. Troubleshooting 115

136 The file $DBDIR/AMW/logs/trace_tmnt_ <component_name>_engn.log are the traces maintained at the gateway of the activities carried out when the particular component engine is running.the n is a number in the range 1-9; as each file becomes full the number is incremented, cycling back to 1 when file 9 is full. The <component_name> is the component for which you have enable the trace. The directory $DBDIR/AMW/logs/tedw/<endpoint-name> will be created if the endpoint has been successfully enabled for TEDW. To verify that the TEC events are send, check the directory $LCF_DATDIR/LCFNEW/Tmw2k/UNix/TEC/cache. If the events are not sent to the TEC, the event is cached. The endpoint log files related to the IBM Tivoli Monitoring for Web Infrastructure modules are in $LCF_DATDIR/LCFNEW/<Module_Dir>/logs. The server log files related to the IBM Tivoli Monitoring for Web Infrastructure modules are in $DBDIR/<Module_Dir>/logs. The <Module_Dir> is described in Table 5-1. Table 5-1 Module Directory Warehouse Module Name Apache HTTP Server iplanet Web server Internet Information Server WebSphere Application Server Module Directory gwa gwp gwi izy Tracing All managed node components produce traces. Traces can be configured using the command: wdmconfig -D <component_name>.trace_level=value wdmconfig -D <component_name>.trace_size=value The <component_name> is the name of the component that produces the trace: heartbeat, for the heartbeat engine task, for the task engine tbsma, for the Tivoli Business Systems Manager engine core, for the profile core engine request-manager, for the request manager engine gw, for the endpoint upcall 116 Introducing IBM Tivoli Monitoring for Web Infrastructure

137 To set the trace parameters of the Tivoli Monitoring engine at the endpoint use the following command: wdmtrceng -e endpoint <logfile_name> <level> The <level> is between and 0-3, with 3 being the maximum Some common problems and solutions The following is a list of common problems and their solutions: 1. ITM Engine on endpoint not responding Try the wdmlseng and wdmcmd commands on the endpoint. If you get an error status check the existence of the IBM Tivoli Monitoring for Web Infrastructure modules under the directory $LCFNEW 2. On UNIX endpoints the profile distribution is performed, but the resource models created with Tivoli Monitoring detects an error or on Windows endpoints, the profile distribution fails. Execute the DMEndpointUninstall task at each endpoint component. 3. Events not sent to Tivoli Enterprise Console ACF not installed on the gateway when sending secure events. Tivoli Enterprise Console server not specified in the profile. Baroc files not installed on the server. 4. Uninstall at Windows endpoint fails This because a provider is locked by WMI. To resolve the problem, stop the Windows Management Instrumentation from the Windows Control Panel/Services and retry again. 5. The Web server object on the managed node shows wrong Web site information. All the information about the Web site are maintained on the Web server object on the managed node and has to be refreshed manually Resource Models development The development life cycle of a UNIX resource model can be described as an interactive process based on the following steps: 1. Workbench development and build 2. Resource model installation in the ITM environment with the wdmrm command 3. Testing by pushing the profile on the application object 4. Log file analysis to find possible bugs Chapter 5. Troubleshooting 117

138 A resource model development and installation example is described 4.2.3, Advanced automation - building a new resource model on page 96. Note that a newer version of the same resource model can be installed only if its version number is greater than the currently installed one. Only in this case the wdmcm command will be able to replace the current resource model with the new one. To perform the log file analysis, set the log level to 3 in the command wdmtrceng. Example 5-1 wdmtrceng wdmtrceng -e colt187 "" 3-1 To ease the interactive development process of a resource model, it is very useful to have a clean engine before pushing a profile after having replaced the old resource model with the new one. An engine without any resource models allows you to process the latest mof files, uses the new java scripts and loads the upgraded ILTs and providers. Before removing the resource models from the engine, stop it with wdmcmd command. Example 5-2 wdmcmd wdmcmd -stop -e colt187 Remove the resource models from the engine. A cleanrm.sh script prototype that allows you to remove all the resource models from a UNIX engine is shown in Example 5-3. Example 5-3 the cleanrm.sh script # removes the serialized mof files, don t remove namespace rm $LCFNEW/Tmw2k/Unix/data/cimom/persistence/classes/root/<mof filenames> # removes the ilts and providers classes rm $LCFNEW/Tmw2k/Unix/Classes/com/tivoli/dmunix/ep/ilts/*.class rm $LCFNEW/Tmw2k/Unix/Classes/com/tivoli/dmunix/ep/providers/*.class #removes the javascript file rm $LCFNEW/Tmw2k/Unix/Dec/*.js # removes resource models rm $LCFNEW/Tmw2k/Unix/data/rm/*.zip rm $LCFNEW/Tmw2k/Rm/*.zip # removes the logs rm $LCFNEW/AMW/logs/*.log rm $LCFNEW/AMW/logs/*.old # removes the profiles rm $LCFNEW/Tmw2k/Unix/data/profiles/*.dmprf Push the profile and analyze the log files for possible bugs. 118 Introducing IBM Tivoli Monitoring for Web Infrastructure

139 6 Chapter 6. Management reporting The Tivoli Enterprise Data Warehouse (TEDW) is an application used to collect and manage data from various Tivoli and non-tivoli system management applications. The data is imported into the TEDW databases through specialized programs, called extract, transform and load (ETL) programs, from the management application databases, and further processed for historical analysis and evaluation. It is Tivoli s strategy to have most of its products providing ETLs so that the TEDW databases can be populated with meaningful systems management data. The IBM Tivoli Monitoring for Web Infrastructure is one of the many products to fully leverage and utilize TEDW. This chapter provides details on how IBM Tivoli Monitoring for Web Infrastructure leverages the Tivoli Enterprise Data Warehouse, and how to achieve integration and how to obtain the Tivoli Enterprise Data Warehouse reports. Copyright IBM Corp All rights reserved. 119

140 6.1 Overview of Tivoli Enterprise Data Warehouse Having access to historical data regarding the performance and availability of IT resources may prove to be very useful in various ways, such as: TEDW collects historical data from many applications into one central place. TEDW collects the underlying data about the network devices/connections, desktops/servers, applications/software, and the problems and activities that have gone on to manage the infrastructure. This allows the for construction of an end-to-end view of their enterprise and view the related resource data independent of the specific applications used to monitor and control the resources. TEDW adds value to raw data. TEDW performs data aggregation based on user specified periods, such as daily or weekly, and allows for restricting the amount of data stored in the central data TEDW repository. The data is also cleaned and consolidated in order to allow the data model of the central repository to share common dimensions. For example, TEDW ensures that time, host name, and IP addresses are the same dimensions across all the applications. TEDW allows for correlation of information from many Tivoli applications. TEDW can also be used to derive added value by correlating data from many Tivoli applications. It allows reports to be written, which correlate cross application data. TEDW uses open, proven interfaces for extracting, storing, and sharing the data. TEDW can extract data from any application, Tivoli and non-tivoli, and store it in a common, central database. TEDW also provides transparent access for third-party Business Intelligence (BI) solutions using the CWM standard, such as IBM DB2 OLAP, Crystal Decisions, Cognos, BusinessObjects, Brio Technology, Microsoft OLAP Server. CWM stands for Common Warehouse Metadata, an industry standard specification for metadata interchange defined by the Object Management Group (see TEDW provides a Web-based reporting front end, called the Reporting Interface, but the open architecture provided by the TEDW allows other BI front ends to be used to access the data in the central warehouse. The value here is flexibility. Customers can use the reporting application of their choice; they are not limited to any specific one. 120 Introducing IBM Tivoli Monitoring for Web Infrastructure

141 TEDW provides a robust security mechanism. TEDW provides a robust security mechanism by allowing data marts to be built with data from subsets of managed resources; and, by providing database level authorization to access those data marts, TEDW can address most of the security requirements related to limiting access to specific data to those customers/business units with a need to know. TEDW provides a scalable architecture. Since TEDW depends on the proven and industry standard RDBMS technology, it provides a scalable architecture for storing and retrieving the data TEDW concepts and components This section discusses the key concepts and the various components of TEDW in the logical order that the measurement data flows: from the monitors collecting raw data to the final detailed report. Figure 6-1 depicts a typical Tivoli Enterprise Data Warehouse configuration that will be used throughout this section. Source Applications ITM ITM Database TEDW Environment TEC ITMfWeb ITMfBI TEC Database ITM Database ITM Database Source Appls ETLs TEDW Central Data Warehouse Target ETLs Data Mart Data Mart Data Mart Data Mart Data Mart TEDW Reporting Interface Business Intelligence and Reporting Tools IBM BRIO TEDW Control (Metadata) TEDW Control Center Business Objects Cognos Crystal Reports Third Party Third-Party Database Figure 6-1 A typical TEDW environment It is common for enterprises to have various distributed performance and availability monitoring applications deployed that collect some sort of measurement data and provide some type of threshold management, central Chapter 6. Management reporting 121

142 event management, and other basic monitoring functions. These applications are referred to as source applications. The first step to obtain management data is to enable the source applications. This means providing all tools and castigation necessary to import the source operational data into the TEDW central data warehouse. All components needed for that task are collected in so-called warehouse modules for each source application. In the context of the topic of this publication, IBM Tivoli Monitoring for Web Infrastructure is the source application providing management data for Web server and Application server data warehouse modules. One important part of the warehouse modules are the Extract, Transform and Load data programs or simply ETL programs. In general, ETL programs process data in three steps. 1. First they extract the data from a source application database, called the data source. 2. Then the data is validated, transformed, aggregated, and/or cleansed so that it fits the format and needs of the data target. 3. Finally the data is loaded into the target database. In TEDW there are two types of ETLs: central data warehouse ETL and data mart ETL. Central data warehouse ETL: The central data warehouse ETL pulls the data from the source applications and loads it into the central data warehouse, as shown in Figure 6-1. The central data warehouse ETL is also often referred to as the source ETL or ETL1. Data mart ETL: As shown in Figure 6-1, the data mart ETL extracts a subset of historical data from the central data warehouse that contains data tailored to and optimized for a specific reporting or analysis task. This subset of data is used to populate data marts. The data mart ETL is also known as target ETL or ETL2. As a generic concept, a data warehouse is a structured, extensible database environment designed for the analysis of consistent data. The data that is inserted in a data warehouse is logically and physically transformed from multiple source applications, updated and maintained for a long time period of time, and summarized for quick analysis. The Tivoli Enterprise Data Warehouse Central Data Warehouse (CDW) is the database that contains all enterprise-wide historical data, with hour as the lowest granularity. This data store is optimized for the efficient storage of large amounts of data and has a documented format that makes the data accessible to many analysis solutions. The database is organized in a very flexible way, which lets you store data from new applications without adding or changing tables. 122 Introducing IBM Tivoli Monitoring for Web Infrastructure

143 The TEDW server is an IBM DB2 Universal Database Enterprise Edition server that hosts the TEDW Central Data Warehouse databases. These databases are populated with operational data from Tivoli and/or other third-party applications for historical analyses. A data mart is a subset of the historical data that satisfies the needs of a specific department, team, or customer. A data mart is optimized for interactive reporting and data analysis. The format of a data mart is specific to the reporting or analysis tool you plan to use. Each application that provides a data mart ETL creates its data marts in the appropriate format. TEDW provides a Report Interface (RI) that creates static two-dimensional reports of your data using the data marts. The Report Interface is a role-based Web interface that can be accessed with a simple Web browser without any additional software installed on the client. You can also use other tools to perform OLAP analysis, business intelligence reporting, or data mining. The TEDW Control Center is the IBM DB2 Universal Database Enterprise Edition server containing the TEDW control database that manages your TEDW environment. From the TEDW Control Center, you can also manage all source applications databases in your environment. The default internal name for the TEDW control database is TWH_MD. The TEDW Control Center also manages the communication between the various components, such as the TEDW Central Data Warehouse, the data marts, and the Report Interfaces. The TEDW Control Center uses the DB2 Data Warehouse Center utility to define, maintain, schedule and monitor the ETL processes The TEDW stores raw historical data from all Tivoli and third-party application databases in the TEDW Central Data Warehouse database. The internal name of the TEDW Central Data Warehouse database is TWH_CDW. Once the data has been inserted into the TWH_CDW database, it is available for either the TEDW ETLs to load to the TEDW Data Mart database (the internal name of the TEDW Data Mart database is TWH_MART) or to any other application-specific ETL to process the data and load the application-specific data mart database Monitoring process data flow In this section we discuss how the warehouse component of the IBM Tivoli Monitoring for Web Infrastructure product interacts with the Tivoli Enterprise Data Warehouse. We will also describe the various components that make up the IBM Tivoli Monitoring for Web Infrastructure warehouse component. We demonstrate how the data is collected from the endpoint and how it reaches the data warehouse database as shown in Figure 6-2. The data marts and ELT s used by the warehouse components are explained in Table 6-4 on page 147 and Table 6-5 on page 149. Chapter 6. Management reporting 123

144 TEDW Environment ITM Middle Layer Database Source Appls ETLs TEDW Central Data Warehouse ETLs Data Mart Data Mart Data Mart Data Mart Data Mart TEDW Reporting Interface ITM Uploader TEDW Control (Metadata) TEDW Control Center Business Intelligence and Reporting Tools IBM Business Objects Cognos BRIO Crystal Reports Endpoint Database Endpoint Database Figure 6-2 ITM for Web Infrastructure data flow To enable TEDW to receive data gathered by a resource model, you should enable the TEDW data logging for the profile in which, the resource model is used. Once this is profile is distributed to the endpoints, they start logging the data to the local IBM Tivoli Monitoring database. This database is available on every endpoint. The ITM upload component is responsible for moving data from the endpoint database to the middle layer storage database. The generic ETL1 is then used to collect data from the middle layer database for any IBM Tivoli Monitoring for Web Infrastructure module, transform and load these to the staging area tables and dynamic data tables in the central data warehouse, TWH_CDH. When the wdmcollect command is executed, the data collection from the endpoint database to the ITM middle layer database starts. In the next step the generic ETLs run to populate the Central Data Warehouse. Finally, the target ETLs are executed at scheduled intervals and the data mart databases are populated. Now, the Report Interface may be used to generate and show various reports based on the data in the newly populated/updated data mart. 124 Introducing IBM Tivoli Monitoring for Web Infrastructure

145 6.2 Install and configure the Warehouse components In this section we describe the necessary steps to configure the data gathering process in your environment, as follows: 1. Install and configure IBM Tivoli Monitoring - TEDW Support, Version Install, configure, and schedule the IBM Tivoli Monitoring Warehouse module. 3. Install, configure, and schedule the IBM Tivoli Monitoring for Web Infrastructure 5.1 Warehouse modules. 4. Create and configure the IBM Tivoli Monitoring for Web Infrastructure Data Mart database. Before going into the details of each step, we present the environment used for TEDW in the ITSO lab. This can be used as a starting point for setting up the data gathering process. We assume no pre-existing components will be used and describe the steps of a brand new installation. 1 AIX DB2 Server TEDW Central Data Warehouse TEDW Datamart AIX DB2 Server ITM Database (itm_db) ITM Data Mart (??????) TEDW Server Database Server (RIM Host) TWH_CWD Reporting data using OLAP and business inteligence tools TWH_MART 2 ITM Database ITM Data Mart Reporting data Web Browsers connecting to the Report Interface Windows 2000 DB2 Server TEDW Control Center Server ITM ETLs (???????) TWH_MD TEDW Control Center Figure 6-3 Installation scenario 3 TEDW Reporting Interface Windows 2000 DB2 Client TEDW Reporting Interface Tivoli Presentation Services As shown in Figure 6-3, our Tivoli Enterprise Data Warehouse environment is a small, distributed environment composed by three machines: 1. Tivoli Enterprise Data Warehouse server machine hosting the central Warehouse and the Warehouse Data Mart databases. Chapter 6. Management reporting 125

146 2. Tivoli Enterprise Data Warehouse Control Center machine hosting the Warehouse metadata database and handling all the ETLs executions. 3. Tivoli Enterprise Data Warehouse Reporting Interface machine allowing end users to obtain reports from data stored in the ITM data marts Installing and configuring the ITM Warehouse Support The IBM Tivoli Monitoring - TEDW Support, Version should be installed on the TMR Server and all Gateways/ Managed Nodes in your Tivoli environment that serves/supports the endpoints from which you want to collect data to be available for TEDW. As a requirement, the IBM Tivoli Monitoring product should be already installed. The installation method described here uses the Tivoli Desktop, as follows: 1. From the Tivoli desktop, select Desktop->Install->Install Product. 2. The Install Product dialog shows three products that are available to install. as depicted in Figure 6-4. Figure 6-4 Installing warehouse support 126 Introducing IBM Tivoli Monitoring for Web Infrastructure

147 3. Select IBM Tivoli Monitoring - TEDW Support, Version 5.1.1, then select your Tivoli Management Region server and the gateways that you want to have it installed on. Click Install and follow the normal installation dialogs. 4. RIM configuration is required to proceed the installation, as shown in Figure 6-5. Figure 6-5 RIM setup options The installation process will create a RIM object named itm_rim_<rimhost>, where <rimhost> is the RIM host of your Tivoli environment. The RIM object can also be created a later time using, for instance, the following command, assuming a DB2 database server: wcrtrim -v DB2 -h emlab3 -d itm_db -u db2 -H c:/db2/sqllib -s TCPIP -I c:/db2 itm_rim_emlab3 This RIM object by default has itmitm as the password. This must be changed to match the password of your database instance owner. To do this, use the wsetrimpw command as follows: wsetrimpw itm_rim_<rimhost> itmitm <newpw> Chapter 6. Management reporting 127

148 Where, <newpw> is the database instance owner password. 5. The database for the Warehouse Support component name is itm_db and now needs to be created. This process can be accomplished either by using a provided shell script or using SQL scripts. If you intend to use the provided shell script, make sure you grant the RDBMS administrator (or database instance owner) user ID with Administrator (root) and Tivoli_Admin_Privileges and run the script logged in as the RDBMS administrator user ID. The reason for that is the shell script collects information from the previously created RIM object in order to create both the database and its structure. The shell script name is cr_itm_db.sh and it is located in the $BINDIR/TME/Tmw2k/Warehousecfg directory. As an alternative method, you can use the SQL scripts. These scripts are also located in the $BINDIR/TME/Tmw2k/Warehousecfg directory and have the following name standard: cr_bd.<dbext> and cr_tbl.<dbext> Where, <DBext> is the database vendor designator. The following describes the database creation process for a DB2 RDBMS using the SQL scripts. a. On the RIM Host machine, login as your instance owner, in our case, db2inst1. b. Only perform this step if the RIM Host machine does not have the Warehouse Support component installed. Copy the cr_db.db2 and cr_tbl.db2 files from the $BINDIR/TME/Tmw2k/Warehousecfg directory from your TMR Server to the RIM Host machine. c. Move to the directory where the SQL scripts are located and rename cr_db.db2 to cr_db_db2.sql and rename cr_tbl.db2 to cr_tbl_db2.sql d. Run the following command to create the itm_db database: db2 -td$ -vf cr_db_db2.sql e. In order to have the itm_db database structure created run the following commands, where <db2inst1pw> is the database instance owner password. db2 connect to itm_db user db2inst1 using <db2inst1pw> db2 -td$ -vf cr_tbl_db2.sql 6. On the TMR server, test the RIM object connection: wrimtest -l itm_rim_<rimhost> The output should be similar to the following: 128 Introducing IBM Tivoli Monitoring for Web Infrastructure

149 Example 6-1 Testing the RIM object c:\>wrimtest -l itm_rim_emlab3 Resource Type : RIM Resource Label : itm_rim_emlab3 Hostname : emlab3 User Name : db2 Vendor : DB2 Database : itm_db Database Home : c:/db2/sqllib Server ID : TCPIP Instance Home : c:/db2 Opening Regular Session...Session Opened RIM : Enter Option > 7. The data collection process of the Warehouse Support component needs to be configured. The configuration file is named.config and it is located in the $DBDIR/dmml directory. The Warehouse support entries in the.config file have the prefix datacollector. Such entries should be added/modified using the wdmconfig command and it is important to notice that this file must not be modified manually. For details on the wdmconfig command refer to the IBM Tivoli Monitoring User s Guide, SH To configure the data collection process issue the following command: wdmconfig -m <TMRname> -D datacollector.rim_name=itm_rim_<rimhost> \ -D datacollector.db_purge_interval=30 \ -D datacollector.db_purge_time=0 \ -D datacollector.delay=30 \ -D datacollector.sleep_time=1 \ -D datacollector.max_retry_time=6 You can check if the entries were correctly set by issuing: wdmconfig -m <TMRname> -G datacollector* The output should be similar to the following: Example 6-2 Verifying data collection configuration c:\>wdmconfig -G datacollector* Managed Node : 'emlab3': ======================== datacollector.delay = 30 datacollector.sleep_time = 1 datacollector.max_retry_time = 6 datacollector.rim_name = itm_rim_emlab3 datacollector.db_purge_time = 0 datacollector.db_purge_interval = 30 Chapter 6. Management reporting 129

150 8. To enable data collection for a profile, you should enable the TEDW data logging. This can be done using the following steps: a. Double-click the profile manager you want to work with. b. Double-click the profile you want to distribute. c. Add or Edit the resource model. d. Click Logging and check Enable Data Logging and TEDW Data as shown in Figure Re-distribute the profile to the endpoints to activate the changes. Now the profile will start logging the data. Figure 6-6 Data logging 10.Run wdmcollect command on the gateway or TMR server to start the data collection Installing and Configuring the Warehouse modules The following sections describe the procedures in order to install, configure and schedule the Warehouse modules for both the IBM Tivoli Monitoring and IBM Tivoli Monitoring for Web Infrastructure products. The description of the installation steps is based on our lab environment scenario described in Figure 6-3 on page Introducing IBM Tivoli Monitoring for Web Infrastructure

151 It is assumed that the Tivoli Enterprise Data Warehouse environment Version 1.1 is already installed and operational. Details for achieving this can be found in the redbook Introduction to Tivoli Enterprise Data Warehouse, SG Pre-installation steps Prior to the installation of the Warehouse modules, you are required to perform the following tasks: Upgrade IBM DB2 Universal Database Enterprise Edition version 7.2 to at least Fixpack 6 level on your Tivoli Enterprise Data Warehouse environment. Fixpack6 for IBM DB2 Universal Database Enterprise Edition can be download from the official IBM DB2 technical support Web site: hist.d2w/report Apply the Fixpack 1.1-TDW-0002 on every database server in your TEDW environment. Fixpack 1.1-TDW-0002 for Tivoli Enterprise Data Warehouse can be downloaded from the IBM Tivoli Software support Web site, under the Tivoli Enterprise Data Warehouse category: Update your TEDW environment to the 1-1-TDW-FP01a. Fixpack 1-1-TDW-FP01a for Tivoli Enterprise Data Warehouse can be downloaded from the IBM Tivoli Software support Web site, under the Tivoli Enterprise Data Warehouse category: The documentation that accompanies the Fixpacks details the steps for installation in greater detail. Setting up the ITM Warehouse Module The IBM Tivoli Monitoring Warehouse Module extracts data from the IBM Tivoli Monitoring database (ITM_DB) and loads it into the TEDW Central Data Warehouse database (TWH_CDW) database. So this module acts as a source ETL. The IBM Tivoli Monitoring Warehouse module is often referred as ITM Generic ETL1. All TEDW ETL programs follow a naming convention using a three letter application-specific product code, known as measurement source code. The measurement source code for the ITMWeb generic ETL1 is AMX. The installation can be done using the TEDW Command Line Interface (CLI) or the Graphical User Interface (GUI) based installation program. Here we describe the process using the GUI method. The following steps should be performed in the Tivoli Enterprise Data Warehouse Control Center server. Chapter 6. Management reporting 131

152 Note: You need both the TEDW and the IBM Tivoli Monitoring products installation media. 1. Select Start -> Run. Type in D:\setup.exe and click OK to start the installation, where D is the CDROM directory. 2. When the InstallShield Wizard dialogue window for TEDW Installation appears, click Next. 3. The dialogue window for the type of installation appears. Select Application installation only and the directory name where the TEDW components are installed. We used C:\TWH. Click Next to continue. 4. The host name dialogue window appears. Verify that this is the correct host name for the TEDW Control Center server. Click Next. 5. The local system DB2 configuration dialogue window appears. The installation process asks for a valid DB2 user ID. Enter the valid DB2 user ID and password that were created during the DB2 installation on your local system. In our case, we used db2admin. Click Next. 6. The path to the installation media for the application packages dialogue window appears, as shown in Figure 6-7. You should provide the location of the IBM Tivoli Monitoring Generic ETL1 program. Change the TEDW CD in the CD-ROM drive with the IBM Tivoli Monitoring installation CD. Specify the path to the twh_app_install_list.cfg file (by default in the CD_drive:\tedw_apps\amx\ directory) on the IBM Tivoli Monitoring CD in the directory name field. Leave the Now option checked (prevents typing errors) to verify that the source directory is immediately accessible and that it contains the correct files. Click Next. 132 Introducing IBM Tivoli Monitoring for Web Infrastructure

153 Figure 6-7 Path to the installation media for the ITM Generic ETL1 program 7. The overview of selected features dialog window appears as shown in Figure 6-8. Click Install to start the installation. Figure 6-8 ITM Generic ETL1 program installation 8. Once the installation is finished the Installation summary window appears, as shown in Figure 6-9. If the installation was not successful, check the TWHApp.log file for any errors. This log file is located at the <TWH_inst_dir>\apps\AMX\, where <TWH_inst_dir> is the TEDW installation directory. Chapter 6. Management reporting 133

154 Figure 6-9 Installation summary window Post-installation steps There is a need to change some configuration settings shown below: Changes on the TWH_CDW database Creating an ODBC connection to the ITM_DB database Defining user authority to the Warehouse Sources and Targets Scheduling the ETL Changing the ETL status to Production Changes on the TWH_CDW database The applications control heap size on the TWH_CDW database needs to be set to at least 512, as follows: 1. Logon using DB2 administrator user ID to your TEDW Server machine, in our case db2admin, connect to the TWH_CDW database: db2 connect to TWH_CDW user db2admin using <db2pw> Where, <db2pw> is the database administrator password. 2. In order to determine the actual heap size issue, use: db2 get db cfg for TWH_CDW grep CTL_HEAP The output should be similar to this: Example 6-3 Current applications control heap size on the TWH_CDW database Max appl. control heap size (4KB) (APP_CTL_HEAP_SZ) = If the heap size is less that 512, perform: db2 update db cfg for TWH_CDW using APP_CTL_HEAP_SZ Introducing IBM Tivoli Monitoring for Web Infrastructure

155 The output should be similar to this: Example 6-4 Output from db2 update db cfg for TWH_CDW DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully. DB21026I For most configuration parameters, all applications must disconnect from this database before the changes become effective. 4. You should now restart DB2 by issuing the following series of commands: db2 disconnect THW_CDW db2 force application all db2 terminate db2stop db2admin stop db2admin start db2start Creating an ODBC connection to the ITM_DB database The TEDW Control Center server hosts all the ETL. This server needs to have access to the various databases that the SQL scripts deal with. In the case of IBM Tivoli Monitoring Generic ETL1, a connection to the ITM_DB database should be defined. On the TEDW Control Center server using a DB2 command line window, issue the following commands: db2 catalog tcpip node CAT_ODBC remote <TWH_SVR> server <DB2_PORT> db2 catalog database ITM_DB at node CAT_ODBC db2 catalog system odbc data source ITM_DB Where, <TWH_SVR> is the TEDW Server hostname, and <DB2_PORT> is the TCPIP port used by DB2 (default is 50000). Defining user authority to the Warehouse Sources and Targets You should inform the TEDW Control Center server of user access information for every source and target ETL process installed by the IBM Tivoli Monitoring Generic ETL1. Follow these steps: 1. Start the IBM DB2 Control Center utility by selecting Start -> Programs -> IBM DB2 -> Control Center. 2. On the IBM DB2 Control Center utility, start the IBM DB2 Data Warehouse Center utility by selecting Tools -> Data Warehouse Center. The Data Warehouse Center logon windows appears. 3. Log into the IBM DB2 Data Warehouse Center utility using the local DB2 administrator user ID. In our case, db2admin. 4. In the Data Warehouse Center window, expand the Warehouse Sources folder. As shown in Figure 6-10, there are two entries for the IBM Tivoli Chapter 6. Management reporting 135

156 Monitoring Generic ETL1 programs that need to be configured, as follows: AMX_ITM_RIM_Source AMX_TWH_CDW_Source Figure 6-10 IBM Tivoli Monitoring Generic ETL1 Sources You should edit the properties of each one of the above entries. In order to do that, right-click on the actual object and select Properties from the pop-up menu. Then select the Database tab. Fill in the database instance owner user ID information. For our environment the values are shown in Figure 6-11, using the AMX_ITM_RIM_Source as an example. Figure 6-11 AMX_ITM_RIM_Source user ID information 136 Introducing IBM Tivoli Monitoring for Web Infrastructure

157 5. For the IBM Tivoli Monitoring Generic ETL1 Target ETL, shown in Figure 6-12, expand the Warehouse Target folder, right-click the AMX_TWH_CDW_Target, select Properties and then select the Database tab. Fill in the user ID information. Figure 6-12 IBM Tivoli Monitoring Generic ETL1 Target The values used in the ITSO lab environment are shown in Figure Figure 6-13 AMX_TWH_CDW_Target user ID information Chapter 6. Management reporting 137

158 Scheduling the ETL There are two processes that need to be scheduled for the IBM Tivoli Monitoring Generic ETL1 to run. They are: AMX_c05_ETL1_Process AMX_c10_Rim_Prune_Process The following steps are similar for both processes and we will use AMX_c05_ETL1_Process to describe them. 1. On the TEDW Control Center server using Data Warehouse Center window expand Subject Areas. 2. Select AMX_IBM_TIVOLI_Monitoring_v5.1.1_Subject_Area -> Processes and right-click AMX_c05_ETL1_Process. 3. Choose Schedule, as shown in Figure Figure 6-14 Schedule AMX_c05_ETL1_Process Selecting Schedule will open up a dialog as shown in Figure Introducing IBM Tivoli Monitoring for Web Infrastructure

159 Figure 6-15 Schedule configuration for AMX_c05_ETL1_Process Changing the ETL status to Production Both the AMX_c05_ETL1_Process and AMX_c10_Rim_Prune_Process are composed by components that have Development status set as default. In order for them to run, their status needs to be changed from Development to Production. They are: AMX_c05_ETL1_Process AMX_c05_s010_Rim_Extract AMX_c05_s020_Parsing AMX_c05_s030_Exception AMX_c05_s040_Comp_Msmt AMX_c10_Rim_Prune_Process AMX_c10_s010_Rim_Prune The following step must be performed for all processes described above. Here we use AMX_c05_ETL1_Process to describe it. On the TEDW Control Center server using Data Warehouse Center window select the above processes and right-click on them. Choose Mode -> Production, as shown in Figure Chapter 6. Management reporting 139

160 Figure 6-16 Promoting scheduled processes to Production status Setting up Web Infrastructure Warehouse modules Here we describe the installation procedures of IBM Tivoli Monitoring for Web Infrastructure Warehouse modules, also known as IBM Tivoli Monitoring for Web Infrastructure ETLs. They are: IBM Tivoli Monitoring for Web Infrastructure: Apache HTTP Server Warehouse ETL. IBM Tivoli Monitoring for Web Infrastructure: iplanet Server Warehouse ETL. IBM Tivoli Monitoring for Web Infrastructure: Internet Information Server Warehouse ETL. IBM Tivoli Monitoring for WebSphere Application Server Warehouse ETL. All the IBM Tivoli Monitoring for Web Infrastructure ETLs provide a set of metadata to drive the ITM Generic ETL1 to retrieve data collected by the IBM Tivoli Monitoring resource models, as well as general-purpose reports. IBM Tivoli Monitoring for Web Infrastructure ETLs extracts data from the TWH_CDW database and loads it into the Web Infrastructure data marts. Therefore they are called as a target ETLs. Each warehouse module has a measurement code as shown in Table 6-1. Table 6-1 Measurement code Warehouse Module Name Apache HTTP Server iplanet Web server Measurement Code gwa gwp 140 Introducing IBM Tivoli Monitoring for Web Infrastructure

161 Warehouse Module Name Internet Information Server WebSphere Application Server Measurement Code gwi izy The installation can be done using the Tivoli Enterprise Data Warehouse CLI or the GUI installation program. Here we describe the process using the GUI method. The following steps should be performed in the Tivoli Enterprise Data Warehouse Control Center server. Note: You need both the TEDW and the IBM Tivoli Monitoring for Web Infrastructure products installation media. The installation is similar for all ETLs. 1. Select Start -> Run. Type in D:\setup.exe and click OK to start the installation, where D is the CDROM directory. 2. When the InstallShield Wizard dialog window for TEDW Installation appears, click Next. 3. The dialogue window for the type of installation appears. Select Application installation only and the directory name where the TEDW components are installed. We used C:\TWH. Click Next to continue. 4. The host name dialogue window appears. Verify that this is the correct host name for the TEDW Control Center server. Click Next. 5. The local system DB2 configuration dialog window appears. The installation process asks for a valid DB2 user ID. Enter the valid DB2 user ID and password that were created during the DB2 installation on your local system. In our case, we used db2admin. Click Next. 6. The path to the installation media for the application packages dialog window appears. You should provide the location of the Web Infrastructure ETL package. Change the TEDW CD in the CD-ROM drive with the IBM Tivoli Monitoring for Web Infrastructure installation CD. Specify the path to the twh_app_install_list.cfg file in the directory name field. By default the path is <CD_drive:>\tedw_apps\<Mesaurment_Code>, where: <CD_drive:> Is directory of the IBM Tivoli Monitoring for Web Infrastructure CD <Mesaurment_Code> Is the directory for the module you are installing. 7. Check the Now option (prevents typing errors) to verify that the source directory is immediately accessible and that it contains the correct files. Click Next. The Figure 6-17 shows the installation of IBM Tivoli Monitoring for Web Infrastructure: Apache HTTP Server ETL as an example. Chapter 6. Management reporting 141

162 Figure 6-17 Path to the installation media for the Apache ETL program 8. The overview of selected features dialog window appears as shown in Figure Click Install to start the installation. Figure 6-18 Apache ETL programs installation 9. Once the installation is finished the Installation summary window appears. Figure 6-19 on page 143 shows a successful installation. If the installation was not successful, check the TWHApp.log file for any errors. This log file is located at the <TWH_inst_dir>\apps\<Mesaurment_Code>. <TWH_inst_dir> is the TEDW installation directory and <Mesaurment_Code> are the directory names in Table Introducing IBM Tivoli Monitoring for Web Infrastructure

163 Tip: To reinstall a failed installation, you need to first un-install the module from TEDW, Figure 6-19 Installation Summary Window 10.After the pack installation conclusion, you must reboot the TEDW Control Center server. Post-installation steps In order to ensure that the IBM Tivoli Monitoring for Web Infrastructure Warehouse modules are functioning properly, a few changes must be applied to their configuration settings. The following steps should be performed for all installed IBM Tivoli Monitoring for Web Infrastructure ETLs: 1. Define user authority to the Warehouse Sources and Targets 2. Schedule the ETL 3. Change the ETL status to Production Defining user authority to the Warehouse Sources and Targets You should inform the TEDW Control Center server of user access information for every source and target ETL process installed by the IBM Tivoli Monitoring for Web Infrastructure ETL. Follow these steps: 1. Start the IBM DB2 Control Center utility by selecting Start -> Programs -> IBM DB2 -> Control Center. 2. On the IBM DB2 Control Center utility, start the IBM DB2 Data Warehouse Center utility by selecting Tools -> Data Warehouse Center. The Data Warehouse Center logon window appears. Chapter 6. Management reporting 143

164 3. Log into the IBM DB2 Data Warehouse Center utility using the local DB2 administrator user ID. In our case, db2admin. 4. In the Data Warehouse Center window, expand the Warehouse Sources folder. As shown in Figure 6-20, there is one entry for each of the IBM Tivoli Monitoring for Web Infrastructure ETL. You have to configure the warehouse source corresponding to your Web server. Table 6-2 Warehouse Source Modules Warehouse Module Name Apache HTTP Server iplanet Web server Internet Information Server WebSphere Application Server Warehouse Source GWA_TWH_CDW_Source GWP_TWH_CDW_Source GWI_TWH_CDW_Source IZY_TWH_CDW_Source Figure 6-20 IBM Tivoli Monitoring for Web Infrastructure ETL Sources Edit the properties of each entry in Table 6-2 corresponding to your module. In order to do this, right-click it and select Properties and then select the Database tab. Fill in the database instance owner user ID information. The values used in the ITSO lab environment are shown in Figure 6-21, using the GWA_TWH_CDW_Source as example. 144 Introducing IBM Tivoli Monitoring for Web Infrastructure

165 Figure 6-21 GWA_TWH_CDW_Source user ID information 5. Finally, configure the warehouse target ETL s. As shown in Figure 6-22, there is one entry for the IBM Tivoli Monitoring for Web Infrastructure for Apache, iplanet and IIS. There are two entries for the IBM Tivoli Monitoring for Web Infrastructure for WebSphere. The target ETL programs listed in Figure 6-3, which corresponds to your Web server, need to be configured, as follows: Table 6-3 Warehouse Target Modules Warehouse Module Name Apache HTTP Server iplanet Web server Internet Information Server WebSphere Application Server Warehouse Target GWA_TWH_MART_Target GWP_TWH_MART_Target GWI_TWH_MART_Target IZY_TWH_MART_Target IZY_TWH_MART_Target Chapter 6. Management reporting 145

166 Figure 6-22 IBM Tivoli Monitoring for Web Infrastructure ETL Targets Edit the properties of each entry in Table 6-3 corresponding to your module. In order to do that, right-click it and select Properties and then select the Database tab. Fill in the database instance owner user ID information. The values use in the ITSO lab environment are shown in Figure 6-23, using the GWA_TWH_MART_Target as example. Figure 6-23 GWA_TWH_MART_Target user ID information 146 Introducing IBM Tivoli Monitoring for Web Infrastructure

167 Scheduling the ETL The table below list the process that needs to be scheduled for the IBM Tivoli Monitoring for Web Infrastructure ETL s to run. You have to schedule the processes corresponding to the module you have installed. Table 6-4 Warehouse processes Warehouse Module Name Apache HTTP Server iplanet Web server Internet Information Server WebSphere Application Server Process GWA_m05_CleanDataMart_Process GWA_m10_ETL2_Process GWP_m05_CleanDataMart_Process GWP_m10_ETL2_Process GWI_m05_CleanDataMart_Process GWI_m10_ETL2_Process IZY_m05_Dimension_Process IZY_m10_Fact_Process The following steps are similar for all above processes and we use GWA_m05_CleanDataMart_Process to describe them. 1. On the TEDW Control Center server using Data Warehouse Center window expand Subject Areas. 2. Select GWA_IBM_Monitoring_for_Apache_HTTP_Server_v5.1.0 Subject_Area -> Processes and right-click GWA_m05_CleanDataMart_Process. Choose Schedule, as shown in Figure Chapter 6. Management reporting 147

168 Figure 6-24 Scheduling GWA_m05_CleanDataMart_Process This will open up a dialog as shown in Figure Figure 6-25 Schedule configuration for GWA_m05_CleanDataMart_Process 148 Introducing IBM Tivoli Monitoring for Web Infrastructure

169 Changing the ETL status to Production All IBM Tivoli Monitoring for Web Infrastructure processes are composed by components that have Development status set as default. In order for them to run, their status needs to be changed from Development to Production. Table 6-5 Warehouse processes and components Warehouse Module Name Apache HTTP Server iplanet Web Server Internet Information Server WebSphere Application Server Process GWA_m05_CleanDataMart_Pro cess GWA_m10_ETL2_Process GWP_m05_CleanDataMart_Pro cess GWP_m10_ETL2_Process GWI_m05_CleanDataMart_Proc ess GWI_m10_ETL2_Process IZY_m05_Dimension_Process IZY_m10_Fact_Process Component GWA_m05_s010_CleanDat amart GWA_m10_s010_LoadDat amart GWP_m05_s010_CleanDat amart GWP_m10_s010_LoadDat amart GWI_m05_s010_CleanDat amart GWI_m10_s010_BuildData Mart IZY_m05_s010_Dimension IZY_m10_s010_Fact IZY_m10_s020_AdminSrv_ Rollup IZY_m10_s030_ApplSrv_R ollup IZY_m10_s020_ApplComp _Rollup IZY_m10_s020_SubComp_ Rollup The following steps must be performed for all processes corresponding to your IBM Tivoli Monitoring for Web Infrastructure module. The Table 6-5 describes the complete list. Here we use GWA_m05_s010_CleanDataMart as an example to describe the process. Chapter 6. Management reporting 149

170 On the TEDW Control Center server using Data Warehouse Center window select the above processes and right-click on them. Choose Mode -> Production, as shown in Figure Figure 6-26 Promoting scheduled ETL processes to Production status Now all the processes are ready and scheduled to be run in production mode. When the data collection is done we can use the reports provided by IBM Tivoli Monitoring for Web Infrastructure to view the data. 6.3 ITM for Web Infrastructure reports In this section we discuss the various reports provided by IBM Tivoli Monitoring for Web Infrastructure modules, how to access these reports, how to create new reports, and working with data marts Working with reports All TEDW reports are accessed through the IBM Web Console. This console can be accessed by typing one of the URL s listed below into your Web browser. In the following, Computer_Name denotes the fully qualified name of a computer, where Web Services for the IBM Console is running. Tip: The text IBMConsole in the URL is case-sensitive; type it exactly as shown. 150 Introducing IBM Tivoli Monitoring for Web Infrastructure

171 If SSL is not enabled and the number for the HTTP server port on the computer where Web Services for the IBM Console is running is 80 (the default port number), type this address: If an alternate port is used, type this address, where <port_number> is the number for the HTTP server port on the computer where Web Services for the IBM Console is running: If SSL has been enabled on the computer where Web Services for the IBM Console is running and the SSL port number on that computer is 443 (default), type this address: If an alternate port is used, type this address, where <SSL_port_number> is the number for the SSL port on the computer where Web Services for the IBM Console is running and SSL is enabled: This would launch the IBM Web Console and you have to login using a valid TEDW userid and password. Use the Work with Reports task group in the portfolio to manage users, groups, and data marts for TEDW, or to run, create, and view TEDW reports. To configure users to work with reports you need to add at least one of the TEDW roles given below. Warehouse Security Administrator With this role, a user can create and manage groups and data marts. A user with this role controls access to data marts by assigning users to groups and by giving groups access to specific data marts. In effect, this role controls access to the TEDW data using user groups and data marts. Report roles control a user s ability to create and modify reports for the data marts his user groups can access. Assign only one of the following roles to each user: Advanced Report Author With this role, a user can create, modify, run, and delete public and their own personal reports, and save the output of reports, both public and personal. Report Author With this role, a user can run and save the output of public reports and create and modify their own personal reports. They can run public and personal reports, and create, modify, and delete personal reports. Chapter 6. Management reporting 151

172 Report Reader With this role, a user can run public reports and view the saved output of public reports. Figure 6-27 shows how to generate a report manually using the Report Interface. You can schedule a report to run automatically when the associated data mart is updated. This ensures that when you examine the output of the report, it displays the most recent data in the warehouse. To manually run a report, complete the following steps: a. From the portfolio of the IBM Console, select Work with Reports->Manage Reports and Report Output. b. In the Manage Reports and Report Output window, in the Reports view, right-click on a report icon, and select Run from the context menu. To schedule a report to run automatically when the associated data mart is updated, complete the following steps: a. From the portfolio of the IBM Console, select Work with Reports->Manage Reports and Report Output. b. In the Manage Reports and Report Output window, in the Reports view, right-click on a report icon, and select Properties from the context menu. c. Click the Schedule option and enable the Run of the report when the data mart is built. Figure 6-27 Running reports from IBM Console 152 Introducing IBM Tivoli Monitoring for Web Infrastructure

173 Table 6-6 describes the various predefined reports that are available when the IBM Tivoli Monitoring for Web Infrastructure Data Warehouse components have just been installed. The names for the reports are described at the time of writing this book. Please note the term IZY identifies reports that are related to WebSphere Application Server. The columns Report Type and Shared are discussed in detail in Create reports on page 160. Table 6-6 Report names and descriptions Name Description Type Shared Apache Health Check Error Report This report provides basic information on Apache Error metrics Health Check Public Apache Health Check Performance Report This report provides basic information on Apache Performance metrics Health Check Public Internet Information Server Performance Report This is a basic report for Internet Information Server Health Check Public iplanet Web server Performance Report This is a basic report for iplanet Web server Health Check Public IZY EJB Performance Health EJB performance, load and throughput aggregated at the application server Health Check Personal IZY EJB Resource Model Summary The minimum, maximum, average and total values, respectively, for all EJB measurements, grouped by operating system platform, host name, and application server. Summary Personal IZY EJBs with the Most Hits The top 25 EJBs with the highest weekly average total requests. Extreme Case Personal IZY JVM Runtime Resource Model Summary The minimum, maximum, average, and total values, respectively, for all JVM Runtime measurements, grouped by operating system platform, host name and application server. Summary Personal IZY Servlet Performance Health Servlet performance, load and throughput aggregated at the application server level. Health Check Personal Chapter 6. Management reporting 153

174 Name Description Type Shared IZY Servlet Session Resource Model Summary The minimum, maximum, average and total values, respectively, for all servlet session measurements, grouped by operating system platform, host name, and application server. Summary Personal IZY Servlets with the Highest Response Time The top 25 servlets with the highest weekly average total response time. Extreme Case Personal IZY Servlets with the Most Hits The top 25 servlets with the highest weekly average total requests. Extreme Case Personal IZY Transaction Manager Resource Model Summary The minimum, maximum, average, and total values, respectively for all transaction manager measurements, grouped by operating system platform, host name and application server. Summary Personal IZY Web Application Resource Model Summary The minimum, maximum, average and total values, respectively, for all the Web application measurements, grouped by operating system platform, host name and application server. Summary Personal Defining your own reports This section provides information about how to create your own reports. To facilitate customization, the data marts and star schemas provided by default, after successful installation of the relevant IBM Tivoli Monitoring for Web Infrastructure Warehouse modules, will be used. Every report is made from a data mart, and each data mart is made up of one or more star schema s. This section includes directions about how to modify an existing data mart and also how to create a new data mart using existing star schemas. Data marts Data mart contains a subset of the historical data from the central data warehouse to satisfy the analysis and reporting needs of a specific department, team, customer, or application. The system that hosts this DB2 database is called the data mart server. Although you can have many data marts, you can 154 Introducing IBM Tivoli Monitoring for Web Infrastructure

175 have only one data mart server. The data mart component requires IBM DB2 Universal Database Enterprise Edition V7, which you must install manually before installing the control server. To address a reporting need specific to your situation, you can either modify an existing data mart, or create new data marts that contain slightly different data. To modify or create a data mart, you must be familiar with database ETL processes and with the internal representation of a data mart as star schemas in the TEDW databases. For information about this, see Tivoli Enterprise Data Warehouse V1.1 Enabling an Application for Tivoli Enterprise Data Warehouse, GC Installation of the warehouse modules for Tivoli Monitoring for Web Infrastructure creates data marts whose structure is suitable for the Report Interface. Table 6-7 describes the various default data marts. Table 6-7 Default data marts Module Data Mart Description Apache iplanet IIS WebSphere GWA Sample Website Data Mart GWP Basic Data Mart GWI Basic Data Mart IZY Monitoring for WebSphere Application Server This data mart is used to report Apache Web site data This data mart includes some performance metrics provided by iplanet module This data mart includes performance metrics provided by Internet Information Server module IZY Monitoring for WebSphere Application Server Each data mart is made up of one or more star schemas. You can add, remove and change the properties of the star schemas in a data mart. As an example we are adding a schema to the GWA Sample Website Data Mart as shown in Figure From the portfolio of the IBM Console, select Work with Reports->Manage Data Marts. 2. In the Manage Data Marts window, click GWA Sample Website Data Mart. 3. In the Star Schemas view, click the context menu icon of a star schema and select Add. 4. In the Add Star Schemas to a Data Mart window go through the list of schemas and select the ones which you need, and click OK. Chapter 6. Management reporting 155

176 To create a new data mart use the following steps: 1. From the portfolio of the IBM Console, select Work with Reports->Manage Data Marts. 2. In the Manage Data Marts window, click on the context menu icon of any Data Mart or Root, and select Create. 3. Add all the details in Create Data Mart window and click OK. You have to now configure the user groups and star schemas. Figure 6-28 Manage Data Marts Star schemas The purpose of the star schemas is to transform raw business data into business information that can be easily reported and analyzed. The star schema consists of the following: One metric dimension table Metrics are the items about which you collect data. Sample metrics include the amount of RAM on a PC, the number of help desk calls made by a customer, the average CPU busy time for a server, and mean time to failure for a hardware device. A dimension is a single piece of descriptive information used to identify fact table records. One or many component dimension tables Component dimension tables contain component attributes (column name=component attribute). These attributes are displayed in the Report Interface so that users can filter on them. 156 Introducing IBM Tivoli Monitoring for Web Infrastructure

177 One fact table A single fact table contains measurement information. The columns in a fact table must include the foreign key columns to the component dimension tables, metric_id, meas_date (day/week/month), meas_hour (summarized timestamps on hourly boundaries), min_value, max_value, avg_value, total_value and sample_count. The Figure 6-8 describes the default star schemas available when the IBM Tivoli Monitoring for Web Infrastructure Data Warehouse is installed. For more information about how to create your own star schemas see Enabling an Application for Tivoli Enterprise Data Warehouse Version 1 Release 1, GC Table 6-8 Default Star Schemas Name GWA Daily Apache HTTP Server Star Schema GWA Daily Apache Website Star Schema GWP Daily iplanet Web server Star Schema GWI Daily Server Star Schema IZY Daily Administration Server Star Schema IZY Daily Application Server Component Star Schema IZY Daily Application Server Star Schema IZY Daily Application Server Subcomponent Schema Description This star schema is used to arrange Apache HTTP server related data extracted from the central data warehouse in a subject-oriented way for reporting purposes. The reporting rollup period is on a daily basis. This star schema is used to arrange Apache Web site related data extracted from the central data warehouse in a subject-oriented way for reporting purposes. The reporting rollup period is on a daily basis. This star schema is used to produce daily reports for data collected on iplanet Web servers. This star schema uses all measurements related to the component type IIS. Star schema with dimension tables associated with the daily fact table for the WebSphere administration server components. Star schema with dimension tables associated with the daily fact table for the WebSphere application server components, such as data sources, EJBs, JVMs, Web applications, thread pools, servlet sessions and transaction managers. Star schema with dimension tables associated with the daily fact table for the WebSphere application servers. Star schema with dimension tables associated with the daily fact table for the WebSphere application server subcomponents, such as connection pools and servlets. Chapter 6. Management reporting 157

178 Name IZY Hourly Administration Server Star Schema IZY Hourly Application Server Component Star Schema. IZY Hourly Application Server Star Schema IZY Hourly Application Server Subcomponent Schema IZY Monthly Administration Server Star Schema. IZY Monthly Application Server Component Star Schema IZY Monthly Application Server Star Schema IZY Monthly Application Server Subcomponent Schema. IZY Weekly Administration Server Star Schema IZY Weekly Application Server Component Star Schema IZY Weekly Application Server Star Schema Description Star schema with dimension tables associated with the hourly fact table for the WebSphere administration server components. Star schema with dimension tables associated with the hourly fact table for the WebSphere application server components, such as data sources, EJBs, JVMs, Web applications, thread pools, servlet sessions and transaction managers. Star schema with dimension tables associated with the hourly fact table for the WebSphere application servers. Star schema with dimension tables associated with the hourly fact table for the WebSphere application server subcomponents, such as connection pools and servlets. Star schema with dimension tables associated with the monthly fact table for the WebSphere administration server components. Star schema with dimension tables associated with the monthly fact table for the WebSphere application server components, such as data sources, EJBs, JVMs, Web applications, thread pools, servlet sessions and transaction managers. Star schema with dimension tables associated with the monthly fact table for the WebSphere application servers. Star schema with dimension tables associated with the monthly fact table for the WebSphere application server subcomponents, such as connection pools and servlets. Star schema with dimension tables associated with the weekly fact table for the WebSphere administration server components. Star schema with dimension tables associated with the weekly fact table for the WebSphere application server components, such as data sources, EJBs, JVMs, Web applications, thread pools, servlet sessions and transaction managers. Star schema with dimension tables associated with the weekly fact table for the WebSphere application servers. 158 Introducing IBM Tivoli Monitoring for Web Infrastructure

179 Name IZY Weekly Application Server Subcomponent Schema Description Star schema with dimension tables associated with the weekly fact table for the WebSphere application server subcomponents; such as servlets and connection pools. Time frame You can select predetermined values for the time frame of the report for modifying them. The predetermined values of Peak Hours and Weekdays, which are specified under Filtering in the Time page of report properties, can be modified. This is done by modifying the information in the control database on the control server. The default value for Peak Hours is 9:00 a.m. through 5:00 p.m., or 0900 to This value can be modified to reflect different peak hours if necessary. The default value for weekdays is Monday through Friday. This value can also be modified. The RPI.TimeFilters database table contains the following filters and default filter values as shown in Table 6-9. Table 6-9 Default time filter names and values TIME_FILTER_NAME TIME_FILTER_VALUES Peak Hours hour (meas_hour) in (9,10,11,12,13,14,15,16,17) Weekdays day of week (meas_date) between 2 and 6 To change the default filtering values displayed in the Report Interface, perform the following steps: 1. Connect to the control database (TWH_MD). 2. Use an SQL statement similar to the following to modify the values for Peak Hours or Weekdays in the RPI.TimeFilters table. The following example sets the Weekdays filter to represent Sunday through Thursday: Update RPI.TimeFilters set TIME_FILTER_VALUES = dayofweek(meas_date) between 1 and 5 where TIME_FILTER_NAME = Weekdays After doing this, when a user selects a Weekdays filter for a report in the Report Interface, the data returned is for Sunday through Thursday. Important: No error checking is done for the values inserted into the tables for Peak Hours and weekdays. Therefore, make sure that the information you insert into the tables is correct. Any Warehouse components that use the Report Interface to display reports must create data marts whose structure is suitable for the Report Interface. They Chapter 6. Management reporting 159

180 do this by providing an extract, transform, and load (ETL) process, called a data mart ETL, that creates the data mart and loads it with data from the central data warehouse. You can modify an existing data mart, or create new data marts that contain slightly different data, to address a reporting need specific to your situation. To modify or create a data mart, you must be familiar with database ETL processes and with the internal representation of a data mart as star schemas in the TEDW databases. Create reports TEDW provides the following types of reports when you want to create your own reports. They are: Summary Extreme case Health check Summary reports The summary report is typically used to display a many measurements versus many components relation. The result is a table where the rows show components or groups of components and the columns show typically the measurements. Additionally summary values for all components and all groups of components are shown. This kind of report can be used if, for example, you want to create an overview of the workload of servers or server groups. Here is how to create a new summary report: 1. Log in to your IBM Console as a user which has the required roles to create reports. 2. Expand Work with Reports and click Create Report. Tip: For users logged as superadmin, the portfolio and the context menus for reports contain multiple menus. For example, the context menus contain two Create a Report entries and three entries for Properties. Use the first entry in the list of duplicate entries which represents the highest level role authorized to perform that function. 3. Choose Summary as report type and select the data mart which contains the star schema with the data for your report. You will later choose the metrics for your reports from the star schemas of this data mart. In our example, we choose GWA Sample Website Data Mart for Apache. Select the data marts you need in your environment and click OK when ready. 4. First provide a meaningful name and description for the new report. 160 Introducing IBM Tivoli Monitoring for Web Infrastructure

181 5. Check the Public button when you want to create a public report which can be seen and used by other users. You see the public entry only when you have sufficient roles to create public reports. 6. Click on the Metrics tab. You will see the list of chosen metrics which is still empty. In a summary report there a typically many metrics. 7. Click Add to choose metrics from the star schema. You will see the list of all star schemas of the chosen data mart. Select one of them, and you will see all available metrics of this star schema you see that there is a minimum, maximum and average type of each metrics. These values are generated when the aggregation of the source data to hourly and daily data is done. Each aggregation level has its own star schema with its own fact table. In a fact table each measurement can have a minimum, maximum, average and total value. Which values are used depends on the application and can be defined in the D_METRIC table. When a value is used, a corresponding entry will appear in the available metrics list in the Reporting Interface. 8. Choose the metrics you need in your report and click Next. You will see the Specify Aggregations dialog. In this dialog you have to choose an aggregation type for each chosen metric. A summary report covers a certain time window (defined later in this section). All measurements are aggregated over that time window. The aggregation type is defined here. 9. Furthermore there might be an aggregation over many components if the report is made for component groups instead of single component. Let us first consider these settings. Remember, all measurements are records in the fact table with a link to a metric and a certain set of component attributes. In the Specify Attributes dialog you will be able to filter on component attributes and to group measurements to component groups. 10.With Filter By, you select only those records that match the values given in this file. In the resulting SQL statement, each chosen filter will result in a where clause. The Group By function works as follows: if you choose one attribute in the Group By field, then all records with the same value for this attribute are taken together and aggregated according to the type chosen in the previous dialog. The result is one aggregated measurement for each different value of the chosen attribute. Each entry in the Group By column will result in a group by clause in the SQL statement. The aggregation type will show up in the select part (line 1) where Total is translated to sum. Tip: When creating a summary report, ensure that the group by and order by selections match. Chapter 6. Management reporting 161

182 11.We choose no filter in our example, therefore all hosts in our database will appear in the report. We could filter, for example, on the domain name or IP sub net to constrain possible values for hostname. The possible choices of the filters are automatically populated from all values in the star schemas. If more than 27 distinct values exist you cannot filter on these attributes. 12.Click Finish to set up your metrics and click on the Time pad. 13.In this dialog you have to choose the time interval for the report. In summary reports all measurements of the chosen time interval will be aggregated for all groups. 14.In the Schedule pad you can select the Run the report when the data mart is built. A record is inserted into the RPI.SSUpdated table in the TWH_MD database tells the report execution engine when a star schema has been updated and the report execution engine runs all scheduled reports that have been created from that star schema. 15.When all settings are done, click OK to create the report. You should see a window displaying Report created successfully. 16.To see the report in the report list, click Refresh and expand root in the Reports panel, and click Reports. 17.Usually the reports are scheduled and run automatically when the data mart is built. However, you can run the report manually at any time by choosing Run from the reports pop-up menu. 18.You can make changes to the time window of the report. Click Next to continue. 19.You can now provide a name and a description for the particular report output produced by this run. Click Run to continue. You now see the summary report with the three metrics, which were chosen in the Add Metrics dialog in the columns. In the rows you find the hostnames which were chosen in the Group By entry in the Specify Attributes dialog. All hosts of our example data mart are displayed as no filter was chosen. In the lowest row you find a summary value for all hosts. If more then one Group By attributes are chosen, then there will be summary values for all component groups. 20.You can now save this report output. You will find it in the folder Report Output. Extreme case reports The extreme case report is a one measurement versus many components report. With this type of report you can find the components or component groups with the highest or lowest values of a certain metric. The result will be a 162 Introducing IBM Tivoli Monitoring for Web Infrastructure

183 graph with the worst or best components in the x-axis and the corresponding metric values in the y-axis. 1. Open your IBM Console, expand Work with Reports and click Create Report. 2. Choose Extreme Case from the type selection and proceed analogous to the previous section. The first difference to the summary report is in the Add Metrics dialog. In an extreme case report you can choose one metric only, for example the metric with the extreme value. There is one additional field compared to the summary report below the metric list. Here you can change the order direction. If you choose ascending order, the graph will start with the lowest value of the metrics. Conversely, you can use descending order to find the largest values. As you already chose the order of the graph in this dialog, the Order By choice will be missing in the Specify Attributes dialog. 3. We chose the hostname as the Group by entry and the interesting subdomain in the Filter by entry. 4. The procedure to finish and run this report is again equal to the summary report example. Health reports The health report is typically used to display many measurements against many components versus time relation. The result is a graph where the x-axis shows the time and the y-axis shows typically the measurements. This kind of report is used to show the time-development of a metric. This allows you to recognize a trend and to predict possible health problems of a component in the future. 1. To create a new health report open your IBM Console, expand Work with Reports and click Create Report. 2. Choose Health Report from the type selection and proceed analogous to Summary reports. Tip: For the health report, choose your time window according to the aggregation level of your data. If there are too many data points on the x-axis the report becomes unreadable. 3. Note that you can choose only five metrics at maximum for a health report. The first difference to the creation of a summary report appears in the Specify Attributes dialog. Health reports are always graphs of the type measurements versus time. For this reason no Group By or Order By is to be selected, because it is always grouped by time and ascending ordered by time. If no filter is selected the measurement is aggregated (minimum, maximum, average or sum according to the choice in the Specify Aggregations dialog) over all components. There can be many metrics displayed in one graph, but Chapter 6. Management reporting 163

184 they all apply to the same component or group of components, therefore it is not possible to compare different components in one graph. If there are more than 27 different values for an attribute, no choices can be made for this particular attribute in the Specify Attributes dialog. 164 Introducing IBM Tivoli Monitoring for Web Infrastructure

185 A Appendix A. Resource models context parameters This appendix contains lists of the context parameters that the Web server objects pass to the resource models when a profile is distributed. It is vital to remember, that the values for the parameters are collected during the discovery phase and every time a refresh action is performed on a Web server managed object. These context parameters may be used to customize existing resource models or develop new ones. When developing resource models and scripts used in the Tivoli environment, for example, to automate operations, the values of the context parameters may be accessed through specific method calls or by using the low-level Tivoli idlattr command. To get or set the value of a context parameter from a script running on the TMR server or a managed node, the context parameters may be accessed through the idlattr command, as demonstrated in Example 4-1 and Example 4-2 on page 90. To get the value of a context parameter from a decision tree script, use the Svc.GetContextProperty(<parameter name>) method. In order to check if it exists or not, use the Svc.GetContextProperty(<parameter name>) method as shown in Example A-1. Copyright IBM Corp All rights reserved. 165

186 Example: A-1 Using the GetContextProperty method Below there is a code snippet from the iplanetvirtualserverperformance Resource Model. isadmin = Svc.GetContextProperty("WebServerIsAdmin"); if (isadmin == "true") { retcode = 802; Svc.Trace(0, "iplanet_server_availability ---> Init: The resource model cannot run on an Administration server."); }... return (retcode); Apache HTTP server context parameters Table A-1 provides the context parameters used by the Apache resource models. Table A-1 Apache context variables Property Type Context Variable Name Source Web server type String WEB_SERVER_ TYPE The discovery task Web server Sub-Type (IBM/Standard Apache) String WEB_SERVER_ SUBTYPE The discovery task Product Version String WEB_SERVER_ VERSION 1.3 IBM HTTP Server Administrator String WEB_SERVER_ IS_ADMIN User Installation Path String WEB_SERVER_ INSTALLATION Apache configuration File ServerRoot directive Fully qualified configuration file (e.g. /usr/httpserver/conf/ httpd.conf) String WEB_SERVER_ CONFIG_PATH NAME User App Proxy Label String WEB_SERVER_ APP_PROXY Automatically generated prior to creation Pid File Path String WEB_SERVER_ PID_FILE_PATH Apache configuration file PidFile directive 166 Introducing IBM Tivoli Monitoring for Web Infrastructure

187 Property Type Context Variable Name Source Web Sites. Comma separated list of Web sites (e.g. www-3.ibm.com) String WEB_SERVER_ SITE_NAMES Apache configuration file VirtualHosts Web Ports. Comma separated list of ports supported by each Web site (e.g. 80, 8080). String WEB_SERVER_ SITE_NAMES Apache Configuration file Listen and Port directives Secure socket layer enabled String WEB_SERVER_ SITE_IS_SSL Apache Configuration file Application Proxy interface String WEB_SERVER_ APPLICATION_ CLASS default value, ApacheWebServer Hostname String WEB_SERVER_ ENDPOINT_HO STNAME - IIS context parameters Table A-2 provides a list of the context parameters used by the IIS resource models. Table A-2 IIS context variables Property Type Context Variable Source Web server Type String WEB_SERVER_ TYPE The discovery task Product Version String WEB_SERVER_ VERSION The discovery task Application Proxy (object) Label String WEB_SERVER_ APP_PROXY User Web Sites Names. Comma separated list of Web site names String WebSiteNames IIS Metabase Appendix A. Resource models context parameters 167

188 Property Type Context Variable Source Web Sites addresses. Comma separated list of Web sites addresses String WebSiteAddress es IIS Metabase Web Ports. Comma separated list of ports supported by each Web site String WebSitePorts IIS Metabase Secure socket layer enabled String WebSiteIsSSL IIS Metabase Application Proxy interface String WEB_SERVER_ APPLICATION_ CLASS default value, IISWebServer Hostname String WEB_SERVER_ ENDPOINT_HO STNAME - iplanet context parameters Table A-3 provides a list of the context parameters used by the iplanet resource models. Table A-3 iplanet Context Variables Property Type Context Variable Source WebServerVersion String WEB_SERVER_ VERSION MIB Application Proxy (object) Label String WEB_SERVER_ APP_PROXY Automatically generated prior to creation Server Root String ServerRoot User Snmp port String SnmpPort User Snmp community String SnmpCommunity User Web server instance index String WebInstance MIB Virtual Server names String WebSiteNames Server.xml Virtual server ports String WebSitePorts Server.xml 168 Introducing IBM Tivoli Monitoring for Web Infrastructure

189 Property Type Context Variable Source Virtual server addresses String WebSiteAddress es Server.xml Virtual server Secure Socket Layer enablement String WebSiteSecure Server.xml Virtual server index String WebSiteIds Server.xml Administrator Web server String WebServerIsAd min - Virtual Class String VirtualClass - Web server Name String WebServerName - Application Proxy interface String WEB_SERVER_ APPLICATION_ CLASS Default value, IPLanetWebServer Hostname String WEB_SERVER_ ENDPOINT_HO STNAME - WebSphere Application Server context parameters Table A-4 provides a list the context parameters used by the WebSphere resource models. Table A-4 iwebsphere Context Variables Property Type Context Variable WebSphere Server Operating System Type String IZY_OSTYPE WebSphere Server Node Name String IZY_NODENAME WebSphere Administration Server Object ID String IZY_ADMINSERVER_OID WebSphere Application Server Name String IZY_APPSERVERNAME WebSphere Version String IZY_WASVERSION WebSphere Hostname String IZY_HOSTNAME WebSphere Fully qualified Hostname String IZY_FULLHOSTNAME Type of Endpoint Class String ENDPOINT_CLASS Appendix A. Resource models context parameters 169

190 170 Introducing IBM Tivoli Monitoring for Web Infrastructure

191 B Appendix B. Patterns for e-business The IBM Patterns for e-business are a collective set of proven architectures that have been compiled from more than 20,000 successful Internet-based engagements. This repository of assets can be used by companies to facilitate the development of Web-based applications. They help an organization understand and analyze complex business problems and break them down into smaller, more manageable functions that can then be implemented using low-level design patterns. Copyright IBM Corp All rights reserved. 171

192 Introduction to Patterns for e-business As companies compete in the e-business marketplace, they find that they must re-evaluate their business processes and applications so that their technology is not limited by time, space, organizational boundaries, or territorial borders. They must consider the time it takes to implement the solution, as well as the resources (people, money, and time) they have at their disposal to successfully execute the solution. These challenges, coupled with the integration issues of existing legacy systems and the pressure to deliver consistent high-quality service, present a significant undertaking when developing an e-business solution. In an effort to alleviate the tasks involved in defining an e-business solution, IBM has built a repository of patterns to simplify the effort. In simple terms, a pattern can be defined as a model or plan used as a guide in making things. As such, patterns serve to facilitate the development and production of things. Patterns codify the repeatable experience and knowledge of people who have performed similar tasks before. Patterns not only document solutions to common problems, but also point out pitfalls that should be avoided. IBM Patterns for e-business consists of documented architectural best practices. They define a comprehensive framework of guidelines and techniques that were actually used in creating architectures for customer engagements. The Patterns for e-business bridge the business and IT gap by defining architectural patterns at various levels from Business patterns to Application patterns to Runtime patterns, enabling easy navigation from one level to the next. Each of the patterns (Business, Integration, Application, and Runtime) help companies understand the true scope of their development project and provide the necessary tools to facilitate the application development process, thereby, allowing companies to shorten time to market, reduce risk, and more importantly, realize a more significant return on investment. The core types of Patterns for e-business are as follows: Business Patterns Integration Patterns Composite Patterns Application Patterns Runtime Patterns and matching product mappings When a company takes advantage of these documented assets, they are able to reduce the time and risk involved in completing a project. For example, a line-of-business (LOB) executive who understands the business aspects and requirements of a solution can use Business patterns to develop a high-level structure for a solution. Business patterns represent common business problems. A LOB executive can match their requirements (IT and business 172 Introducing IBM Tivoli Monitoring for Web Infrastructure

193 drivers) to Business patterns that have already been documented. The patterns provide tangible solutions to the most frequently encountered business challenges by identifying common interactions among users, business, and data. Senior technical executives can use Application patterns to make critical decisions related to the structure and architecture of the proposed solution. Application patterns help refine Business patterns so that they can be implemented as computer-based solutions. Technical executives can use these patterns to identify and describe the high-level logical components that are needed to implement the key functions identified in a Business pattern. Each Application pattern would describe the structure (tiers of the application), placement of the data, and the integration (loosely or tightly coupled) of the systems involved. Finally, solution architects and systems designers can develop a technical architecture by using Runtime patterns to realize the Application patterns. Runtime patterns describe the logical architecture that is required to implement an Application pattern. Solution architects can match Runtime patterns to existing environment and business needs. The Runtime pattern they implement establishes the components needed to support the chosen Application pattern. It defines the logical middleware nodes, their roles, and the interfaces among these nodes in order to meet business requirements. The Runtime pattern documents what must be in place to complete the application, but does not specify product brands. Determination of actual products is made in the product mapping phase of the patterns. In summary, Patterns for e-business capture e-business approaches that have been tested and proven. By making these approaches available and classifying them into useful categories, LOB executives, planners, architects, and developers can further refine them into useful, tangible guidelines. The patterns and their associated guidelines allow the individual to start with a problem and a vision, find a conceptual pattern that fits this vision, define the necessary functional pieces that the application will need to succeed, and then actually build the application. Furthermore, the Patterns for e-business provide common terminology from a project s onset and ensures that the application supports business objectives, significantly reducing cost and risk. The Patterns for e-business layered asset model The Patterns for e-business approach enables architects to implement successful e-business solutions through the re-use of components and solution elements from proven, successful experiences. The Patterns approach is based on a set of layered assets that can be exploited by any existing development Appendix B. Patterns for e-business 173

194 methodology. These layered assets are structured in a way that each level of detail builds on the last. These assets include: Business patterns that identify the interaction between users, businesses, and data. Integration patterns that tie multiple Business patterns together when a solution cannot be provided based on a single Business pattern. Composite patterns that represent commonly occurring combinations of Business patterns and Integration patterns. Application patterns that provide a conceptual layout describing how the application components and data within a Business pattern or Integration pattern interact. Runtime patterns that define the logical middleware structure supporting an Application pattern. Runtime patterns depict the major middleware nodes, their roles, and the interfaces between these nodes. Product mappings that identify proven and tested software implementations for each Runtime pattern. Best-practice guidelines for design, development, deployment, and management of e-business applications. These assets and their relation to each other are shown in Figure B-1. Customer requirements Business patterns Composite patterns Integration patterns Any methodology Application patterns Runtime patterns Product mappings Best-Practice Guidelines Application Design Systems Management Performance Application Development Technology Choices Figure B-1 Patterns layered asset model 174 Introducing IBM Tivoli Monitoring for Web Infrastructure

195 Patterns for e-business Web site The Patterns Web site provides an easy way of navigating top down through the layered Patterns assets in order to determine the preferred reusable assets for an engagement. For easy reference to Patterns for e-business, refer to the Patterns for e-business Web site at: How to use the Patterns for e-business As described in the previous section, the Patterns for e-business are structured in a way that each level of detail builds on the last. At the highest level are Business patterns that describe the entities involved in the e-business solution. A Business pattern describes the relationship between the users, the business organization or applications, and the data to be accessed. Composite patterns appear in the hierarchy shown in Figure B-1 above the Business patterns. However, Composite patterns are made up of a number of individual Business patterns and at least one Integration pattern. In this section, we discuss how to use the layered structure of the Patterns for e-business assets. There are four primary Business patterns as shown in Table B-1. Table B-1 Business patterns Business patterns Description Examples Self-Service (User-to-Business) Information Aggregation (User-to-Data) Collaboration (User-to-User) Extended Enterprise (Business-to-Business) Applications where users interact with a business via the Internet Applications where users can extract useful information from large volumes of data, text, images, etc. Applications where the Internet supports collaborative work between users Applications that link two or more business processes across separate enterprises Simple Web site applications Business intelligence, knowledge management, Web crawlers , community, chat, video conferencing, etc. EDI, supply chain management, etc. Appendix B. Patterns for e-business 175

196 It would be very convenient if all problems fitted nicely into the four Business patterns above, but reality says that things will often be more complicated. The patterns assume that all problems, when broken down into their most basic components, will fit more than one of these patterns. When a problem describes multiple objectives that fit into multiple Business patterns, the Patterns for e-business provide the solution in the form of Integration patterns. Integration patterns allow us to tie together multiple Business patterns to solve a problem. The Integration patterns are shown in Table B-2. Table B-2 Integration patterns Integration patterns Description Examples Access Integration Application Integration Integration of a number of services through a common entry point Integration of multiple applications and data sources without the user directly invoking them Portals Message brokers, Workflow managers These Business and Integration patterns can be combined to implement installation-specific business solutions. We call this a Custom design. We can represent the use of a Custom design to address a business problem through an iconic representation, as shown in Figure B-2. Acess Integration Self-Service Collaboration Information Aggregation Extended Enterprise Application Integration Figure B-2 Pattern representation of a Custom design If any of the Business or Integration patterns are not used in a Custom design, we can show that with lighter blocks. For example, Figure B-3 shows a Custom design that does not have a mandatory Collaboration business pattern or an Extended Enterprise business pattern for a business problem. 176 Introducing IBM Tivoli Monitoring for Web Infrastructure

197 Acess Integration Self-Service Collaboration (optional) Information Aggregation Extended Enterprise (optional) Application Integration Figure B-3 Custom design A Custom design may also be a Composite pattern if it recurs many times across domains with similar business problems. For example, the iconic view of a Custom design in Figure B-3 can also describe a Sell-Side Hub composite pattern. Several common uses of Business and Integration patterns have been identified and formalized into Composite patterns. The identified Composite patterns are shown in Table B-3. Table B-3 Composite patterns Composite patterns Electronic Commerce Portal Account Access Description User-to-Online-Buying Typically designed to aggregate multiple information sources and applications to provide uniform, seamless, and personalized access for its users Provide customers with around-the-clock account access to their account information Examples Enterprise intranet portal providing self-service functions, such as payroll, benefits, and travel expenses Collaboration providers who provide services such as or instant messaging Online brokerage trading apps Telephone company account manager functions Bank, credit card, and insurance company online apps Appendix B. Patterns for e-business 177

198 Composite patterns Trading Exchange Sell-Side Hub (Supplier) Buy-Side Hub (Purchaser) Description Allows buyers and sellers to trade goods and services on a public site The seller owns the e-marketplace and uses it as a vehicle to sell goods and services on the Web The buyer of the goods owns the e-marketplace and uses it as a vehicle to leverage the buying or procurement budget in soliciting the best deals for goods and services from prospective sellers across the Web Examples Buyer's side - interaction between buyer's procurement system and commerce functions of e-marketplace Seller's side - interaction between the procurement functions of the e-marketplace and its suppliers (car purchase) (WorldWide Retail Exchange) The makeup of these patterns is variable in that there will be basic patterns present for each type, but the Composite can easily be extended to meet additional criteria. For more information about Composite patterns, refer to Patterns for e-business: A Strategy for Reuse by Jonathan Adams, et al., ISBN Selecting Patterns and product mapping After the appropriate Business pattern is identified, the next step is to define the high-level logical components that make up the solution and how these components interact. This is known as the Application pattern. A Business pattern will usually have multiple Application patterns identified that describe the possible logical components and their interactions. For example, an Application pattern may have logical components that describe a presentation tier for interacting with users, a Web application tier, and a back-end application tier. The Application pattern requires an underpinning of middleware that is expressed as one or more Runtime patterns. Runtime patterns define functional nodes that represent middleware functions that must be performed. After a Runtime pattern has been identified, the next logical step is to determine the actual product and platform to use for each node. Patterns for e-business 178 Introducing IBM Tivoli Monitoring for Web Infrastructure

199 have product mappings that correlate to the Runtime patterns, describing actual products that have been used to build an e-business solution for this situation. Finally, guidelines assist you in creating the application using best practices that have been identified through experience. For more information about determining how to select each of the layered assets, refer to the Patterns for e-business Web site at: Appendix B. Patterns for e-business 179

200 180 Introducing IBM Tivoli Monitoring for Web Infrastructure

201 C Appendix C. Additional material This redbook refers to additional material that can be downloaded from the Internet as described below. Locating the Web material The Web material associated with this redbook is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to: ftp:// Alternatively, you can go to the IBM Redbooks Web site at: Select the Additional materials and open the directory that corresponds with the redbook form number, SG Using the Web material The additional Web material that accompanies this redbook includes the following files: File name SG zip Description Automation resource model and related files Copyright IBM Corp All rights reserved. 181

202 System requirements for downloading the Web material The following system configuration is recommended: Hard disk space: 1 MB Operating System: Windows or UNIX Processor: any Memory: any How to use the Web material Create a subdirectory (folder) on your workstation, and unzip the contents of the Web material zip file into this folder. 182 Introducing IBM Tivoli Monitoring for Web Infrastructure

203 Abbreviations and acronyms BDT CDW CIM CIMOM CLI CMW DMTF DMZ DNS GUI HTTP IBM IIS ILT IT ITIL ITM ITSO Bulk Data Transfer Central Data Warehouse Common Information Model CIM Object Management Command Line Interface Common Warehouse Metadata Distributed Management Task Force Demilitarized Zone Domain Name Server Graphical User Interface Hypertext Transfer Protocol International Business Machines Corporation Microsoft Internet Information Server Resource Interface Instrumentation Library Type Information Technology Information Technology Infrastructure Library IBM Tivoli Monitoring International Technical Support Organization RDBMS RI RIM SIS SNMP SSL TBSM TEC TEDW TMF TMR TSL URL VB WAS WEBM WMI Relational Database Management System Reporting Interface RDBMS Interface Module Software Installation Services Simple Network Management Protocol Secure Socket Layer Tivoli Business Systems Manager Tivoli Enterprise Console Tivoli Enterprise Data Warehouse Tivoli Management Framework Tivoli Management Region Touchpoint Service Layer Universal Resource Locator Visual Basic WebSphere Application Server Web-based Enterprise Management Windows Management Instrumentation JRE Java Runtime Environment JVMPI Java Virtual Machine Profiler Interface MOF Managed Object Format NIC Network Interface Card OLAP Online Analytical Processing PAC Proactive Analysis Component Copyright IBM Corp All rights reserved. 183

204 184 Introducing IBM Tivoli Monitoring for Web Infrastructure

205 Related publications The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook. IBM Redbooks Other resources For information on ordering these publications, see How to get IBM Redbooks on page 187. IBM Tivoli Monitoring Version 5.1: Advanced Resource Monitoring, SG Tivoli Enterprise Management Across Firewalls, SG Early Experiences with Tivoli Enterprise Console 3.7, SG Tivoli Business Systems Manager: A Complete End-to-End Management Solution, SG Introduction to Tivoli Enterprise Data Warehouse, SG Patterns for e-business: User-to-Business Patterns for Topology 1 and 2 using WebSphere Advanced Edition, SG Patterns for the Edge of Network, SG These publications are also relevant as further information sources: IBM Tivoli Monitoring for Web Infrastructure Installation and Setup Guide, GC IBM Tivoli Monitoring for Web Infrastructure Reference Guide, GC IBM Tivoli Monitoring for Web Infrastructure Apache HTTP Server User s Guide, SH IBM Tivoli Monitoring for Web Infrastructure Internet Information Server User s Guide, SH IBM Tivoli Monitoring for Web Infrastructure iplanet Server User s Guide, SH IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server User s Guide, SC Copyright IBM Corp All rights reserved. 185

206 IBM Tivoli Monitoring User s Guide, SH IBM Tivoli Monitoring Workbench 5.1 User s Guide, SH Tivoli Enterprise Data Warehouse V1.1 Enabling an Application for Tivoli Enterprise Data Warehouse, GC Tivoli Management Framework Users Guide, GC Tivoli Management Framework Reference Manual, SC Tivoli Enterprise Console Reference Manual, GC Patterns for e-business by Jonathan Adams, et. al. IBM Press, October ISBN: Referenced Web sites These Web sites are also relevant as further information sources: Tivoli Technical Product Documents IBM WebSphere Infocenter iplanet Web server, Enterprise Edition Administrator's Guide Common Information Model (CIM) Standards Apache Documentation Object Management Group IBM DB2 UDB v7 Fixpack download site: t.d2w/report Tivoli Fixpack download stie: JRE for AIX from IBM developerworks: Introducing IBM Tivoli Monitoring for Web Infrastructure

207 JRE for Windows from the IBM WebSphere technology preview: Patterns for e-business How to get IBM Redbooks You can order hardcopy Redbooks, as well as view, download, or search for Redbooks at the following Web site: ibm.com/redbooks You can also download additional materials (code samples or diskette/cd-rom images) from that site. IBM Redbooks collections Redbooks are also available on CD-ROMs. Click the CD-ROMs button on the Redbooks Web site for information about all the CD-ROMs offered, as well as updates and formats. Related publications 187

208 188 Introducing IBM Tivoli Monitoring for Web Infrastructure

209 Index A access control 151 TEDW 151 accesslog Apache 37 actions corrective 61 Adapter TEC 65 Administration Server WebSphere 37 administration server WebSphere start 55 stop 55 administration server status WebSphere 55 administrator role 34 Advanced Report Author 151 agent listener aggreation component 161 time window 161 aggregated log data 85 aggregated measurement 161 aggregation data 120 aggregation level 161 aggregation type 161 analysis 122 business impact 57 OLAP 123 Apache accesslog 37 configuring 36 managed application object 40 ServerName 36 start 54 stop 54 virtual host 37 application patterns 178 application server WebSphere list 55 start 56 stop 56 application server status WebSphere 56 applications source 122 Availability Management 9 B back-end application tier 178 Bad_Interpreter error 52 baroc file 60 61, 63, 117 Web servers 62 WebSphere 62 BDT 30 See Bulk Data Transfer BI See Business Intelligence Brio Technology 120 business impact analysis 57 Business Intelligence 120 Business Intelligence reporting 123 Business Objects 120 C Capacity Management 9 CDW See central data warehouse Central Data Warehouse 122 Central Data Warehouse ETL 122 change RIM object password 127 Change Management 10 CIM 97, 114 CIM model 80 class event 61 Cognos 120 collect data 126 collect performance data Copyright IBM Corp All rights reserved. 189

210 WebSphere 38 common dimensions 120 Common Warehouse Metadata 120 community name 37 component dimension table 156 component, aggreation 161 component, star schema 156 components 80 service 7 configuration Web Health Console 58 Configuration Management 9 configure WebSphere event server 55 WebSphere TEC adapter 55 configuring Apache 36 data collection 129 connection database 135 context parameters 97, 165 Contingency Planning 9 control heap size 134 corrective actions 61 correlating data 120 correlation 120 event 57 Cost Management 8 creating RIM object 127 summary report 160 creation data mart database 128 Crystal Decisions 120 custom installation 31 custom installation plan 31 CWM See Common Warehouse Metadata cycle monitoring 82 cycle time 80, 82 resource model 58 D D_METRIC table 161 data correlating 120 extract 122 historical 60, 120, , 154 management 122 measurement 121 data aggregation 120 data analysis 123 data collection 124 configuring 129 data gathering 125 data logging TEDW 130 data mart 121, 123, 155, 161 creation format 123 managing 151 modification 155 structure 155 Web Infrastructure 140 data mart database creation 128 data mart ETL , 160 data mart server 154 data mining 123 data source 122 data target 122 data warehouse 122 database connection 135 database instance 146 datamart server 154 decision tree 80, 97 default star schema 157 development status 139, 149 dimension, star schema 156 dimensions common 120 discover resources 71 WebSphere 56 display WebSphere TEC adapter configuration 55 distribution profile 50 DMEndpointUninstall 117 DMLinkJre 35 DMZ See Demilitarized Zone DNS See Domain Name Server domain name Introducing IBM Tivoli Monitoring for Web Infrastructure

211 dynamic data tables 124 E endpoint 36, 58 health 58 state 58 status 58 endpoint database 124 Endpoint Health Web Health Console Web Health Console Endpoint Health 60 endpoint level 28 end-to-end view 120 ETL Central Data Warehouse 122 data mart , 160 process 135 processes 149 scheduling 138 source 122, 143 target 122, 124, 140, 143, 145 ETL process 155, 160 ETL processes 123 ETL programs 122 event correlation 57 event class 61 event type 60 events 60, 65 TBSM 81 TEC 81 extract data 122 extreme case report 162 extreme value, metric 163 F fact table 157, 161 file baroc 61 rule set 63 files mof 80 Filter By 161 filter, report 162 firewall ports 30 format data mart 123 Framework Version 3.7B 183 G gateway 116 gathering data 125 gemeeconfig 68 GEMLookupCID 68 Group By 161 groups 151 H health endpoint 58 health report 163 heap size control 134 Help Desk 9 historical data 60, 120, , 154 holes 83 host name 120 I IBM Console 160 IBM Web Console IBMConsole 150 ihstttec 67 IIS managed application object 43 See Internet Information Server start 54 start site 54 ILT 115, 118 indication resource model 58, 82 installation custom 31 Web Health Console 58 installation parameters 31 installation wizard 31 instance owner , 136, 144 interactive reporting 123 IP address 120 iplanet managed application object 42 start 54 start site 54 stop 54 Index 191

212 stop site 54 virtual servers 37 ISS stop site 54 ITM_DB 135 itm_db 128 IZY 153 J jar files 115 Java monitors 115 Java Runtime Environment 29, 35 java scripts 115 Java Virtual Machine Profiler Interface 38 JRE 35 path 35 See Java Runtime Environment JVMPI See Java Virtual Machine Profiler Interface L layered assets 179 level endpoint 28 software 28 LOB resources 65 local IBM Tivoli Monitoring database 124 log data aggregated 85 RAW 85 TEDW 85 log file log file analysis 118 log file format 37 W3C 37 logging resource model 85 logging data 124 login Web Health Console Web Health Console login 59 M M12JavaProvider 115 managed application object 26, 39 Apache 40 IIS 43 iplanet 42 WebSphere 45 WebSphere Application Server 47 managed application objects WebSphere Administration Server 45 managed node proxy 26 managed object 26 managed resource 39 management data 122 MDist 28 MDist2 51 measurement aggregated 161 measurement data 121 measurement, star schema 157 metadata 140 metadata interchange 120 metric extreme value 163 metric dimension table 156 metric, report 162 metric, star schema 156 metrics, report 161 middle layer database 124 modules warehouse 122 mof files 80, 97, 115, 118 monitoring 6 real time 60 monitoring cycle 82 N name resolution 30 network settings 30 notice 83 O object managed 26 managed application 26, 39 name 27 type 27 Web server 27 Object Management Group Introducing IBM Tivoli Monitoring for Web Infrastructure

213 occurrence 83 resource model 58 OLAP analysis 123 operational task 67 output report 162 P parameters context 165 installation 31 resource model 84 path JRE 35 Patterns for e-business 171 Peak Hours 159 permissions 30 personal report 151 plan custom installation 31 planner tool 31 policy region 34, 39 ports firewall 30 Preferences Web Health Console Web Health Console Preferences 59 presentation tier 178 Problem Management 10 process ETL 135, 155, 160 processes ETL 123, 149 product mappings 179 production status 139, 149 status production 139 profile 49 profile distribution 50 profile manager 50 profile properties 81 properties profile 81 resource model 81 provider 115, 118 proxy managed node 26 public report 151, 161 R rapid deployment 58 RAW log data 85 raw data 120 RDBMS 121 RDBMS administrator 128 real time monitoring 60 Redbooks Web site 187 Contact us xvii relay 30 repeaters 51 report create 151 extreme case 162 filetr 162 generating 152 health 163 metric 162 metrics 161 name 160 Peak Hours 159 personal 151 public 151, 161 scheduling 152, 162 shared 153 summary 160 time frame 159 time interval 162 type 153 viewing 152 Weekdays 159 Report Author 151 Report Interface , 152, 159 report output 162 Report Reader 152 reporting Business Intelligence 123 interactive 123 REPORTS 150 reports 160 predefined 153 Resource Analyzer WebSphere 38 resource model 50, 60, 80, 97, 115, 124 components 80 Index 193

214 cycle time 58 indication 58, 82 logging 85 occurance 58 parameters 84 threshold 58 resource model properties 81 resource models 29, 79, 140 resources discover 71 LOB 65 RI See Report Interface RIM configuration 127 RIM object 127 creation 127 password change 127 testing 128 role 30 administrator 34 Advanced Report Author 151 Report Author 151 Report Reader 152 TEDW 151 Warehouse Security Administrator 151 RPI.TimeFilters 159 rule set file 63 rules 61 schedule 85 TEC 61, 65 rulesets 61, 66 Runtime patterns 178 runtime settings 81 S schedule rules 85 scheduling ETL 138 report 162 schema star 154 security TEDW 121 WebSphere 46 security properties WebSphere 37 ServerName Apache 36 service components 7 Tivoli BSM Task Server 70 Service Delivery 8 Service Level Management 8 services 6 severity 84 SIS 35 See Software Installation Services SNMP 37 SNMP agent port 43 SNMP community 43 Software Control and Distribution 10 Software Installation Services 31 software level 28 source warehouse 144 source applications 122 source ETL 122, 143 SQL scripts 128 SSL See Secure Socket Layer staging area tables 124 star schema , component 156 component dimension table 156 default 157 dimension 156 fact table 157 measurement 157 metric 156 metric dimension table 156 start Apache 54 IIS 54 IIS site 54 iplanet 54 iplanet site 54 Web server 73 WebSphere TEC adapter 55 state endpoint 58 status 58 development 139, 149 production 149 Web server 65 stop Apache 54 iplanet Introducing IBM Tivoli Monitoring for Web Infrastructure

215 iplanet site 54 ISS site 54 WebSphere TEC adapter 55 stratus production 139 subscribers 50 summary report 160 creating 160 T tables dynamic data 124 staging area 124 target ETL 122, 124, 140, 143, 145 task DMLinkJre 35 operational 67 task server TBSM 67 TBSM events 65 rulesets 66 TBSM Console 67 TBSM events 81 TBSM task server 67 TEC 60 TEC adapter 65 TEC events 60, 81, 116 TEC rules 61, 65 TEC rulesets 61 TEDW 151 data logging 130 installation 132 log data 85 reports 150 security 121 TEDW Central Data Warehouse 123 TEDW Control Center 123 TEDW Control Center server 132 TEDW repository 120 TEDW role 151 TEDW server 123 TEDW userid 151 testing RIM object 128 theoretical view Web Health Console Web Health Console theoretical view 60 threshold 80, 82 resource model 58 time frame, reporting 159 time interval, report 162 time window, aggreation 161 Tivoli BSM Task Server service 70 Tivoli Enterprise Data Warehouse source applications 122 Tivoli_Admin_Privileges 128 TMR server 26 tmw2k 115 Tmw2kProfile 49, 115 Touchpoint 115 trace files 115 trend 163 twh_app_install_list.cfg 132, 141 TWH_CDW 123, 140 TWH_MART 123 TWH_MD 123, 159 TWHApp.log 133, 142 type event 60 U uninstallation 30 updated 162 user management Web Health Console 59 V version number 118 virtual host Apache 37 virtual servers iplanet 37 W W3C 37 wadminep 28 wapachews 40 warehouse modules 122 Warehouse Security Administrator 151 warehouse source 144 WAS See WebSphere Application Server wbkupdb 31 Index 195

216 wcomprules 69 wcrtprf 49 wcrtprfmgr 49 wcrtrim 127 wdmcm 118 wdmcmd wdmcollect 124, 130 wdmconfig 116, 129 wdmdistrib 35, 52 wdmeditprf 50 wdmlseng 52, 117 wdmrm 117 wdmtrceng Web application tier 178 Web Health Console 57 configuration 58 installation 58 security security Web Health Console 59 user management 59 Web Infrastructure data mart 140 Web server baroc files 62 start 73 status 65 Web server, object 27 Web Services for the IBM Console 151 WebSphere Administration Server 37 administration server status 55 application server status 56 baroc file 62 collect performance data 38 configure event server 55 configure TEC adapter 55 delete trace logs 56 discover 56 display TEC adapter configuration 55 list application server 55 list trace logs 56 managed application object 45 Resource Analyzer 38 security 46 security properties 37 start administration server 55 start application server 56 start TEC adapter 55 stop administration server 55 stop application server 56 stop TEC adapter 55 TBMS discover 56 WebSphere Administration Server managed application objects 45 WebSphere Application Server managed application object 47 Weekdays 159 wiisws 40 Windows Management Instrumentation 37 winstall 32 wiplanetws 40 wizard installation 31 wloadrb 69 wlsinst 33 WMI See Windows Management Instrumentation WorkBench 80 Workbench 58 wrb 69 wrimtest 128 wruntask 67 WSAdministrationServer 45 WSApplicationServer 47 wscp 37 wsetadmin 35 wsetrimpw 127 wsub 50 wwebsphere Introducing IBM Tivoli Monitoring for Web Infrastructure

217 Introducing IBM Tivoli Monitoring for Web Infrastructure (0.2 spine) 0.17 <-> <->249 pages

218

219

220 Back cover Introducing IBM Tivoli Monitoring for Web Infrastructure Gain centralized control of all the Web servers in the enterprise Pro-actively manage Web server resources Report Web server availability and performance Managing the infrastructure of a multitude of Web based services requires a highly sophisticated, modular, and versatile Systems Management solution. The IBM Tivoli Monitoring for Web Infrastructure includes all the functions needed from basic Resource Management, through advanced Event Management, to provide one centralized solution for the management of all the HTTP and WebSphere Application Servers in the enterprise, whether they are Apache, Microsoft Internet Information Server, or Sun iplanet Server based. This IBM Redbook describes the business benefits of monitoring the Web Infrastructure, the overall monitoring architecture, installation procedures and basic customization for the core components of the IBM Tivoli Monitoring for Web Infrastructure. In addition, this book demonstrates how to the integrate the IBM Tivoli Monitoring for Web Infrastructure with other key components of the enterprise systems management solution, such as Tivoli Enterprise Console, Tivoli Business Systems Manager, and Tivoli Data Warehouse. Furthermore, step-by-step examples about how to expand the monitoring solution using customized and/or home grown resource models are provided. This book will be valuable for professionals involved in planning, installing, deploying, or customizing Web sites and Web based applications in any kind of e-business environment. It is expected that the readers of this book are familiar with most of the Tivoli management products. INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment. For more information: ibm.com/redbooks SG ISBN