Lab d’observabilité : Prometheus et Grafana, avec une règle d’alerte à écrire

Ce lab donne à chaque élève un petit serveur web à surveiller et les outils qui le surveillent : un exporteur qui transforme la page d’état du serveur en métriques, Prometheus qui les collecte toutes les cinq secondes, et Grafana, déjà connecté et déjà relié à Prometheus. L’élève pose des questions en PromQL, dessine un panneau, puis écrit une règle d’alerte, casse le serveur exprès et regarde l’alerte passer de « pending » à « firing ».

Il est conçu par nos soins à partir de quatre images publiques : il n’y a rien de vulnérable à attaquer, seulement un système à surveiller. Ce n’est pas un lab d’attaque. La copie du lab n’a aucun accès à internet ni à aucun autre élève.

Ce que les élèves apprennent

À quoi sert la supervision et comment ses éléments s’assemblent : un programme qui publie des chiffres, un exporteur pour les logiciels qui n’en publient pas, un collecteur qui les relève à intervalle régulier et les conserve, et un tableau de bord qui les dessine. Ils posent des questions en PromQL, comme nginx_up et le débit de requêtes sur une minute, dans la page de Prometheus et avec curl sur son API, et font un panneau Grafana à partir de la même requête. Le cœur du lab est une règle d’alerte : ils l’écrivent dans un fichier de règles, rechargent Prometheus, la voient listée comme inactive, cassent le serveur et regardent l’alerte passer à « pending » puis à « firing », puis disparaître quand ils remettent le serveur en marche. Il convient aux unités DevOps, exploitation, cloud et systèmes ; vérifiez la formulation exacte dans l’unité de votre propre organisme certificateur.

Le lancer dans votre navigateur

Le serveur web est le service nommé app, son exporteur est exporter, et le terminal du lab atteint Prometheus sous le nom prometheus et Grafana sous le nom grafana. Une commande docker du terminal peut examiner, entrer dans, arrêter, démarrer et redémarrer les services du lab et lire leurs journaux : elle ne peut rien créer, télécharger ni supprimer. La configuration et les règles de Prometheus, ainsi que les tableaux de bord Grafana de l’élève, sont sur des volumes nommés : ils sont toujours là quand le lab est arrêté puis redémarré. Les mesures ne sont pas conservées : un lab redémarré commence avec un graphique vide.

  1. Ouvrir la page Conteneur. Ouvrez « Créer » dans la barre et choisissez « Lancer un conteneur ». Tout le monde peut ouvrir la page, et le lab Git et le lab SQL se lancent sans compte. Tous les autres labs demandent un compte gratuit : créez-en un, connectez-vous, puis appuyez sur « Démarrer ».
  2. Trouver le lab. La carte « Laboratoires d’exemple » liste tous les exemples. Trouvez Observability: Prometheus and Grafana.
  3. Appuyer sur Démarrer. « Démarrer » le lance tel quel, en un clic. « Modifier le fichier d’abord » ouvre le fichier compose pour que vous puissiez le changer avant de démarrer.
  4. L’ouvrir. Sur la page du lab, la barre du lab a deux liens, Prometheus et Grafana, déjà connecté et relié à Prometheus. Dans Prometheus, lancez nginx_up. Dans le terminal à côté du lab, curl http://prometheus:9090/api/v1/query?query=nginx_up pose la même question. Pour écrire une règle, lancez docker exec -it prometheus sh et créez un fichier se terminant par .yml dans /etc/prometheus/rules, rechargez avec curl -X POST http://prometheus:9090/-/reload, puis docker stop app et regardez la page Alerts. docker start app remet le serveur en marche.

Que demander aux élèves de rendre

La règle elle-même, une capture d’écran de l’alerte déclenchée sur la page Alerts de Prometheus, et un panneau Grafana montrant le même signal. Pour la compréhension, une phrase ou deux sur ce que demande la règle, pourquoi elle attend dix secondes avant de se déclencher, et ce que ferait la personne d’astreinte en la voyant. Pour un travail plus poussé, demandez une seconde règle sur un autre signal, comme le débit de requêtes.

Rien n’est noté automatiquement. Les limites du lab méritent d’être dites à voix haute : l’alerte peut être observée mais personne n’est prévenu, car il n’y a ni messagerie ni service de discussion à atteindre.

Une leçon de base sur ce lab

Observability Basics est une petite leçon qui se fait dans ce lab, chaque étape étant expliquée et accompagnée d’un bouton Exécuter qui tape sa commande dans le terminal de l’élève. Elle pose une question à Prometheus, écrit une règle d’alerte depuis le terminal, arrête le serveur web et montre l’alerte passer à « pending » puis à « firing », puis le redémarre. Dessiner un panneau est laissé à l’élève.

Un compte personnel gratuit la reçoit dans le module Basics, qui se trouve sur « Accueil », chaque établissement peut la copier depuis le dossier Basics de la Bibliothèque, et un nouvel établissement l’a dans un module appelé Lab Basics (Sample). Elle est volontairement petite : elle montre à un enseignant ce qu’est une leçon qui se fait dans un lab, et le lab fait le reste. Copiez-la dans un module à vous pour la modifier.

Le code sur GitHub

Le fichier compose lance quatre images publiques, chacune figée sur une version et utilisée telle quelle : nginx (BSD-2-Clause), l’exporteur Prometheus de NGINX et Prometheus (tous deux Apache-2.0) et Grafana (AGPL-3.0). Aucune n’est distribuée par nous. La configuration de chacune est écrite par son propre point d’entrée, et celle de Prometheus n’est écrite qu’au premier démarrage : ce que l’élève change n’est donc pas remis en place. Le test du dépôt déroule le lab comme un élève, avec une règle qui se déclenche puis un arrêt et un démarrage, sous les mêmes limites que celles de la plateforme. Le catalogue de plugins et la recherche de mises à jour de Grafana sont désactivés, car le lab n’a aucun accès à internet.

En faire un travail

Indiquez dans la tâche quelle règle écrire et ce qu’il faut rendre.

  1. Créer le lab. Dans votre module, ajoutez une tâche et choisissez la carte « Lab de conteneurs », puis « Dans un dépôt GitHub ». Indiquez https://github.com/mitsurutech/lab-observability avec la branche main. Le fichier compose par défaut est compose.yaml. Faites d’abord un fork du dépôt si vous voulez le modifier.
  2. Publier et l’essayer. « Publier » fige le commit qui vous a été montré : un changement ultérieur dans le dépôt ne modifie donc pas un lab que vous avez déjà proposé. Démarrez d’abord votre propre copie.
  3. Le distribuer. Attribuez-le comme n’importe quelle tâche, avec une échéance si vous le souhaitez, et indiquez dans la tâche ce qu’il faut faire et ce qu’il faut rendre.
  4. Noter ce qui est rendu. Ouvrez la copie d’un élève et le travail rendu, notez-le et renvoyez-le avec un motif s’il demande un complément.

Questions fréquentes

Une alerte peut-elle envoyer un e-mail ou un message ?
Non. Le lab n’a aucun accès à internet et aucun service de messagerie, donc une alerte se voit sur la page Alerts et dans l’API mais n’est envoyée nulle part. Cela vaut la peine d’être dit à une classe : la règle est la partie que l’élève écrit, et l’endroit où elle est envoyée est une autre pièce, Alertmanager, que ce lab ne comprend pas.
Que se passe-t-il si un élève casse la configuration de Prometheus ?
Le fichier est écrit une seule fois, au premier démarrage, puis il est à l’élève : un redémarrage ne le remet pas en place. Quand un rechargement échoue, par exemple à cause d’une erreur dans un fichier de règles, la commande de rechargement affiche la raison et Prometheus garde les règles qu’il avait avant. Pour repartir de l’original, supprimez le fichier .lab-seeded dans /etc/prometheus et redémarrez le service, ou commencez une copie neuve.
Le lab d’observabilité note-t-il automatiquement la règle d’alerte ?
Non. Rien n’est noté automatiquement : demandez aux élèves de rendre la règle, une capture d’écran de celle-ci en train de se déclencher sur la page Alerts de Prometheus et un panneau Grafana montrant le même signal. Une phrase sur la raison pour laquelle la règle attend dix secondes avant de se déclencher montre s’ils l’ont comprise.