|
technical: The Basics About
ITM
Almost all Tivoli monitoring products, including those
running on z/OS, now use a single framework to process and
display information – the IBM Tivoli Monitoring (ITM)
framework. ITM provides IBM with a common front-end that allows
users to integrate and combine features and information from
different monitoring products. This article provides an introduction
to ITM – what it is, what it does, and how it works.
When IBM acquired Candle in 2004, they also acquired three
products that have become the face of almost all Tivoli monitoring
products: Omegamon XE, Omegamon DE and CandleNet Portal. Today,
these have become IBM Tivoli Monitoring (ITM).
ITM can be viewed as the basic building block for Tivoli
(and some ISV) monitoring products. By itself, it doesn't
monitor anything. What it does is to provide facilities that
other monitors can use to process, archive and present performance
and availability information. Facilities like warehousing,
information processing, alert generation, and a framework
to create workspaces that present the information.
ITM consists of several individual components, as shown below.
Let's look at each of these components.
TEMS
At the heart of everything is the Tivoli Enterprise Monitoring
Server (TEMS), previously known as the Candle Management Server,
or CMS. This is the clearing house for alerts, and performance
and availability data sent in from agents (more on these in
a moment). It
- Checks that all agents are responding by sending and
receiving a regular 'heartbeat'.
- Stores short-term data from agents.
- Stores, starts and tracks all situations and policies.
- Stores every active condition on every agent.
The TEMS stores all this information in a special database
format called EIB (Enterprise Information Base) – essentially
a group of files that are installed as part of the TEMS.
You can see that the TEMS does a huge amount of work, which
can be too much for a single server. ITM allows the TEMS to
be split up – so separate servers can share the load.
There is at least one 'hub' TEMS (*LOCAL), which is the boss.
'Remote' (*REMOTE) TEMS control a subset of agents, and connect
to the HUB TEMS.
TEMS includes ITM Web Services, a SOAP server. Any program
or product can send SOAP requests to the TEMS to retrieve
information, and manage policies and situations.
Tivoli hasn't forgotten users of the Tivoli Enterprise Console
(TEC) and (Micromuse) Netcool/OMNIbus. ITM 6.2 can receive
events from both using the Tivoli Event Integration Facility
(EIF).
A TEMS can run on z/OS – installed using Tivoli's standard
CICAT TSO/ISPF dialogs. However sites keen to minimise their
z/OS processor usage will host all TEMS on Windows or UNIX
servers.
TEMA
The TEMS Agent (TEMA, previously known as the Intelligent
Resource Agent, or IRA) runs on the system or subsystem being
monitored – including z/OS. It sends performance and
availability data back to the TEMS (including heartbeat acknowledgments).
TEMAs can also process commands and SQL-like queries from
their TEMS.
The TEMA comes with the product doing the actual monitoring
- not with ITM. One exception is the operating system monitoring
TEMAs that come bundled with ITM - for Microsoft Windows or
UNIX only. No such freebies for z/OS - the separately priced
Omegamon for z/OS is needed. In some products the TEMA actually
performs the monitoring duties, in others it is the 'middle
man' between monitors and the TEMS. The agent can run within
a monitor, or as its own process or address space. In z/OS
terms, the TEMA is usually a separate started task.
Developers and ISVs can build their own agents using the
ITM agent builder – an Eclipse wizard.
TEPS and TEP Client
Previously called the CandleNet Portal, the Tivoli Enterprise
Portal (TEP) is how users see and manage ITM. The Tivoli Enterprise
Portal Server (TEPS) manages the presentation of ITM data.
It
- manages userids and user access rules
- provides core presentation facilities
The TEPS needs a database system: either DB2 or SQL Server.
TEPS cannot run on z/OS.
Users access this information from TEP clients – using
either a Java client running on their PC, or the HTTP server
on the TEPS via a web browser.
Whichever TEP client is used, the display is the same.
ITM comes with a basic set of workspaces, showing agents
installed and alerts that are active. Individual agents add
to this basic set. Each agent can supply their own workspaces
to view current data, alerts, or events. They can also add
functionality to issue commands via the 'Take Action' facility,
and provide more information and expert advice using the ITM
'Expert Advice' feature.
Users can also define their own workspaces. A big advantage
with ITM is that data from several different agents can be
integrated into one single workspace.
When monitoring systems using ITM, there are three powerful
features that can be used:
- Alert – an alert is created when something is wrong
or needs attention. Alerts can be sent from agents, or created
from situations. Alerts can be seen on the standard ITM
workspaces.
- Situations - using the TEP client Situation Editor, users
can define a trigger – something that is satisfied
when a threshold is reached, a problem occurs, or a value
is matched. Once triggered, an alert is created.
- Policies – policies can be setup using the Workflow
Editor to automatically respond to a situation. This response
can be anything from submitting an agent command, saving
information in the TDW, or notifying staff.
Tivoli Data Warehouse
ITM optionally works with Tivoli Data Warehouse (TDW) to
archive information for later use. It provides an agent (Warehouse
Proxy Agent, or WPA) to consolidate some or all historical
data from the TEMS and store in the TDW.
The Summarization and Pruning Agent processes the raw data
in TDW, storing it in a more useful pattern, removing obsolete
data, and generally managing the enormous amount of data that
can be produced by agents. TDW needs DB2, SQL Server or Oracle
Database. No components of TDW run on z/OS.
Conclusion
The ITM infrastructure has become the basic building block
for almost all Tivoli monitoring products – including
those running on z/OS. This provides a common user interface
that can be used to integrate and combine different Tivoli
(and possible ISV) monitoring products.
Although the ITM TEMS and z/OS related TEMAs run comfortably
on z/OS, all other components must run on Windows or UNIX
servers.
References:
David
Stephens
|
