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} 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:[email protected]]
>>Sent: Tuesday, November 04, 2008 10:12 AM
>>To: [email protected]
>>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 r
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]