Monitoring Docker pour les agences et les MSP

Vous exploitez les serveurs des autres. Chaque stack est un peu différente, chaque client pose la même question — est-ce que ça tourne ? — et la réponse honnête vient aujourd’hui de cinq tableaux de bord ouverts en parallèle, ou d’un mail du client arrivé avant votre alerte.

Cette page traite de la façon de combler cet écart avec un conteneur léger par parc, plutôt qu’une pile de monitoring par client.

Ce qu’exige réellement l’infrastructure d’un client

Surveiller son homelab et surveiller une infrastructure qu’on est payé pour garder en vie sont deux métiers différents. Le second ajoute quatre exigences que le premier n’a jamais :

• Une licence qui l’autorise. Personal vise une seule personne sur sa propre infrastructure, freelances inclus. Elle ne couvre ni l’infrastructure de tiers ni la revente du monitoring comme service. Pro le fait, et accorde le droit d’usage commercial.
• La portée du parc. Un seul Maintenant, beaucoup de machines. Pro supprime totalement la limite d’hôtes.
• Des alertes qui atteignent un humain. Routage e-mail dès Personal, Slack et Teams en Pro, politiques d’escalade si le premier destinataire n’acquitte pas, et fenêtres de maintenance pour qu’une migration planifiée ne réveille personne à 2 h du matin.
• Quelque chose à montrer au client. Une page de statut publique à votre marque, avec l’historique des incidents et les notifications aux abonnés.

Comment ça se déploie sur un parc

Un serveur fait tourner Maintenant. Chaque autre machine fait tourner un agent léger, enrôlé avec un jeton unique, qui remonte son état Docker, Swarm et Kubernetes à l’instance centrale. Il n’y a pas d’installation à concevoir par client, pas de pile d’exporteurs à exploiter, et rien à configurer par conteneur : Maintenant lit le socket Docker en lecture seule et découvre ce qui tourne.

Ajouter un client, c’est enrôler ses serveurs. En retirer un, c’est révoquer un jeton.

services:
  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:
  maintenant-data:

Montez le socket en lecture seule. Maintenant observe, il n’écrit jamais dans la stack qu’il surveille. Il n’embarque volontairement aucune authentification : placez-le derrière le reverse proxy et le middleware d’authentification que vous exploitez déjà, comme vous le feriez pour Dozzle ou Prometheus.

Ce qu’une seule instance surveille

Sur l’ensemble des hôtes enrôlés, au même endroit :

• l’état des conteneurs, les health checks, les boucles de redémarrage et les logs ;
• les endpoints HTTP et TCP, avec des seuils configurables ;
• l’expiration des certificats SSL/TLS, détectés automatiquement depuis les endpoints déjà surveillés ;
• les échéances des tâches cron et des jobs de fond, via des URL de heartbeat ;
• les métriques CPU, mémoire, réseau et disque par conteneur ;
• les mises à jour d’images, par comparaison des digests du registre OCI ;
• les constats de sécurité réseau — ports exposés sur 0.0.0.0, conteneurs en host-network ou privilégiés, NodePorts Kubernetes à risque — avec enrichissement CVE et score de risque dès Personal.

Le dernier point est celui que les clients demandent rarement et veulent toujours voir dans un rapport.

L’économie du modèle

Le monitoring est l’une des lignes les plus faciles à ajouter à un contrat de maintenance, parce que le client croit déjà payer pour de la disponibilité.

Facturez la supervision 49 €/mois à dix clients : cela fait 490 € de revenu récurrent face à un coût logiciel de 29 €/mois — 290 € par an — qui ne bouge pas quand le onzième client arrive. Aucune tarification à l’hôte à modéliser, aucun usage facturé à réconcilier en fin de mois.

Ce que ce n’est pas

Poser les limites clairement évite un essai inutile :

• Pas multi-tenant. Il n’y a pas de compte par client isolant la vue d’un customer de celle d’un autre. Ce que le client voit, c’est la page de statut que vous publiez pour lui ; ce que vous voyez, c’est tout le parc.
• Pas un stockage de métriques longue durée. L’historique va jusqu’à 30 jours en Pro. S’il vous faut des années de données haute résolution, exportez via l’API REST vers votre propre stockage, ou gardez Prometheus pour ce seul usage.
• Pas hautement disponible. Un conteneur, un hôte. Si cet hôte meurt, le monitoring meurt avec lui.
• Pas un APM. Ni tracing distribué, ni profilage au niveau du code. Il surveille l’infrastructure, pas les entrailles applicatives.

Par où commencer

Installez Community sur une machine et pointez-le vers une stack que vous exploitez déjà. Cela ne coûte rien et prend environ 30 secondes. Quand vous enrôlerez le deuxième serveur, ou le premier serveur appartenant à un client, c’est là que Pro commencera à se payer.