Lors du 1er article de cette saga consacrée au monitoring, vous avez surement remarqué que nous n’évoquons pas d’outils de monitoring mais des solutions de monitoring. La première erreur à éviter lors de la mise en place de monitoring est de chercher un outil au lieu de réfléchir sur ses besoins. Il est primordial de bien comprendre les différents types de monitoring existants car ils ne sont pas couverts par tous les outils.
Type de monitoring
Les applications de monitoring peuvent être matérialisées en 4 catégories :
- Exploitation de Log : Outil permettant de centraliser les logs applicatifs et d’offrir des fonctionnalités avancées de recherche.
C’est la base du monitoring, il faut pouvoir rechercher dans les logs de tous les services au travers d’une interface unique sans avoir à se connecter à différent serveurs. Par exemple, pour retracer l’activité d’un utilisateur, l’outil d’exploitation de log doit pouvoir vous permettre de filtrer sur l’identifiant de l’utilisateur et ainsi retracer son parcours au travers des différents services.
A titre d’exemple d’outil existant, la suite Elastic (ElasticSearch Logstash Kibana) est populaire.
- Collecte de métriques : Il s’agit de pouvoir collecter les nombreuses métriques que sont capables de renvoyer les différentes couches du système, du hardware aux métriques métiers. Par exemple : la charge CPU, la mémoire utilisée, l’espace disque libre, les pools de connections http ou de base de données, le nombre de requêtes par secondes, le nombre d’appel à une fonctionnalité métier, etc.
Des outils se sont spécialisés tel que Prometheus pour collecter et restituer rapidement ces données aux formats particuliers composés du couple valeur numérique et temps. Nous pourrons utiliser Grafana pour la visualisation et la création de dashboard.
- APM : APM signifie Agent Performance Monitoring. Cet outil de monitoring avancé va être embarqué dans le runtime d’exécution de l’application. De ce fait, il a la possibilité de surveiller tout ce qu’il se passe durant l’exécution des traitements : combien de temps s’écoule dans une méthode, l’allocation mémoire utilisée, les requêtes SQL, etc. De nombreux outils existent avec une tarification très variée. Un APM est spécifique à la technologie de votre application, par exemple si celle-ci est en java, vous devrez prendre un APM conçu pour du java. Par leur nature, les APM sont aptes à fournir les autres types de monitoring tel que le tracing et les métriques.
- Tracing : Un incontournable pour les architectures micro-services, c’est un outil de monitoring de trace permettant de suivre le flux de traitement au travers des applications. Un peu comme un side-car qui va suivre le traitement partout où il passe pour collecter les données et ainsi pouvoir restituer la trace complète du traitement, même si celui-ci est passé par une dizaine d’applications différentes, contrairement à un APM qui va se limiter au périmètre de l’application (à noter, que certains APM avancés supportent aussi le tracing). Nous pourrons par exemple collecter la trace d’un traitement utilisateur, depuis le clic sur le bouton de l’interface graphique jusqu’au dernier micro-service appelé.
L’objectif est de conserver la trace même si la technologie des applications est différente en propageant un contexte. Ce type de monitoring est assez récent et des standards sont en train d’émerger comme OpenTracing/OpenTelemetry pour assurer la comptabilité cross-technologie.
Les leaders sur le marché du monitoring investissent massivement sur l’intelligence artificielle pour faciliter l’identification de la source du problème. Nous parlons alors de AIOps caractérisé par l’utilisation d’intelligence artificielle (AI) pour résoudre des problèmes d’IT Ops Les retours du Gartner sont d’ailleurs prometteurs sur cette nouvelle avancée.
Il existe des outils de monitoring tels que notre partenaire Dynatrace qui sont capables de couvrir ces différents types de monitoring, mais ils peuvent très vite s’avérer onéreux. Une autre voie est alors de construire sa propre stack d’outils de monitoring en se basant sur des solutions libres d’utilisation tels que Prometheus, Grafana, ELK, Jaeger (Tracing). Cette approche vous demandera de faire évoluer votre code pour exposer les métriques et bien sûr configurer et installer ces nouveaux outils. En résumé, monitorer les applications demandera soit un investissement financier pour l’acquisition d’outil clef en main, soit du temps pour la mise place d’outil sur mesure.
Maintenant que vous avez la vue globale sur les différents types de monitoring, se pose la question de savoir quoi faire de toutes ces informations collectées ?
S’organiser autour du monitoring
Vous voilà avec vos applications monitorées et vous collectez plusieurs milliers donnés à la minute : des logs, des métriques, des traces, des stacktraces, etc…
La première étape est de concevoir des dashboards pour centraliser cette information. Cette étape n’est pas aussi simple qu’il n’y parait et elle est cruciale pour investiguer rapidement en cas de problème. Il faut savoir que beaucoup de métriques collectées vont être obscures ou mal comprises. Il est essentiel de réaliser des dashboards les plus clairs possible en mettant des noms de graphiques compréhensibles et en complétant au mieux leurs descriptions. Nous sommes souvent amenés à transformer les métriques pour les rendre plus assimilables et compréhensibles. Une métrique comme le compteur de requête http va être transformée en taux pour afficher le nombre de requêtes à la seconde. Il est parfois intéressant de combiner plusieurs métriques. A titre d’exemple, je me suis vu combiner plusieurs métriques du pool de connexion pour afficher de façon synthétique et visuelle l’état du pool de connections : une valeur négative montre combien de connections sont en attente.
Plusieurs approches sont possibles pour définir le contenu et le périmètre du dashboard. Pour les métriques, j’ai opté pour une approche avec 2 types de dashboard, les spécifiques par composant et les globaux.
Les dashboards spécifiques regroupent des métriques issues du même composant. Nous aurons par exemple un dashboard pour afficher les métriques du protocole http et un autre pour celles des connexions pool de base de données. Il est aussi envisageable d’avoir des dashboards pour des métriques de composants métiers tel que le nombre d’annulation et de validation d’un formulaire.
Les dashboards globaux sont importants pour avoir une vue synthétique de l’état de la production. C’est le premier dashboard que vous allez voir quand vous recevez un coup de fil vous informant que la production est devenue lente. Le choix des métriques à afficher doit être pensé intelligemment afin de conserver une vue globale la plus légère et la plus ergonomique possible. Il y a quelques métriques incontournables comme le CPU, mais là plus part du temps, il faudra les adapter en fonction du type de technologie et du fonctionnement de l’application. Des applications web avec de nombreux utilisateurs actifs auront tendance à saturer au niveau du nombre de requête http et il sera donc important de monitorer leur nombre actif. A l’inverse, une application de gestion avec un faible nombre d’utilisateur mais avec de lourds traitements risque plus facilement de saturer le nombre de connexion à la base de données. Les métriques utilisées dans les dashboards globaux vont être les premières à être branchées sur des alertes afin de ne pas avoir à les surveiller en permanence.
A savoir, il peut s’avérer intéressant d’utiliser des indicateurs comme APDEX (Application performance Index). C’est une formule mathématique qui, à partir du temps de réponse, permet d’estimer en pourcentage la satisfaction utilisateur, 100% étant le mieux.
La deuxième étape est de mettre en place un système d’alerting pour être notifié en cas de problème. La plupart des outils de monitoring intègrent un mécanisme d’alerting au minima par email. Je préconise si possible d’utiliser celui qui héberge vos dashboards comme Grafana et non Prometheus car il simplifie la gestion des alertes en les liant avec vos dashboards.
Mettre en place une alerte est délicat et demande du temps pour la fiabiliser. En effet, il est très perturbateur de recevoir de fausses alertes parce le paramétrage du seuil de déclenchement a été configuré trop strictement. Je conseillerais d’utiliser des seuils d’alertes basés sur des périodes flottantes. Par exemple, pour une application en java, il existe une métrique mesurant le temps d’exécution du garbage collector (procès qui stoppe toutes les exécutions pour pouvoir libérer de la mémoire). Si celui-ci reste élevé pendant longtemps cela indique souvent qu’il n’arrive plus à libérer de la mémoire et que le système va crasher en OutOfMemory. Dans ce cas, il est intéressant de configurer une alerte sur la non-atteinte d’un minimum pendant une période de temps.
L’alerting ne doit pas se limiter à un simple envoi d’email. Celui-ci doit être pris en charge et traité dans les plus brefs délais. Il est préférable de formaliser le processus de prise en charge de ces alertes et de définir les actions à entreprendre.
La dernière étape concerne la formation. Les outils de monitoring doivent être facilement accessibles en lecture par le plus grand nombre. Il convient ensuite de former les dev et ops à ces outils afin qu’ils soient autonomes dans la recherche d’informations, tout en étant capables de les interpréter. Ainsi ils sauront comment leur application se comporte, comment elle interagit avec les autres applications et ils pourront accélérer la résolution des incidents.
Conclusion
Le monitoring concerne plusieurs problèmes complexes réunis sous un même terme. Ce n’est pas un buzzword mais une réelle nécessité dans cette période de digitalisation à outrance. Les applications deviennent de plus en plus nombreuses et ce phénomène est accentué par l’abandon des architectures monolithiques vers des services distribués. Sans solution de monitoring adéquate, la complexité du système fait qu’il devient impossible de comprendre ce qu’il s’y passe.
En fonction du dégrée de maturité du SI, la mise en place de solutions de monitoring d’application peut s’avérer être un projet à part entière. Ce déploiement demande la mise en place d’une organisation autour de ces outils, qui selon leur complexité, nécessitera la formation de personnes qualifiées. En effet, le monitoring exige un bon niveau d’expertise de la technologie monitorée afin de comprendre les métriques collectées, pouvoir les sélectionner et être capable de les interpréter correctement.
Une fois que la solution de monitoring sera aboutie, lors d’un incident, la personne analysant les dashboards aura toujours à se poser cette question : Est-ce que cette métrique dans le rouge est la source du problème ou la conséquence ?
Dans le 3ème et dernier article de cette saga consacrée au monitoring d’applications, nous vous présenterons un cas concret couplé à un retour d’expérience sur l’utilisation de ces outils.
Grâce à nos
Auteur
