FAQ
As with any project, people frequently have questions regarding the software, it's design, and why certain choices were made in the implementation. The common ones are addressed here and are updated as new ones come along.
Why s-expressions instead of XML or binary?
This one comes up rather frequently. Other systems out there are based
on a wide variety of data transport and representation formats, most
commonly XML and binary. The original version of supermon was based on
Sun RPC, which is a binary format. Though Sun RPC interfaces provide a
somewhat portable means for transmitting binary, binary has two main
limitations:
- If not using a portable binary library, binary is, well,
not portable.
- Extensions to the protocol, new data structures, and new
data types
are very difficult to add. Binary is not extensible or composable,
as defined on the DataProtocol
page.
Binary can be very fast, but the speed is not so drastically better than a good ASCII format to justify the above limitations.
XML on the other hand provides an extensible, composable format that conforms to a standard, portable specification. Unfortunately, XML is a heavyweight option for achieving this. The main drawbacks are:
- Parsers are very computationally intensive, especially with validation enabled.
- XML suffers from bloat. Expressing simple structures requires large ASCII data relative to the data size itself.
- Although libraries such as libxml2 and Xerces are available on systemssuch as Linux, they are not necessarily available elsewhere. We recognize the fact that not everyone uses, or wants to be forced to use, Linux. We don't like the idea of requiring users to install additional software to support Supermon.
S-expressions are capable of expressing the same tree structures as XML, without cross-referencing as achieved with XLinks, XPointers, and other XML linking methods. We don't believe these are necessary. What s-expressions lack is a method for inlining metadata with data itself to aid in interpreting it. Supermon provides a way to deal with this. The # command provides a description of the structure of a sample. A client is free to read this and initialize it's internal structures and then sample. A valid sample will obey the constraints described by the # command, and an invalid sample will generally not. With reliable transport protocols like TCP/IP, we can assume data received is exactly what was sent by a source to clients. Given sources that have been verified to send correct data, validation is not necessary outside the development cycle of supermon itself.
In short, although XML can achieve the end goal, it is not necessarily a wise choice from a software engineering perspective considering the performance constraints imposed by requiring LowPerturbation of the monitoring system. In this sense, it's like going deer hunting with a bazooka - although it may achieve the end goal (killing the deer), it may not be the most elegant choice considering the desired result (an intact carcass fit for dinner).
Is Supermon only usable on Linux?
Referring to the SupermonArchitecture
explanation, one can see that a clientmust connect to some data source
on TCP port 2709. How data reaches this
port is not important, as long as it is in a format compatible with the
DataProtocol.
Supermon provides Linux kernel modules that make entries in
/proc that mon picks
up and provides over the socket. This does not
prohibit users of other operating systems from creating similar kernel
modules
to provide data in a similar manner, given that mon
can find them.
Furthermore, if a user wishes to not go through the trouble (or simply
does not have permissions) to create kernel-level data sources, the MonHole
provides a simple, although lower performance and more restrictive,
option for pushing data through the Supermon data stream. The clusters
at LANL are Linux, and so Supermon has been primarily developed there.
The supermon server, clients, and even mon
have been at one time oranother run on other systems. Older versions of
Supermon demonstrated
it's usability on FreeBSD and SGI Irix for providing data to mon
(this
code is unfortunately outdated and incompatible with current supermon
versions due to those platforms no longer being used). The supermon
server and clients have been run on MacOSX/Darwin based systems, while
one client was even run on a Windows based machine!
Figure 1. A supermon client running on a Windows-based powerwall.
Symbols are missing when I try to load the supermon kernel modules!