RFC: Nagios + AMQP

[Thomas Guyot-Sionnest]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

First of all with the new Wiki here's the new URL:

http://community.nagios.org/wiki/index.php/Nagios_AMQP

Frost, Mark {PBG} wrote:
> 
>> -----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.

Ok, although I still have some difficulties towards implementing that.
Maybe I wasn't looking at the right place because I had hard time
finding C, Python or Perl API's for JMS. C would be a requirement to
integrate into Nagios, and I'd need Perl or Python API's for writing a
POC. With AMQP I have up to date API's for both C and Python (from
Apache Qpid) that can talk 0-8, 0-9 and 0-10.

If anyone could point me in the right direction I'll be more than happy.
I'm just not going to write a C implementation of JMS from stratch if I
can use AMQP APIs directly :).

> 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.

AMQP is an emerging standard; the final v1 spec isn't even finished yet.
However there's already a handful of AMQP brokers available and the
standard is being pushed by a consortium of many big companies as a
replacement for big proprietary messaging platform.

The wiki page provides a few links about AMQP if you'd like to dig more.

> 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 would like to keep all existing functionality - *MQ is not something
small users will want to play with. I do think however that there would
be a huge benefit in large-scale and highly distributed installations.

I have the following things in mind already (some of these would be only
meaninfull with messaging supported directly by Nagios):

* An NRPE-like (or DNX-like depending on how you see it) daemon for
executing checks. It could eventually end up straight to the servers
(especially is they have their own broker already) but would also be the
main Nagios plugin executors.

* A nsca daemon sending messages instead of writing to the pipe

* A send-nsca compatible program to send messages (check results and
also Nagios commands)

* Possibly a daemon receiving messages and writing them down to the pipe
(to habe a non-MQ Nagios receive messages).

> 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 performance improvement is in regard to running checks. What if
nagios could concentrate solely on scheduling checks and interpreting
results, and you could have an army of plugin executors monitoring a
huge distributed network.

> 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.

Exactly. Using AMQP, you can have the various tools write to standard
queues and manage these queues within the AMQP brokers (where to route
them, destination queues, etc...).

> 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.

You could also keep up a hot-standby server around using this. For
plugin-execution, you could have multiple consumers (plugin execution
servers) that empty a single check queue. If one of them die the others
will keep up with the checks to execute, so you gain both load-balancing
and redudancy. Finally with AMQP it would also be possible to route
checks to the nearest execution server, so you have a distributed setub
by having multiple execution server rather than multiple Nagios instances.

A remote web interface could also use messaging to control a Nagios daemon.

- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJQph06dZ+Kt5BchYRAr9YAKDJz07o2Q0yTP0A/z6p8Jg5HqMjOACgtIzT
h68PeEw4ZTzVXyVSFr68A60=
=618v
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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/