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.
Figure 1: mon,
supermon kernel modules, and monhole data source
on a compute node.
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.
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)
)
(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.