--On Wednesday, December 05, 2001 12:54 PM -0500 [EMAIL PROTECTED]
wrote:
> A while back, I started to write a Perl/Tk configuration tool for mon. I'm
> a really lousy gui designer, and I found a couple of new bugs in Perl/Tk
> (since fixed), but the really hard part of the project was having to rip
> the parser for the config file out of mon and try to keep up with new mon
> releases. I think it would be valuable to have gui or web-based
> configuration tools for mon (perhaps a webmin module?); I'm finding a
> large config file a bit difficult to maintain, even with m4, and I'd like
> to let other less unix-aware people have some sort of controlled access
> to it. The only way I can see to make this easy would be if the mon
> config file parser were broken out into its own perl module. I don't
> think this would be too difficult, since it mainly involves encapsulating
> code that's already there.
>
> Having a Mon::Config module would also make it possible (not easy!) to
> optionally use something other than a flat file for the configuration,
> e.g. a database. The advantage of this would be to use database user
> access to restrict parts of the configuration.
>
Assuming I can get management approval, we're going to be starting a
project ASAP to replace our current monitoring infrastructure with a system
based on mon & cricket. The largest component of the work in our design so
far is going to be implementing a monitoring system configuration database,
which will address the needs you point out above. The goal is to have a
database representation of all the data in the mon config file, and a web
interface to allow our admins to update the configuration. There will be
access controls, so operations/help center people can see what is
monitored, but not change things, and sysadmins will get control of what is
monitored, and periods for when people get paged vs. when email is sent,
etc, and monitoring admins will be able to control things like system wide
defaults (i.e. default 'alertevery' of 30m, but individual entries could
override). It will support a 'tree' of mon's, with a central mon host
responsible for sending alerts, and slave mon hosts responsible for all the
monitoring, but with all the configuration generated from one system. And
we may try to make it NOT be mon specific, possibly with XML based output
that we would post process to create the mon.cfg.
With a network of thousands of devices and hundreds of servers, a good
interface that empowers all the staff to update the system themselves
without having to understand the intricacies of mon.cfg is essential. Even
better is automating device detection, and integrating host/service
monitoring in with established system management procedures, which are also
parts of our design, but those parts may not be as easy to keep separate
from our in-house systems.
This is all a dream for now... but if I get management approval soon, we'll
be starting work on this within the next few weeks. We do intend to
release the end result.
-David Nolan
Network Software Developer
Computing Services
Carnegie Mellon University
