IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Administrator's Guide > Agent-based services

IBM Tivoli Monitoring, Version 6.3 Fix Pack 2

Autonomous capabilities

In addition to the built-in autonomous capability of Tivoli Enterprise Monitoring Agents and Tivoli System Monitor Agents, you can configure special XML files that require no connection to a Tivoli Enterprise Monitoring Server. With these XML files you can define and run situations locally, emit situation events as SNMP alerts or EIF events to a receiver, collect and save historical data locally, and use Centralized Configuration to distribute XML file updates to selected monitoring agents.

Tivoli Enterprise Monitoring Agent

Tivoli Enterprise Monitoring Agents are configured for autonomous operation by default: The agent starts and continues to run with or without connection to its monitoring server. With no connection to the monitoring server, the agent can continue running situations autonomously; when the agent connects to the monitoring server, it uploads situation events that took place while it was disconnected. This incurs use of additional disk space at the agent.

Some situations might not be able to be evaluated completely on the agent alone and are unable to run when there is no connection to the monitoring server. For example, situations using a group function such as COUNT or AVG in the formula must be evaluated at the monitoring server. Even if the agent or the host system is restarted, the events are persistently preserved and uploaded on reconnect. This happens automatically on all agents that use the Tivoli Enterprise Monitoring Agent V6.2.2 or later framework. No configuration changes are required.

Autonomous mode was introduced in V6.2.1 as a configurable agent parameter: IRA_AUTONOMOUS_MODE. Starting with V6.2.2, this parameter is enabled (set to Y) by default. If you do not want autonomous behavior enabled for an agent, you can disable it by setting the parameter to N. Regardless of the setting for this parameter, historical data collection always runs autonomously and reflex automation for a situation is carried out when the situation becomes true. See Environment variables for autonomous behavior.

OMEGAMON XE for z/OS and OMEGAMON XE for Storage agents must run connected because they are configured in the Tivoli Enterprise Monitoring Server in the local RTE: If the monitoring server becomes unavailable, so too do these agents. Running connected to the monitoring server does not prevent them from supporting autonomous capabilities such as emitting SNMP traps and private situations. (The OMEGAMON XE on z/OS agent can be configured to run standalone, and therefore without a monitoring server connection, but that means that no plex data is available for alerts and situations.) OMEGAMON XE for IMS™ currently does not support any of the autonomous capabilities.

Tivoli System Monitor Agent

The Tivoli System Monitor Agent is installed on a computer that has no Tivoli Management Services components or Tivoli Enterprise Monitoring Agents installed other than agents built with Tivoli Monitoring Agent Builder V6.2.2 or later.

The Tivoli System Monitor Agent agent is an OS agent that never connects to a monitoring server. The autonomous version of the agent uses the same agent code that is installed for a full OS agent, but Java is not used for the installation process and the configuration user interface is not provided. The resulting installation is faster and has a small installed footprint. Local XML configuration files for defining such functions as private situations and SNMP alerts are processed during agent startup.

Private situations

Enterprise monitoring agents and system monitor agents can use locally defined situations to operate fully autonomously. These locally defined private situations are created in a private situation definition XML file. Private situations events come directly from the monitoring agent. You must place a private situation configuration file in the agent installation and restart the agent to enable this function. To send an SNMP alert or EIF event when a private situation event is opened, then the SNMP trap configuration file or EIF event configuration file must also be in the agent installation.

Private situations on an enterprise monitoring agent have no interaction with or reporting of any kind to the monitoring server. Private situations and enterprise situations can run concurrently.

Important: Be aware that all situations, whether private or enterprise, must have unique names. Otherwise, actions invoked upon one situation are applied to the other situation with the same name. You can use the CLI tacmd listSit command to get a list of the enterprise situations on the hub monitoring server.

See Private situations.

SNMP alerts and EIF events

Prior to IBM Tivoli Monitoring V.6.2.2, situation events for an enterprise monitoring agent could be forwarded by the Tivoli Enterprise Monitoring Server to an EIF (Event Integration Facility) receiver. IBM Tivoli Monitoring V.6.2.2 or later enables you to configure SNMP alerts to be sent for situation events to an SNMP receiver directly from the agent without first passing the event through the monitoring server. Likewise, with IBM Tivoli Monitoring V.6.2.2 Fix Pack 1 or later, you can create an EIF event configuration file for emitting private situation events to an EIF receiver.

These methods of sending events to OMNIbus can coexist and your monitored environment can be configured for any combination thereof:

Enterprise situations: You can create a trap configuration XML file that enables an agent to emit SNMP alerts directly to the event receiver with no routing through the monitoring server. The agent must connect to the monitoring server at least once to receive enterprise situation definitions. The user needs to place an SNMP trap configuration file in the agent installation and restart the agent to enable this function.

Private situations: Enterprise monitoring agents and system monitor agents can also send SNMP alerts for private situations directly to a receiver such as the Netcool/OMNIbus SNMP Probe or emit EIF events for private situations to an EIF receiver such as the IBM Tivoli Enterprise Console event server or the Netcool/OMNIbus Probe for Tivoli EIF.

Important: If you are forwarding enterprise situation events to the Netcool/OMNIbus Probe for Tivoli EIF and emitting SNMP alerts for enterprise situation events to the Netcool/OMNIbus SNMP Probe, there is a difference in the EIF forwarded situation event and the SNMP alert formats and the data contained by each. Be aware that an event for a situation that is sent to both probes connected to the same Netcool/OMNIbus ObjectServer will not be detected as the same event by OMNIbus deduplication. This results in duplicate entries for the same event within the ObjectServer that will be treated individually. Normally this is not desirable and might be difficult to manage.

See SNMP alerts and EIF events.

Private history

Just as you can create private situations for the agents installed locally, you can configure private history for collecting short-term historical data in the same private situation configuration file using the HISTORY element. The resulting private history binary files can be viewed through the Agent Service Interface. If you have the Tivoli Data Warehouse configured, you can have the short-term data rolled off to a historical database at intervals.

The HISTORY element includes an attribute for setting the number of hours to keep historical data on the computer before it is trimmed or rolled off to the data warehouse. Although the default value is to retain historical data for 24 hours, there is no limit to the number of hours you can keep locally other than the practical limitations of the computer's storage. If you do not have the EXPORT parameter configured, you can use the provided file conversion programs, such as krarloff, to move data out of the historical files to text files.

The WAREHOUSE element specifies the location of the Warehouse Proxy agent to which historical data is exported.

See Private history.

Enterprise situation overrides

You can configure situation overrides for the locally installed enterprise monitoring agent by using a pc_thresholds.xml (where pc is the two-character product code) configuration file. And you can manage the overrides at the agent manually or with Centralized Configuration. Updated situation thresholds take effect after you restart the monitoring agent. The agent sends threshold overrides to a local file and maintains active situation thresholds over agent restarts.

You can apply a schedule by weekdays, days of the month, and start and stop time of a day. The enterprise monitoring agent maintains dynamic situation threshold overrides audit trails by writing active situation threshold records to the agent operation log, which you can add to a workspace in the Tivoli Enterprise Portal to review situation thresholds in effect.

See Enterprise situation override XML specification.

Agent Service Interface

The IBM Tivoli Monitoring Service Index utility provides links to the Agent Service Interface for each monitoring agent installed locally. After logging into the operating system, you can select one of these reports: agent information, situation, history, or queries.

Additionally, you can make a service interface request directly such as to initiate an immediate configuration download or to recycle a situation.

See Agent Service Interface.

Centralized Configuration

Use Centralized Configuration to maintain monitoring agent configuration XML files at a central location that are pulled from the central configuration server at intervals (default is every 60 minutes) or on demand. Agents participating in Centralized Configuration each have their own configuration load list XML file that tells where to connect to get the latest updates in the specified configuration files.

A computer that one or more monitoring agents connect to for configuration updates is called a central configuration server. A computer with one or more monitoring agents that download configuration updates is called a central configuration client.

See Centralized Configuration.


Parent topic:

Agent-based services

+

Search Tips   |   Advanced Search