|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
| News | See also | Recommended Links | Perl |
| Spong | Big Sister | Nagios | |
| Humor | Etc |
mon (see also FSF page and kernel.org page) is the king of simplicity among monitoring products that we reviewed here. It was written by Jim Trocki and released under GPL.
Active development slowed considerably after 2001. Still there have been several new features added and bugs fixed in mon 1.2.0 which was released at the end of June this year.
The author wisely resisted the overcomplexity trap and mon remains simple and capable product with the transparent code base, the codebase that can be easily understood by wide audience of system administrators. In one of his posts David Nolan aptly stated:
My best summary of Mon is that its monitoring for sysadmins. Its not pretty, its not designed for management, its designed to allow a sysadmin to automate the performance monitoring that might otherwise be done ad-hoc or with cron jobs. It doesn't trivially provide the typical statistics gathering that many bean-counters are looking for, but its extensible and scalable in amazing ways. (See recent posts on this list about one company deploying a network of 2400 mon servers
and 1200 locations, and my mon site which runs 500K monitoring tests a day, some of those on hostgroups with hundreds of hosts.)
This is really a quintessential monitoring package "by sysadmin for sysadmins" -- simple, very flexible (each probe can be heavily modified to suit your need without much digging into documentation) but functional enough to provide great value. And in his reply to the David Nolan post the author of the mon stated:
... the design of mon is extremely flexible, and was purposefully built the way it was in order to leverage other tools which already exist. it follows the traditional Unix design philosophy, which i think is the most elegant system design in existence to this very day. it is all about having a mechanism to connect together lots of smaller tools which do one job very well in order to solve larger problems, rather than writing a large tool for each new problem.
you can also think of this design in terms of using natural language, words and grammar to phrase something you want to say. perl itself also follows this model. larry wall is a linguist (a cunning one at that, sorry couldn't resist the pun), and he applied that to perl.
for example, mon leverages fping, the net-snmp tools, traceroute, rrdtool, etc. another example of mon's flexibility is how an on-call notification system with escalation was added without changing anything in mon at all, it was just a matter of writing a custom alert and plugging it in to your mon configuration file with the correct grammar.
in order to get a good idea of how mon works, i would recommend reading the slides from this presentation:
ftp://ftp.kernel.org/pub/software/admin/mon/mon-talk-0.4.tar.gz
And that fact that is written in "simple Perl" without OO perversions only increases its value. One of the first versions (0.38j) is small enough to get basic ideas without getting headache and I recommend to get it first. You should use v. 1.01 but to get the ideas you still need 0.38j.
But even in version 1.01 mon is a rather simple package. It is still
completely written in Perl and you can study what it is doing in debugger. It
is also relatively easy to understand how particular checks are programmed and
that constitutes tremendous advantage as it permit easy customarization.
Mon fundamentally is a scheduler which executes the monitors (each test a specific
condition), and calls the appropriate alerts if the monitor fails.
It views resource monitoring as two separate tasks: the testing of a condition,
and triggering an action upon failure. It is important to understand that
mon implements the testing and action-taking
tasks as separate, stand-alone programs: invocation of an alert is governed
by logic which offers various "squelch" features and dependencies, configurable
by the user.
The current version is available from ftp://ftp.kernel.org/pub/software/admin/mon/devel
mon was developed under Linux, but it is known to work under Solaris. As both the clients and server are written completely in Perl portability should not be an issue. I would be very surprised if there are serious portability issues with mon.
On startup, mon reads a configuration file and then performs tests as scheduled in the configuration file.
Each mon monitor
(called "service monitor" in documentation)
is a Perl script located in /etc/mon/mon.d. There are more then
a dozen prepackaged monitors that come with mon and most can be easily
customized to your own needs:
If a test fails, Mon calls the alert as specified in the configuration file. For example (taken from version 038j):
use File::Df;
foreach (@ARGV) {
($path, $minavail) = split (/:/, $_, 2);
($fs_type, $fs_desc, $used, $avail, $fused, $favail) = df ($path);
if (!defined ($used)) {
push (@failures, "statfs error for $path: $!");
next;
}
if ($avail < $minavail) {
push (@failures, sprintf ("%1.1fGB free on %s", $avail / 1024 / 1024,
$path));
}
}
if (@failures) {
print join (", ", @failures), "\n";
exit 1;
}
exit 0;
Mon alerts are
also Perl scripts. They are located in /etc/mon/alert.d.
Alerts that come with mon:
Most are simple scripts that notify users about a particular problem via particular communication channel like example SMTP mail or instant messaging. For example mail.alert that channel alerts into SMTP mails is structured as following:
open (MAIL, "| /usr/lib/sendmail -oi -t") ||
die "could not open pipe to mail: $!\n";
print MAIL ...
The most commonly used interface is mon.cgi, maintained by Ryan Clark.
Mon was designed to be open and extensible in the
sense that Mon's monitor programs can be any executable. The relevant quote
from the documentations is:
Monitor processes are invoked with the arguments specified in the configuration file, appended by the hosts from the applicable host group.
.... should return an exit status of 0 if it completed successfully (found no problems), or nonzero if a problem was detected. The first line of output from the monitor script has a special meaning: it is used as a brief summary of the exact failure which was detected, and is passed to the alert program. All remaining output is also passed to the alert program, but it has no required interpretation.
This states "Active development stopped approximately in 2001", which is incorrect. Things slowed down for a bit, but there have been many new features added and bugs fixed in mon 1.2.0 which was released at the end of June this year.Thank you for the nice write-up, though.
mon- Service Monitoring Daemon Jim Trocki at kernel.org
mon - Freshmeat page
FSF page - FSF page
ftp://ftp.kernel.org/pub/software/admin/mon/mon-talk-0.4.tar.gz
http://www.ryanclark.org. Home of mon CGI interface by Ryan Clark. He also started working on a newer version of the mon client. See also http://moncgi.sourceforge.net/
Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: June 02, 2008