On 03/25/2011 10:52 AM, Jochen Bern wrote:
> On 03/24/2011 05:48 PM, Ton Voon wrote:
>> the current mechanism of deletion by id number doesn't work in a
>> distributed environment.
>
> FWIW, and taking a rather theoretical/long-term stance, coordination
> between different Nagios instances is hampered by the fact that there's
> no core interface genuinely supporting it:
> -- The command file is unidirectional.
Easily fixed by either transmitting the command as-is or by sending the
resulting event but blocking the command in the transmission layer.
> -- OC*P covers only a very limited set of topics.
Those aren't really important, imo. OC?P commands are less useful by
every day.
> -- The NEB modules API doesn't do remote comm. (Several popular actual
> modules filled that gap, though.)
Already fixed, just as you say. This is also by design. There's no point
building in remote communication into Nagios when modules can do it just
as easily. It *would* help if it was designed for it from the get-go, but
it's not, so we'll have to live with that.
> And once a comm channel is available, globally unique IDs (from downtime
> IDs to hostnames to whatever) and their relations (as in, is "Foobar
> Database Connector" the *same* host for all communicating Nagiosses?
Also already fixed, although decidedly inefficiently for some states.
> What about host "Nagios"?) would likely be the next issue.
>
There's no point in having one host named "Nagios" in a distributed or
redundant setup. Instead you'd have "Nagios1", "Nagios2" or perhaps
"Nagios-asia" etc... In all currently available models there are ways
to make sure the local node is properly checked by itself.
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]