Monitoring
| Ma défition
Le monitoring est le fait de surveiller quelque chose avec des données mesurables. Le but est de mettre en place des seuils sur ces données afin d’être informé d’un comportement inhabituel.
Dans un système d’information, le monitoring sert à mesurer de nombreuses données afin de se rendre compte rapidement lorsqu’un incident est en cours. Il peut prendre aussi la forme de tableaux de bords servant à mener des analyses. Par exemple, dans un système d’information, on peut mettre en place des tableaux de bords pour surveiller les RAM/CPU d’un parc de machines.
L’utilisation d’un système de monitoring a de nombreux avantages, l’article “What is IT Monitoring?” paru sur le site qiminfo.ch en détaille quelques-uns comme la réduction des temps d’arrêt liés aux incidents, la prévention des incidents ou encore une meilleure gestion des performances.
| Mes éléments de preuve
Ayant mis en place une solution de monitoring dans le cadre du projet “Solution de monitoring”, je possède plusieurs anecdotes où j’ai dû mettre en oeuvre cette compétence.
Lorsque nous avons migré tous nos outils et environnement dans le Cloud Azure j’ai adapté les sondes à ce nouvel environnement. Concernant le monitoring des points de montage, nous utilisions auparavant l’exportateur par défaut node-exporter qui ne correspondait plus à tous nos besoins. En effet, les accès aux points de montage par les utilisateurs ont grandement étés restreints dans le Cloud au profit de comptes génériques. Nous avions alors besoin de surveiller que la combinaison Owner/Group de chaque point de montage ne soit pas modifiée par erreur humaine ou par un comportement anormal d’un outil. Nous avions aussi besoin de surveiller que les points de montage soient toujours disponibles. Pour cela, j’ai développé un nouvel exportateur customisé (rédigé en Python) qui permet de répondre à ces besoins. L’exportateur se base sur un fichier de configuration comportant toutes les combinaisons attendues, il envoie ensuite les métriques au service Pushgateway qui est lui-même scrappé par Prometheus. J’ai ensuite programmé des règles d’envoi d’alerte lorsqu’un changement de groupe ou d’owner intervient sur un point de montage. Les labels associés à l’alerte nous permettent de savoir directement le point de montage concerné, le groupe ou le owner qui a changé par rapport à celui attendu. L’exportateur permet aussi de remonter des alertes lorsqu’un point de montage à + de 90% d’espace disque occupé et lorsque qu’un point de montage semble ne plus être disponible. Pour l’instant, cet exportateur nous a permis d’être alerté rapidement à plusieurs reprises qu’un point de montage était quasiment plein. Il est arrivé une fois de se rendre compte du remplissage très rapide d’un point de montage critique avec des terabytes de fichiers de logs causé par un bug outil. L’alerte nous a permis de se rendre compte très rapidement du problème et cela a limité significativement les incidents liés à ce problème.
Etant chargé d’ajouter continuellement de nouvelles sondes de monitoring, voici une deuxième anecdote. Récemment, j’ai ajouté une nouvelle sonde permettant de surveiller un outil que nous allons nommer “Product delivery”. Cet outil est une automation qui met à disposition des produits générés par une autre équipe de l’entreprise. Cette automation est lancée en cron toutes les heures et elle permet d’installer tous les nouveaux produits. Ces produits sont livrés sous forme de package avec une version d’un logiciel externe. Les versions du logiciel externe sont installées par une autre équipe et il arrive des fois qu’une version n’est pas disponible pour le package. Dans ce cas, un mail est envoyé au support mais il est arrivé deux fois que ce mail n’ai pas été vu et cela pose plusieurs problèmes en en chaine dans l’environnement de production. Il m’a alors été demandé de modifier l’outil “Product Delivery” pour qu’il envoie des métriques à la solution de monitoring. L’objectif était de pouvoir être alerté dans le canal Teams des alertes de monitoring qui est suivi rigoureusement par le support. L’intégration des métriques au sein de la solution de monitoring a aussi permit d’analyser les occurrences (fréquences, type de package concerné).
| Mon autocritique
Au sein de mon alternance, j’ai pu constater l’importance d’avoir du monitoring. En effet, la solution de monitoring a amené une réelle visibilité et a permis de mieux comprendre et gérer un environnement complexe (grande charge système, serveurs multi-sites, logiciels externes).
J’exerce cette compétence de façon continue depuis 3 ans (avec une charge moyenne de 50%) et je pense avoir le niveau « Confirmé« . J’ai progressé assez rapidement sur cette compétence. J’ai identifié un axe de progression, au sujet du monitoring des performances (code, réseau) dont je n’ai pas beaucoup eu l’occasion d’exploiter.
Le monitoring est la compétence que j’ai le plus eu l’opportunité de travailler et dont personnellement j’apprécie le plus car je trouve bénéfique de mettre en place des sondes automatiques qui permettent ensuite d’aider le support mais aussi le management. Cependant, je pense qu’un système de monitoring ne doit pas être une solution de contournement qui servirait à ne pas corriger un incident lié à une mauvaise architecture ou du code non optimisé.
| Mon évolution dans cette compétence
Je souhaiterai avoir l’opportunité de continuer à travailler dans un poste qui comporte des missions de monitoring afin de renforcer mon niveau.
J’aimerai aussi d’ici un à deux ans tenter d’obtenir la certification “Prometheus Certified Associate” qui me permettrait de renforcer mes compétences avec l’outil Prometheus qui est beaucoup utilisé en entreprise.