[ Version 3.0 ]

Here are some things on the wishlist for Nagios 3.0. Please note that not all of these items may be implemented in 3.0.

Misc Changes:

• More adaptive monitoring features, including the ability to alter check timeperiod, notification timeperiod, and default notification groups/options on the fly

Multi-Line Plugin Output:

Nagios 3.0 will allow plugins to return multi-line text and performance data output. This feature will be implemented in such a way as to ensure that all current plugins continue to work without modification. Multi-line performance data will likely be combined into the existing $HOSTPERFDATA$ and $SERVICEPERFDATA$ macros. Multi-line text output will be handled like this: The first line of output will continue to be stored in the $HOSTOUTPUT$ and $SERVICEOUTPUT$ macros. Additional text output (optionally spanning multiple lines) will be stored in new $LONGHOSTOUTPUT$ and $LONGSERVICEOUTPUT$ macros.

User-Defined Object Directives:

Object definitions will be extended to allow for user-defined variables/directives to be entered. This custom variables will be inheritable, just like the standard variables now. Custom variables will likely look something like this...

define host{
	host_name		host1
	...
	_customvar1		"This is a custom variable of some kind"
	_location   		"Host is physically located in Room 301..."
	_snmp_community_string 	public
	}

Event Broker Enhancements:

Before the event broker can be enhanced, it first needs to be documented. :-) I'll be working on that before development of 3.0 gets underway. With 3.0 I would like to extend the event broker to allow modules to do things like:

• Override default notification logic
• Override default host and service check logic
• Executing checks/commands internally rather than executing external checks (plugins) or commands using system() calls
• etc...

There are a whole number of things that I would like to see event broker able to do. Essentially I would like to allow event broker modules to override most of the internal logic in the daemon when it comes to host/service checks, notifications, flap detection, logging, executing external commands, etc. This will allow people to do a number of neat things that would otherwise require extensive rewriting of the Nagios daemon. More details will be coming in the future, as I start to ramp up towards development of 3.0.

Host Check Improvements:

* Regularly-scheduled host checks will likely be run in parallel, much like how service checks are currently run. This should help improve performance in installations where a large number of hosts are being actively checked. On-demand host checks (propagated by the reachability logic) will still be performed in a serial fashion.

* The host reachability logic will likely be improved a bit. Currently, host problems are propagated both upwards and downwards from the host on which a problem (or state change) is first noticed. When Nagios determines the root cause (e.g. the offending/blocking parent host) of an outage, checks are not propagated to all child routes. This can result in delayed UNREACHABLE notifications for some children of a DOWN/UNREACHABLE host. The route propagation logic will be improved to ensure that all children of "blocking" hosts are checked as soon as possible.

CGIs Going Away:

The CGIs that compromise the official web interface for Nagios will be disappearing in 3.0. Why? It makes more sense to break the interface off as a seperate project and move to something more sustainable that CGIs written in C. Several projects are already underway to develop new interfaces in PHP/Perl.

Some of the reasons I'd like to see a move to PHP/Perl interfaces include:

• Eaiser to support multiple languages (internationalization)
• Hardcoded HTML in the CGIs requires a recompile to make changes to the interface, PHP/Perl should be much easier
• The current CGIs need some serious help with UI design. PHP/Perl interfaces will hopefully lure more people into helping make a better looking interface.
• Session state is much easier to track using PHP/Perl. The current CGIs would require a lot of work to incorporate sessions.

Once 2.0 is released as stable, I'll start to focus on 3.0. As part of that, I'll lend a hand (as much as I can) to developers who want to create alternative web interfaces in PHP/Perl/etc. My involvement may be limited to helping document that data files, getting status data into a DB (MySQL/PostgreSQL), etc.