On Thu, Mar 10, 2011 at 11:42 AM, Hermann Lauer <
hermann.la...@iwr.uni-heidelberg.de> wrote:
> Hello,
>
> On Wed, Mar 09, 2011 at 09:14:07PM +0100, nap wrote:
> > On Wed, Mar 9, 2011 at 5:13 PM, Gerhard Lausser
> > <gerhard.laus...@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.
>
Hi,
>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 ;)
Jean
>
> Just a few more ideas.
> Thanks and greetings
>
> Hermann
>
> --
> Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres
> Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
> IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
> Email: hermann.la...@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.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
