Introduction
Un monitoring efficace ne se limite pas à la collecte de métriques ; il s'agit surtout d'être averti lorsque quelque chose ne fonctionne pas comme prévu. Prometheus dispose d'un système d'alerte puissant et intégré qui vous permet de définir des conditions d'alerte en utilisant le même langage de requête PromQL que celui utilisé pour la création de graphiques. Lorsqu'une condition d'alerte est remplie, celle-ci passe à l'état « firing » (en cours de déclenchement).
Dans ce laboratoire, vous apprendrez les fondamentaux des alertes Prometheus. Vous commencerez avec un environnement préconfiguré exécutant Prometheus et un Node Exporter. Votre mission consistera à créer un fichier de règles d'alerte distinct, à définir une règle pour détecter une utilisation élevée du CPU, à configurer Prometheus pour charger ce fichier, et enfin, à simuler une forte charge CPU pour observer le déclenchement de votre alerte dans l'interface utilisateur de Prometheus.
Comprendre l'environnement d'alerte
Dans cette étape, vous allez vous familiariser avec l'environnement du laboratoire. Le script d'installation a déjà démarré deux conteneurs Docker pour vous : un pour Prometheus et un pour Node Exporter.
Tout d'abord, vérifions que les deux conteneurs sont en cours d'exécution. Ouvrez un terminal et exécutez la commande docker ps :
docker ps
Vous devriez voir une sortie similaire à celle-ci, montrant les conteneurs prometheus et node-exporter avec un statut « Up ».
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
... prom/prometheus "/bin/prometheus --c…" 15 seconds ago Up 14 seconds 0.0.0.0:9090->9090/tcp, :::9090->9090/tcp prometheus
... prom/node-exporter "/bin/node_exporter …" 16 seconds ago Up 15 seconds 0.0.0.0:9100->9100/tcp, :::9100->9100/tcp node-exporter
Le conteneur node-exporter expose des métriques sur le système hôte (notre machine virtuelle de laboratoire), et le conteneur prometheus est configuré pour récupérer (collecter) ces métriques.
Maintenant, vérifions l'interface utilisateur de Prometheus. Pour y accéder :
- Dans l'interface LabEx, cliquez sur le bouton
+(Nouvel onglet) dans la barre de navigation supérieure. - Choisissez Web Service dans le menu déroulant.
- Entrez
9090comme numéro de port. - Cliquez sur Open pour lancer l'interface web de Prometheus.
Lorsque le nouvel onglet s'ouvre, vous devriez voir la page d'accueil de l'explorateur d'expressions Prometheus. Accédez à Status -> Targets depuis le menu de navigation supérieur. Vous devriez constater que le job node_exporter a un état « UP » en vert, confirmant que Prometheus collecte correctement les données. Cette connexion est la base de notre règle d'alerte.

Créer alert-rules.yml pour l'alerte de haute charge CPU
Dans cette étape, vous allez créer un fichier dédié à vos règles d'alerte. Il est recommandé de séparer les règles de la configuration principale de Prometheus pour une meilleure organisation.
Nous allons créer un fichier nommé alert-rules.yml dans votre répertoire de projet. Utilisez l'éditeur nano pour créer et modifier le fichier :
nano ~/project/alert-rules.yml
Copiez et collez maintenant le contenu YAML suivant dans l'éditeur nano. Cela définit un groupe de règles contenant une alerte unique qui se déclenche lorsque l'utilisation du CPU est élevée.
groups:
- name: node_alerts
rules:
- alert: HighCpuLoad
expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100) > 10
for: 1m
labels:
severity: warning
annotations:
summary: "High CPU load on {{ $labels.instance }}"
description: "CPU load is > 10% (current value: {{ $value }}%)"
Analysons cette règle :
groups: Les règles sont organisées en groupes. Toutes les règles d'un groupe sont évaluées séquentiellement.alert: Le nom de notre alerte,HighCpuLoad.expr: L'expression PromQL qui est évaluée. Si elle renvoie une valeur, l'alerte est déclenchée. Ici, nous calculons le pourcentage de temps CPU non inactif sur la dernière minute. S'il est supérieur à 10 %, la condition est remplie.for: Cette clause spécifie que la condition doit être vraie pendant une durée continue (1 minute) avant que l'alerte ne passe à l'état « Firing ». Cela évite les alertes intempestives lors de pics brefs.annotations: Elles ajoutent des informations lisibles par l'homme à l'alerte.summaryetdescriptionsont des annotations standard. Vous pouvez utiliser des variables de modèle comme{{ $labels.instance }}et{{ $value }}pour inclure des données dynamiques dans vos messages d'alerte.
Après avoir collé le contenu, enregistrez le fichier et quittez nano en appuyant sur Ctrl+X, puis Y, et enfin Enter.
Exécuter le conteneur Prometheus avec le fichier de règles monté
Dans cette étape, vous allez demander à Prometheus de charger votre nouveau fichier de règles et redémarrer le conteneur avec la configuration mise à jour.
Tout d'abord, vous devez modifier le fichier de configuration principal, prometheus.yml, pour inclure une référence à votre fichier de règles. Ouvrez-le avec nano :
nano ~/project/prometheus.yml
Ajoutez la directive rule_files au niveau racine du fichier, et non à l'intérieur du bloc global. Le fichier devrait ressembler à ceci après vos modifications :
global:
scrape_interval: 15s
rule_files:
- "alert-rules.yml"
scrape_configs:
- job_name: "prometheus"
static_configs:
- targets: ["prometheus:9090"]
- job_name: "node_exporter"
static_configs:
- targets: ["node-exporter:9100"]
Enregistrez le fichier et quittez nano (Ctrl+X, Y, Enter).
Maintenant que la configuration est mise à jour, vous devez redémarrer le conteneur Prometheus pour appliquer les changements. Arrêtez et supprimez d'abord l'ancien conteneur :
docker stop prometheus
docker rm prometheus
Enfin, exécutez un nouveau conteneur Prometheus. Cette commande est similaire à celle du script d'installation, mais elle inclut un second flag -v pour monter votre fichier alert-rules.yml dans le conteneur.
docker run -d --name prometheus -p 9090:9090 \
--network monitoring \
-v /home/labex/project/prometheus.yml:/etc/prometheus/prometheus.yml \
-v /home/labex/project/alert-rules.yml:/etc/prometheus/alert-rules.yml \
prom/prometheus
Cette commande garantit que la configuration principale et les règles d'alerte sont disponibles à l'intérieur du conteneur Prometheus.
Vérifier le chargement des règles d'alerte dans l'interface Prometheus
Dans cette étape, vous allez confirmer que Prometheus a bien chargé votre nouvelle règle d'alerte.
Retournez sur l'onglet de l'interface Prometheus dans votre navigateur (ou ouvrez un nouvel onglet Web Service sur le port 9090 si nécessaire). Si la page ne se charge pas, attendez quelques secondes que le nouveau conteneur démarre, puis rafraîchissez la page.
Dans la barre de navigation supérieure, cliquez sur l'élément de menu Alerts.
Vous devriez maintenant voir votre alerte HighCpuLoad listée. L'alerte sera dans la section Inactive, indiquée par un fond vert. C'est l'état attendu car la charge CPU sur le système est actuellement faible, donc l'expression de l'alerte (expr) est évaluée comme fausse.

Il est important de comprendre les trois états d'une alerte :
- Inactive (Vert) : La condition d'alerte est fausse.
- Pending (Jaune) : La condition d'alerte est devenue vraie, mais la durée
forn'est pas encore écoulée. Prometheus attend de voir si la condition persiste. - Firing (Rouge) : La condition d'alerte est vraie depuis toute la durée
for. Dans une configuration de production, c'est à ce moment que Prometheus enverrait l'alerte à un Alertmanager.
Votre alerte est actuellement inactive, ce qui est correct. À l'étape suivante, nous allons provoquer son déclenchement.
Simuler une charge pour tester le déclenchement de l'alerte
Dans cette dernière étape, vous allez augmenter intentionnellement la charge CPU sur le système pour tester si votre alerte se déclenche correctement.
Nous pouvons générer une charge CPU en utilisant une simple boucle shell infinie. Dans votre terminal, exécutez la commande suivante. Le & à la fin exécutera le processus en arrière-plan, vous permettant de continuer à utiliser votre terminal.
while true; do true; done &
Cette commande démarre un processus qui consomme 100 % d'un cœur CPU. Maintenant, revenez rapidement à la page Alerts dans l'interface Prometheus (accessible via l'onglet Web Service sur le port 9090).
Vous observerez le changement d'état de l'alerte HighCpuLoad :
- En 15 à 30 secondes environ, l'expression de l'alerte deviendra vraie. L'alerte passera dans la section Pending et deviendra jaune. Cela signifie que Prometheus a détecté la charge CPU élevée mais attend la durée
1mspécifiée dans la clausefor. - Après être restée dans l'état Pending pendant une minute, l'alerte passera dans la section Firing et deviendra rouge. Cela confirme que votre règle d'alerte fonctionne comme prévu ! Vous pouvez développer l'alerte pour voir les annotations que vous avez définies, avec la valeur actuelle.

Une fois que vous avez vu l'alerte se déclencher, vous pouvez arrêter la génération de charge. Retournez dans votre terminal et exécutez la commande suivante pour tuer le processus en arrière-plan :
Important : Pour économiser les ressources du serveur LabEx, assurez-vous d'exécuter la commande suivante pour arrêter la génération de charge.
kill $!
Après avoir arrêté la charge, surveillez à nouveau l'interface Prometheus. L'alerte reviendra bientôt à l'état Inactive (vert), complétant ainsi le cycle de test.
Résumé
Félicitations ! Vous avez configuré et testé avec succès une alerte Prometheus.
Dans ce laboratoire, vous avez appris à :
- Structurer les règles d'alerte dans un fichier YAML séparé.
- Rédiger une expression PromQL pour définir une condition d'alerte pour une utilisation élevée du CPU.
- Utiliser des annotations pour créer des messages d'alerte significatifs et lisibles par l'homme.
- Configurer Prometheus pour charger vos fichiers de règles et le redémarrer pour appliquer les changements.
- Observer le cycle de vie d'une alerte dans l'interface Prometheus, de Inactive à Pending, puis Firing.
- Simuler une condition pour déclencher et tester votre alerte.
Ceci constitue la première moitié du système d'alerte. L'étape logique suivante, qui dépasse le cadre de ce laboratoire, serait de configurer une instance Alertmanager. Prometheus enverrait alors ses alertes en cours de déclenchement à l'Alertmanager, qui serait responsable de la déduplication, du regroupement et de l'acheminement vers des canaux de notification réels comme l'e-mail, Slack ou PagerDuty.



