Grafana + Prometheus : du monitoring de niveau entreprise sans licence

Datadog facture à l'hôte monitoré, au volume de logs, aux métriques custom — la facture grimpe vite dès que l'infrastructure dépasse deux ou trois serveurs. Grafana et Prometheus font le même travail : collecter des métriques (CPU, RAM, latence, taux d'erreur) et les visualiser en dashboards temps réel avec alerting. Cette stack fait tourner le monitoring de Kubernetes lui-même, de SoundCloud, de la moitié des équipes SRE qui ont un budget infra à surveiller sans exploser le budget monitoring.

Prometheus est une base de données de séries temporelles spécialisée : il interroge ("scrape") périodiquement des endpoints HTTP qui exposent des métriques dans un format texte standardisé, et stocke l'historique. Grafana se branche dessus comme source de données et transforme ces séries en graphiques, jauges, tableaux et alertes visuelles. Les deux sont indépendants et modulaires — Grafana affiche aussi bien des données PostgreSQL, InfluxDB ou Loki que Prometheus.

Installation avec Docker Compose

services:
  prometheus:
    image: prom/prometheus:latest
    restart: always
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prom_data:/prometheus
    ports:
      - "9090:9090"
 
  node-exporter:
    image: prom/node-exporter:latest
    restart: always
    ports:
      - "9100:9100"
 
  grafana:
    image: grafana/grafana:latest
    restart: always
    environment:
      GF_SECURITY_ADMIN_PASSWORD: changeme
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"
 
volumes:
  prom_data:
  grafana_data:

node-exporter expose les métriques système de la machine hôte (CPU, RAM, disque, réseau) sur le port 9100 — Prometheus vient les récupérer à intervalle régulier.

global:
  scrape_interval: 15s
 
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['node-exporter:9100']
 
  - job_name: 'mon-api'
    static_configs:
      - targets: ['mon-api:8080']
    metrics_path: '/metrics'

Chaque job_name définit une cible à interroger. Une application custom expose ses propres métriques sur /metrics via une librairie cliente Prometheus (disponible pour Go, Node.js, Python, Java...), et Prometheus vient les collecter au même rythme que les métriques système.

Instrumenter une application

Exposer des métriques custom depuis une API demande peu de code. Exemple en Node.js avec prom-client :

const client = require('prom-client');
const express = require('express');
const app = express();
 
const httpDuration = new client.Histogram({
  name: 'http_request_duration_seconds',
  help: 'Durée des requêtes HTTP',
  labelNames: ['method', 'route', 'status'],
});
 
app.use((req, res, next) => {
  const end = httpDuration.startTimer();
  res.on('finish', () => {
    end({ method: req.method, route: req.path, status: res.statusCode });
  });
  next();
});
 
app.get('/metrics', async (req, res) => {
  res.set('Content-Type', client.register.contentType);
  res.end(await client.register.metrics());
});

Cet endpoint /metrics renvoie un texte brut que Prometheus sait parser — le format est simple et lisible directement dans un navigateur.

Connecter Grafana à Prometheus

Dans Grafana (http://votre-serveur:3000, login admin/mot de passe défini), ajouter une source de données : Connections > Data sources > Prometheus, URL http://prometheus:9090. Une fois connectée, les dashboards communautaires s'importent en un clic via leur ID depuis grafana.com/dashboards — le dashboard "Node Exporter Full" (ID 1860) donne une vue système complète en une importation.

PromQL — le langage de requête

Prometheus utilise PromQL pour agréger et filtrer les métriques dans les dashboards et les alertes.

# Utilisation CPU moyenne sur 5 minutes
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
 
# Taux d'erreur HTTP sur l'API
sum(rate(http_request_duration_seconds_count{status=~"5.."}[5m]))
/
sum(rate(http_request_duration_seconds_count[5m]))

Le second exemple calcule un taux d'erreur 5xx sur une fenêtre glissante de 5 minutes — la base de la plupart des alertes de production sérieuses.

Alerting

Grafana gère l'alerting directement, sans outil séparé. Une règle d'alerte se définit sur n'importe quelle requête PromQL avec un seuil :

Condition : taux d'erreur > 5% pendant 3 minutes
Action : notifier via webhook Mattermost / Slack / PagerDuty

# Contact point Grafana vers un webhook
- name: mattermost-alerts
  type: webhook
  settings:
    url: https://chat.mondomaine.fr/hooks/xxxxxxxxxxxxxxxxxxxxxxxxxxxx

Les mêmes canaux que pour Uptime Kuma peuvent recevoir ces alertes — la différence de fond entre les deux outils : Uptime Kuma répond à "est-ce up ou down", Grafana + Prometheus répond à "quelle est la tendance, et où est le problème exactement".

Grafana/Prometheus vs Datadog vs Uptime Kuma

Prometheus seul n'est pas fait pour du stockage de métriques sur des années — sa rétention par défaut est locale et limitée. Pour du long terme à grande échelle, des projets complémentaires comme Thanos ou Mimir prennent le relais, mais pour un serveur perso ou une petite infra, la rétention par défaut (15 jours, configurable) suffit largement.

Retention et volumétrie

# prometheus.yml — augmenter la rétention
command:
  - '--storage.tsdb.retention.time=90d'

Chaque métrique scrapée toutes les 15 secondes sur 90 jours représente un volume non négligeable — surveiller l'espace disque du volume prom_data devient vite pertinent, un comble pour un outil de monitoring qui doit aussi se surveiller lui-même.

Grafana et Prometheus demandent un vrai investissement d'apprentissage — PromQL n'est pas intuitif au premier abord, et la configuration des scrape targets prend du temps à maîtriser. Mais sur une infrastructure qui tourne déjà Nginx et plusieurs services Docker, c'est littéralement la stack qu'utilisent les plus grandes plateformes tech du monde — gratuite, et sous votre contrôle total.