You are currently viewing Observabilité open source : surveiller son infrastructure avec Prometheus, Grafana et Loki

Observabilité open source : surveiller son infrastructure avec Prometheus, Grafana et Loki

Observabilité open source : surveiller son infrastructure avec Prometheus, Grafana et Loki

Déployer des services, c’est bien. Savoir ce qui s’y passe en temps réel, c’est mieux. L’observabilité — métriques, logs et traces — est le pilier souvent négligé d’une infrastructure auto-hébergée. Cet article présente une stack d’observabilité entièrement open source, déployable en quelques conteneurs, pour reprendre le contrôle sur la visibilité de vos services.

Pourquoi l’observabilité est indispensable

Quand on gère ses propres serveurs — Nextcloud, Keycloak, CKAN, Gitea — il est tentant de ne réagir qu’aux pannes. Mais sans métriques ni logs centralisés, chaque incident devient une enquête aveugle. L’observabilité permet de passer d’un mode réactif à un mode proactif : détecter les anomalies avant qu’elles ne deviennent des pannes, comprendre les tendances de consommation, et documenter le comportement réel de l’infrastructure.

Les trois piliers : métriques, logs, traces

L’observabilité repose sur trois types de données complémentaires :

Les métriques sont des valeurs numériques échantillonnées dans le temps : utilisation CPU, mémoire, nombre de requêtes HTTP, latence. Elles répondent à la question « est-ce que ça va ? » et permettent de poser des alertes.

Les logs sont les messages textuels émis par les applications. Centralisés et indexés, ils permettent de comprendre le « pourquoi » quand quelque chose dysfonctionne.

Les traces suivent le parcours d’une requête à travers plusieurs services. Elles sont essentielles dans une architecture de microservices pour identifier les goulets d’étranglement.

La stack proposée

Voici une stack cohérente, entièrement open source et auto-hébergeable :

  • Prometheus — collecte et stockage des métriques. Il fonctionne en mode pull : il interroge périodiquement les endpoints /metrics exposés par vos services. Sa configuration est déclarative et son modèle de données (séries temporelles avec labels) est devenu un standard de fait.
  • Grafana — visualisation et tableaux de bord. Il se connecte à Prometheus, Loki et d’autres sources pour créer des dashboards lisibles et partageables. La communauté propose des centaines de dashboards prêts à l’emploi pour les services courants (Nginx, PostgreSQL, Docker, Node Exporter).
  • Loki — agrégation de logs. Conçu par l’équipe Grafana, Loki adopte une approche légère : il indexe les labels des logs, pas leur contenu complet, ce qui le rend économe en ressources comparé à Elasticsearch.
  • Promtail — agent de collecte de logs qui envoie les flux vers Loki. Il s’installe comme sidecar ou en daemon et sait lire les logs Docker nativement.
  • Node Exporter — expose les métriques système (CPU, RAM, disque, réseau) au format Prometheus. Un incontournable pour surveiller l’hôte lui-même.

Déploiement avec Docker Compose

L’ensemble de la stack tient dans un seul fichier docker-compose.yml. Voici la structure typique :

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=changeme

  loki:
    image: grafana/loki:latest
    ports:
      - "3100:3100"

  promtail:
    image: grafana/promtail:latest
    volumes:
      - /var/log:/var/log
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
      - ./promtail.yml:/etc/promtail/config.yml

  node-exporter:
    image: prom/node-exporter:latest
    ports:
      - "9100:9100"
    pid: host
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro

volumes:
  prometheus_data:
  grafana_data:

En quelques minutes, vous disposez d’un système de monitoring complet, accessible via Grafana sur le port 3000.

Configuration de Prometheus

Le fichier prometheus.yml déclare les cibles à scraper :

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['node-exporter:9100']

  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

Chaque service exposant un endpoint /metrics peut être ajouté comme cible. Nginx (via nginx-prometheus-exporter), PostgreSQL (via postgres_exporter) et Keycloak exposent tous des métriques compatibles.

Créer des alertes avec Alertmanager

Prometheus intègre un moteur de règles d’alerte. Couplé à Alertmanager, il peut envoyer des notifications par email, Slack ou webhook. Un exemple de règle :

groups:
  - name: infra
    rules:
      - alert: HighMemoryUsage
        expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Mémoire disponible sous 10% sur {{ $labels.instance }}"

Bonnes pratiques

Commencer petit. Node Exporter + Prometheus + Grafana suffisent pour démarrer. Ajoutez Loki quand le besoin de centraliser les logs se fait sentir.

Utiliser les dashboards communautaires. Sur grafana.com/dashboards, importez des dashboards prêts à l’emploi par ID. Le dashboard Node Exporter Full (ID 1860) est un classique.

Sécuriser l’accès. En production, placez Grafana derrière votre reverse proxy Nginx avec authentification Keycloak (OAuth2 Proxy). Ne laissez pas Prometheus et Loki exposés publiquement.

Dimensionner la rétention. Par défaut, Prometheus conserve 15 jours de données. Ajustez avec --storage.tsdb.retention.time selon votre espace disque et vos besoins d’historique.

Étiqueter proprement. Adoptez une convention de labels cohérente dès le début (environnement, service, instance). C’est ce qui rendra vos requêtes PromQL exploitables à l’échelle.

Conclusion

L’observabilité n’est pas un luxe réservé aux grandes équipes DevOps. Avec Prometheus, Grafana et Loki, une personne seule peut mettre en place un monitoring professionnel de son infrastructure en une après-midi. C’est un investissement qui se rentabilise dès le premier incident évité — et qui transforme la gestion d’infrastructure d’un exercice de pompier en une pratique sereine et maîtrisée.