Une intégration Prometheus-Grafana qui détecte les problèmes

Publié le 6 octobre 2026

L’intégration de Prometheus et Grafana permet de tirer parti des métriques de votre serveur : elles montrent ce qui évolue, vous avertissent avant qu’un seuil ne provoque une panne et vous aident à comprendre pourquoi un service semble lent. Prometheus collecte et stocke les données chiffrées. Grafana les transforme en tableaux de bord et en alertes que votre équipe peut comprendre d’un coup d’œil. Ensemble, ils remplacent les suppositions par une vision plus sereine des opérations.

Pour un VPS, un serveur dédié, une plateforme SaaS ou une boutique en ligne très fréquentée, cette configuration est particulièrement utile avant qu’un incident ne survienne. Un disque plein, une mémoire saturée, des temps de réponse en hausse ou un pool de connexions à la base de données proche de sa limite laissent généralement des signes dans les métriques. Le service fonctionne peut-être encore, mais le graphique raconte déjà la suite de l’histoire.

Les rôles respectifs de Prometheus et de Grafana

Prometheus est un système de supervision de séries temporelles. Il collecte les métriques des cibles à intervalles réguliers, ajoute des étiquettes à ces mesures et les conserve pour permettre leur interrogation. Il convient particulièrement bien à la supervision des serveurs et des applications, car les métriques comme l’utilisation du processeur, la pression mémoire, le débit des requêtes, la latence et la capacité du système de fichiers correspondent naturellement à son modèle.

Grafana est la couche de visualisation et de gestion des alertes. Il se connecte à Prometheus comme source de données, permet de créer des panneaux à partir de requêtes PromQL et de les organiser en tableaux de bord. Un bon tableau de bord Grafana n’a pas besoin d’être décoratif. Son objectif est de répondre rapidement à des questions concrètes : le serveur est-il en bon état ? Quel service utilise les ressources ? Les performances se dégradent-elles ? Le déploiement de 14:00 a-t-il changé quelque chose ?

Prometheus peut évaluer lui-même les règles d’alerte, tandis qu’Alertmanager gère le regroupement, le routage et la mise en sourdine des notifications. Grafana peut également générer des alertes à partir des requêtes des tableaux de bord. Les deux approches peuvent fonctionner. Pour les alertes couvrant toute l’infrastructure et gérées sous forme de code, les règles Prometheus associées à Alertmanager sont souvent plus faciles à normaliser. Pour un tableau de bord consacré à un service précis, les alertes gérées par Grafana peuvent être pratiques. Évitez d’exécuter les deux pour exactement la même condition, sauf si vous souhaitez recevoir des notifications en double à 3 h du matin. ne fassent partie du plan.

Intégration de Prometheus et Grafana : une architecture pratique

Une architecture de départ raisonnable est simple. Exécutez Prometheus et Grafana sur un VPS dédié à la supervision, séparé si possible du serveur ou de l’application surveillés. Installez des exportateurs sur les systèmes surveillés. Les exportateurs exposent les métriques sur un point de terminaison HTTP, que Prometheus collecte selon une planification définie.

Pour les serveurs Linux, Node Exporter est le choix habituel pour commencer. Il expose des mesures au niveau de l’hôte, notamment le processeur, la mémoire, la charge moyenne, l’utilisation du disque, le trafic réseau et les statistiques du système de fichiers. Les exportateurs de bases de données peuvent fournir une visibilité supplémentaire sur MySQL, PostgreSQL, Redis et d’autres services. Les métriques de l’application peuvent provenir d’un point de terminaison Prometheus natif, d’une bibliothèque de framework ou d’un exportateur choisi avec soin.

Le flux de données principal est simple :

• Un exportateur expose les métriques d’un serveur, d’une base de données ou d’une application.
• Prometheus collecte les données du point de terminaison et stocke les séries temporelles.
• Grafana interroge Prometheus et affiche les résultats.
• Les règles d’alerte évaluent les seuils ou les comportements anormaux et envoient des notifications par le canal choisi.

Cette représentation simple est importante, car elle simplifie aussi le dépannage. Si un panneau Grafana est vide, vérifiez si Grafana peut interroger Prometheus. Si Prometheus ne dispose d’aucune donnée, vérifiez la page des cibles et le point de terminaison de l’exportateur. Si la cible est hors service, vérifiez l’accès réseau, les règles du pare-feu, l’état du service et la configuration de l’exportateur. Les journaux racontent généralement la même histoire à ce stade.

Commencez par des métriques qui mènent à l’action

Collecter toutes les métriques disponibles génère du bruit, consomme de l’espace de stockage et produit des tableaux de bord que personne ne consulte. Commencez par des métriques qui facilitent une décision opérationnelle claire. Pour la plupart des serveurs, il s’agit de l’utilisation du processeur et de la charge, de la mémoire disponible, de l’activité du swap, de l’espace disque et de l’utilisation des inodes, de la latence des E/S disque, des erreurs réseau, de la disponibilité des processus et de la durée de fonctionnement du système.

Pour les applications Web, ajoutez le débit des requêtes HTTP, le taux d’erreur, la durée des requêtes, le nombre de connexions actives et la profondeur de la file d’attente, le cas échéant. Pour les bases de données, suivez le nombre de connexions, les requêtes lentes, l’état de la réplication, l’efficacité du cache, les verrous et la croissance du stockage. Un site de commerce électronique peut accorder une grande importance aux erreurs de paiement et à la latence de la base de données ; une agence de développement peut donner la priorité à la disponibilité des environnements clients et à la réussite des sauvegardes. Tout dépend de la charge de travail, et non du tableau de bord le plus impressionnant.

Utilisez les étiquettes avec discernement. Les étiquettes permettent de filtrer par environnement, rôle du serveur, client, région ou application. Elles peuvent aussi créer un grand nombre de séries temporelles distinctes lorsqu’elles incluent des valeurs qui changent constamment, comme des identifiants utilisateur, des identifiants de commande, des jetons de session ou des chemins de requête avec des paramètres dynamiques. Des étiquettes à forte cardinalité peuvent discrètement faire travailler Prometheus bien plus que nécessaire.

Configurez la collecte sans créer de nouveaux risques

Prometheus a besoin d’une liste de cibles dans sa configuration. Une cible Node Exporter de base peut ressembler à ceci :

``\`yaml scrape_configs:

• job_name: node

static_configs:

• targets: ['10.0.0.15:9100']

labels: environment: production role: web ``\`

Dans un petit environnement, les cibles statiques sont claires et fiables. À mesure que l’infrastructure se développe, la découverte de services est généralement plus adaptée, car les cibles sont ajoutées et supprimées automatiquement. Quelle que soit la méthode choisie, gardez les points de terminaison de supervision privés dans la mesure du possible. N’exposez pas largement les ports des exportateurs sur Internet simplement parce qu’un tableau de bord a besoin de données.

Utilisez un réseau privé, des listes d’autorisation de pare-feu, un VPN ou un proxy inverse avec authentification, selon le contexte. Chiffrez le trafic lorsque les métriques transitent par des réseaux non fiables. Les métriques Prometheus peuvent révéler les noms d’hôte, les noms des services internes, les profils de charge et les détails des versions. Ce sont des données opérationnelles, pas des éléments décoratifs destinés au public.

Définissez la durée de conservation en fonction de vos besoins en matière d’incidents et de planification de capacité. Pour de nombreuses petites installations, une durée de quinze à trente jours suffit pour repérer les changements récents et les tendances à court terme. Une conservation plus longue aide à suivre la demande saisonnière et la croissance progressive de la capacité, mais augmente les besoins en espace disque. Pour établir des rapports historiques sur une période prolongée, envisagez un stockage distant plutôt qu’une conservation illimitée sur le même VPS que Grafana.

Créez des tableaux de bord pour diagnostiquer rapidement

Commencez par créer un tableau de bord récapitulatif. Il doit présenter l’état des systèmes les plus importants, et non toutes les métriques du catalogue. Un récapitulatif utile comprend souvent la disponibilité des serveurs, le processeur, la mémoire, l’utilisation du disque, le trafic réseau, le taux d’erreurs HTTP et la latence des requêtes. Utilisez des variables pour l’hôte, l’environnement et le service afin qu’un seul tableau de bord couvre plusieurs systèmes sans devenir un musée du copier-coller.

Créez ensuite des tableaux de bord propres à chaque service. Un tableau de bord de base de données nécessite des panneaux différents de ceux d’un serveur Web. Un tableau de bord destiné à un processus d’arrière-plan doit afficher la profondeur de la file d’attente, le temps de traitement, les nouvelles tentatives et les échecs. Choisissez des titres de panneaux explicites : « Espace disque disponible sur /var », « Taux de réponses HTTP 5xx » et « Connexions PostgreSQL actives » valent mieux que des noms astucieux qui nécessitent une traduction au pire moment.

Il est utile d’ajouter des annotations pour les déploiements, les fenêtres de maintenance et les changements de configuration. Quand la latence augmente peu après une mise en production, une annotation transforme un graphique suspect en point de départ utile pour la discussion. Cela ne prouve pas qu’il y a un lien de cause à effet, mais donne à l’enquête un point de départ pertinent.

Déclenchez des alertes sur les symptômes, pas sur chaque valeur

Une alerte lorsque le processeur atteint 80 % peut être utile pour un serveur et dénuée de sens pour un autre. Un nœud de traitement par lots peut fonctionner à pleine charge pendant des heures, comme prévu, tandis qu’une hausse soudaine de la latence de l’API peut affecter immédiatement les clients, même si l’utilisation du processeur reste modérée. Les règles d’alerte doivent tenir compte de l’impact et du comportement attendu.

Commencez par les alertes signalant des situations qui nécessitent une intervention : un exportateur ou un service est inaccessible, l’espace disque sera bientôt épuisé, des tâches de sauvegarde échouent, la pression mémoire provoque l’utilisation du swap, le taux d’erreur augmente, des certificats approchent de leur date d’expiration ou la réplication de la base de données est en mauvais état. Ajoutez une durée pour éviter qu’une courte pointe ne réveille quelqu’un inutilement. Par exemple, un espace disque durablement faible pendant quinze minutes est généralement plus significatif qu’une baisse de cinq secondes.

Chaque alerte doit répondre à trois questions : quel est le problème, où se produit-il et que doit vérifier la personne chargée d’intervenir en premier ? Indiquez le nom du serveur, l’environnement, le service et une brève consigne tirée du guide d’intervention dans l’annotation de l’alerte. « Espace disque faible » ne suffit pas quand il y a vingt serveurs et que quelqu’un lit le message sur son téléphone.

Les mises en sourdine et les fenêtres de maintenance font partie d’une gestion saine des alertes ; elles ne servent pas à masquer les problèmes. Utilisez-les pour les travaux planifiés, puis supprimez-les une fois les travaux terminés. Une mise en sourdine oubliée choisit très mal son moment pour expirer.

Gardez la pile de supervision facile à maintenir

Considérez les tableaux de bord, les règles d’alerte et la configuration Prometheus comme des ressources opérationnelles. Sauvegardez-les, passez-les en revue après les incidents et stockez la configuration dans un système de contrôle de version si votre équipe peut le faire en toute sécurité. Testez les alertes de temps à autre. Un canal de notification qui n’a jamais été testé n’est qu’une hypothèse optimiste.

Supervisez également le système de supervision. Prometheus a besoin de suffisamment de mémoire et d’espace de stockage, Grafana nécessite des sauvegardes de sa configuration et de sa base de données, et les exportateurs doivent rester accessibles après toute modification du pare-feu ou du réseau. Surveillez la durée de collecte, les échecs de collecte, la capacité de stockage et les échecs de livraison des alertes. Si le serveur de supervision est surchargé, ses graphiques peuvent sembler calmes alors qu’il ne recueille discrètement plus les éléments dont vous avez besoin.

Pour les équipes qui souhaitent bénéficier d’une assistance opérationnelle en plus de leur infrastructure, kodu.cloud peut prendre en charge les environnements VPS et serveurs supervisés, tandis que vous gardez une visibilité sur les métriques essentielles à votre activité. L’objectif n’est pas de rendre la supervision mystérieuse. Il s’agit de rendre le prochain problème moins grave, de le détecter plus tôt et de le résoudre plus facilement.

Une configuration Prometheus-Grafana bien réglée n’élimine pas les incidents. Elle permet à votre équipe d’être avertie plus tôt, de disposer d’un contexte plus clair et de prendre moins de décisions à l’aveugle lorsqu’un incident survient. Commencez avec un serveur, un tableau de bord et quelques alertes auxquelles les personnes concernées donneront réellement suite. À partir de là, le service retrouve son calme.

Andres Saar, ingénieur du service client