web-dev-qa-db-fra.com

Redis Vs RabbitMQ en tant que courtier de données / système de messagerie entre Logstash et elasticsearch

Nous définissons actuellement une architecture permettant de collecter les informations de journalisation par les expéditeurs Logstash installés dans différentes machines, d’indexer centralement les données dans un serveur elasticsearch et d’utiliser Kibana en tant que couche graphique. Nous avons besoin d'un système de messagerie fiable entre les expéditeurs de Logstash et elasticsearch pour garantir la livraison. Quels facteurs doivent être pris en compte lors de la sélection de Redis sur RabbitMQ en tant que courtier de données/système de messagerie entre les expéditeurs de Logstash et elasticsearch ou inversement?

elasticsearchredisrabbitmqlogstash
69
Salindaw

Après avoir évalué Redis et RabbitMQ, j'ai choisi RabbitMQ comme courtier pour les raisons suivantes:

  1. RabbitMQ vous permet d'utiliser une couche de sécurité intégrée en utilisant des certificats SSL pour chiffrer les données que vous envoyez au courtier. Cela signifie que personne ne va renifler vos données et avoir accès à vos données organisationnelles essentielles.
  2. RabbitMQ est un produit très stable pouvant gérer un grand nombre d’événements par seconde et de nombreuses connexions sans être le goulot d’étranglement.
  3. Dans notre organisation, nous utilisions déjà RabbitMQ et possédions une bonne connaissance interne de son utilisation et une intégration déjà préparée avec le chef.

En ce qui concerne la mise à l'échelle, RabbitMQ a une implémentation de cluster intégrée que vous pouvez utiliser en plus d'un équilibreur de charge afin d'implémenter un environnement de courtier redondant.

Mon cluster RabbitMQ est-il actif actif ou actif passif?

Passons maintenant au point faible de l’utilisation de RabbitMQ:

  1. la plupart des expéditeurs de Logstash ne prennent pas en charge RabbitMQ mais, d’autre part, le meilleur, nommé Beaver, a une implémentation qui envoie les données à RabbitMQ sans problème.
  2. L'implémentation que Beaver a avec RabbitMQ dans sa version actuelle est un peu lente en termes de performances (pour mes besoins) et n'a pas été en mesure de gérer le taux de 3000 événements/s d'un serveur et le service tombait de temps en temps en panne.
  3. Je travaille actuellement sur un correctif qui résoudra le problème de performances de RabbitMQ et rendra l’expéditeur Beaver plus stable. La première solution consiste à ajouter davantage de processus pouvant s'exécuter simultanément et donnant plus de puissance à l'expéditeur. La deuxième solution consiste à changer Beaver pour envoyer des données à RabbitMQ de manière asynchrone, ce qui devrait théoriquement être beaucoup plus rapide. J'espère que les deux solutions seront finalisées d'ici la fin de la semaine.

Vous pouvez suivre le problème ici: https://github.com/josegonzalez/python-beaver/issues/32

Et vérifiez la demande de tirage ici: https://github.com/josegonzalez/python-beaver/pull/324

Si vous avez plus de questions, n'hésitez pas à laisser un commentaire.

77
Tom Kregenbild

Redis est créé en tant que magasin de données de valeur clé malgré les capacités certaines bases du courtier de messages.

RabbitMQ est créé en tant que courtier de messages. Il a naturellement de nombreuses capacités de courtier de messages.

43
Ferhat

J'ai fait des recherches sur ce sujet. Si les performances sont importantes et que la persistance ne l’est pas, RabbitMQ est un choix parfait. Redis est une technologie développée dans un but différent.

Voici une liste des pros pour l'utilisation de RabbitMQ sur Redis:

  • RabbitMQ utilise le protocole AMQP (Advanced Message Queuing Protocol) qui peut être configuré pour utiliser SSL, couche de sécurité supplémentaire.
  • RabbitMQ prend environ 75% du temps requis par Redis pour accepter les messages.
  • RabbitMQ prend en charge les priorités pour les messages, que les travailleurs peuvent utiliser pour consommer d’abord des messages de priorité élevée.
  • Il n'y a aucune chance de perdre le message si un travailleur se bloque après l'avoir consommé, ce qui n'est pas le cas avec Redis.
  • RabbitMQ a un bon système de routage pour diriger les messages vers différentes files d'attente.

Quelques inconvénients pour utiliser RabbitMQ:

  • RabbitMQ pourrait être un peu difficile à maintenir, difficile à déboguer les collisions.
  • les fluctuations nom-nœud ou nœud-ip peuvent entraîner une perte de données, mais si elles sont bien gérées, des messages durables peuvent résoudre le problème.
37
Arun Reddy

Je me suis demandé la même chose. Les précédentes recommandations de Logstash recommandaient Redis plutôt que RabbitMQ ( http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized ), mais cette section de la note n'existe plus dans la documentation actuelle bien qu'il y ait des notes génériques sur l'utilisation d'un courtier pour traiter les pointes ici https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html .

Bien que j'utilise également assez heureusement RabbitMQ, je suis en train d'explorer un courtier Redis, car le protocole AMQP est probablement excessif pour mon cas d'utilisation de la journalisation.

4
opennomad

Questions rapides à poser:

  1. pourquoi avez-vous besoin d'un courtier? Si vous utilisez logstash ou logstash-forwarder pour lire les fichiers de ces serveurs, ils ralentiront tous les deux si le pipeline est encombré.
  2. avez-vous de l'expérience dans l'administration de lapin ou de Redis? Toutes choses étant égales par ailleurs, l'outil que vous savez utiliser est le meilleur.

Dans le domaine des opinions, j'ai couru Redis en tant que courtier et je l'ai détesté. Bien sûr, cela aurait pu être mon inexpérience avec Redis (ce n’était pas un problème avec le produit lui-même), mais c’était le maillon le plus faible de notre portefeuille et nous avons toujours échoué lorsque nous en avions le plus besoin.

3
Alain Collins