How It Works

The main goal of XSI is simplicity. Foremost, it should be simple to use with little to no configuration required. As a read-only monitor (as opposed to things like SNMP), it has a very secure design. No user-supplied input is processed, and no data from network clients is accepted.

On the technical side, XSI runs as a single-threaded daemon and periodically collects statistics. These are served in XML format to network clients on a configurable TCP port.[1] If run with superuser privileges, it uses them to confine itself using chroot() on platforms where it can be done, and always discards them by dropping to an unprivileged user as early as possible.

XSI offers three modes of operation:

• Standard mode serves current snapshots of periodically updated statistics.
• One-Shot Mode prints collected statistics to stdout and exits.
• One-Client Mode expects to be queried by a single client only, with requests by that client triggering updates of statistics.

1: XSI does not perform authentication, encryption or any access control by itself. This is by design and needs to be taken into account when deploying it. Pay attention to the SECURITY section in the xsi(8) manual after installation!

Stats & Information

XSI monitors a variety of useful and interesting statistics. This data should allow the user to observe a machine's health and be alerted to problems or failures.

Available information and statistics include the following:

• XSI's own configuration settings
   
• System information:
  • Machine overview
  • CPUs and load distribution on CPU states
  • Interrupts
  • Memory and swap space
  • Operating system:
    • Generic information
    • Uptime, load averages
    • Information about processes
• Sensors:
  • Temperature
  • Fan RPM
  • Voltage
  • Disk drives
  • Indicators
  • ...
• Storage devices:
  • Filesystems
  • Disk (I/O)
  • RAID arrays (optional)
• Network:
  • IP default routes
  • Information and statistics per interface, including:
    • Properties
    • CARP status
    • Addresses
    • Packet, byte and error counters
  • Statistics from multiple packet filters (optional)

The formal definition of the output is contained in the XML Schema. A complete reference of all elements and attributes, with descriptions in plain English, can be found in the XSI output documentation. Last, but not least, example output from the developer's desktop machine is kept in sync with new releases, to show how XSI output looks on a supported platform.

Lightweight & Portable

XSI is architecture-independent and easy on resources. The result of a very time consuming experiment is the output of XSI on OpenBSD/vax, running inside the SIMH VAX simulator. It took more than one hour to build XSI there, which makes the VAX simulation at least 60 times slower overall than the host, an AMD 2600+. Still, XSI only consumes less than 3% CPU while running in Standard Mode (no queries, 2 seconds update interval.) In One-Client Mode, it could be queried about 3 times per second, with ca. 50% of the CPU time spent in userland.

By itself, XSI is very portable and known to compile and run on a wide variety of POSIX/Unix systems. System dependent code is limited to a single source file per OS and easy to hook into the build system. Take a look at the PORTING file, if you are interested in making XSI work on your OS of choice.