Monitorer Docker Compose Sans Écrire de Fichier de Config

Chaque outil de monitoring vous demande d’écrire des fichiers de config. Prometheus a besoin de prometheus.yml. Grafana a besoin de configs de datasource. Alertmanager a besoin de règles de routage. Même Uptime Kuma vous demande de cliquer dans une UI web pour ajouter chaque monitor manuellement.

Et si votre outil de monitoring se débrouillait… tout seul ?

Le Problème des Fichiers de Config

Les fichiers de config créent trois problèmes :

1. La dérive — votre config de monitoring dérive de votre infrastructure réelle. Vous ajoutez un service et oubliez d’ajouter un monitor. Vous renommez un conteneur et l’ancienne alerte continue de se déclencher.
2. La duplication — votre service est défini dans docker-compose.yml, puis dans prometheus.yml, puis dans Grafana. Trois endroits à mettre à jour pour chaque changement.
3. La courbe d’apprentissage — chaque outil a son propre format de config. PromQL, YAML avec des schémas spécifiques, datasources JSON. Chacun est une chose de plus à apprendre.

L’Approche par Labels

Les labels Docker sont des métadonnées attachées à vos conteneurs. Ils sont définis dans votre docker-compose.yml — le même fichier où vivent vos services. Pas de fichier de config séparé.

Maintenant lit les labels Docker pour configurer le monitoring :

services:
  api:
    image: myapp:latest
    labels:
      maintenant.endpoint.http: "http://api:3000/health"
      maintenant.endpoint.interval: "30s"
      maintenant.endpoint.http.expected-status: "200"

  postgres:
    image: postgres:16
    labels:
      maintenant.endpoint.tcp: "postgres:5432"

  redis:
    image: redis:7-alpine
    labels:
      maintenant.endpoint.tcp: "redis:6379"

Votre configuration de monitoring vit à côté de la définition de vos services. Quand vous ajoutez un service, le monitoring est juste là. Quand vous supprimez un service, le monitoring part avec. Pas de dérive.

Ce Qui Est Auto-Découvert (Zéro Config)

Même sans aucun label, Maintenant auto-découvre :

• Tous les conteneurs — états, health checks, boucles de redémarrage, codes de sortie
• Les projets Compose — conteneurs groupés par leur label com.docker.compose.project
• Les certificats SSL — auto-détectés sur tous les endpoints HTTPS monitorés
• Les ressources système — CPU, RAM, réseau, disque par conteneur et par hôte
• Les mises à jour disponibles — comparaison de digest OCI pour toutes les images en cours d’exécution

Ce Que Vous Configurez par Labels

Les labels ajoutent du monitoring qui nécessite de savoir quoi vérifier :

Checks d’endpoints HTTP

labels:
  maintenant.endpoint.http: "https://api.example.com/health"
  maintenant.endpoint.interval: "15s"
  maintenant.endpoint.http.expected-status: "200"

Checks de connectivité TCP

labels:
  maintenant.endpoint.tcp: "postgres:5432"

Sévérité des alertes

labels:
  maintenant.alert.severity: "critical"

Un Exemple Complet

Voici un stack Docker Compose complet avec monitoring intégré — zéro fichier de config externe :

services:
  traefik:
    image: traefik:v3
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

  api:
    image: myapp:latest
    labels:
      maintenant.endpoint.http: "http://api:3000/health"
      maintenant.endpoint.interval: "15s"

  worker:
    image: myapp:latest
    command: worker

  postgres:
    image: postgres:16
    labels:
      maintenant.endpoint.tcp: "postgres:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    labels:
      maintenant.endpoint.tcp: "redis:6379"

  maintenant:
    image: ghcr.io/kolapsis/maintenant:latest
    ports:
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /proc:/host/proc:ro
      - maintenant-data:/data
    environment:
      MAINTENANT_ADDR: "0.0.0.0:8080"
      MAINTENANT_DB: "/data/maintenant.db"
    restart: unless-stopped

volumes:
  pgdata:
  maintenant-data:

docker compose up -d

C’est tout. Six services monitorés. Zéro fichier de config écrit. Le dashboard montre tout :

Comparé à l’Approche par Fichiers de Config

Pourquoi C’est Important

Le monitoring-as-code ne devrait pas signifier “plus de fichiers de code à maintenir.” Cela devrait signifier “du monitoring qui vit là où vivent vos services.”

Les labels Docker accomplissent cela. Votre configuration de monitoring est :

• Versionnée — elle est dans votre docker-compose.yml, qui est dans votre dépôt git
• Colocalisée — à côté du service qu’elle monitore, pas dans un répertoire séparé
• Atomique — quand vous supprimez un service, son monitoring part avec
• Découvrable — quiconque lit le fichier compose voit ce qui est monitoré

Pas de prometheus.yml. Pas de grafana.ini. Pas d’alertmanager.yml. Juste votre docker-compose.yml avec quelques labels en plus.

Installer Maintenant →