Fwd: How to request. Using send_nsca to report from remote host(s).

[Arno Lehmann]

Hello,

On 5/26/2006 7:17 PM, Tiernan, Michael C. wrote:
>>-----Original Message-----
>>From: Morris, Patrick [mailto:patrick.morris at hp.com] 
>>Sent: Friday, May 26, 2006 11:42 AM
>>To: Tiernan, Michael C.; nagios-users at lists.sourceforge.net
> 
> 
>>Since you're using nsca, you'll want to set it up as a 
>>passive service.
> 
> Thank you very much for your help with all of this.
> 
> I think I'm finally seeing my confusion here. Let's see if I can state
> what I think is going on:
> 
> 1) I have a Nagios host. It collects data, displays webpages, sends
> alerts.
> 2) I have a remote host that I wish to have report to the Nagios host on
> some system value on a regular basis.
> 
> It seems that what I'm reading assumes that:
> A) The Nagios host has a full installation. (No surprise there.)
> B) The remote host has *almost* a full Nagios installation but doesn't
> display webpages or alerts.
> 
> Is this correct? Why do I ask? I was under the assumption (yea yea, I
> know) that the remote host could use any program or script to generate
> an output that conforms to the message standard (one of the included
> plugins or a roll-your-own widget). It then hands this message to
> "send_nsca", which is almost the only piece of Nagios that is available
> on the remote host, where the message will be magically transported to
> the Nagios host where, once queued with other messages in the command
> pipe, will be interpreted by Nagios who then understands that the
> message it got is connected to a host or service that it knows about but
> doesn't control.

our assumption was correct, I'd say.
It is _also_ possible to have a full nagios installation on the remote 
host for different reasons (one being a more adaptive scheduling of 
checks, one other the ability to check other hosts - think firewalled 
systems etc.), but that's not exactly necessary.

For example, I have a gateway host that has a simple cron job checking 
the number of logins once a minute and submitting that via NSCA to the 
central nagios host and voilà - you've got part of a simple IDS.

> On the simplest level, if I run 'check_load -w# -c#' on a remote host
> and send it, via send_nsca, to the Nagios host, how does the nagios host
> know what to do with that message? It seems, from what I can glean from
> the docs (aka TFM) that I'll tell the Nagios host that there's a service
> on a host:
> define service {
>    host_name              remote.host.fqdn
>    service_description    load-check-on-remote.host
>    check_command          <- Question "a"
>    active_checks_enabled  0
>    passive_checks_enabled <- Question "b"
>    check_period           <- Question "c"
>  .......
> }
> 
> a) How do you tell it what the check_command is when the command is
> remotely run?

You don't. Usually, you either set up a command like check_dummy to be 
run only when passive check results don't come in in time, and that 
would trigger a critical state or a warning or an unknown - whatever 
you'd need. In my example above, I obviously have the service go 
critical as soon as there's a login. In other cases an unknown state 
will be sufficient.

> b) Passive checks enabled, I assume that's '1'?

Should be...

> c) check_period (and other required values) What goes here? What does
> Nagios need to know about a remote host's data collector?

Basically, the host name and service name your central Nagios and your 
submitted result use must match. The rest depends on your needs. The 
important thing is - but that's also explained in the manual - that 
Nagios runs the active check, even when disabled in the service 
configuration, when the passive check results become stale.

If you enable active and passive checks, AFAIK Nagios will not only 
accept passive checks but also run active checks. This is most 
definitely not what you want when you have a check command that riggers 
an immediate critical state...

> Can you see the confusion?

I can, and I can assure you that, at least for me, reading and 
re-reading the corresponding manual sections thoroughly helped a lot ;-)

> Again, thank you for helping me with this.

Well, I hope I could help clarify the base of your confsion a little.

Arno


> 
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> 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
> 

-- 
IT-Service Lehmann                    al at its-lehmann.de
Arno Lehmann                  http://www.its-lehmann.de



-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid7521&bid$8729&dat1642
_______________________________________________
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