Redis Vs RabbitMQ como un agente de datos/sistema de mensajería entre Logstash y Elasticsearch

rabbitmq redis

Question

Estamos definiendo una arquitectura para recopilar información de registro de los remitentes de Logstash que están instalados en varias máquinas e indexan los datos en un servidor de búsqueda elástica centralmente y usan Kibana como la capa gráfica. Necesitamos un sistema de mensajería confiable entre los cargadores de Logstash y Elasticsearch para garantizar la entrega. ¿Qué factores deben considerarse al seleccionar Redis sobre RabbitMQ como un agente de datos / sistema de mensajería entre los cargadores de Logstash y el Elasticsearch o viceversa?

Answer 1

Después de evaluar tanto a Redis como a RabbitMQ, elegí a RabbitMQ como nuestro corredor por las siguientes razones:

1. RabbitMQ le permite utilizar una capa de seguridad incorporada mediante el uso de certificados SSL para cifrar los datos que está enviando al agente y eso significa que nadie detectará sus datos y tendrá acceso a sus datos organizacionales vitales.
2. RabbitMQ es un producto muy estable que puede manejar grandes cantidades de eventos por segundo y muchas conexiones sin ser el cuello de la botella.
3. En nuestra organización ya usamos RabbitMQ y teníamos un buen conocimiento interno sobre su uso y una integración ya preparada con el chef.

Con respecto al escalado, RabbitMQ tiene una implementación de clúster incorporada que puede usar además de un equilibrador de carga para implementar un entorno de intermediario redundante.

¿Mi clúster RabbitMQ está activo activo o activo pasivo?

Ahora al punto más débil de usar RabbitMQ:

1. la mayoría de los cargadores de Logstash no son compatibles con RabbitMQ pero, por otro lado, el mejor, llamado Beaver, tiene una implementación que enviará datos a RabbitMQ sin problemas.
2. La implementación que Beaver tiene con RabbitMQ en su versión actual es un poco lenta en el rendimiento (para mis propósitos) y no fue capaz de manejar la tasa de 3000 eventos / seg de un servidor y de vez en cuando el servicio fallaba.
3. En este momento estoy trabajando en una solución que resolverá el problema de rendimiento de RabbitMQ y hará que el cargador Beaver sea más estable. La primera solución es agregar más procesos que puedan ejecutarse simultáneamente y le darán más potencia al remitente. La segunda solución es cambiar Beaver para enviar datos a RabbitMQ de forma asincrónica, lo que en teoría debería ser mucho más rápido. Espero terminar de implementar ambas soluciones para fines de esta semana.

Puede seguir el problema aquí: https://github.com/josegonzalez/python-beaver/issues/323

Y verifique la solicitud de extracción aquí: https://github.com/josegonzalez/python-beaver/pull/324

Si tiene más preguntas, no dude en dejar un comentario.

Answer 2

He estado haciendo algunas investigaciones sobre este tema. Si el rendimiento es importante y la persistencia no lo es, RabbitMQ es una elección perfecta. Redis es una tecnología desarrollada con una intención diferente.

La siguiente es una lista de profesionales para usar RabbitMQ sobre Redis:

• RabbitMQ utiliza el Protocolo avanzado de colas de mensajes (AMQP) que se puede configurar para usar SSL, una capa adicional de seguridad.
• RabbitMQ tarda aproximadamente el 75% del tiempo que Redis tarda en aceptar mensajes.
• RabbitMQ admite prioridades para mensajes, que los trabajadores pueden usar para consumir mensajes de alta prioridad primero.
• No hay posibilidad de perder el mensaje si algún trabajador falla después de consumir el mensaje, que no es el caso con Redis.
• RabbitMQ tiene un buen sistema de enrutamiento para dirigir mensajes a diferentes colas.

Algunas desventajas para usar RabbitMQ:

• RabbitMQ puede ser un poco difícil de mantener, difícil de depurar.
• Las fluctuaciones de nombre de nodo o ip de nodo pueden causar la pérdida de datos, pero si se gestionan bien, los mensajes duraderos pueden resolver el problema.

Answer 3

Me he estado preguntando lo mismo. Las recomendaciones anteriores de la gente de Logstash recomiendan Redis sobre RabbitMQ ( http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized ), sin embargo, esa sección de las notas ya no existe en la documentación actual, aunque hay notas genéricas sobre el uso de un corredor para lidiar con los picos aquí https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html .

Si bien también estoy usando RabbitMQ con bastante felicidad, actualmente estoy explorando un corredor de Redis, ya que el protocolo AMQP probablemente sea excesivo para mi caso de uso de registro.

Answer 4

Preguntas rápidas para hacer:

1. ¿Por qué necesitas un corredor? Si está utilizando logstash o logstash-forwarder para leer archivos de estos servidores, ambos se ralentizarán si la tubería se congestiona.
2. ¿Tienes alguna experiencia con la administración de conejo o redis? En igualdad de condiciones, la herramienta que sabes cómo usar es la mejor herramienta.

En el ámbito de las opiniones, he ejecutado redis como intermediario y lo odio. Por supuesto, esa podría haber sido mi inexperiencia con redis (no es un problema con el producto en sí), pero era el eslabón más débil en la tubería y siempre fallaba cuando más lo necesitábamos.

Answer 5

Redis se crea como un almacén de datos de valor clave a pesar de tener algunas capacidades básicas de intermediario de mensajes.

RabbitMQ se crea como un agente de mensajes. Tiene muchas capacidades de intermediario de mensajes, naturalmente.