How do distributed setups work? (longish)

[Tobias Klausmann]

Hi! 

First off, thanks for your quick reply.

On Wed, 22 Nov 2006, Patrick Morris wrote:
> > 1) Documentation for NSCA is - mildly put - lacking. As far
> > as I can tell, send-NSCA expects data tab-separated on stdin.
> > It would've been nice to actually see an example for getting
> > host and service data into it. Am I supposed to do something
> > like "printf $X$\t$Y$\t$Z$|send_nsca -H ..." for the OCSP
> > command?
> 
> There are examples in the default distribution that show how to
> do this.  Take a look in (on my platform, at least)
> /usr/lib/nagios/plugins/eventhandlers/submit_nsca_result.  Your
> location and filename may vary.

Ah, with a little bit of searching (slocate be praised) I dug it
up (it's named /submit_check_result_via_nsca here). Looks like
it's what I would've come up with :)

> > 2) How does the information that a check should be disabled
> > get from the central machine to the checkers? I've found no
> > "usual" way of doing it?  Would it be necessary to setup some
> > distribution via SSH to the checkers?
> 
> There are several different ways you could handle this, but
> you'd need to find *some* way to get the information out to the
> machines doing the checking.  For my prurposes, just turning
> off notifications has been enough, and that's something you can
> do at the central box only if that's where your notifications
> come from.

Of course. Disabling checks entirely surely is a seldom
occurrence. I guess it only matters if the checks break something
on the checked machine - or they cause congestion for some
reason. As I was planning on handling notification centrally,
it's enough for me.

> > 3) All machines setup to be check passively (i.e. by a
> > checker) are displayed as "disabled" in the web front end.
> > This is very counter-intuitive (they *are* checked, after
> > all). 
> 
> Yes, that's how they look when active checks are disabled.

Which in turn will confuse the hell out of my users. Is there no
way around this? I thought of replacing all my check_commands on
the central machine with /bin/true, but that would result in a
lot of flapping, so it's no solution. 

I guess the only way would be to hack the CGIs. Oh well.

> > 4) There would have to be some mechanism of config
> > distribution.  Both the central machine and the checker need
> > to agree on which services there are. Otherwise, some checks
> > would never be executed or the central machine would ignore
> > the submitted results.
> 
> People do this different ways, but I push the same config to
> all my boxes (keeps synching easy), and have several service
> templates (for example "location_a_service,
> location_b_service,i" etc.) defined on each box.  At location
> A, a "location_a_service" is defined as active.  At location b,
> it's defined as disabled.  At the central box, it's defined as
> passive.
> 
> This allows me to keep per-box-configuration differences
> minimal, and still allows configs to be kept in sync with
> minimal effort (in my case, I rsync the whole damn thing over
> to every machine, except the one small per-server config file).

I was thinking along similar lines, but having a "template
config" which gets filtered into the different configs for
checkers and central machine. How I'd exactly solve that I don't
know yet. But your approach sounds like an interesting
alternative.

Thanks again,
Tobias

-- 
Never touch a burning system.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null