Re: [Nagios-devel] New Nagios dev branch?
Posted: Tue Feb 09, 2010 11:55 am
--Apple-Mail-117--353505498
Content-Type: text/plain;
charset=US-ASCII;
format=flowed;
delsp=yes
Content-Transfer-Encoding: 7bit
On 9 Feb 2010, at 11:41, Andreas Ericsson wrote:
>>
>> Any feedback? Some people might think there is a lack of development
>> in Nagios
>>
>
> I'm kinda torn on this option. If Nagios is given the option to accept
> check results via a socket rather than from temporary files, there's
> no harm in having the checking daemons sit on a different server, with
> possibly a feeder daemon in between to handle authentication, security
> and multiplexing.
Cheers for the opinion.
This is not about having check results though - that's a completely
different path of logic because if it was a check result then there's
other processing like parent-child dependencies/notifications/event
handlers could be invoked. This patch is about selectively changing or
adding to existing retention data.
> I'm for it, but I feel it would be redundant with a different fix.
I'm fine with ripping it out afterwards if there is a better way, but
I'm erring on the side of functionality now rather than in some
unspecified time in the future.
Ton
--Apple-Mail-117--353505498
Content-Type: text/html;
charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
On 9 Feb 2010, at =
11:41, Andreas Ericsson wrote:Any =
feedback? Some people might think there is a lack of =
developmentin Nagios =
:)I'm =
kinda torn on this option. If Nagios is given the option to =
acceptcheck results via a socket rather than from temporary files, =
there'sno harm in having the checking daemons sit on a different =
server, withpossibly a feeder daemon in between to handle =
authentication, securityand =
multiplexing.Cheers for the =
opinion.This is not about having check results =
though - that's a completely different path of logic because if it was a =
check result then there's other processing like parent-child =
dependencies/notifications/event handlers could be invoked. This patch =
is about selectively changing or adding to existing retention =
data.I'm =
for it, but I feel it would be redundant with a different =
fix.I'm fine with ripping it out =
afterwards if there is a better way, but I'm erring on the side of =
functionality now rather than in some unspecified time in the =
future.Ton=
--Apple-Mail-117--353505498--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]