active checks vs. passive checks

Rick Mangus rick.mangus+nagios at gmail.com
Thu Mar 11 14:27:47 CET 2010


Reply scattered amidst your mail.  :)  I hope it is clear.

On Thu, Mar 11, 2010 at 5:01 AM, Richard Gliebe <richard.gliebe at fhv.at> wrote:
> On 3/11/10 11:07 AM Mark Elsen wrote:
>>> how do I have to check the services on the servers which are outside of
>>> our network? Do I have to install a hole nagios environment (like a
>>> second Nagios server?) or only the nagios-plugins, or something else?
>>>
>>>
>>
>> If there isn't a permanent connection with the NAGIOS server, the
>> issue becomes tricky as even standard
>> passive setups imply that a result can be submitted to NAGIOS at any time.
>> If that is not possible the program which submits the result will
>> fail, when no communication with the NAGIOS
>> server can be established. Hence provisions must be taken, to setup a
>> system which can queue results , and send,
>> information to the NAGIOS server when possible.
>>
>> But this has consequences ,for the NAGIOS operator, which must be
>> aware of the fact that any service
>> status in that case, may be 'time-dilatation-affected'  , and may not
>> represent the actual status of the service in current time.
>> This does not mean that such setups will be meaningless, but it depens
>> on SLA levels, w.r.t to the remote service being monitored.
>
> Ok, lets talk about, there is a permanent connection available between
> the application server and the nagios server.
>

Your intermittent connection can be handled several ways.  If you
don't mind just missing some results, and you connect often enough to
avoid stale results on the server, just let your NSCA daemon time out
when you can't connect, and hopefully when you are connected you'll
get a service check through.  If you want to set up a queuing daemon,
you'll likely write all your service checks to a file and then have
something that checks for connection (or runs at a time when you know
your server is available) that will loop through the stored checks.
If you're doing anything with performance data, include a timestamp in
your perfdata, as you're nagios timestamps will match the time
received.

> You told me, that the passive service- and hostchecks will be done by
> the applicationserver and NOT by the nagios server.
> ... I don't know how to set up this ...
>

I use passive checks throughout my setup, and 99% of them are bash
scripts started by cron.  You could use "at," or run them by hand, or
have a custom program/script that spawns them; what matters here is
that passive service (and host) checks are not initiated by the nagios
server.  You simply connect to the nagios server and tell them your
status, on your own schedule.  The nagios server will complain if you
let the services go "stale" by not updating before the freshness
threshold.

> All configurations for all hosts and services are locally stored on the
> nagios Server. How are the checks started on the application Server?
> This is my great question.
>

The checks are started by your server, nagios is not involved.  See
above comment re: cron.  Your scripts will need to know the service
name that they are updating on the nagios server, and almost nothing
else about your nagios config.  The messages sent by NSCA have the
format "$HOSTNAME\t$SERVICENAME\t$SERVICESTATEID\t$SERVICEOUTPUT|$PERFDATA"
 This gives the nagios server enough information to identify which
service on which host is being updated.

> The results will be send via NSCA from the app.server to the nagios
> server. OK. this will be another story ;-)
>

You have the right idea, here.

> Oh my god, send me a flashlight ...
>

It is pitch black. You are likely to be eaten by a grue.

> thanks
> Richard.
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> 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
>

Good luck, and I hope I have been helpful!

--Rick

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
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





More information about the Users mailing list