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

Nous définissons une architecture pour collecter les informations de journal par les expéditeurs Logstash qui sont installés dans diverses machines et indexent les données dans un serveur elasticsearch de manière centralisée et utilisent Kibana comme couche graphique. Nous avons besoin d'un système de messagerie fiable entre les expéditeurs 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 Logstash et elasticsearch ou vice versa?

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 crypter les données que vous envoyez au courtier et cela signifie que personne ne reniflera vos données et n'aura accès à vos données organisationnelles vitales.
2. RabbitMQ est un produit très stable qui peut gérer de grandes quantités d'événements par seconde et de nombreuses connexions sans être le goulot de la bouteille.
3. Dans notre organisation, nous utilisions déjà RabbitMQ et avions de bonnes connaissances internes sur son utilisation et une intégration déjà préparée avec le chef.

En ce qui concerne la mise à l'échelle, RabbitMQ dispose d'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 le plus faible de l'utilisation de RabbitMQ:

1. la plupart des expéditeurs Logstash ne prennent pas en charge RabbitMQ mais d'un autre côté, le meilleur, nommé Beaver, a une implémentation qui enverra les données à RabbitMQ sans problème.
2. L'implémentation que Beaver a avec RabbitMQ dans sa version actuelle est un peu lente sur les performances (pour mes besoins) et n'a pas été en mesure de gérer le taux de 3000 événements / s à partir d'un serveur et de temps en temps le service a planté.
3. En ce moment, je travaille sur un correctif qui résoudra le problème de performance de RabbitMQ et rendra l'expéditeur Beaver plus stable. La première solution est d'ajouter plus de processus qui peuvent s'exécuter simultanément et donneront 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 je terminerai la mise en œuvre des deux solutions d'ici la fin de cette semaine.

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

Et vérifiez la demande d'extraction ici: https://github.com/josegonzalez/python-beaver/pull/324

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

Redis est créé en tant que magasin de données à valeur clé malgré certaines fonctionnalités de base de courtier de messages.

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

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 avec une intention différente.

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

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

Quelques inconvénients pour l'utilisation de RabbitMQ:

• RabbitMQ peut être un peu difficile à maintenir, difficile à déboguer des plantages.
• Les fluctuations de nom de nœud ou d'adresse de nœud peuvent entraîner des pertes de données, mais si elles sont bien gérées, les messages durables peuvent résoudre le problème.

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

Bien que j'utilise également RabbitMQ avec bonheur, j'explore actuellement un courtier Redis, car le protocole AMQP est probablement excessif pour mon cas d'utilisation de journalisation.

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 une expérience de l'administration de lapin ou de redis? Toutes choses étant égales par ailleurs, l'outil que vous savez utiliser est le meilleur outil.

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