Search code examples
scalabilitymonitoringreal-timeamqp

Messaging Protocols - feed a middleware monitoring solution


From all the NMS(network management solutions) I've looked into, only Zenoss has a daemon to process AMQP messages (meaning my prefered one, Zabbix, is oblivious to it.)

Why is that? Is AMQP that far away from production ready? From a glance RabbitMQ 2.0 (or even ØMQ) seem to have solved most problems still standing from the Reddit May 10' test. )

AMQP scalability and generic design stand to me as an obvious choice for an efficient and agnostic NMS feeder. Is being agnostic its main flaw? Is it being ignored by existing NMS solutions because having a proprietary communication protocol makes it harder for enterprises to switch from one NMS to another?


Solution

  • So far, AMQP is an "unrealized potential" for a simple reason : there are several non interoperable versions of the protocol, which makes it very difficult for an ecosystem to emerge.

    For instance, RabbitMQ is supporting versions 0.8 and 0.9 of the protocol, Qpid C++ is implementing 0.10 so you've got no way to connect them. Hopefully, the situation should evolve positively in 2011 because the working group is closed to releasing version 1.0 of the protocol and implementers are working together to make sure that interoperability is achieved (it's a condition for marking the current version 1.0 proposal as "final"). When this happens, it should make a lot more sense for third party products to support AMQP.

    Also, you should note that having an open messaging protocol doesn't solve all the problems. In the case of a monitoring solution, it would allow various applications do communicate but it wouldn't say what are the expected information in each message or where they should be sent. That's why Qpid has developped it's own monitoring and management protocol on top of AMQP (See Qpid Management Framework)