ISPPlanet Network Management System Series - ipMonitor

Using Groups to See the Forest through the Trees

Monitors are great building blocks. But, except in very small networks, they are far too granular to manage individually. Fortunately, ipMonitor also support Groups—sets of related Monitors.

Members and dependencies can be Monitors—or other Groups. Membership enables overall status aggregation for the Group. Dependencies (right) allow decisions to be made based on critical resource status. Defining a Group is a simple three-step process: name the Group, add members to the Group, and define dependencies that determine whether the Group is functioning as a whole.

For example, we created three Groups representing our three Class C subnets. We used Add Network to create Monitors for every device in each subnet (e.g., Monitors for subnets 192.168.0.0, 192.168.1.0, and 192.168.2.0 became members of OutsideLAN, InsideLAN, and DMZLAN Group, respectively). In each Group, we identified only our router PING Monitors as dependencies—we consider a subnet functioning if all router interfaces are reachable, failed if any router interface is unreachable. Other application-level Monitors in each Group will also fail if the router fails—but dependencies allow us to respond only to the root cause and ignore these side-effect failures. But we still want to monitor applications so that we can record availability, and we can use other Groups to detect true app-level failure.

Monitors can be dependencies for more than one Group. Groups can depend on other Groups, and "ipMonitor" Monitors can be used to propagate Group status from one system to another. This methodology is quite flexible, and can be used to model a wide variety of resource relationships. The downside? The dependency configuration panel lists all Monitors, not just Group members. Query functions operate only on Monitors, not Groups. In a large installation, these interfaces would be unwieldy. More importantly, by looking at a Monitor or Group, it isn't obvious what (other) Groups depend on it. Graphic representation of dependencies would be a welcome addition.

Responding to Trouble Using Profiles and Alerts

Putting a monitor in place is only helpful if action is taken when failure is detected. This need is fulfilled by Alerts. Alerts (right) automate response actions, triggered when a Monitor detects a failure.

 

Defining ipMonitor Alerts is a simple three-step process: select the type of Alert, supply type-specific parameters, and define a schedule (right) (i.e., the time period during which the Alert can be generated).
There are many types of Alerts. Write a message to a logfile (right) or the NT event log. Send a simple mail message, create a detailed message in text or HTML format, or mail a complete report containing historical trend analysis and Java graphs. Invoke a "pop up" dialog window on any Windows workstation.
Restart (right) an NT service or reboot the NT workstation identified by the failed Monitor. Launch any local executable, including third-party programs. Forward an SNMP trap to a network management system. Or send a simple, numeric, or alphanumeric page.

In most cases, you really need a sequence of actions, or alternatives based on time of day or day of week. For example, whenever our FTP Monitor fails, write a log message. The first time we're notified, also restart the FTP service. The second time we're notified, send email to the admin on duty (Abel during the day, Cain at night and on weekends). The third, fourth, and fifth time we're notified, page the admin on duty. And so on. Until we reach the end of our rope and take no further action. ipMonitor supports this kind of sequencing and escalation using Profiles.

Profiles (left) tie a set of Monitors and/or Groups to a sequence of Alerts. Whenever a failure is detected by any Monitor, a "notification" is generated. Notifications are checked against all Profiles. For each affected Profile, notifications are checked against all Alerts.

We found this system flexible. It enables a high degree of automation, and supports a wide variety of communication methods. But we also found several drawbacks. The logfile Alert is broken in v6.02 but fixed in v6.05. A few Alerts—notably restart/reboot—are limited to NT. No action is taken when an Alert fails (e.g., SMTP server unreachable, executable does not exist, insufficient permission)—nothing is logged, and there's no way to invoke a secondary Alert only if the primary fails. Although Alerts can be triggered manually for testing, there's no diagnostic information to understand why a Monitor or Alert is not being triggered. The ability to see all Profiles associated with a given Monitor would be useful, as would the ability to "test fail" a Monitor to verify alert sequencing. We'd also like to see device control using SNMP SET requests. Nonetheless, ipMonitor Alerts are powerful tools, and significant automation can be accomplished through complex, sequenced Profiles.

Pt. 1: Getting Started / Initial Config.	Pt. 3: Using Groups / Responding to Trouble
Pt. 2: Using Monitors	Pt. 4: Scheduled Jobs / NT / Status / Final Words