NetSage: Project Goals

Why NetSage

We'd like to give the people who make the changes in our environment the power to make the matching changes in the monitoring, rather then rely on the Monitoring Guru to make those changes. (Thus the name NetSage. The database system will become the Wise Old Man that people tell about the changes they've made, and it will take care of updating the monitoring systems.)

This is one place where the commercial monitoring systems (claim to) shine, compared to the open source alternatives. Thus we've decided we need to write a configuration front-end for Mon and Cricket, concentrating on Mon first. Here is a list of most of our current project goals. Most of these goals are wholely contained within the NetSage project, but some involve changes to Mon itself, or the Mon clients.

Primary Goal:

Proposed 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, and is the 'known' Mon server used by Mon clients. This is primarily to provide scalability, and conceptual division of labor, but could also be used to provide a local monitoring host for monitoring servers in a remote location.
• 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 multiple 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)