FORMATO 2 – CARACTERIZACIÓN SECTORIAL

Tivoli OMEGAMON XE for WebSphere Application Server was acquired from Candle® Corporation, and WebSphere Studio Application Monitor was acquired from Cyanea. We expect that IBM will consolidate these products into a single offering sometime in 2005. In the meantime, while there is some overlap in functionality, each tool provides unique benefits.

Tivoli OMEGAMON for WebSphere Application Server

Tivoli OMEGAMON for WebSphere Application Server is a member of the Tivoli OMEGAMON family of monitors. These monitors share a common infrastructure that allows data from many different platforms and subsystems to be shared.

These monitors include:

򐂰 Tivoli OMEGAMON for z/OS

򐂰 Tivoli OMEGAMON for Customer Information Control System (CICS)

򐂰 Tivoli OMEGAMON for Information Management System (IMS)

򐂰 Tivoli OMEGAMON for DB2

򐂰 Tivoli OMEGAMON for Mainframe Networks

򐂰 Tivoli OMEGAMON for UNIX System Services

򐂰 Tivoli OMEGAMON for Storage

򐂰 Tivoli OMEGAMON for WebSphere MQ

򐂰 Tivoli OMEGAMON for WebSphere Integration Brokers

The WebSphere Application Server environment is very complex, and can be affected by may different factors. Therefore, having visibility into connected systems and subsystems is critical.

The OMEGAMON family of monitors uses a multi-tier, multi-platform architecture for scalability and flexibility. OMEGAMON consists of a data server (Candle Management Server®), one or more monitoring agents, a presentation server (Tivoli Management Portal Server), and one or more user interface clients (Tivoli Management Portal). These components can be arranged in three tiers: agent, server, client. They can also be arranged in four tiers: agent, server (hub), server (remote), client, see Figure 5-1. The second server allows for additional

scalability by offloading the hub server.

The OMGEAMON family of monitors is intended to be used in a production environment, and, therefore, have capabilities suited to day-to-day operations.

The dashboard provides a high-level view, showing alerts that have been generated. Alerts have associated Expert Advice to help less experienced users determine the correct course of action. Take Action commands are available to operational tasks such as starting and stopping Application Tracing or server instance.

Figure 5-1 OMEGAMON components: four-tier structure

5.1.1 Agents

OMEGAMON agents (see Figure 5-2) collect operating system, database, subsystem, and application metrics. Agents are installed on the platforms or LPARs as the resources being monitored. On z/OS, these agents are installed using System Modification Program/Extended (SMP/E). These agents pass data to the Candle Management Server when requested. When a user requests a report, the request is passed to the server, which, in turn, requests data from the agent. Ongoing data transfer between the server and agent is minimized.

Thresholds for metrics are passed from the server when the agent connects to the server. Alerts are triggered when thresholds are exceeded. Evaluation of the thresholds is performed as close to the source of data as possible. Therefore, the metrics are compared to the thresholds at the agent level, and events at the Candle Management Server are raised only when thresholds are exceeded.

Automated responses to events can also be executed at the agent without communicating with the server. Thus, the agents are considered Intelligent Remote Agents.

Figure 5-2 OMEGAMON agents

5.1.2 Candle Management Server

The Candle Management Server collects data from the various agents.

Thresholds are defined and stored at the server and distributed to the agents when the agent connects to the server. The Candle Management Server can run on Windows, AIX, HP-UX, Solaris™, and z/OS. The server runs equally well on all of these platforms. Installation on Windows tends to be quicker and easier.

Implementation on z/OS has two advantages: use of SMP/E and use of Resource Access Control Facility (RACF®). Using SMP, maintenance is more reliable, since prerequisite and corequisite maintenance is checked and validated. Use of RACF security allows for validation of user access, which is then correlated with user authority. This will be a single source of user access authentication.

5.1.3 Tivoli Management Portal Server

The Tivoli Management Portal Server connects to the Candle Management Server. It analyzes and formats data for presentation at the Tivoli Management

Portal Client. The Tivoli Management Portal Server is installed on a Windows platform.

5.1.4 Tivoli Management Portal Client

The Tivoli Management Portal Client (see Figure 5-3) acts as both a display console and as an administrative console. It displays reports containing charts, graphs, and tables of data representing the health of systems and applications. It also allows a user to define new users, define thresholds to generate alerts, and customize reports, combining metrics to provide information.

The Tivoli Management Portal Client can be either a browser-based client or a Java desktop client. If you choose the browser-based client, install Java, if it is not already installed. You do not need to install other software on the client workstation. This light client model allows for easier client maintenance. As new versions of Tivoli Management Portal Client become available, the new software is automatically deployed when the browser connects to the Tivoli Management Portal Server. As an alternative, the Tivoli Management Portal Java client can be installed on the client desktop.

Figure 5-3 The Tivoli Management Portal Client

5.1.5 Tivoli OMEGAMON Monitoring Agent for WebSphere

The Tivoli OMEGAMON Monitoring Agent® for WebSphere collects data from WebSphere’s Performance Monitoring Infrastructure (PMI), byte code

instrumentation, verbose garbage collection trace, application server log, System Management Facility (SMF) 120 records, and configuration files.

From PMI

򐂰 Application Server summary

򐂰 Application Server

򐂰 Enterprise JavaBeans (EJB) container

򐂰 Container transactions

򐂰 Container object pools

򐂰 EJBs

򐂰 EJB methods

򐂰 Database connection pools

򐂰 Web applications

򐂰 Servlets/JSPDynamic Cache (WebSphere Application Server V5)

򐂰 Workload Management (WebSphere Application Server V5)

򐂰 Servlet sessions (WebSphere Application Server V5)

򐂰 Thread pools (WebSphere Application Server V5)

򐂰 J2C connection pools (WebSphere Application Server V5)

From Byte Code Instrumentation

– Java Naming and Directory Interface™ (JNDI) delay – JTA delay

– Miscellaneous delay – Network socket delay

– Structured Query Language (SQL) connection delay – SQL query delay

– JMS topic subscriber and publication message type

򐂰 Application trace

– Server instance name – Start time

– Workload type

– Class name (workload being traced) – User ID and Internet Protocol (IP) address – Response time

– Delay percent

򐂰 Hypertext Transfer Protocol (HTTP) sessions

– Creation date and time

– Creating user ID and IP address – HTTP session size

򐂰 From verbose garbage collection trace:

– Garbage collection

򐂰 From WebSphere log stream

– WebSphere Application Server error messages

– Who used the message (server instance name, JOBNAME, ASID, PID) – Message number (that is, BBOU0012W)

– Message text

򐂰 From configuration files:

– Counts of defined and active server instances – Release and build level

– Java 2 Platform, Enterprise Edition (J2EE) containers – J2EE beans

– J2EE bean methods

– Servant regions heap statistics