David, did you ever get management approval on that? I've gotten management approval to build a web-based configuration tool for Mon and rerelease it back to the world, but I don't want to duplicate effort if you've already gotten part of it done.
On Thu, Dec 06, 2001 at 10:45:00AM -0500, David Nolan wrote: > > > --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 -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
