RFC: Nagios + AMQP

[Frost, Mark {PBG}]

>-----Original Message-----
>From: Hans Engelen [mailto:engelenh at gmail.com]
>Sent: Tuesday, December 09, 2008 11:37 AM
>To: Nagios Developers List
>Subject: Re: [Nagios-devel] RFC: Nagios + AMQP
>
>> 1. How this will affect speed? One of the biggest advantages if using
>> messaging would be speeding up the Nagios daemon, so to what extend
>JMS
>> would offset these gains? I'm thinking about systems that could
>possibly
>> run hundreds (or thousands?) of checks per second, and under the
>current
>> architecture Nagios would send check messages serially).
>
>I don't think the effect would be all that noticeable, though I must
>admit when I did my adaption I went with a native MQ mode for the
>messaging layer.
>
>The only change as I understand it for MQ at least is that you add
>some JMS defenitions on top of the native MQ objects. Without having
>tried it (we use native MQ for everything here) it sounds like it's
>just a sort of logical link that maps a JMS compatible object
>defenition to what is in reality a bog-standard MQ Queue.
>
>On the client side you would then just use a different way of talking
>to server process. Again, I briefly looked into it 2 months ago when I
>posted about it and didn't go forward it.
>
>> 2. Build/setup requirements: adding more dependencies means more work
>> required to get a MOM-enabled Nagios working.
>
>True
>
>> 3. To what extent will this be useful? Would it be possible to
>implement
>> some kind of JMS proxy to interact with other messaging platforms
>> instead? After all JMS would really be useful only to people that
>> already use a messaging platform, and I doubt there's that many among
>> Nagios users. Also unlike other messaging platform AMQP is totally
>free
>> and open.
>
>True also but I would guess that the target audience for this would be
>likely candidates to have a MOM. Or to turn the tables around, people
>with environments complex enough to need a MOM would be more
>interested in the advantages this messaging layer would add.
>
>As I said before my vision on this is tainted, of all the companies I
>work with every single one without exception has a Messaging platform,
>some even more then one. But my vision is tainted because I work in
>the financial sector and that explains why MOMs are so common to me.
>(AMQP was developed or created by JP Morgan wasn't it).
>
>Cheers,
>Hans

I would also have to throw my support behind using JMS.  Every
message-using application we use is geared towards using that as a
standard API and that's what we drive towards as an organization.  It
allows us to swap out the messaging tier with anything that's capable of
being a JMS server.  That would mean Websphere MQ, Tibco EMS, Bea
(Oracle) products, and even the free OpenMQ.

Up until this messaging thread, I'd never even heard of AMQP, but maybe
I've been living under a rock.  I've not heard of MQ support for it, for
example.

The way I'd imagined this working was that the client-side app would
still make a call out to a local binary (say a messaging 'send_nsca'
equivalent).  That binary would have a config file that told it how to
send that message to that environment's messaging tier.  It could
probably even be made argument-compatible with send_nsca if that was of
benefit.  This approach means that it's easy(er) to make working
binaries for Windows, Unix, Linux or any other tier that can build JMS
code.

I'm less interested in seeing performance improvements with this (we
don't really see performance issues with NSCA).  I also don't really
have performance concerns with messaging either as we've seen MQ
transfers can be very fast.

The benefits I can imagine are

1) That the transmission from the client and the server are decoupled.
If the server isn't available, the client doesn't have to either hold on
to the check result itself or drop the result entirely until the server
comes back.

2) The possibility for doing pub/sub.  This might be kind of a weird
scenario, but we've got a backup central monitoring server that receives
all the check output from distributed servers.  To do this, I'm sending
the data twice from the distributed nodes -- once to the on-line central
server and once to the backup.  In theory, I could have the distributed
nodes "publish" their service check results and then any authorized
Nagios server could pick the results up as long as it was subscribed to
that topic.  Put one message and multiple servers could (potentially)
receive it.

My $0.02.

Mark

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/