Hello, David -- We've just started an in-house project in our company to create a web-based configuration tool for mon. Nothing nearly as ambitious as yours, just something to take the burden of day-to-day configuration off the shoulders of the monitoring system developers.
I'd definitely be interested in lending a hand, and reaping the fruits of your efforts. Is their any particular task you'd like to farm out? -- Scott Scott Prater Dpto. Sistemas [EMAIL PROTECTED] SERVICOM 2000 Av. Primado Reig, 189 entlo. 46020 Valencia - Spain Tel. (+34) 96 332 12 00 Fax. (+34) 96 332 12 01 www.servicom2000.com -----Mensaje original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de David Nolan Enviado el: martes, 09 de abril de 2002 3:47 Para: Joe Rhett CC: [EMAIL PROTECTED] Asunto: Re: Suggestion: Mon::Config --On Friday, April 05, 2002 9:19 AM -0800 Joe Rhett <[EMAIL PROTECTED]> wrote: > 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. > Actually, it's funny you should ask that now, as I've just recently gotten approval for the project to move forward. We're starting development on the system now. If you, or anyone else, wants to give us a hand, we would welcome the support. Here is a quick list of the features we're looking for from the system. I'll be documenting this a bit better, and setting up a project web page, sometime this week. Primary Goal: Provide a web based interface to the Mon configuration. More specifically, abstract away the specifics of the Mon config file, and allow staff members who aren't familiar with Mon to make changes without having to understand the way Mon works. Feature List: -Support multiple Mon servers, in a slave/master tree setup, where Slave servers are responsible for doing most of the actual monitoring, and use Mon traps to send data to the Master server. The Master server will be responsible for sending alerts. -Support Hierachichal 'Views', defined in the database, and used by the Mon clients. (Most clients don't support views right now, but I'd like to change that. Views become more important as you monitor more stuff.) -Provide multiple levels of access, to allow users to change some aspects of the system, but prevent them from changing certain other aspects. For example, allow a network engineer to specify the 'interval', 'alertevery' and 'alertafter' parameters for an entry that monitors network devices, but prevent them from changing an entry that monitors web servers. Specific levels of access might include: -Super Admin, can change anything. Primarily used by automated scripts for loading data from external sources (see below). -Admin user, who can change almost anything. Primarily responsible for defining service types and generating default values for the relevant fields. -Service Admin, who has access to specific hostgroups, and is responsible for controlling what machines are in those groups, and what services are monitored on those groups -Coverage User, who has access to certain attributes of specific hostgroups, and to 'views' information. Can change what views exist, resulting in different options available to Mon clients. Also can change alert periods, to control when pages are sent vs. when email is sent, for example. -Visitor/Management User, who can see the data, but can't change a thing. -Provide some concept of 'externally maintained data', so sites can load data in automatically from another source (in our case, our network registration system, which already has all our hosts in it, and some concepts similar to hostgroups). External data shouldn't be updated through the interface, or it might just get overwritten during the next data load. -The database design should be extensible enough to allow other types of monitoring to be integrated, such as Cricket graphs. -Output from the system will be in XML, with translation done via XSLT/XPATH to generate the multipe mon.cfg files, and other associated files (perhaps /etc/hosts for example). -The interface for the system should involve an abstraction layer, or layout engine, to provide segmentation between Data and Presentation. An XML Application Server is one approach we've been considering. -Provide useful levels of security on all network transactions to prevent an evil person from fooling the system into believing something that isn't true. This means using SSL for web transactions, and adding some sort of security to the mon traps. (Probably an MD5 hash, with a shared secret) Obviously we've already put a good deal of thought into the system. But there is basically nothing written yet, so additional input is welcome, as are development efforts. I intend to keep the mon community up to date on our progress, and provide access to our work as it progresses. (Starting with the first useful milestone, which will be having the SQL->XML->Mon data conversion all mostly working, but without a user interface for the database.) -David Nolan Network Software Developer Computing Services Carnegie Mellon University
