BL MOM et RabbitMQ
L'interopérabilité est l'un des principaux défis de l'ingénierie des systèmes d'information d'entreprise. Le manque d'interopérabilité entre les applications et leurs sous-systèmes est un problème critique qui peut affecter la qualité globale du service. L'interopérabilité des données est mise en œuvre par des systèmes de transport et d'échange de données, ces derniers devant être fiables et sécurisés pour garantir un haut niveau d'interopérabilité.
BL MOM (Message Oriented Middleware) est une API développée par Berger Levrault comme un des moyens de mettre en place des échanges de données entre les applications communicantes BL et avec des applications externes. BL MOM est une API basée sur la messagerie, ce qui signifie que les données sont véhiculées sous forme de messages. L'envoi et la réception des messages sont gérés en établissant un modèle de communication de type "publish/subscribe" permettant aux applications d'être faiblement couplées. Pour ce faire, BL MOM utilise la fonction Protocole AMQP avec le soutien de RabbitMQ qui met en œuvre les concepts de ce protocole :
- Exchange : une entité nommée qui reçoit les messages des éditeurs et les achemine vers les files d'attente.
- File d'attente : une entité nommée qui conserve les messages jusqu'à ce qu'ils soient consommés.
- Clé de routage : une adresse virtuelle qu'un échange peut utiliser pour acheminer les messages vers les files d'attente.
- Liaison : assure le lien entre les échanges et les files d'attente, met en œuvre une stratégie de routage.
- Publisher : une application cliente qui publie des messages vers des échanges.
- Consommateur : une application cliente qui s'abonne aux échanges et reçoit des messages des files d'attente.
- Message : un message est composé d'un en-tête et d'un corps. L'en-tête contient les propriétés du message présentées dans un type de format spécifique. Le corps ou charge utile est constitué des données de l'application en transit, également présentées dans un type de format spécifique.
Il existe plusieurs types d'échanges. BL MOM utilise des échanges de thèmes, en mode fanout. Cela crée un réseau d'éditeurs et de consommateurs qui partagent et accèdent aux données sur un sujet commun. Cette distribution permet aux applications de fonctionner en s'appuyant sur les données d'autres applications, où qu'elles se trouvent et quel que soit leur mode de déploiement (sur site / dans le nuage).
RabbitMQ est donc utilisé par BL MOM comme infrastructure sous-jacente qui transporte et gère le routage des messages. RabbitMQ est un courtier fiable qui offre de hautes performances et une grande disponibilité. Il permet de mettre en place des interactions robustes et de gérer des architectures d'interopérabilité évolutives et configurables dans un environnement en constante évolution avec de multiples interactions.
Nécessité de moyens de contrôle
L'interopérabilité est une contrainte qui doit être prise en compte lors de la conception et du développement de systèmes communicants et que les systèmes d'information modernes doivent vérifier. Les méthodes d'évaluation de l'interopérabilité prennent en compte les obstacles qui empêchent les entreprises et les systèmes d'interopérer. Cependant, même si ces barrières sont surmontées et que des moyens d'interopérabilité sont mis en place, les systèmes sont en constante évolution : les processus, les interfaces peuvent changer, ce qui peut affecter la manière dont l'interopérabilité est menée. Dans le cas de notre utilisation de RabbitMQ, les propriétés qui ont été mises en place pour effectuer la publication et la consommation de messages (schémas de messages, informations d'authentification...etc.) peuvent être modifiées, entraînant l'interruption des canaux de communication. C'est pourquoi il est important de garder une trace des échanges et de prévoir des moyens de surveillance et d'alerte pour faciliter la maintenance du système d'échange de données.
On peut vouloir s'appuyer sur la console de gestion de RabbitMQ car elle fournit des informations sur la structure du système de messagerie et l'état des messages. Elle présente des listes de ressources existantes (canaux, échanges, files d'attente, etc.), leurs caractéristiques, ainsi qu'un ensemble de statistiques. Il est, par exemple, possible de vérifier s'il y a des messages en attente dans une file d'attente. Cependant, la console ne peut être utilisée que pour vérifier la situation actuelle du courtier, sans historique des événements précédents et sans système d'alerte. Elle ne permet pas non plus d'effectuer des requêtes et des filtrages avancés sur les ressources, ce qui est particulièrement nécessaire en cas d'échanges d'interopérabilité multiples avec plusieurs files d'attente. Ceci rend la maintenance des interactions d'interopérabilité de plus en plus lourde et l'analyse des dysfonctionnements difficile pour les administrateurs qui doivent consulter plusieurs fichiers de logs pour analyser la situation et qui préféreraient être avertis avant que le dysfonctionnement n'impacte les clients. Par conséquent, nous avons travaillé à fournir des moyens de surveillance qui ne sont pas offerts par la console de gestion RabbitMQ. Notre objectif est de superviser RabbitMQ : collecter des informations sur le système d'échange de données existant et proposer des indicateurs, des requêtes et des visualisations.
Surveillance avec Prometheus et Grafana
La solution proposée est basée sur deux outils proéminents à code source ouvert : Prometheus et Grafana. Prometheus est une boîte à outils de surveillance fournie avec une base de données de séries temporelles intégrée pour stocker les données collectées. Ces dernières peuvent être représentées comme une liste de métriques nommées et horodatées, chacune consistant en un ensemble d'étiquettes (paires clé/valeur) qui spécifient les propriétés des variables surveillées.
Par exemple, le nombre total de messages publiés vers un échange donné dans un cluster donné et l'hôte virtuel est formaté dans la métrique suivante :
- exchange_messages_publiés_en_total{cluster="rabbit@CSLSAASRBS1″, vhost="/",exchange="consoleSaasClientContract"} 45
Prometheus fournit également un langage d'interrogation simple : PromQL et quelques moyens de base pour visualiser les données. Pour une visualisation plus avancée, nous utilisons Grafana. Il s'agit d'un système de visualisation de métriques et d'alerte largement utilisé qui prend en charge Prometheus et son langage de requête, ainsi que plusieurs autres sources de données telles que InfluxDB, ElasticSearch, etc.
Prometheus est un système basé sur l'extraction qui extrait activement les valeurs des métriques d'un point de terminaison conforme à son format. Cela signifie que pour surveiller un système, nous devons fournir un point de terminaison HTTP exposant les métriques surveillées. Prometheus scrape alors périodiquement le point final. Depuis que nous avons travaillé sur Surveillance de RabbitMQ, Rabbitmq a publié en octobre 2019 une amélioration de ses possibilités de surveillance avec un support intégré pour Prometheus. Ainsi, il fournit désormais un point de terminaison avec un ensemble de métriques Prometheus.
Ces mesures couvrent un ensemble d'informations très utiles qui répondent à certains de nos besoins de suivi, tels que :
- Utilisation du disque et de la mémoire du nœud RabbitMQ et santé des nœuds du cluster RabbitMQ
- Indicateurs globaux sur le nombre de ressources existantes, de messages, et leurs types
- Compteur de certains événements comme la création ou la suppression de ressources.
Néanmoins, ces événements ne sont pas spécifiques aux ressources. Nous ne pouvons pas, par exemple, savoir quelle file d'attente a été supprimée et par quel utilisateur. En plus de cela, il n'y a pas de support pour les événements liés aux utilisateurs, permissions, vhosts et autres éléments de la structure RabbitMQ. Nous avons, par conséquent, entrepris le développement d'un exportateur Prometheus pour couvrir plus de besoins de surveillance.
Notre exportateur RabbitMQ Prometheus tire parti de l'outil de gestion de la qualité de l'eau. plugin d'échange d'événements qui pousse plusieurs événements : création et suppression de ressources, d'hôtes virtuels, d'utilisateurs et de permissions ; création et fermeture de connexions et de canaux, tentatives d'authentification des utilisateurs, etc. L'exportateur est un consommateur RabbitMQ qui est abonné à ces événements. Il définit un ensemble de métriques Prometheus et les incrémente chaque fois qu'un événement se produit. Une fois déployé, l'exportateur fournit un nouveau point de terminaison Prometheus avec un ensemble de nouvelles métriques. Les métriques sont fournies avec toutes les informations disponibles pour aider les administrateurs lors des activités de maintenance.
Pour exploiter ces métriques et fournir un point de contrôle unique sur les clusters RabbitMQ existants, nous avons mis en place un tableau de bord Grafana. Grafana utilise un serveur Prometheus qui scrape les deux points de terminaison Prometheus de RabbitMQ, le point natif et celui exposé par notre exportateur. Nous avons utilisé un tableau de bord Grafana fourni par RabbitMQ et l'avons étendu avec notre ensemble de métriques, de visualisations et d'alertes.
Nous alertons les administrateurs avec des notifications en temps réel sur :
- Échec des opérations (ex. messages non acquittés)
- Des taux qui dépassent les seuils acceptés
- L'apparition d'événements indésirables tels que : la suppression d'une ressource, la suppression d'un utilisateur, l'échec de l'authentification d'un utilisateur... etc.
De plus, comme Grafana prend en charge PromQL, il est possible pour les administrateurs d'interroger les métriques pour analyser une situation de manière plus détaillée. Dans l'exemple suivant, il est possible de savoir exactement quand les consommateurs des files d'attente dont le nom contient une sous-chaîne spécifique ont été supprimés.
Ce tableau de bord de surveillance RabbitMQ est utile à toute équipe qui utilise BL MOM ou RabbitMQ. Il donne une vue d'ensemble du comportement du système d'échange ; il facilite la maintenance des liens d'interopérabilité existants et l'exécution d'actions correctives si nécessaire. En outre, il renforce la fiabilité du système d'échange, améliorant ainsi le niveau de service global des systèmes concernés.
