Re: [Nagios-devel] RFC: Nagios + AMQP
Posted: Fri Dec 12, 2008 5:00 pm
-----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:[email protected]]
>> 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 mor
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
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:[email protected]]
>> 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 mor
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]