Overview

Mercury Architecture

The design of the Mercury Monitoring System follows the recommendations of the Grid Monitoring Architecture (GMA) published by the Global Grid Forum.

The input of the monitoring system consists of measurements generated by sensors. Sensors are embedded in producers that manage the generated data and forward it to consumers. It is important to note that Mercury makes no measurements until explicitly requested by a consumer to keep the intrusiveness of the monitoring system at the minimum.

Sensors implement the measurement of one or more measurable quantities called metrics. Every metric is defined by an unique name, a data type and a list of formal parameters. The formal parameters are used to specify the monitored entity (like the name of a network interface in case of network statistics). Mercury supports both event-like metrics when measurements are triggered by some external event (like log messages) and continuously measurable metrics when consumers must request the measurements explicitly (like CPU utilization).

Mercury extends the GMA by introducing actuators to enable the manipulation of monitored objects. Similar to sensors and metrics, actuators implement one or more controls. Like metrics, controls are also defined by an unique name, a data type and a list of formal parameters. But while metrics are used to gather data about an object without noticeably disturbing its behavior, controls are used to manipulate the monitored object.

The Mercury Monitoring System has a distributed, hierarchical architecture. A producer called the Local Monitor is running on every machine. It collects information about application processes and grid services running on that machine as well as information about the machine itself. Local Monitors are supervised by Main Monitors. The Main Monitor distributes the requests it receives from remote consumers between the Local Monitors, and forwards any data generated by the Local Monitors back to the consumers. The Main Monitor therefore is acting as a consumer for the Local Monitors and as a producer for the original consumers.

The Main Monitor has several roles:

Complex request routing and processing of the data produced by the Local Monitors can be implemented by loading the appropriate sensors and actuators into the Main Monitor.

Multiple Main Monitors may connect to the same Local Monitors making it easy to implement load-balancing should a single Main Monitor become a performance bottleneck.

Main Monitors may be connected to other Main Monitors thus building custom hierarchical monitoring networks. Main Monitors do not need extra privileges to run so regular users are able to run their own Main Monitor instances to aggregate all data they are interested in and make it available at a single location.

Main Monitors may also act as authorization enforcement points by configuring Local Monitors to accept requests from the Main Monitor only. This enables centralized access control and also keeps the configuration of Local Monitors simple and homogeneous.