Broker on Zwindler's Reflection

Récap’ du RabbitMQ Summit 2019

Tue, 05 Nov 2019 12:45:09 +0000

Des lapins partout, nous étions au RabbitMQ Summit !

Dimanche soir, je suis arrivé à Londres pour participer, avec deux de mes collègues, au RabbitMQ Summit 2019. Cette journée est dédiée à mon broker de messages préféré, RabbitMQ (et non ce n’est pas Kafka - ceci est un troll gratuit pour mes collègues).

Pour ceux qui n’auraient pas suivi, j’ai déjà écris quelques articles sur le sujet dont une introduction si vous débutez.

Cette journée a été l’occasion de pouvoir faire le plein de bonnes pratiques, REX, et autres protips pour optimiser nos clusters.

Keynote

Sans surprise, la keynote d’introduction était réalisée par des membres de la core team de RabbitMQ (Diana ParraCorbacho et Michael Klishin), qui ont parlé de l’actualité du Broker.

Une version majeure de RabbitMQ est sortie en octobre (la 3.8) et de nombreuses des features annoncées l’an dernier sont maintenant utilisables.

Je suis particulièrement enthousiaste à propos des quorum queues et des métriques Prometheus natives, qui sont clairement les deux stars de cette édition, avec plusieurs talks dédiés ou y faisant référence.

L’ajout de features flags pour faciliter les mises à jours (présents à partir de la 3.7.20+ ou 3.8+) est clairement un autre gros point positif. Michael Klishin a officiellement indiqué que le blue/green deployment n’était désormais plus la seule méthode supportée pour mettre un cluster à jour.

La 3.8 étant maintenant derrière nous (seulement des bugs fix sortiront à partir de maintenant), cap sur la 3.9 !

Dans les points importants, un travail va être réalisé pour rendre le core de chaque protocole identique. En effet, aujourd’hui, chaque protocole supporté par RabbitMQ est un module spécifique. Une refonte de l’UI est aussi prévue.

Dans les annonces, une version entreprise (RabbitMQ Entreprise Edition) devrait également voir le jour dans les mois qui viennent. Identique à la version communautaire dans les grandes lignes, elle intégrera des modifications supplémentaires pour faciliter l’hébergement de cluster RabbitMQ inter-connecté sur un WAN ou crossDC. Bien évidemment un support pro fera parti du package.

Le dernier point abordé, pour le futur, est le gros travail sur le “moteur de stockage” utilisé par RabbitMQ (pour la configuration et la persistance). Aujourd’hui, ce travail est réalisé par un projet annexe appelé Mnesia. Michael Klishin a insisté sur le fait que même si le code restait pertinent, la base de code était elle vieillissante.

Un nouveau projet Mnevis avait donc été lancé. Cette réécriture de 0 à pour but de mieux prendre en compte des problématiques multi DC et une meilleure reprise sur incident.

Même si Mnevis ne sera pas officiellement pas disponible pour tout de suite, (probablement pas avant la version 4) un prototype devrait être disponible avec une version modifiée de RabbitMQ. Les sources de Mnevis sont disponibles ici. On aura certainement plus d’infos au prochain RabbitMQ Summit !

Practical Advice for the Care & Feeding of RabbitMQ

La keynote passée, Gavin Roy a présenté un REX sur plus de 10 ans d’utilisation de RabbitMQ en production, avec les pièges dans lesquels lui et son équipes étaient tombés.

De soucis de code PHP qui ouvrait des connexions éphémères (coûteuses dans RabbitMQ), jusqu’à l’envoi de messages contenant des payloads (alors que AMQP propose d’ajouter des metadata), en passant par des lenteurs dues à des erreurs de configuration, le talk a été riche en bonnes pratiques (ou plutôt, mauvaises pratiques à éviter !).

Même si certaines erreurs peuvent sembler faciles à éviter (surtout avec le recul), c’est un de mes talks préférés de la journée, avec de nombreuses réflexions à venir, une fois rentré.

Prometheus Export

C’est le 2ème gros sujet de la journée. J’ai assisté à la présentation de l’ajout de métriques natives au format OpenMetrics directement dans RabbitMQ.

Un des gros soucis de l’interface de management actuelle et des métriques qu’elle expose est qu’il est nécessaire de disposer de privilèges important pour les consulter. Dans un contexte multi-équipes (ou multitenant), ce n’est pas pratique. Le second est un problème de performance. Actuellement l’interface de management (plugin de RabbitMQ) arrive parfois à saturation, nécessitant en cas de charge plusieurs dizaines de secondes à s’afficher.

Pour éviter ces soucis, certains d’entre vous utilisent peut être le rabbitmq-exporter, qui récupère les données de la management UI et les expose à Prometheus au format OpenMetrics. Cependant, ce client, tributaire de la management UI, est nécessairement également limité en cas de surcharge.

La vraie solution qui vient de sortir en 3.8 est donc l’exposition native de métriques au format OpenMetrics. Cet ajout a a priori déjà été énormément bénéfique à RabbitMQ et son écosystème, permettant de déceler plusieurs portions de code inefficientes dans le code de RabbitMQ et même dans le code de Erlang (bugs fixés depuis).

Après déjeuner, 2 talks… un peu décevant…

Les talks suivants (“Source oriented exchanges pattern to keep events in order” et “RabbitMQ MQTT versus EMQX”) ne sont pas simples à retranscrire.

Le premier était très générique, sur la façon de gérer correctement un processus nécessitant que les messages soient traités dans l’ordre.

Le second, un peu étonnant, comparait RabbitMQ avec un produit concurrent au travers du scope MQTT et sur un usecase très précis.

Quelques points que j’ai retenu :

j’ai raté un talk de Wework qui parle de sharding et qui est probablement intéressant à (re)voir (Wework’s “good enough” order guarantee, je mettrai à jour le lien)
il existe un outil appelé MZ Tool (???) qui permet de stress-tester vos infrastructures MQTT. Ce dernier peut être piloté par Ansible ou Terraform. J’ai trouvé un projet MZ-Tools qui n’a rien à voir… Je continue à chercher.

RabbitMQ at Scale

Partenaires principaux du RabbitMQ Summit, les gens de Code84 (CloudAMQP) étaient présents, en nombre ! La société est spécialisée dans l’hébergement de serveurs RabbitMQ, mais aussi de Kafka, PostgreSQL et Mosquitto en mode PaaS. La société est également connue sur son blog technique pléthorique.

Lovisa Johansson (qui a écrit la plupart des articles du blog, que je recommande chaudement) et Anders Bälter nous ont présenté le cheminement de leur société depuis 2012. En partant de simples API Heroku et de serveurs AWS, la plateforme hébergement maintenant les serveurs RabbitMQ de milliers de clients, tout en publiant des métriques, des logs, des alertes, vers la plupart des composants SaaS connus.

Ce talk a aussi été l’occasion de présenter quelques statistiques d’utilisation, notamment sur les moyennes/maximums de métriques comme le nombre de messages par secondes, le nombre de vhosts ou de policy, etc.

Feature complete: uncovering the true cost of different rabbitmq features and configurations

Le dernier talk auquel que nous avons vu a été donné par Jack Vanlightly, qui travaille maintenant chez Pivotal (l’éditeur de RabbitMQ).

Ce talk a été extrêmement riche et mérite d’être revu, à tête reposée.

Jack Vanlightly a fait une série de bench sur plusieurs types de serveurs, avec diverses compositions de producers/consumers, types d’exchanges et d’autres paramètres moins connus.

Les cas étaient parfois extrêmes, mais je pense que les différents cas qu’ils illustrent s’avéreront utiles pour tuner des comportements d’apparence anormaux dans des cas réels (quel paramètre tuner en fonction du nombre de consumers ou de la latence du réseau par exemple).

Conclusion

Malgré notre envie de rester jusqu’au bout, nous devions partir pour arriver à l’heure pour notre vol retour.

Ce RabbitMQ Summit a été l’occasion de discuter avec d’autres utilisateurs de RabbitMQ et de revoir les bonnes pratiques avec des professionnels qui en hébergent des milliers (600000 connexions actives chez CloudAMQP tout de même !).

Ça a aussi été l’occasion de voir que nous n’étions pas aussi “petits” que nous pensions dans notre usage de RabbitMQ, même si nous sommes très loin des limites de l’application dans nos cas d’usage !

Les joies du Dual Tracks ont fait que nous avons forcément raté certains talks que nous aurions voulu voir… Heureusement qu’il y aura les vidéos sur YouTube dans quelques jours/semaines !

A refaire, donc !

[Tutoriel] Shinken 2.4 sur CentOS/RHEL 7 – partie 3

Tue, 22 Sep 2015 16:32:00 +0000

Cet article fait parti d’une série d’articles (au moins 3) que je vais publier sur le sujet et que j’ai séparé pour les rendre un peu plus digestes. Je vous conseille quand même de ne pas en sauter pour bien comprendre de quoi on parle ;-) :

Les modules

L’ensemble des modules et en particulier le broker n’a donc aucun module d’activé. Or les interfaces graphiques sont gérées par des modules du broker pour ne citer qu’eux.

Les modules et shinken.io

Par convention (ce n’était pas forcément le cas dans les précédentes versions), la configuration des modules est définie dans des fichiers de configurations individuels qui seront stockés dans le sous dossier modules de /etc/shinken/.

On peut trouver les fichiers liés aux modules dans le répertoire /var/lib/shinken/modules/ (par défaut, mais vous pouvez le modifier dans le fichier shinken.cfg ou dans les « .ini » des démons).

cat /etc/shinken/modules/sample.cfg
# Here is a sample module that will do nothing :)
#define module{
# module_name module-sample
# module_type module-sample
# key1 value1
# key2 value2
ll /var/lib/shinken/modules
total 24
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_arbiter
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_broker
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_broker_external
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_poller
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_scheduler
-rw-r--r-- 1 shinkn shinkn 919 17 sept. 14:34 __init__.py

Autant dire que pour l’instant on ne peut pas faire grand chose !

C’est un choix technique qui a été fait à partir de la version 2 (si je ne m’abuse) et qui permet de n’avoir que ce dont on a vraiment besoin, ce qui est une très bonne pratique.

Pour autant, pour éviter de trop alourdir le processus d’installation de multiples modules, l’équipe a mis au point un catalogue d’extensions qui permet d’installer les modules manquants à l’aide d’une simple ligne de commande, ce qui est très pratique.

La première fois, il faut commencer par « initialise » notre Shinken 2.4, avec la commande suivante :

shinken --init

Le site shinken.io référence à date pas moins de 138 packages dont les fameux modules qui nous manquent.

Premier module : les logs comme nagios.log

Pour installer le module de log plat à la mode « Nagios », il faut installer simple-log.

shinken install simple-log
Grabbing : simple-log
OK simple-log

Pas mal hein?

Si vous avez l’erreur suivante qui apparaît, c’est que vous n’avez pas fait la commande shinken init à l’étape précédente.

shinken install simple-log
[1442761511] ERROR: [Shnken] Cannot load cli commands, missing paths or cli entry in the config
[1442761511] ERROR: [Shnken] CLI loading not done: missing configuration data. Please run --init
shinken --init
Creating ini section paths
Creating ini section shinken.io
Saving the new configuration file /root/.shnken.ini

Installer la WebUI, l’interface graphique officielle du projet

Pour installer l’interface graphique « officielle » (aka la WebUI), il faut se rendre sur la page suivante (et la documentation qui détaille sont installation sont disponibles ici).

Toutes les dépendances python peuvent être installées via pip et le fichier requirements.txt. Pour mongodb, je vous l’ai déjà fait installer un peu plus tôt donc ça devrait déjà être fait (enfin… si vous avez suivi… sinon :-p retournez à l’article précédent).

pip install -r https://raw.githubusercontent.com/shinken-monitoring/mod-webui/develop/requirements.txt
shinken install webui2
Grabbing : webui2
OK webui2

Par défaut, le fichier de configuration webui2.cfg est créé dans le dossier /etc/shinken/modules/ et les fichiers du modules ont été déposés dans /var/lib/shinken/modules/.

Pour que notre authentification par fichier htpasswd soit prise en compte, il faut dé-commenter la ligne contenant le paramètre htpasswd_file.

[Deprecated]Vous devriez aussi changer tout de suite le paramètre auth_secret dans le fichier de configuration webui2.cfg. Remplacez CHANGEME par la valeur que vous voulez.

Historiquement il fallait changer soit même le paramètre auth_secret dans le fichier de configuration mais cette option a été remplacée par un fichier autogénéré. Cette méthode est plus sécurisante car elle évite d’oublier de le faire ;-).

htpasswd_file /etc/shinken/htpasswd.users
[...]
# Authentication secret for session cookie
#auth_secret BOBLEPONGE
# ; CHANGE THIS or someone could forge cookies
auth_secret_file /var/lib/shinken/auth_secret
[...]

Pour l’instant, seule l’authentification par Apache htpasswd est activé (vu qu’on vient de le décommenter). On pourra en rajouter d’autres par la suite mais pour faire simple, on va juste y ajouter un compte pour commencer.

htpasswd -c /etc/shinken/htpasswd.users admin

Ensuite on démarre la base mongodb

systemctl enable mongod
systemctl start mongod

Câbler le tout

On a installé deux modules, mais aucun des deux n’ont été reliés au broker : ils ne seront pas utilisés au démarrage. On modifie donc la configuration du broker en conséquence.

vi /etc/shinken/brokers/broker-master.cfg
modules simple-log,webui2

Pour plus de détails sur la configuration du broker, je vous renvoie vers la page broker de la documentation officielle.

Redémarrez l’outil pour prendre en compte la modification de configuration et connectez vous à l’URL http://@IP_shinken:7767

systemctl restart shinken

Yata !

Le dashboard. Mais pour l’instant il n’y a pas grand chose !

En cas de problèmes

Par défaut, les logs sont stockés dans le répertoire /var/log/shinken/, avec un fichier par démon.

Ils sont généralement assez détaillés et on peut moduler le niveau de détails dans les fichiers de configuration des démons que j’ai présenté un peu plus tôt.

Dans le cas où la configuration (shinken.cfg et tous les autres .cfg qui en découlent) contiendrait une erreur, l’arbiter plantera au démarrage et les informations sur son plantage seront contenues dans le fichier /tmp/bad_start_for_arbiter. Ça peut être utile.

Aller plus loin

Ça y est. Votre nouvel outil de supervision fonctionne et vous disposez d’une interface graphique pour voir ce qu’il s’y passe.

Voici quelques pistes pour réellement terminer le travail que vous venez de commencer :

D’abord vous pourriez commencer par ajouter des plugins et quelques serveurs à votre configuration pour voir comment Shinken réagit quand on lui donne un peu de travail. Et pourquoi ne pas vous économiser du travail de configuration en utilisant les packs, dans ce but ultime d’automatiser toujours plus (pour travailler moins) ?
Ensuite, vous pourriez ajouter des modules à la WebUI, comme par exemple ui-graphite ou ui-pnp pour ajouter la gestion des graphes dans votre WebUI.
Enfin, vous pourriez vous pencher sur les aspects de haute disponibilité, de répartition de charge et de gestion des royaumes, histoire de répondre à des problématiques plus complexe ?