[Nagios-users] Nagios client merge NSCA/NRPE
Frost, Mark {PBG}
mark.frost1 at pepsi.com
Wed Nov 5 17:02:06 CET 2008
This idea is fascinating to me -- using a messaging system to return
passive check results. This would
- allow larger messages
- allow for multiplexing of checks into a single message if the Nagios
server side agent (the program that pulls messages off the queue and
turns them into check results) knows how to do that
- provide a nice way of handling check results if your Nagios server
goes offline (they'll queue up in the messaging system)
- you could potentially even do Pub/Sub with check results to allow
multiple Nagios server to "subscribe" to particular check results
- I would think you could just write some kind of simple program that
could be called on each platform (kind of a send_nsca equivalent) that
sends results to the messaging system. It's more overhead, but most
prominent messaging systems can use JMS which could make the message
layer mostly vendor agnostic
I too have struggled with NSCA but in my case, it's about sending output
from my distributed servers to the central server(s). I ended up having
to write my own send_nsca batching-daemon to transfer more efficiently
(and reliably). I have 2 running -- one to send to my primary Nagios
server and another to the backup.
Mark
>-----Original Message-----
>From: Hans Engelen [mailto:engelenh at gmail.com]
>Sent: Tuesday, November 04, 2008 10:12 AM
>To: nagios-devel at lists.sourceforge.net
>Subject: Re: [Nagios-devel] [Nagios-users] Nagios client merge
>NSCA/NRPE
>
>Slightly confused on what it is you need here.
>
>Personally I never really liked NSCA, as for NRPE it's better but
>still has issues (such as manual work is needed to configure and set
>up the checks on the remote end). I think this is similar to what you
>are saying.
>
>I must admit I have been playing with some ideas along those lines
>myself lately but for me the more urgent priority was to get NSCA out
>of the mix. I chose to go with an EMS (enterprise messaging system) as
>my means of communication. Currently I have a few passive checks
>running as that. Because of the somewhat exotic software we have
>running I usually end up coding my own passive checks and I wanted to
>get rid of having to fork out to send_nsca. The main reason being that
>I needed more feedback on the actual submission of the check results
>(loosing the check results on something that runs but once per day is
>a pretty big thing for me) to make sure the submission was successful.
>
>As such I am currently using IBM Websphere MQ to handle the messaging
>back and forth.
>
>Next on my list was NRPE, although I am still thinking that through
>since there is far more to take care of. Part of that would be pushing
>out updated plugins to the remote host.
>
>By the way, why IBM Websphere MQ, simple, it has api's for almost
>every programming language I use (in fact all of them).
>
>On the Nagios side I am currently using a fairly simple perl script
>(currently cronned) that feeds back into the external command file
>though I might go with an actual module that hooks into the nagios
>process later if the need arises (although I don't really want to if I
>can help it).
>
>Cheers,
>Hans
>
>On Mon, Oct 20, 2008 at 3:02 PM, Bo Philip Larsen
><boph at tdchosting.dk> wrote:
>> I need to find a client to use with nagios, it should be
>using passive
>> communication like "nsca", it also should use standard
>nagios plugins and be
>> configured with an nrpe.cfg like syntax it would be nice if
>each service
>> check could be scheduled individual in the client configfile
>without using
>> cron.
>>
>>
>>
>> The client will be used on various *nix systems
>>
>>
>>
>> Does anyone know if that type of client exists or have
>anyone a clue or
>> interest in developing this ?
>>
>>
>>
>> The background: we are using nagios in a distributed network
>with nrpe on
>> 1000+ hosts and a company merges have given us 2000+ hosts more using
>> various monitoring systems like bigb using passive
>communication and the
>> active communication is on an option for now. We are using nagconf
>> (http://nagconf.naguser.dk) as configtools and would like to
>be able to
>> config/manage the monitoring on all servers and clients from
>a central site.
>>
>>
>>
>>
>>
>> Regards
>>
>>
>>
>> Bo
>>
>>
>>
>>
>---------------------------------------------------------------
>----------
>> This SF.Net email is sponsored by the Moblin Your Move
>Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK &
>win great
>> prizes
>> Grand prize is a trip for two to an Open Source event
>anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> 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
>>
>
>---------------------------------------------------------------
>----------
>This SF.Net email is sponsored by the Moblin Your Move
>Developer's challenge
>Build the coolest Linux based applications with Moblin SDK &
>win great prizes
>Grand prize is a trip for two to an Open Source event anywhere
>in the world
>http://moblin-contest.org/redirect.php?banner_id=100&url=/
>_______________________________________________
>Nagios-devel mailing list
>Nagios-devel at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
More information about the Developers
mailing list