On Thu, Mar 10, 2011 at 11:42 AM, Hermann Lauer <Hermann.Lauer@iwr.uni-heidelberg.de> wrote:

On Wed, Mar 09, 2011 at 09:14:07PM +0100, nap wrote:
> On Wed, Mar 9, 2011 at 5:13 PM, Gerhard Lausser
> <Gerhard.Lausser@consol.de>wrote:
> > Hi,
> >
> > > change this in the future, or even better, if it is possible
> > > to have distributed passive service checks in some form with
> > what exactly do you mean by that? From the clients' view there is one
> > ip-address where nsca messages are to be sent to.
> > The weak point here is, when Shinken performs an arbiter failover, the
> > nsca-listener gets another address. I have no idea how to handle this
> > except by integrating the arbiter in some cluster framework with a virtual
> > address.
> >
> Yes, the only solution is a VIP between the two receiver or arbiter IP. But
> it's quite easy to setup, so it's not a big deal :)
> We can also think about a nsca protocol over multicast too  ;)

Just to widen that up a little more, leaving out the so far unused
nsca at our site:

Actually we are using the pipe to send in PROCESS_SERVICE_CHECK_RESULT
to our different old nagios configs. As far as I understand for active
checks the scheduler gets the results from the pollers and distribute it.

In shinken/external_command.py the are two methods
load_scheduler(self, scheduler) and load_arbiter(self, arbiter),
which I hoped a scheduler is also prepared for reading a local pipe
and reacting on (at least) the hosts he knows about.

That would be sufficient in our setup and allow multiple entry points
for passive checks, fitting well in the distributed architecture of shinken.

In the more far future Messages for a host not handled by this scheduler
could be probably forwarded to another scheduler.

From now in fact scheduler do not open tis anymore, it's only the arbiter (and not in a module, but harcoded..). But it possible to do a module that do it for scheduler and if hte host is not available, wait for the arbiter for get and dispatch. But it's better for this to be taken by a receiver, it's a more clean way ;)


Just a few more ideas.
Thanks and greetings


Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
Email: Hermann.Lauer@iwr.uni-heidelberg.de

Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
Shinken-devel mailing list