what's the exected future scope of cacti

[ehall]

I may be a cacti noob but I've got a fair bit of experience with some other management systems. There's a lot of features that cacti would benefit from but before I write them up I would like to know if they have any chance of ever being adopted.

What are the expectatins for things like traps, alerts, escalation, notification, etc.

[rony]

With the planned plugin system, the sky is the limit.

The community will be able to write plugins that will intergrate with Cacti to provide almost any functionality you are looking for.

[ehall]

Good to hear.

In order for some of this stuff to work though, a lot of support infrastructure will have to be wired into cacti itself. For example, notification plugins would be feasible but a generalized notification framework (eg templates, escalation, cancellation, etc) would have to be there first.

I'll start putting together some things.

[rony]

Check out the Thold Plugin in the Addons section of the forums. I will be working with existing plugin authors to have there plugins ready for Cacti 0.9.0 plugin system.

[ehall]

Yah, I've looked at thold, it seems like a good tool (haven't used it yet because I don't want to go too far off the code-base reservation but I looked at it). But the point here is that the notification mechanics need to be in cacti proper not in another add-on that has its own add-ons.

Notifications as global events can be used for all kinds of things besides threshold tripwires--system discovery and system failure, software changes, hardware changes, etc.--and you want a generalized action->notification system in place for dealing with that stuff. This is really going to be important if you are going to pursue broad-scope functionality (discovery, inventory, etc), especially because notifications might be part of a complicated action chain (this is really visible when you get into the escalation and cancellation scripts).

Also, there are about a zillion ways to issue notifications (secondary SNMP traps, SMB messaging, IM apps, ...), and some of them are going to require special exception handling of their own.

There are about a half-dozen core mechanisms that need to be developed for generalized management services to work really well. SNMP polling (what you've got now) is just one of them. That's why I'm asking what the intention is; cacti is a fine grapher and I'm perfectly happy looking at it that way.

[rony]

It is a grapher, that is what Cacti does. We developers are attempting to focus on just that, the core.

As far as other features, we have decided to leave that up to the community with the addition of a plugin system. We are planing a pretty extensible API set for the plugins. And all current functions are being documented and altered to match the API design.

I understand your concerns about notifications and I am at the point of adding email functionality to 0.9.0 for the purpose of logging/event notifications. Please email me, we can discuss some options concerning notifications.

[cigamit]

I think I would like to point out that the great thing about the plugin architecture, is that you can have a global scope based notification system, without actually having to be part of the core. All that is required is hooks into the proper part of the core code.

As an example, the threshold plugin already hooks into the core code where host down / up notifications are updated in the database. Based on this, the threshold plugin is then able to send email notifications that Cacti saw a host went down / up. I have been planning on moving the alerting to its own plugin, that would solely handle only alerts passed to it from the other plugins. This plugin would allow emails, syslog, snmp traps, SMS messages, or whatever else you want to send, all based on what the alerting plugin wants. I believe this is something like you are planning, so I would like to see what ideas you have on the subject (this is more the alerting side though). This is really just the start of what can be done.

A lot of the things you mention like host discovery, inventory, hardware changes, etc... would probably be better if they weren't part of the core, since Cacti is a grapher and SNMP Poller. It does what it does very well. Adding more complexity to Cacti will create more of a burden on the developers, and cause the development of the Graphing and SNMP Polling portions to slow down. The main point of the Plugin Architecture to is allevate this issue. Cacti can be modularized so that it can become as complex as the end user wants it, without the extra overhead. Other programmers can write additions that easily integrate into Cacti without having to modify the core Cacti files. Notifications, cancellation, and other things could then easily be integrated as plugins. Granted there will always have to be little tweaks to the core, to allow for more complex things, but these can be handled by the Plugin Architecture, while leaving the main bulk of the code outside that scope. This also allows for smaller downloads and more customization on the end user's part, since they can select exactly what they want they want in their system.

As an example of how it can be modularized, I've already tentively started on an "All-N-1" solution by creating a CD that integrates Cacti and a few plugins and installs it all for the user. It already contains central syslog integration, host discovery (using basic nmap scanning), and the excellent Mac Tracker by "The Witness" (an early beta of the CD can be found on my site). While it really still has a long way to go, the architecture itself is still in its infancy, and I can see it going way beyond its current situation.

You do have some excellent ideas, and I hope I'm not coming off as trying to cut the wind from your sails (which I'm not). I would definitely like to hear more of your ideas, and see where they might lead. I just thought it best to express my ideas on how to both ease the expansion and modularization of Cacti, without putting the burden of maintaining all the new code on the core developers. The easiest way to help Cacti acheive the robustness you (and I) want is to work with the developers, while also respecting the direction they also want Cacti to grow.

----

To help, I should probably take a little time to explain how the current Plugin Architecture works (I'll try to keep it brief). There are only a few functions that are required in the core for plugins to work. The main function is the plugin loader function whichs loads the registered plugins (which are added in config.php) and the other 2 are the hooking functions. All plugins contain a setup.php file, they use this file to register with Cacti on what hooks they want to use, and this file contains the functions that are executed when Cacti calls a hook.

For this example, I will call the plugin "fakeplugin". The plugins are stored in the plugins directory, in a directory that is the same as their plugin name. So in our example plugin, the setup.php would be located here

Code: Select all

/cact/plugins/fakeplugin/setup.php

In this file, you will find a function that begins with plugin_init_ and ends with the plugin name. This function is mandatory, and is used to register hooks with Cacti. Before most everything else happens, Cacti polls the registered plugin for the hooks by executing the initialization function. So to register for example with the hook for adding a Tab at the top of the console, you would do this in your setup.php.

Code: Select all

function plugin_init_fakeplugin() {

	global $plugin_hooks;
	$plugin_hooks['top_header_tabs']['fakeplugin'] = 'fakeplugin_function';
}

function fakeplugin_function () {
    // EXECUTE CODE HERE
}

The global variable $plugin_hooks contains all the information Cacti will need to call the appropriate plugins at the right time, and what function to use to call that hook. In the Cacti core, when it wants to allow plugins to add tabs, all that it is required is to do is call this function

Code: Select all

do_hook("top_header_tabs");

The do_hook function (I think "plugin_hook" might be better later on) looks at all the plugins that have registered to use the hook, and then executes the function that the plugin provided. There is also another type of hooking function that allows the Core to pass variables to the function and use the results returned from the plugins. If a hook has no registered plugin, Cacti simply continues on as normal, otherwise a whole slew of cool things can be done by different hooks (ex: realm adding, adding sections full of settings, tabs, new console links, extra things to do before or after pollings).

This is the extreme basics of the Architecture, but for its simplicity it works extremely well. This is the same Architecture that is used in Squirrelmail (its GPL, and I'm a developer and a Plugins Team Leader), which has been tested and hardened for more than the last 6 years (so why re-invent the wheel?). A strong architecture has spawned an extremely large user base (not that Squirrelmail wouldn't have it without it, but there are currently 206 plugins) and created an application that can be both simplistic or as complex and feature rich as you want it to be.

This architecture is ofcourse set to change in anyway that the developers see fit (I see lots of ways to improve it already and will be discussing them), so nothing is set in stone (its even possible to go with a completely different solution) its all being hammered out by them, since it is after all, their project. But you should be able to see the ways that Cacti can be modularized, without having to be complex at the same time.

(-- Sorry, seems I don't know the meaning of brief --)

[ehall]

Alright here's some architectural considerations, I'll dump them here and let folks think on it. This stuff has already been done in other packages but there is a lot of room for a good functional open-source solution. Some example platforms that already have some of this stuff are IBM Director, HP Systems Insight Manger, AdRem NetCrunch, and others.

Generally speaking, these kinds of things are intended to provide a console for monitoring the status of network nodes, and reacting to change accordingly. This requires the following peer-level components:

Device database
basic IP identity data
user-defined "types" (host vs switch vs router etc)
hardware inventory (interfaces, installed RAM, etc; some SNMP, some WMI)
software inventory (available with SNMP host data)
auto-discovery (multicast pings, ...) and -classification schema (is a host, ...)

Events
SNMP traps (most common)
SNMP polling (changes and thresholds)
syslog parsing
mailbox monitoring
local script output
device-change detection (new software, T3 line card missing, etc)
scheduled events (rescan subnet each night, rescan inventory each week, etc)

Actions
Notifications (SMTP, IM, etc [Director even supports NNTP])
Local command execution
Remote command execution (SSH, whatever) on target or third-party
SNMP trap signalling
Escalation if event not acknowledged
De-escalate if event cleared

Wizarding
MIB browser/walker
Create charts, etc.
Define thresholds, events, actions for device ~type, etc.

Some scenarios how these play together:

Printer low on ink, sends trap which causes email to fire, no escalation
Printer out of ink, send email, escalate to paging

10 failed logins on a workstation, escalate through security channels
3 failed logins on a server, ditto
reset event counter on successful login before threshold

new system detected, quarantine to vlan (SNMP SET) and notify

software inventory changed, fire remote virus scanning

etc.

Cacti has the right underpinnings to pull this stuff off, but its a lot of stuff to hammer on. Also, most of the main architectural stuff needs to be in the core in order for the system to be generalized enough.

I'd encourage folks to play with Director or SIM and get a feel for this stuff. You'll also see why they fall short of the mark.

Thanks

[rony]

cigamit,

Thanks for you input, I have yet to contact you, because I haven't gotten to the 0.9.0 plugin arch.

I will discuss with both of you, in email, notification system in cacti. ehall, please email me.

I like all these ideas, and I'm open to discussion, because I want to see cacti succeed in helping the community. That being said, I do have concerns, and Cigamit sums it up pretty good concerning why we are doing plugins and not intergrating a majority of this functionality.

We have discussed Certifiying plugins, and have yet to develop a system, but we are considering a proceedure that would allow developers to Certify there plugin. This would allow there plugin to be included with cacti, but not active, so that they can use it out of the box.

Ehall, please email me, I will start a email thread between you, me and Cigamit to discuss the notifications system. I think you have a lot of good ideas and I don't want to miss anything.

Thanks,

[gandalf]

Topic split off:
http://forums.cacti.net/viewtopic.php?t=11085
Reinhard