Iguane Solutions, en tant qu’expert dans l’hébergement et l’infogérance d’infrastructure IT, doit être en mesure de connaître en temps réel l’état de l’ensemble des infrastructures sous son contrôle.
Les évolutions continues des différentes couches logicielles, l’arrivée de nouvelles pratiques de développements avec la conteneurisation, les nouveaux outils de développements agiles, les pratiques DevOps génèrent de plus en plus de données à collecter et à centraliser pour agir et réagir toujours plus rapidement. La mise en œuvre de l’observabilité est la solution suivie par nos équipes techniques pour mener à bien leurs missions.
Observabilité : définition
Ce terme est une transformation en français du mot Anglais “Observability” qui désigne la capacité à observer le comportement d’un système. Pour cela, l’instrumentalisation du système est nécessaire sur les 3 piliers suivants: :
Métriques (Metrics ) : Mesure l’état de la plateforme et de ses services. Plus précisément, les métriques sont des éléments quantifiés mesurés à un instant T et à une fréquence régulière permettant de tracer des courbes d’évolution dans le temps
Journaux (Logs ) : fichier texte contenant l’ensemble des informations d’état d’une application: nouvelle connexion, message d’erreurs, message pour les développeurs. Les journaux applicatifs sont utiles pour investiguer sur les root cause des incidents en complément des métriques.
Traces (Traces) : Suivi horizontal d’une requête au sein de plusieurs applications. Pratique pour comprendre le comportement d’une application et pouvoir l’améliorer.
Un autre terme est très souvent employé dans ce contexte est : supervision (“monitoring” en Anglais). La supervision c’est l’action de suivre le comportement d’un système.
A noter que la mise en place de la collecte des traces applicatives est intrusive et peut avoir un impact non négligeable sur les performances.
En résumé :
– Observabilité: concept d’observation d’un comportement d’une application grâce à 3 éléments : les métriques, les journaux et les traces applicatives.
– Supervision : action de suivre et éventuellement alerter sur le comportement anormal d’une application ou d’un système.
Observabilité : mise en oeuvre
En 2018, notre système de supervision historique autour de Naemon et Graphite commençait à montrer quelques limites et surtout ne couvrait plus l’ensemble de nos besoins pour garantir un niveau de service optimal pour nous et nos clients. La stack devenait vieillissante et toute modification pour inclure les nouvelles plateformes était complexe. En outre, notre système ne surveillait uniquement que les métriques “systèmes” des équipements.
Pour ces raisons, nous avons acté la mise en place d’une nouvelle solution de métrologie avec le cahier des charges suivant :
- Collecter les métriques hardware;
- Collecter les métriques systèmes (vue du système sur les ressources : CPU, RAM, stockage, Réseau);
- Collecter les métriques des services nécessaires aux applications (nginx, apache, php, mysql, mongo DB, elasticsearch, Docker, Kubernetes, …);
- Collecter les journaux systèmes;
- Collecter les journaux des services;
- Contrôler la quantité et/ou cardinalité de chaque métrique;
- Système multi-tenant (isolation des clients);
- Interface de visualisation pour nous et nos clients;
- Rétention des métriques très longue voire illimité si possible.
La partie “Traces applicatives” ne fait pas partie du cahier des charges car les traces applicatives collectent des informations directement dans le code source des applications que nous hébergeons.
A l’image d’un service de PaaS (Platform as a Service), au travers de l’infogérance, nous mettons à disposition des plateformes spécifiques aux besoins de nos clients. Une plateforme regroupe la couche infrastructure, la partie système (OS + services pour les applications) et toute l’observabilité de l’ensemble Infrastructure + Système. La partie “Software” (code de l’application) demeure la responsabilité de nos clients. Toutefois sur demande dans le cadre d’un investigation ou pour la recherche d’optimisations, nous pouvons proposer au client de déployer un outil de collecte de traces applicatives pour optimiser le fonctionnement de l’ensemble de la plateforme.
Figure: Représentation des différentes couches d’une application logicielle avec leurs éléments d’observabilité respectifs.
Sur la base du cahier des charges précédent nous avions 2 options :
- Utiliser un outil d’observabilité du marché comme Datadog, Dynatrace, Splunk par exemple
- S’appuyer sur un ensemble d’outils Open Source comme Prometheus, VictoriaMetrics, InfluxDB, Grafana et développer les parties qui nous manquent.
Après une rapide étude nous sommes arrivés au tableau comparatif suivant :
La colonne “Outil à base de solution Open Source + Dev” remporte les suffrages puisque c’est l’option la plus malléable. Les développements internes nous permettent d’ajouter des besoins non présents dans les solutions open Source :
- Lier les différentes logiciels sélectionnés,
- Sécuriser les échanges (mise en place de TLS entre chaque composants)
- Isoler les clients.
- Avoir notre propre agent de collecte des métriques et des logs
Cette combinaison de solutions Open Source et développements internes est la seule qui réponde réellement à nos besoins en termes de modularité, d’intégration des métriques matérielles, une durée de rétention longue et un coût total moindre qu’une solution SaaS du marché.
Cette option nous permet aussi d’avoir le contrôle complet de la chaîne de traitement de l’information de sa génération, son traitement et son stockage.
Ce projet interne a reçu le nom de Sismology.
Architecture et Fonctionnement de Sismology
L’architecture de Sismology et sa logique de fonctionnement reste très simple :
- Agent de collecte des métriques et des logs sur tous les équipements;
- 2 appliances (redondance oblige) par organisation client : serveurs avec Prometheus (collecte des métriques) et Fluentd (collecte des logs);
- Cluster Victoria Metrics (centralisation de toutes les métriques avec identification clients pour l’isolation) et Loki (centralisation des logs);
- Au sein du cluster Victoria metrics nous avons développés 2 services pour supporter la gestion automatique et sécurisée de l’isolation des clients:
- Sismology Ingester: qui va se charger d’insérer les métriques pour un client donné en fonction des identifiants de l’appliance Sismology du client
- Sismology Selecter: qui va faire de même pour sélectionner les bonnes métriques pour l’interface de visualisation.
- Visualisation via dashboards Grafana avec une gestion par organisation client.
Figure: Diagramme de flux des métriques entre les équipements, la collecte, le stockage et la visualisation
Pour la collecte des métriques, nous avons développé un ensemble de plugins adapté à chaque type de service mesuré : système, hardware, mysql, php, apache, … Chaque agent active les plugins nécessaires uniquement sur la base des services configurés sur l’équipement.
Pour la centralisation des métriques, nous avions dans un premier temps fait le choix d’utiliser InfluxDB comme outil d’agrégation de points de métriques. Cependant nous avons fait assez rapidement face à des problématiques de performances qui se sont dégradées avec l’ajout de nouveaux équipements.
Après quelques recherches et quelques benchmarks plus poussés, nous avons choisi d’utiliser VictoriaMetrics pour l’agrégation de point, sa compatibilité avec Grafana et la possibilité de le déployer en cluster “Haute disponibilité” dans sa version OpenSource. De plus, VictoriaMetrics dispose d’une excellente capacité de déduplication et de compression de données qui s’améliore avec le temps : plus il y a de données, meilleure est la compression sans dégrader les performances. En complément, VictoriaMetrics permet aussi une gestion simple des différentes organisations et donc une isolation propre des données. Enfin, VictoriaMetrics s’intègre parfaitement avec Grafana et donc la refonte de nos dashboards de visualisation n’était pas une tâche complexe.
👉 Plus de détails technique sur notre utilisation de VictoriaMetrics : https://medium.com/iguanesolutions/sismology-iguana-solutions-monitoring-system-f46e4170447f
Pour la partie Logs, nous avons développé notre outil de collecte et centralisation des logs autour de Fluentd (collecte) et Loki (Centralisation). Loki est un outil développé par Grafana Labs et s’intègre donc parfaitement dans Grafana pour faciliter la visualisation et la navigation dans les journaux.
Figure: Diagramme de flux des journaux entre les équipements, la collecte, le stockage et la visualisation
Ce dernier point est très important car il facilite l’investigation en cas d’événement anormal. Sur un même Dashboard Grafana il est possible de voir les métriques et les logs d’un système à une période donnée.
Figure: Exemples de différents dashboards des services utilisés dans le cadre d’un site e-commerce (sur base de Magento)
Exemple: en cas d’erreur HTTP sur un serveur web, il est possible d’avoir sur un même écran l’évolution des erreurs et les journaux correspondants.
Nos équipes Supports et Experts économisent donc un temps précieux lors de tout événement anormal ou incident.
Day to Day
Nous avons là une solution modulaire et sécurisée pour collecter et centraliser les métriques et les logs de toutes les plateformes. Grâce à ces données nous avons pu développer un outil de supervision efficace.
Cet outil de gestion des alertes directement intégré à Sismology nous permet, selon des critères définis par nos Experts DevOps, de déclencher le support ou l’astreinte à toute heure. Notre alert manager est connecté à PagerDuty (déclenchement du support) ainsi qu’à Slack où nous recevons toutes les notifications en temps réel de toutes les alertes de toutes les plateformes. Ainsi nous pouvons réagir immédiatement quelque soit la nature de l’alerte et résoudre au plus vite toute anomalie.
La mise en place de détection préventive d’incident ainsi que l’ajout de la détection de problèmes matériels par Seismology ont considérablement réduit leur impact sur les systèmes clients ce qui a, par conséquent, amélioré nos SLAs.
Conclusion
Pour conclure, l’observabilité est un concept très important dans la supervision du fonctionnement d’une plateforme. Pour nous c’est le cœur même de notre métier qui passe par la mise en place d’une solution fiable, efficace et adaptée à nos besoins.
Notre outil de métrologie se focalise donc sur 2 des 3 piliers de l’observabilité : les métriques et les journaux.
Avec Sismology, nous disposons donc d’un outil simple, efficace et facile à maintenir avec le strict nécessaire pour le garder le plus simple possible. Toutes nos équipes techniques contribuent à l’évolution de l’outil en ajoutant régulièrement des nouveaux plugins pour supporter un nouveau framework ou bien pour faire évoluer la collecte d’un service existant. Après plus de 4 ans d’utilisation, nous avons éprouvé de très nombreux cas d’usage et nous proposons des tableaux de bords adaptés à nos clients pour suivre très simplement le comportement de leurs plateformes.
A retenir:
- Observabilité : 3 axes pour observer le comportement d’une application: métriques, journaux, trace applicatives
- Supervision : action de surveiller le comportement des plateformes en s’appuyant sur l’observabilité
- La mise en oeuvre passe par le déploiement d’outils :
- soit des outils “clés en main” avec énormément d’intégrations : Datadog, Dynatrace, Splunk…
- Soit des outils Open Source éprouvés avec des développements à faire pour les adapter : Prometheus, VictoriaMetrics, Fluentd, Grafana
- Sismology : solution de métrologie Iguane Solutions qui se focalise sur l’essentiel des métriques et des logs par rapport aux plateformes clients à surveiller