Prometheus et Grafana : Guide complet d’installation, configuration et monitoring

Installation et configuration de Prometheus

Téléchargement et installation du binaire

Pour débuter, rendez-vous sur la page officielle de téléchargement de Prometheus et récupérez la dernière version stable. L’installation se résume à quatre opérations simples :

• Télécharger l’archive officielle (prometheus-*.tar.gz)
• Extraire avec la commande tar xvfz prometheus-*.tar.gz
• Lancer le binaire prometheus depuis le dossier extrait
• Vérifier l’interface web sur le port 9090

Dès le premier démarrage, l’outil fonctionne avec une configuration par défaut qui scrape sa propre instance. Cette approche permet de valider immédiatement que le service est opérationnel avant d’ajouter vos premières cibles.

Configuration du scraping et des cibles

Toute la configuration repose sur le fichier prometheus.yml. C’est ici que vous définissez l’intervalle de scraping, fixé par défaut à 15s, ainsi que la liste des cibles à interroger. Chaque cible doit exposer ses métriques sur un endpoint /metrics, et Prometheus vient les récupérer périodiquement selon le modèle pull.

Pour ajouter un serveur à surveiller, il suffit de déclarer une nouvelle entrée dans la section scrape_configs du fichier. Par exemple, pour monitorer un hôte avec Node Exporter, vous indiquerez son adresse IP suivi du port 9100. Après modification, un simple rechargement du service (kill -HUP ou redémarrage) applique les changements sans interruption.

La vérification de vos réglages s’effectue directement dans l’interface web. Sous l’onglet Status → Targets, vous visualisez l’état de chaque cible et les éventuelles erreurs de connexion. Le port 9090 sert également d’accès à l’explorateur de métriques, un outil précieux pour tester vos requêtes PromQL en conditions réelles avant de les intégrer à vos dashboards.

Installation et configuration de Grafana

Connexion de la source de données Prometheus

Une fois Prometheus opérationnel sur le port 9090, l’installation de Grafana se fait soit via une instance locale (paquet ou binaire), soit via une instance hébergée sur Grafana Cloud. L’interface de Grafana est accessible par défaut sur le port 3000 avec le couple identifiant/mot de passe admin/admin.

La première étape consiste à déclarer Prometheus comme source de données. Depuis le menu Configuration → Data Sources, cliquez sur Add data source et sélectionnez Prometheus. Dans le champ URL, renseignez http://localhost:9090 ou l’adresse de votre serveur Prometheus si celui-ci est distant. Laissez l’intervalle de scraping à 15s (valeur par défaut) pour rester cohérent avec la configuration de votre cible.

Cliquez ensuite sur Save & Test : Grafana vérifie la connexion et affiche un message de confirmation. Cette intégration native permet à Grafana de comprendre automatiquement les métriques disponibles et d’exploiter l’historique de vos séries temporelles.

Création et importation de dashboards

Grafana propose deux approches pour construire vos tableaux de bord : la création manuelle ou l’importation de dashboards existants. Pour un premier pas rapide, l’importation via le numéro d’ID du dashboard officiel (par exemple le 1860 pour Node Exporter) est la méthode recommandée elle fournit des graphiques fonctionnels en quelques clics.

Pour créer un dashboard manuellement, utilisez le bouton + → Create Dashboard → Add visualization. Sélectionnez votre source Prometheus, puis écrivez votre première requête PromQL dans l’éditeur. Par exemple, la métrique up indique si une cible est active (valeur 1) ou inactive (valeur 0). Chaque panneau peut être configuré avec des unités, des seuils et des variables de templating pour filtrer les données par instance ou par environnement.

Pensez à utiliser la vue Drilldown pour naviguer dans vos données sans écrire de requêtes complexes : cette fonctionnalité de Grafana vous permet d’explorer les métriques par labels et par ressources. Enfin, sauvegardez régulièrement votre dashboard et partagez-le via l’export JSON si vous souhaitez le réutiliser sur une autre instance.

Installation et usage des exporters

Node exporter : la base du monitoring système

Le Node exporter est le premier exporter à installer sur chaque hôte à surveiller. Il expose un endpoint /metrics sur le port 9100 qui transforme les métriques du système en format lisible par Prometheus. Téléchargez le binaire, lancez-le en arrière-plan, puis ajoutez simplement la cible dans la section scrape_configs de votre prometheus.yml.

Cette approche par agents spécialisés rappelle l’architecture des frameworks multi-agents comme AutoGen, où chaque agent joue un rôle précis dans un pipeline automatisé.

Sur une machine Linux, le Node exporter remonte les métriques essentielles : utilisation CPU, consommation mémoire, espace disque, trafic réseau et charge système. Pour un déploiement rapide sur plusieurs serveurs, pensez à utiliser un gestionnaire de processus comme systemd.

Blackbox exporter : surveiller la disponibilité des services

Le Blackbox exporter vérifie la disponibilité de vos services depuis l’extérieur. Il sonde vos endpoints via HTTP, DNS, TLS ou ICMP et expose le résultat sous forme de métriques sur le port 9115. Contrairement au Node exporter qui mesure l’état interne d’une machine, le Blackbox exporter valide que vos services répondent correctement.

Chaque exporter joue un rôle précis dans votre infrastructure de monitoring. Pour les applications métier, des exporters dédiés existent : MySQL exporter, PostgreSQL exporter ou Redis exporter. Tous suivent le même principe : transformer une source en endpoint /metrics que Prometheus viendra scraper.

L’installation se résume à trois étapes : télécharger le binaire, le configurer, puis l’ajouter comme cible de scraping. Avec le Node exporter sur le port 9100 installé sur tous vos hôtes, vous obtenez une vision complète de votre parc machine en quelques minutes.

Configuration d’Alertmanager et création d’alertes

Une fois vos métriques collectées et visualisées dans Grafana, l’étape suivante consiste à être proactif. Alertmanager est le composant séparé qui prend en charge le routage des alertes et l’envoi de notifications vers Slack, email ou PagerDuty. Il fonctionne en parallèle de Prometheus, qui se charge uniquement de détecter les seuils dépassés grâce à des règles.

Définition des règles d’alerte dans Prometheus

Avant de notifier qui que ce soit, il faut définir ce qui mérite une alerte. Cela se fait dans le fichier prometheus.yml via un bloc rule_files. Vous y référencez un fichier.yml distinct qui contient vos règles, comme par exemple :

<code>groups:
 - name: instance_down
 rules:
 - alert: InstanceDown
 expr: up == 0
 for: 1m
 labels:
 severity: critical
 annotations:
 summary: "Instance {{ $labels.instance }} down"</code>

• L’expression : une requête PromQL qui, si elle renvoie des résultats, déclenche l’alerte (ex. up == 0).
• La clause for : la durée pendant laquelle la condition doit être vraie avant de déclencher (ici 1 minute).
• Les labels et annotations : ils permettent d’ajouter du contexte et de la sévérité, utilisés ensuite par Alertmanager pour le routage.

Le flux complet repose sur 5 étapes simples : l’exposition des métriques par les cibles, le pull par Prometheus, le stockage local, puis les requêtes et enfin les alertes. Comprendre ce flux en 5 étapes vous évitera 80% des confusions lors de vos premiers tests.

Configuration d’Alertmanager pour les notifications

Alertmanager reçoit toutes les alertes de Prometheus et décide, selon des règles de routage par labels, vers quel canal les envoyer. Cette configuration se fait dans un fichier alertmanager.yml séparé.

• Installer le binaire Alertmanager séparément : il ne fait pas partie du binaire principal de Prometheus, qui écoute sur le port 9090.
• Configurer le routage par labels : définissez des routes qui dirigent les alertes vers un destinataire selon le label severity ou team.
• Notifications via email Gmail (SMTP) : utilisez le serveur smtp.gmail.com avec un mot de passe d’application pour un envoi sécurisé.
• Intégration Slack via webhook : le moyen le plus rapide pour recevoir des alertes dans un canal dédié.
• Réception des alertes via PagerDuty : idéal pour les astreintes avec escalade automatique.

Pour le routage, chaque route peut avoir des matchers (comme severity="critical") et des receivers spécifiques. Par exemple, les alertes critiques peuvent aller à PagerDuty tandis que les avertissements partent sur Slack, avec un group_by pour ne pas spammer un canal en cas d’incident massif.

Initiation à PromQL et types de métriques

Les types de métriques fondamentaux

Avant de maîtriser les requêtes, il faut comprendre ce que Prometheus collecte. La base repose sur 4 types de métriques, chacun répondant à un besoin précis. Confondre un compteur et une jauge mène inévitablement à des alertes erronées et des dashboards trompeurs.

• Counter : compteur croissant qui ne descend jamais (requêtes HTTP totales, erreurs cumulées).
• Gauge : valeur variable qui monte et descend (utilisation mémoire, température CPU).
• Histogram : distribution des observations dans des buckets prédéfinis (latences).
• Summary : quantiles calculés côté client (percentiles de temps de réponse).

Le choix du type influence directement la qualité de vos requêtes PromQL. Par exemple, un Counter doit toujours être utilisé avec la fonction rate() pour obtenir un débit par seconde, tandis qu’une Gauge se lit telle quelle. Une erreur courante consiste à appliquer rate() sur une jauge, ce qui produit des résultats incohérents et des alertes fantômes.

Requêtes essentielles : filtres et fonctions

PromQL est le langage de requête de Prometheus. Sa syntaxe repose sur des filtres par labels entre accolades et des fonctions d’agrégation. Avec quelques combinaisons, vous couvrez l’essentiel des besoins de monitoring : CPU par instance, taux d’erreur, latence moyenne par endpoint.

Les fonctions fondamentales à connaître :

• rate() : calcule le taux par seconde d’un counter (requêtes/seconde).
• increase() : mesure l’augmentation sur une période donnée (requêtes sur 5 min).
• delta() : appliqué aux gauges, retourne la variation sur un intervalle.
• deriv() : estimation de la dérivée d’une jauge (tendance de croissance).

Pour filtrer, utilisez les labels entre accolades : http_requests_total{job="api",status="500"}. Les opérateurs de comparaison (>, <) permettent de créer des seuils. L’agrégation avec by groupe les séries : sum(rate(..)) by (instance). La cardinalité reste le piège majeur : chaque combinaison unique de labels crée une nouvelle série temporelle. Un label avec une valeur unique par requête (comme un user_id) peut générer 1M de séries et provoquer un OOM garanti sur une instance mono-nœud. La rétention locale par défaut de 15 jours vaut pour une charge raisonnable ; au-delà de 30 jours, basculez vers Mimir ou VictoriaMetrics.

Monitoring Kubernetes et applications avec métriques custom

Déploiement de la stack avec Prometheus Operator

Pour surveiller un cluster Kubernetes, le déploiement manuel de la stack complète devient vite complexe. Prometheus Operator automatise cette tâche en décrivant la configuration sous forme de ressources Kubernetes natives. Il gère le cycle de vie des instances Prometheus, déploie Alertmanager et crée les cibles de scraping à partir des annotations présentes sur vos pods.

Le cœur du système repose sur la ressource ServiceMonitor. Elle définit quels services Kubernetes doivent être scrappés et avec quels intervalles. Un ServiceMonitor remplace avantageusement la configuration statique du fichier prometheus.yml : les cibles sont découvertes dynamiquement via les labels, et les changements d’infrastructure sont répercutés automatiquement. Prometheus Operator s’appuie sur le mécanisme de découverte de services de Kubernetes, ce qui évite d’avoir à maintenir une liste de cibles à la main.

Cette approche est cohérente avec le modèle pull natif de Prometheus : chaque pod expose ses métriques sur un endpoint /metrics, et le serveur vient les récupérer à intervalle régulier.

Exposition de métriques applicatives custom

Pour exposer les métriques de votre propre application, vous devez instrumenter le code. Les bibliothèques clientes officielles simplifient grandement cette étape :

• Client officiel Python prometheus_client : idéal pour les services Python, il expose un endpoint HTTP /metrics prêt à l’emploi.
• Micrometer pour applications Java : la bibliothèque de référence pour JVM, elle s’intègre nativement à Spring Boot et fournit des métriques sur la mémoire, le CPU et les threads.
• Exposition des métriques sur /metrics : le serveur Prometheus viendra scraper cet endpoint à l’intervalle défini, généralement toutes les 15s.
• Éviter labels à cardinalité élevée : n’utilisez jamais d’identifiants uniques comme user_id ou request_id en tant que labels, cela créerait des millions de séries temporelles et pourrait mener à un OOM garanti dès 1M de séries.
• Alternatives pour métriques push : si vos jobs sont de courte durée (batch, cron), utilisez PushGateway pour pousser les métriques à la fin de l’exécution, plutôt que de laisser le serveur venir les chercher.

Chaque métrique exposée suit l’un des 4 types fondamentaux : counter pour les compteurs croissants, gauge pour les valeurs oscillantes, histogram et summary pour les distributions de latence. Comprendre cette typologie est essentiel pour écrire des requêtes PromQL pertinentes ensuite dans vos dashboards Grafana.

Débogage et troubleshooting de la stack

Commencez par vérifier que le processus et le port 9090 sont actifs. Si le service est mort ou que le port est occupé par un autre process, l’interface ne répondra pas. Utilisez ensuite l’outil promtool pour valider la syntaxe de votre fichier de configuration, une étape rapide qui évite 80% des confusions.

Testez chaque cible manuellement : un simple curl sur l’endpoint /metrics permet de confirmer que l’exporter répond et expose bien les métriques brutes. Vérifiez également l’état de vos targets directement dans l’interface de Prometheus, sur la page Status, pour identifier les erreurs de scraping en quelques secondes. Un scrape interval de 15s peut masquer des problèmes de latence réseau, pensez à l’ajuster.

Dans Grafana, l’erreur « Data source unavailable » signale un souci de connexion ou de firewall vers le port 9090. Le message « No data points » sur un graphique indique que la requête PromQL ne trouve aucune série correspondant à vos filtres de labels, ou que la rétention de 15 jours a purgé les données historiques. Testez votre requête dans l’onglet Explore de Grafana pour isoler le problème et vérifier la disponibilité des métriques. Si vous atteignez 1M de séries temporelles, prévoyez une évolution d’architecture vers un stockage externalisé.

Publications similaires :

1. Automatiser la création de rapports mensuels avec l’IA : guide pratique et outils
2. Générer des formules avec l’IA dans Google Sheets : guide pratique
3. Agent IA en gestion de projet : guide complet 2025
4. Versioning d’API REST : stratégies, bonnes pratiques et gestion des versions