--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
