The Java Agents for Monitoring and Management (JAMM) Architecture Lawrence Berkeley National Laboratory, Data Intensive Distributed Computing Project

Contents

This page contains a description of the architecture and function of Java Agents for Monitoring and Management (JAMM). For a more information, you can read a JAMM paper submitted to the HPDC'00 conference.

• Overview
• Components: Gateway, Logger, Portmonitor, Sensor, Data Collector

Overview

The JAMM architecture is a distributed set of components which collect and publish monitoring data about computer systems. This monitoring data is called events and the components which actually monitor the system are called sensors. Clients may either control the execution of sensors, or they may receive the events from one or more sensors, in which case we say that they are consumers which subscribe to the events.

Below is a diagram showing the connections between the consumers (in blue) and producers of events, and the directory service (in yellow).

JAMM Architecture Diagram

In the following section, each of the components in this diagram will be described briefly:

• Gateway

  The gateway serves as the point-of-contact for a client to control or subscribe to JAMM sensors. There may be one gateway which is responsible for several physical hosts or devices ; because the gateway serves as both a mux/demux and a filter, it shoulders most of the processing load of JAMM. Therefore, in order to not perturb the system being monitored, the gateway should be on a host whose CPU load and I/O load have a minimal effect on the rest of the system.





• Logger

  The Logger is the container for the sensor processes. It starts and stops sensors as well as accepting subscriptions for sensor output. Typically jobs are started either by the Portmonitor on the same host, or by the Sensor Control gui from a remote host. The intent is to have the Logger route all subscriptions through a Gateway, so the Logger is only responsible for sending output to the Gateway.





• Portmonitor

  The portmonitor watches a set of ports on a given host and, based on activity on those ports, triggers the execution of sensors.





• Sensor

  Sensors execute on a host system and collect the actual monitoring data, or events. They either monitor the output of a process that executes once and exits, or the output of a continuously running process. There are assumptions about the nature of the binary being executed by the sensor in the continuous mode, namely that output is flushed on an ongoing basis instead of buffered, otherwise the behavior of the system is non-deterministic. If the sensor is expected to parse the output in order to format it as a Netlogger message, then it loads a java parsing class that is included in a sensor configuration file. The java parsing module can take the output of a program and extract the desired information and then output a Netlogger message. Otherwise it simply passes the output on to any subscribers with the assumption that it is already properly formatted. This means that any program that produces Netlogger output can be incorporated into JAMM by simply modifying the sensor configuration file.

  In the case of the sensors that use a java parsing module, the parsing module is downloaded from an http codebase, which means a module can be revised and the latest revision of the parser will loaded the next time the JAMM system is restarted. In fact, all the different java components in the system are downloaded from the http codebase every time a system is restarted on a host, which makes software updates transparent. The basic parameters of the sensor are frequency, duration, a filter to only pass on data when it changes or to always pass on the data, and any extra parameters that the binary being executed might take. In the case of a continuously running process, the frequency determines how often the output from the program is being checked. The filter is invoked at the parsing level, so in the case of a program that produces its own output the program itself has to support the filter. It is anticipated that further filtering, e.g., some kind of thresholding, will be done by the gateway component which implies that the gateway component has to have some built in intelligence concerning the content of the Netlogger messages. This intelligence should probably take the form of XML data type descriptors or some kind of configuration file, to avoid hard-coding knowledge about specific Netlogger messages into the java code.

  There are pre-built sensors which wrap common Unix utilities: vmstat, netstat, ping, iperf, xntpdc, ps, iostat. There is a tcpdump program included which provides information on retransmits and changes in the TCP window size.





• Data Collector

  The data collector can combine data from several gateways and from an application which is instrumented with NetLogger into a single file for real-time visualization and/or analysis.