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

Estamos definiendo una arquitectura para recopilar información de registro por parte de los remitentes de Logstash que están instalados en varias máquinas e indexan los datos en un servidor de elasticsearch de forma centralizada y utilizan Kibana como capa gráfica. Necesitamos un sistema de mensajería confiable entre los remitentes de Logstash y elasticsearch para otorgar la entrega. ¿Qué factores deben tenerse en cuenta al seleccionar Redis en lugar de RabbitMQ como agente de datos / sistema de mensajería entre los remitentes de Logstash y elasticsearch o viceversa?

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 corredor y eso significa que nadie rastreará sus datos y tendrá acceso a los datos vitales de su organización.
2. RabbitMQ es un producto muy estable que puede manejar grandes cantidades de eventos por segundo y muchas conexiones sin ser el cuello de botella.
3. En nuestra organización ya usábamos 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 agente redundante.

¿Mi clúster RabbitMQ es Activo Activo o Activo Pasivo?

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

1. la mayoría de los remitentes 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 pudo manejar la tasa de 3000 eventos / seg de un servidor y de vez en cuando el servicio fallaba.
3. Ahora mismo 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 poder al transportista. La segunda solución es cambiar Beaver para enviar datos a RabbitMQ de forma asíncrona, lo que teóricamente debería ser mucho más rápido. Espero terminar de implementar ambas soluciones a finales 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.

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 intermediario de mensajes. Tiene muchas capacidades de intermediario de mensajes naturalmente.

He estado investigando un poco 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.

A continuación se muestra una lista de ventajas para usar RabbitMQ sobre Redis:

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

Algunas desventajas de usar RabbitMQ:

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

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 picos aquí https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html .

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

Preguntas rápidas para hacer:

1. ¿Por qué necesita un corredor? Si está utilizando logstash o logstash-forwarder para leer archivos de estos servidores, ambos se ralentizarán si la canalización se congestiona.
2. ¿Tiene alguna experiencia en la administración de conejo o redis? En igualdad de condiciones, la herramienta que sabe cómo utilizar es la mejor herramienta.

En el ámbito de las opiniones, he manejado redis como corredor y lo odiaba. 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.