Re: [Nagios-devel] host_name and service_description examples
Posted: Wed Jun 15, 2005 1:22 pm
sean finney wrote:
> On Wed, Jun 15, 2005 at 09:42:56PM +0200, Andreas Ericsson wrote:
>
>>As a module, I believe. The module api lets nagios work similar to gcc;
>>One module can load the config. The core does the work and another
>>module does the logging (similar to frontend, optimizer and backend).
>
>
> ah, cool. when i sit down and start seriously looking at nagios2, i'm
> sure this will become much more clear.
>
I'm sure it will. The event-broker API is really quite neat, although I
expect it to be extended quite extensively (is there another way?) in
the future. It's well conceived of though so backwards compatibility
should remain untouched.
>
>>Notifications is another thing that perhaps ought to be moved out to a
>>module. It's not strictly necessary on a slave-server sending passive
>>checks to a master host, and compartmentalizing code is most definitely
>>a Good Thing. Nagios will need to understand
>>
>>include /etc/nagios-modules/*.cfg
>
>
> like perhaps the already existing "cfg_dir=/etc/nagios-modules" ?
>
Except that cfg_dir is for object configuration, while include would be
for nagios main config and as such should be able to contain
# load module foobar.nso
broker_module=foobar.nso module-argument
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Lead Developer
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
> On Wed, Jun 15, 2005 at 09:42:56PM +0200, Andreas Ericsson wrote:
>
>>As a module, I believe. The module api lets nagios work similar to gcc;
>>One module can load the config. The core does the work and another
>>module does the logging (similar to frontend, optimizer and backend).
>
>
> ah, cool. when i sit down and start seriously looking at nagios2, i'm
> sure this will become much more clear.
>
I'm sure it will. The event-broker API is really quite neat, although I
expect it to be extended quite extensively (is there another way?) in
the future. It's well conceived of though so backwards compatibility
should remain untouched.
>
>>Notifications is another thing that perhaps ought to be moved out to a
>>module. It's not strictly necessary on a slave-server sending passive
>>checks to a master host, and compartmentalizing code is most definitely
>>a Good Thing. Nagios will need to understand
>>
>>include /etc/nagios-modules/*.cfg
>
>
> like perhaps the already existing "cfg_dir=/etc/nagios-modules" ?
>
Except that cfg_dir is for object configuration, while include would be
for nagios main config and as such should be able to contain
# load module foobar.nso
broker_module=foobar.nso module-argument
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Lead Developer
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]