[Nagios-users] Nagios client merge NSCA/NRPE

Hans Engelen engelenh at gmail.com
Wed Nov 5 18:31:44 CET 2008


Again, I totally agree. In my opinion it makes a lot of sense. Not
just for passive checks either. For instance with many of the Log4*
implementations out there one can do almost anything with the
appenders including turning them into JMS messages. Maybe not the best
example but you get my drift. As messaging is fast becoming (if it
isn't already) a standard thing in the world of corporate applications
adding messaging to Nagios brings the two a little bit closer.

We use for instance Ab Initio (a data processing tool that provides a
programming platform to automate data translation between unrelated
third party applications) here which is pretty hard to monitor (other
then the basics), with a messaging system like IBM MQ in the mix that
problem evaporates quickly since Ab Initio can handle MQ Queues just
fine. Where before one had to parse gigantic log files to traceback
errors, now all it takes is for the Ab Initio graph to just provide
the feedback directly on an MQ Queue. On the nagios server a consumer
dumps it in the external command file again.

I also see possebilities for active checks as I mentioned. Especially
with check distribution systems as seen in DNX.

Other benefits are that EMS systems are easier to tunnel through
things like firewalls and have often got clustering abilities too.

The only downside I see is that it is an extra application to install
and manage and depending on your choice is possibly a commercial
application. Then again I am guessing many corporations already have
an EMS. And also as you mention most EMS have JMS support which would
make the whole thing vendor agnostic (nice term). Where needed one
could always use things like stomp to go even further in the
abstraction.

Cheers,
Hans

On Wed, Nov 5, 2008 at 5:02 PM, Frost, Mark {PBG} <mark.frost1 at pepsi.com> wrote:
>
> 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=/
> _______________________________________________
> 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