Writing Monitors for the Event Monitoring Service (December 1999)

Chapter 1 13
Understanding the Event Monitoring Service
Event Monitoring Service Overview
through many methods, including:
• EMS GUI
• ServiceGuard
• monconfig utility
• resls or resdata commands
2. 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.
3. 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.
4. 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.
5. The EMS API provides the interface between the registrar and the
monitor.
6. The monitor identifies the resources. The list of resources is passed
back through the registrar to the client requestor. Monitors can be
either State or Asynchronous types.
• State type monitors. These monitors check the status of the
resource at specific (polling) intervals. This monitor is polled. A
monitor that is part of an MC/ServiceGuard package must use a
state type monitor.
• Asynchronous type monitors. These monitors are event driven.
They are not polled by EMS. EMS checks the continuousmessages
against the user defined parameters. These monitors do not store
values about resources.
7. 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