Extending templates

[aoverbury]

I've been playing around a lot lately in OpenNMS, trying various ways to hack it to fir my company's needs. Being mostly unsucessful, I went looking for another solution, and came across Cacti. Cacti provides all the graphing capabilities and KPI-logging that we require, and I think with some extensions (which, being written in PHP instead of Java will be more easier for such a fumble-brained programmer as myself) it can really serve our needs well.

Templating interested me a lot, and I'm wondering if anyone's thought about it before the same way I'm thinking about it now: in NMSs you get the concept of a device being a structure that holds a number of services (SNMP, SMTP, POP3, IMAP, WWW, etc, etc...) that can be monitored for key performance indicators as well as general availability. What I'm looking at doing -- and I'd greatly appreciate any pointers, tips or general comments about the idea -- is extending the template engine so that you can template a service -- let's say, SMTP.

The template for SMTP (or, really, any service) has three parts to it: Capability, Availability and Monitoring.

• Capability is a boolean yea or nay about whether or not this device supports the service. For SMTP this would be as simple as connecting to port 25 (by default, although it would be configurable on a host-by-host basis) and waiting for the SMTP greeting line.
  
  Availability is something like an ongoing check for Capability: every polling interval it checks for the capability again, and raises some kind of alert if it's not there.
  
  Monitoring is the collection of the data that Cacti stores in its RRAs and uses for graphing. For SMTP this could include things like average messages per second/minute/hour/day/year/century/so on, number of bounce-back messages, number of denied messages, number of successful deliveries, and so on

This would also require extending (or adding, I haven't looked quite this deep into Cacti yet) a system for raising alerts based on thresholds being violated (for which I believe there's already the THold plugin) and serives going online and offline.

I'm also interested in adding a customisable 'dashboard'-type view. With the current, in-house software we use to monitor the servers we support, we have a page that periodically refreshes itself with new alerts and alarms. I'd like to create something similar for Cacti, with a list of the alerts and so on, and maybe certain key graphs that we want to keep an eye on. This, of course, will be projected onto one of our walls, so screen real-estate isn't really an issue. It's mostly a matter of drawing them out of the different parts of the system. Again, any comments or pointers would be greatly appreciated.

[gandalf]

Thanks for the interesting approach.

To be honest, cacti does not work this way, currently. But I'd like to continue that discussion as it includes some interesting ideas.

Let me briefly explain what and how you can achieve mostly equal results with cacti.

First, cacti supports the model of "host templates". They include a set of "templates" related to the "capabilities" of the target. This is to avoid testing dynamically for a capability on each and every poll. This would slow down the poller to a great extend (or it should be done asynchronously). So it's quite a static approach.
I would agree if you miss a feature to make a host template a list of "capabilities" related to different services. Kinda "host template" built as a list of "capabilities".

Then, cacti supports the concept of plugins, such as THOLD for threshold checks, MONITOR and MANAGE and more than 3 dozens others. They will provide mostly all of your request.

Reinhard

[aoverbury]

I'm eager to help make Cacti work something like this. It would really help take it up to the level of a fledgling NMS, and get the project some more attention. I haven't looked too deeply into CactiD, but I believe it's a more streamlined, multi-threaded poller? If so, it would be the ideal polling platform for this sort of work.

If we changed the concept of a 'device' slightly, it would be possible to support this sort of thing. I intend to look deeper into how the pollers of NMS systems such as OpenNMS work to understand how it can be adapted. Possibly written in a lighter-weight language than PHP, passing data over a unix domain socket or through the loopback interface to avoid having a public-facing interface that could possibly be used to inject junk data into the system.

I don't know... my ideas are clear, but the implementation of them is still a little foggy. It will take some more discussion before they become clear too.