I was thinking about the feature sets that have been proposed and possible
additions to the post 1.0 releases for nagios.
Among the items I would like to propose (feel free to shoot them down
CGIs:
1. Separation of the existing CGI interfaces into a separate sub-project
and compile set (possibly inculding the patch proposed by Russel Scibetti)
2. Supporting a faster CGI interface by having the Nagios core provide a
dbm dump of the running config, possibly indexed by authorization info.
The dbm would be created everytime Nagios was started or SIGHUP'd. This
would also prevent the currently (annoying sometimes) mismatch between the
group/host/service info displayed by the CGIs and those that are being
used by the core.
Using the balanced binary tree would also help make the parsing faster if
a simple dbm of host/service was dumped.
(for reference I was using the dbm from Cricket's config.db)
3. CGI separation would also allow another view to be developed based on
service dependency that could be a boon to the manager/operator interface
Nagios core:
4. A SIGHUP does not put all services into a pending check mode. (This
already exists with the disabling of internal state info - I think)
5. Support socket interfaces for receiving and sending information. A
socket interface with a defined packet format would allow Nagios to be
independent of the platform specific (or lowest common denominator) named
pipe (FIFO) limitations. These seem to be causing some of the limitations
of the submitting passive check result sizes.
6. Support socket communications to plugins in addition to the current
fork/popen. This requires adding a couple of descriptors to the command
definition to denote plugins that can be run as daemons, their startup
options, location and port number (usually localhost).
With a daemon based plugin, Nagios core could send a message via the
socket to the daemon with the complete arguments instead of calling popen
with the complete arguments and prevent the process creation overhead.
This would be really useful for larger sites that use a smaller number of
plugins to check a large number of services. Check_http is one that comes
to mind most easily. It could also allow distribution of the plugins to
multiple hosts while still maintaining a single instance of nagios core
(a slightly bastardized version of load-balancing across multiple hosts)
The socket interface does provoke a number of security questions for a
number of installations. Use of ipchains with uid/gid and/or TCP-Wrappers
should provide some level of security.
7. Better define the capabilities of the Event daemon as to its scope and
ability.
8. Possible use of XML schema for reporting status if performance is not
affected too much.
Nagios plugins:
9. Develop a daemon framework so that new plugins can be built relative
easily by just adding the plugin specific routines. It may be possible to
to have the framework include support for Embedded Perl - thus reducing
the memory footprint of the Nagios core process, but perhaps increasing
the overall requirements for the system if multiple daemons with ePN are
running.
10. Develop some consistent method of storing performance data.
Related efforts:
With the proposed killing off of DB support, a mechanism is need to
support integration of the configuration files with other asset tracking
databases that a user might have. To support this, I would like to
propose a Nagios Perl interface that can read/generate configuratin files
and read status data. This would allow scripting to generate
configurations from various sources whether database, XML, or flat-file,
and development of user interfaces and or reporting from status/archived
data.
--
-Subhendu
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: sghosh@sghosh.org