Lots of good ideas here. Some will probably not make it into 2.0, as
I'm not sure how much I'll want to change all at once, but they are
definitely good ideas for later revs.
Since its late and I haven't had much free time lately, I'll just
touch on two or three points for now.
(1)
I agree that the external command file should probably be changed
from using a FIFO to unix domain sockets. That would do away with a
lot of the limitations that larger installations are running up
against.
(2)
The plugin/daemon idea sound reasonable, although I think it should
really be expanded and kicked off to another project. My thinking on
this is to have the core stop performing service checks (and possibly
host checks) by itself. Instead, when it needs to check a service or
host it simply makes a socket connection to another "plugin" daemon
which actually processes the request (i.e runs a plugin) and then
returns those results to the core. This approach would remove the
majority of the fork()ing that occurs in the core right now. This
would involve some rather significant changes to the check logic in
the core and I haven't really thought about how this would actually
be implemented, but its something to think about.
(3)
The external event daemon (I assume you mean the real time output) is
what I'm looking at for integrating Nagios with pretty much anything
the user wants. The way I envision it working is that the core will
send information on everything it does to a separate daemon (via unix
domain sockets). This information will include core process info,
all data that it reads (initial config settings and object data, as
well as data loaded from the retention file), the information it gets
(service and host check results and performance data), and actions
that are taken (flap detection, notifications, event handlers, etc.).
Communication will be one-way, with the daemon only being able to
read data coming from the core. If it needs to send info to the
core, that would be done through the external command interface.
The event daemon will be able to load user-specified modules at
runtime. Those modules will tell the daemon what information they're
interested in receiving. When the daemon receives info from the
core, it simply passes it on to any modules that may be interested in
it. What the modules do with that information is essentially up to
them. Basic modules that could be written include:
- A debug module that dumps raw event data to a file for debugging
purposes
- A module that dumps host and service status information and
performance data into a database
- A module that enters a trouble ticket into a third-party helpdesk
system
- A modules that makes status information, etc. available in XML
format
- etc...
In addition to parceling out individual events to various modules, my
thought is that the event daemon will also hold a cache of the
following items:
- A full set of the initial configuration options used when the core
started up
- A full set of the original objects that were loaded when the core
started
- A full set of retained status information for all hosts/services
that was used when the core started (if retention was enabled)
- A full set of current status information for all hosts/services
(this gets updated as new information comes in from the core)
If individual modules want to get information on what services are
defined, etc. they can just get that info from the daemon.
If this is indeed how the daemon is implemented, it really does away
with the need for the core to write a status log, comment log, etc.
as that information is always present in the event daemon. In that
case, the CGIs could get just their information from the daemon
rather than parsing the config files and status data by themselves.
With that scenario, the core would just serve as a logic engine -
integration with other software and most all data output would be
handled by the event daemon.
The event daemon is really where I'm going to be concentrating my
efforts in 2.0. Other things - like changing the way the CGIs read
d
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: nagios@nagios.org