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
|
Home
| Press
Room | Contact
Us | Site
Map
