SUPERMON

SUPERMON ARCHITECTURE


The supermon software architecture is made up of a set of servers, APIs, and Linux kernel modules. Interfaces between the servers and APIs separate the two that allows them to be independent of each other - a server can provide data to a client that does not use the provided API, and the provided API can interface to data of the proper format regardless of whether or not it comes from the Supermon servers. Similarly, the Supermon servers do not require data come from Linux or Linux kernel modules. As long as a data source presents the proper format to the Supermon servers, they can pass it up to clients with no problem. And finally, users can gain access to kernel provided monitoring data without the supermon servers or API.

Supermon servers

Supermon provides two servers that move data from the source to the consumer: mon and supermon. mon resides on the compute nodes and gathers up all available monitoring data and provides it to requestors over a TCP/IP socket. It reads data from both the kernel data sources and the MonHole.

./computenode.png

Figure 1: mon, supermon kernel modules, and monhole data source on a compute node.

supermon acts as a data concentrator, gathering data from mon and other supermon sources, composing them together, and passing up a single data sample representing their composition. (See DataProtocol for explanation of composability). The fact that the protocol read by supermon is the same as the one provided by supermon allows hierarchical structures to be created where leaf nodes are mon servers, and interior nodes (including the tree root) are supermon servers.

./supermontree.png

Figure 2: supermon data concentrators connected to mon and other supermon sources.

Finally, a client connects to the socket and uses the programming API (or some other method to parse the data) to initiate and read samples.

Note that both supermon and mon provide data on TCP/IP port 2709. This port is officially registered as owned by Supermon with ICANN.

Data API

Given the above architecture, data can be transported from sources to a single point at which clients can retrieve the aggregation of all source samples as a single large sample. A sample may look something like:

(some s-expression
(will go here)
)

If one writes a simple client in LISP, it no API is required as intrinsics in the language make working with s-expressions trivial. An example LISP client is shown on the ExampleClients page.

 

Updated 08-13-2008