I really like mon. A good deal of my past couple of years of employment has involved installing and configuring mon at different sites. But unfortunately, most of them stopped running mon shortly after I left. Here's why:
Problems: A) Configuration is difficult. I'm not saying mon is sendmail, but even good experienced Unix admins I've worked with have a hard time dealing with the configuration file, especially if they're not working with mon constantly. While m4 can help if used appropriately it adds its own layer of complexity. Mon really, really needs a good configuration GUI. I tried to write a GUI a couple of years ago, but having mon structured around a complicated configuration file makes this extremely difficult (I'm also a wretched GUI programmer). B) Installation and upgrading are difficult. Some sort of package with an install script is sorely needed, and mon needs an appropriate default installation setup. C) Maintenance is difficult. Mon is very well designed, but it's a lot of code in one place. I don't mean this to be in any way a criticism of the author and other contributors. Mon has been a good bit of my bread and butter for the past couple of years. I think mon is a wonderfully conceived project. The underlying design is simple, robust, efficient and extensible in the classic Unix sense; but I think some changes in the implementation would make it far easier to build on and hence far more popular. Here is my (somewhat radical!) suggestion of how mon might be restructured. 1) Break up the mon data structure into the following modules/objects: Mon::Watch Mon::Watch::HostGroup Mon::Watch::Service Mon::Watch::Service::Period Mon::Watch::Service::Period::Alert The mon configuration file is essentially a stripped-down text representation of a large and complicated Perl data structure, and I think this is the natural breakdown if one wanted to modularize it. Yes, this is a lot of modules, but installation could be simplified by creating a CPAN bundle. Better yet, mon could come with an install script that could take a prefix as an argument (like GNU autoconf) and optionally install all the Mon modules under a private lib directory. Modularity is generally a good thing, and it would be far easier to maintain and enhance mon if it were more modular. Discreet chunks of work could be easily meted out to willing parties. This would require reworking pieces of the server code, but the modularity should make the server code much smaller and easier to read and maintain. 2) Separate the state information from the configuration information. This is pretty straighforward; the config file holds configuration information and most of the state information is stored by the server on the data structure in variables that begin with "_". 3) Use an object persistence mechanism to store the configuration information in a database. The Tangram module <http://search.cpan.org/author/JLLEROY/Tangram-2.04/> would be ideal for this. Tangram gives each persistent object a unique identifier; all of the state information could go into a hash keyed on the Tangram OID. For neatness, this can go into its own module, e.g. Mon::State, and would only be used by the server. Tangram will work with any database supported by DBI, and has rapidly evolving XML support. Since Tangram is layered on top of an RDBMS, the underlying RDBMS facilities could be used to set up client views and restrict user access, though making this portable across database platforms might be complicated. Yes, this would require separate installation and management of a database, but it would scale far better than the current monolithic (sorry for the pun) text-based scheme. 4) Rework the Mon::Client interface to make requests to the server based on the Tangram OID. Add methods to Mon::Client to reload and remove objects. Configuration programs would load the configuration object heirarchy from the database, make changes to the objects and commit them back to the database, all via method calls on the objects. They would then call load/reload/remove methods through the client interface to tell the mon server to reload or remove the added/changed/deleted object. Writing configuration clients, either GUI or text-based, would be straightforward, and changes to an object's configuration would not require reloading configuration for the whole database; and writing status clients would not involve parsing complex data structures. Thanks very much for mon, and please take these suggestions in the spirit in which they were intended. Dan Urist -- Dan Urist [EMAIL PROTECTED] http://www.world.std.com/~durist
