消息传递协议 - 提供中间件监控解决方案
从我研究过的所有 NMS（网络管理解决方案）来看， 只有 Zenoss 有一个守护进程来处理 AMQP 消息（这意味着我最喜欢的 Zabbix 没有注意到它。）
这是为什么呢？ AMQP 距离生产准备就绪还有那么远吗？ 乍一看RabbitMQ 2.0（甚至ØMQ）似乎已经解决了 Reddit 5 月 10 日测试中仍然存在的大多数问题。 )
在我看来，AMQP 可扩展性和通用设计是高效且不可知的 NMS 馈送器的明显选择。 不可知论是其主要缺陷吗？ 现有的 NMS 解决方案是否会因为拥有专有通信协议而使企业更难从一种 NMS 切换到另一种 NMS 而忽略它？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
到目前为止，AMQP 仍处于“未实现的潜力”，原因很简单：该协议存在多个不可互操作的版本，这使得生态系统的出现非常困难。
例如，RabbitMQ 支持该协议的 0.8 和 0.9 版本，Qpid C++ 正在实现 0.10，因此您无法连接它们。希望 2011 年情况能够积极发展，因为工作组即将发布该协议的 1.0 版本，并且实施者正在共同努力确保实现互操作性（这是将当前 1.0 版本提案标记为“最终”版本的一个条件） 。当发生这种情况时，第三方产品支持 AMQP 应该更有意义。
另外，您应该注意，拥有开放的消息传递协议并不能解决所有问题。在监控解决方案的情况下，它将允许各种应用程序进行通信，但它不会说明每条消息中的预期信息是什么或它们应该发送到哪里。这就是为什么 Qpid 在 AMQP 之上开发了自己的监控和管理协议（请参阅 Qpid 管理框架)
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)