Протоколы обмена сообщениями - напишите решение для мониторинга промежуточного программного обеспечения - PullRequest
1 голос
/ 26 января 2011

Из всех NMS (решений для управления сетью), которые я изучал, только у Zenoss есть демон для обработки сообщений AMQP (то есть мой любимый Zabbix не обращает на это внимания).

Почему это? AMQP так далеко от производства готов? С первого взгляда RabbitMQ 2.0 (или даже ØMQ ), похоже, решил большинство проблем, которые все еще остаются в тесте Reddit 10 мая. )

Масштабируемость AMQP и универсальный дизайн являются для меня очевидным выбором для эффективного и независимого устройства NMS. Является ли агностик своим главным недостатком? Это игнорируется существующими решениями NMS, потому что благодаря проприетарному протоколу связи предприятиям сложнее переключаться с одной NMS на другую?

1 Ответ

1 голос
/ 06 марта 2011

Пока что AMQP является «нереализованным потенциалом» по простой причине: существует несколько не совместимых версий протокола, что очень затрудняет появление экосистемы.

Например, RabbitMQ являетсяПоддерживая версии 0.8 и 0.9 протокола, Qpid C ++ реализует 0.10, поэтому у вас нет возможности их соединить.Надеемся, что в 2011 году ситуация должна развиваться положительно, потому что рабочая группа закрыта для выпуска версии 1.0 протокола, а разработчики работают вместе, чтобы обеспечить достижение совместимости (это условие для обозначения текущей версии 1.0 как «окончательной»),Когда это происходит, сторонним продуктам должно иметь больше смысла поддерживать AMQP.

Кроме того, следует помнить, что наличие открытого протокола обмена сообщениями не решает всех проблем.В случае решения по мониторингу это позволило бы различным приложениям обмениваться данными, но не сообщало бы, какую информацию ожидают в каждом сообщении или куда их следует отправлять.Вот почему Qpid разработал свой собственный протокол мониторинга и управления поверх AMQP (см. Qpid Management Framework )

...