Redis против RabbitMQ в качестве брокера данных / системы обмена сообщениями между Logstash и elasticsearch

Мы определяем архитектуру для сбора информации журналов поставщиками Logstash, которые установлены на различных машинах, и централизованно индексируют данные на одном сервере elasticsearch и используют Kibana в качестве графического слоя. Нам нужна надежная система обмена сообщениями между грузоотправителями Logstash и elasticsearch, чтобы гарантировать доставку. Какие факторы следует учитывать при выборе Redis вместо RabbitMQ в качестве брокера данных / системы обмена сообщениями между поставщиками Logstash и elasticsearch или наоборот?

После оценки Redis и RabbitMQ я выбрал RabbitMQ в качестве нашего брокера по следующим причинам:

1. RabbitMQ позволяет использовать встроенный уровень безопасности с помощью сертификатов SSL для шифрования данных, которые вы отправляете брокеру, а это означает, что никто не будет прослушивать ваши данные и иметь доступ к вашим жизненно важным данным организации.
2. RabbitMQ - очень стабильный продукт, который может обрабатывать большое количество событий в секунду и множество соединений, не будучи узким местом.
3. В нашей организации мы уже использовали RabbitMQ и имели хорошие внутренние знания о его использовании и уже подготовленную интеграцию с chef.

Что касается масштабирования, RabbitMQ имеет встроенную реализацию кластера, которую вы можете использовать в дополнение к балансировщику нагрузки для реализации среды резервного брокера.

Мой кластер RabbitMQ Active Active или Active Passive?

Теперь о более слабом моменте использования RabbitMQ:

1. большинство поставщиков Logstash не поддерживают RabbitMQ, но, с другой стороны, лучший из них, названный Beaver, имеет реализацию, которая без проблем отправляет данные в RabbitMQ.
2. Реализация Beaver с RabbitMQ в его текущей версии немного медленна по производительности (для моих целей) и не могла обрабатывать скорость 3000 событий в секунду с одного сервера и время от времени сбой службы.
3. Прямо сейчас я работаю над исправлением, которое решит проблему с производительностью RabbitMQ и сделает грузоотправителя Beaver более стабильным. Первое решение - добавить больше процессов, которые могут выполняться одновременно, что даст грузоотправителю больше возможностей. Второе решение - изменить Beaver для асинхронной отправки данных в RabbitMQ, что теоретически должно быть намного быстрее. Надеюсь, что к концу недели я завершу реализацию обоих решений.

Вы можете следить за проблемой здесь: https://github.com/josegonzalez/python-beaver/issues/323

И проверьте запрос на перенос здесь: https://github.com/josegonzalez/python-beaver/pull/324

Если у вас есть еще вопросы, не стесняйтесь оставлять комментарии.

Redis создан как хранилище данных «ключ-значение», несмотря на наличие некоторых базовых возможностей брокера сообщений.

RabbitMQ создан как брокер сообщений. Естественно, он имеет множество возможностей брокера сообщений.

Я провел некоторое исследование по этой теме. Если производительность важна, а настойчивость - нет, RabbitMQ - идеальный выбор. Redis - это технология, разработанная с другой целью.

Ниже приводится список преимуществ использования RabbitMQ поверх Redis:

• RabbitMQ использует протокол расширенной очереди сообщений (AMQP), который можно настроить для использования SSL, дополнительного уровня безопасности.
• RabbitMQ занимает примерно 75% времени, затрачиваемого Redis на прием сообщений.
• RabbitMQ поддерживает приоритеты для сообщений, которые могут использоваться рабочими для использования первоочередных сообщений с высоким приоритетом.
• Нет никакого шанса потерять сообщение, если какой-либо воркер выйдет из строя после использования сообщения, чего нет в Redis.
• RabbitMQ имеет хорошую систему маршрутизации для направления сообщений в разные очереди.

Несколько минусов использования RabbitMQ:

• RabbitMQ может быть немного сложно поддерживать, сложно отлаживать сбои.
• Колебания имени узла или IP-адреса узла могут вызвать потерю данных, но при правильном управлении долговременные сообщения могут решить проблему.

Мне было интересно то же самое. Более ранние рекомендации разработчиков Logstash рекомендуют Redis вместо RabbitMQ ( http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized ), однако этот раздел примечаний больше не существует в текущей документации, хотя есть общие примечания по использованию брокера для борьбы с пиками здесь https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html .

Хотя я также довольно успешно использую RabbitMQ, в настоящее время я изучаю брокера Redis, поскольку протокол AMQP, вероятно, излишен для моего варианта использования журналирования.

Быстрые вопросы:

1. зачем вам брокер? Если вы используете logstash или logstash-forwarder для чтения файлов с этих серверов, они оба будут замедляться, если конвейер будет перегружен.
2. у вас есть опыт применения rabbit или redis? При прочих равных, инструмент, которым вы умеете пользоваться, - лучший инструмент.

Что касается мнений, я запустил Redis в качестве брокера и возненавидел его. Конечно, это могло быть связано с моим отсутствием опыта работы с Redis (не проблема с самим продуктом), но это было самое слабое звено в конвейере, и оно всегда давало сбой, когда мы больше всего в этом нуждались.