Monitoring : Une notion clé pour la fiabilité en entreprise

Ma définition

Le monitoring aussi appelé supervision est l’action de collecter des métriques pour optimiser et prévenir les incidents avant qu’ils ne deviennent critiques. La citation de Peter Drucker « If you can’t measure it, you can’t improve it. » dévoile l’importance de la supervision dans une chaine de production. Dans le métier d’administrateur SRE, cette étape est utilisée lors du déploiement/livraison continu. Lors de la livraison ou du déploiement, elle permet de s’assurer que l’application fonctionne toujours correctement et qu’il n’y a pas eu de dégradation des performances. Au-delà de l’intégration continue et de la livraison continue, elle permet de prévenir les pannes. Par exemple, une application peut se retrouver avec beaucoup plus d’utilisateurs que prévu dû à une collaboration commerciale. Dans ce cadre, si l’application n’arrive pas à allouer de nouvelles ressources suffisamment vite ou si l’application n’est plus accessible, nous serons prévenus via les canaux configurés (Teams, Message, Slack, etc.). Cette notion est importante pour les administrateurs SRE, car elle permet de prévenir et d’avoir une visibilité sur les pannes pour les rétablir rapidement. Elle est aussi importante pour les développeurs qui ont besoin de connaître le comportement des utilisateurs pour améliorer l’ergonomie des applications ou encore si une nouvelle fonctionnalité engendre des fuites de mémoires.

Mes éléments de preuve

Durant ma deuxième année d’alternance au Ministère des Armées, j’ai eu la chance de réaliser une migration complexe d’un cluster Mesosphere à un cluster Kubernetes. Un cluster est un groupe de plusieurs machines qui travaillent ensemble pour mutualiser leurs ressources et fournir de nouvelles fonctionnalités, comme la haute disponibilité et la réplication des applications exécutées sur ces différentes machines. Pour ce faire, nous passons par une couche logicielle sur ces machines, par exemple Mesosphere ou Kubernetes. Pour réaliser cette migration, il y a eu plusieurs prérequis, dont la partie monitoring. Il était essentiel qu’on ait une visibilité sur ce qui se passe sur le cluster. Quelles sont les applications qui sont exécutées et dans quels états elles sont. Il fallait aussi que les erreurs nous soient remontées automatiquement afin de répondre le plus efficacement et rapidement possible aux incidents. Tous ces besoins font partie du monitoring. Pour répondre à ces problématiques, j’ai mis en place un Prometheus et un Grafana. Prometheus permet d’agréger toutes les métriques, c’est-à-dire toutes les informations provenant des applications et des machines provenant du cluster Kubernetes. Prometheus en lui-même n’est pas suffisant, car il ne permet pas de mettre en évidence ou de représenter graphiquement les erreurs ou les métriques. C’est pour cela que j’ai aussi mis en place un Grafana qui a permis de créer des tableaux de bord avec des courbes et des représentations graphiques afin de mettre en évidence les erreurs ou les points à surveiller. Grafana m’a permis avec sa fonctionnalité Alertmanager de créer des alertes automatiques si certaines métriques dépassent un seuil défini. Par exemple, si une application atteint quatre-vingts pour cent d’utilisation des ressources qui lui sont alloués, une alerte est remontée vers nous pour vérifier qu’il s’agisse ou non d’un comportement souhaité. Si ce n’est pas le cas, ça peut nous permettre de déceler et d’éviter une future panne. Les erreurs sont remontées automatiquement dans le Mattermost de notre équipe. En plus de ces deux outils, nous pouvons compter sur Kubernetes Dashboard qui est un outil présent par défaut sur le cluster Kubernetes, qui nous permet d’avoir une visibilité et un historique sur ce qui se passe sur le cluster. Étant donné que son interface est très technique, il est surtout utilisé par nous lors des pannes. Grâce à ces trois outils, nous avons suffisamment d’information pour répondre et prévoir la majorité des pannes et nous répondons au besoin initial autour du monitoring. Suite à cela, nous avons pu entamer la migration.

Dans un second projet, que j’ai développé en cumulant avec ma seconde année d’alternance au Ministère des Armées. J’ai créé une agence de design et de développement web « Noesi » dont les associés et les employés sont complètement en distanciel. Dans cette agence, je dois faire attention à la disponibilité des applications des clients, car nous faisons payer un forfait pour répondre aux incidents en moins de vingt-quatre heures. Pour cela, j’ai installé un paquet au sein de tous les projets développés par l’agence. Ce paquet est un bout de code qui permet d’envoyer des données à un Grafana. Grâce à cela, je peux répondre immédiatement aux incidents et aux pannes chez les clients, car elles sont détectées à la seconde près. Lorsqu’elles sont détectées, Grafana m’envoie directement un email sur une boite mail dédiée aux incidents. En plus de surveiller les applications chez les clients, j’ai mis en place plusieurs logiciels en interne pour récupérer les logs automatiquement des applications que nous développons uniquement pour l’agence. Il s’agit de logs applicatifs. Un log applicatif enregistre les actions des utilisateurs et les erreurs rencontrées sur une application pour trouver rapidement l’origine d’un problème en cas de bug. Pour cela, j’ai mis en place un Elasticsearch, un Logstash et un Kibana. Logstash vient récupérer les logs des applications que nous développons, puis les stocke dans Elasticsearch. Une fois les logs dans Elasticsearch, nous pouvons venir visualiser et explorer ces dernières grâce à l’interface graphique de Kibana. Cette mise en place du monitoring m’a permis d’avoir une visibilité constante sur les étapes de développement et d’utilisation de nos propres outils. Ces essentiels pour être sûr que le temps est alloué à des tâches qui rapportent de la valeur dans l’agence. Les alertes ont été configurées pour prévenir toute anomalie provenant des applications clients que nous gérons.

Mon autocritique

J’utilise régulièrement les outils de supervision des applications et de l’infrastructure. Néanmoins, je n’ai qu’un niveau intermédiaire. Il me manque encore de nombreuses notions avant d’avoir une maîtrise avancée. C’est dû à un manque d’expérience et de pratique dans ce domaine. Je supervise de manière avancée la partie infrastructure. Mais quand il s’agit de récupérer des métriques précises sur le comportement de l’utilisateur dans une application A ou B, je n’ai qu’une vague idée de comment l’exécuter. Je sais qu’il y a plusieurs outils qui permettent de le faire de manière plus ou moins avancée, comme l’outil Sentry. Néanmoins, ce n’est pas encore une notion que j’ai pu mettre en place. Cette notion est très importante pour étudier le comportement des utilisateurs et pour pouvoir modeler l’application à leurs besoins. De plus, je sais mettre en place des agents qui permettent de récolter les métriques sur les applications, mais je n’ai qu’une vague idée des impacts au niveau sécurité que cela peut engendrer. Par conséquent, mes connaissances sont plutôt basiques en supervision. Je peux répondre à toutes ces problématiques, mais ça me prendrait beaucoup plus de temps qu’un expert en supervision ayant l’habitude de ces outils. La supervision est ce qui pourrait s’apparenter à des œils sur les applications et les infrastructures pour l’administrateur SRE. Sans ces derniers, il est aveugle lors des pannes et ne pourra pas répondre efficacement à ces dernières. Elle n’est donc pas à négliger et doit faire partie du parcours logique d’apprentissage pour devenir un administrateur SRE.

Mon évolution dans cette compétence

Finalement, j’ai encore beaucoup de notions à approfondir pour devenir un expert en supervision. La formation « DevOps Observability Foundation » pourrait m’intéresser, elle permet de retravailler tous les piliers de la supervision, en rajoutant une partie intégration de l’intelligence artificielle ainsi qu’une partie sécurité du stockage des métriques. Il me semble qu’elle permettrait de résoudre une grande partie de mes lacunes. J’ai aussi prévu de suivre une formation en interne du Ministère des Armées autour de la solution Elastic qui permet de remonter les journaux d’erreurs des applications qui ont une autre forme de métriques. Ces deux formations devront me permettre d’atteindre un niveau intermédiaire solide avec une vision globale et précise des possibilités qu’offrent actuellement de tels outils de supervision. À l’avenir, je devrais continuer à me former en autodidacte en essayant d’autres outils de supervision, car c’est une notion qui évolue rapidement et qui comporte de très nombreux outils existants. Les entreprises ont par conséquent besoin de personnes extrêmement flexibles et n’ont pas forcément besoin d’un expert.