Event Monitoring Service Overview

The Event Monitoring Service (EMS) monitors system resources. EMS is used by system administrators to configure monitoring requests, check resource status, and send notification when configured conditions are met.

EMS can work in a high availability environment. It can report a loss of redundant resources. Identifying and reporting single points of failure helps maintain a proactive approach to preventing the loss of data and availability.

EMS only observes a system, and does not modify the system. Use EMS with additional software to take or specify action.

The three basic components of EMS are:

Client and Target Applications
System administrators use client applications to set, modify, or remove monitoring requests. System administrators use target applications to receive event notifications and possibly take actions.
Client applications include ServiceGuard (MC/ServiceGuard or ServiceGuard Extension for RAC), the Event Monitoring Service (EMS) GUI (Graphical User Interface), the Event Monitoring Service CLI (Command Line Interface) or other applications that comply with the EMS API.
The target application can be any application that supports the EMS protocols. The supported protocols are:
- TCP/IP or UDP/IP
  This includes any application that accepts these protocols and follows the rules defined in the EMS Developer's Kit.
- opcmsg method (for ITO)
  This option is used for IT/Operations notifications.
- SNMP traps
  This option can be used with any application that accepts SNMP traps, such as NNM or IT/O. You need to set up the application to recognize the SNMP traps generated.
- email
  This option does not require any extra handling. Specify the email address when the monitoring request is created.
- syslog and textlog
  This option does not require any extra handling. Specify the log file when the monitoring request is created. Syslog notifications go to the local system.
- console
  This option does not require any extra handling. Specify the console when the monitoring request is created. Notifications go to the local system.
- ServiceGuard
  This option requires that the client and target application both be ServiceGuard running on the same local system.
Resource Monitors
Resource monitors observe designated resources and report back resource values or events to the Event Monitoring Service.
Hewlett-Packard provides monitors with the High Availability Monitors package and with the Event Monitoring Service. The monitors available through Hewlett-Packard include: HA Database Monitor, HA Disk Monitor, HA Cluster Monitor, HA Network Interface Monitor, and HA System Resource Monitor.
Event Monitoring Service Framework
The EMS framework provides the interface between the client applications, monitors, and target applications.
The EMS framework contains the Applications Programmers Interface (API), registrar, and the Resource Dictionary.
Developers use the API to create additional monitors for use with client and target applications, such as the EMS GUI, EMS CLI or ServiceGuard. Monitor components to be created include: resource dictionary, resource monitor binary file, manpage (recommended), and message catalog (recommended).

Figure 1-1 “Event Monitoring Service Components” shows the relationships between the Event Monitoring Service components.

Figure 1-1 Event Monitoring Service Components

The process is as follows:

The system administrator enters the client application, for example, the EMS GUI, or the EMS CLI, to begin the discovery phase of creating a monitoring request.
The discovery phase, includes identifying the resources to be monitored and configuring the request. It can be accomplished through many methods, including:
- EMS GUI
- EMS CLI
- ServiceGuard
- monconfig utility
- resls or resdata commands
The EMS API provides the interface between the client request and the registrar. There is a one to one correspondence between the client and registrar.
The registrar refers to the dictionary for a list of available resources and related monitors.
The resources listed in the dictionary are passed back to the client.
When a discovery request is made that exceeds the scope of the information in the dictionary, the registrar launches the appropriate resource monitor application, if it is not already running, and passes the request on to the monitor. Multiple registrars may access the same monitor.
The EMS API provides the interface between the registrar and the monitor.
The monitor identifies the resources. The list of resources is passed back through the registrar to the client requestor.
The system administrator, through the client application:
- Continues to drill down through the list of available resources supplied by the registrar, dictionary, and monitor
- Identifies the resources to monitor
- Completes the monitoring request defines conditions of where and how to send the event notification
A completed monitoring request identifies:
- What resources to monitor
- What events to watch for and how often
- What notifications to send when an event occurs
- Where to send notifications
Events are defined for either of two resource state types:
- Periodic checking against either thresholds or state/value changes
- Continuous checking for asynchronous stateless events
The registrar passes completed monitoring requests down to the appropriate resource monitor application.
The monitor checks the resource as specified in the monitor request. It passes back to the EMS API whether the request is accepted or rejected.
The EMS API provides the interface between the monitor and the target.
The monitor begins collecting data as specified in the monitoring request.
The EMS API interprets the information received from the monitor, determines if an event occurred, and forwards the notification to the target applications. The method of informing the target application of a critical resource value can vary for different target applications.
In the case of ServiceGuard, the client application and the target application are the same and reside on the same system.

Event Monitoring Service Overview

Technical documentation

» Table of Contents

» Glossary

» Index