Maintenant : monitorer toute sa stack Docker depuis un seul conteneur

Posté par  (site web personnel) . Édité par Xavier Teyssier et Pierre Jarillon. Modéré par bobble bubble. Licence CC By‑SA.
Étiquettes :
14
17
mar.
2026
Technologie

Maintenant est un logiciel libre de monitoring d'infrastructure, conçu pour les administrateurs et développeurs qui font tourner des conteneurs Docker ou Kubernetes. Il se déploie sous la forme d'un unique conteneur qui auto-découvre et surveille l'ensemble d'une stack sans configuration préalable.

Le projet est publié sous licence AGPL-3.0. Le code source complet est disponible sur GitHub, y compris les fonctionnalités de l'édition Pro.

Le problème

Quand on auto-héberge une vingtaine (ou une quarantaine) de conteneurs sur un VPS, le monitoring finit souvent en une collection d'outils déconnectés : Uptime Kuma pour les checks HTTP, Healthchecks.io pour les tâches cron, un script bash pour les certificats SSL, Portainer ouvert dans un onglet pour voir si les conteneurs tournent, et un docker pull manuel de temps en temps pour vérifier les mises à jour. Cinq outils, zéro communication entre eux, aucune vue d'ensemble.

Maintenant regroupe tout ça dans un seul processus.

Sommaire

Ce que ça fait

Le conteneur se branche sur le socket Docker en lecture seule (il ne crée, ne démarre et n'arrête jamais de conteneurs) et découvre automatiquement tout ce qui tourne. À partir de là :

  • Suivi des conteneurs : états (running, stopped, restarting), health checks Docker natifs, détection de boucles de redémarrage, groupement automatique par projet Compose
  • Métriques de ressources : CPU, mémoire, réseau et I/O disque par conteneur, avec une vue "top consumers" pour identifier rapidement les gourmands
  • Monitoring d'endpoints : sondage actif HTTP/TCP avec suivi des temps de réponse, codes de statut, correspondance de mots-clés, seuils configurables
  • Monitoring de cron jobs : URLs de heartbeat uniques — votre tâche planifiée envoie un ping, Maintenant vous alerte si le ping n'arrive pas
  • Certificats SSL/TLS : détection automatique depuis les endpoints HTTPS, vérification de chaîne complète, alertes avant expiration (30j, 14j, 7j, 3j, 1j)
  • Détection des mises à jour : scan des registres OCI (Docker Hub, GHCR, etc.), comparaison de digests et de tags semver, signalement des sauts de version critiques, commandes de mise à jour et rollback intégrées (Compose-aware)
  • Analyse de sécurité réseau : détection automatique des configurations dangereuses — ports de bases de données exposés sur 0.0.0.0, conteneurs en mode privileged ou host-network, et pour Kubernetes, NodePort/LoadBalancer sans NetworkPolicy
  • Page de statut publique : intégrée, personnalisable, reflète automatiquement l'état des monitors
  • Serveur MCP : serveur Model Context Protocol intégré avec authentification OAuth2, pour requêter l'état de l'infrastructure depuis un assistant IA compatible

Stack technique

Le choix technique central est la simplicité de déploiement :

  • Binaire unique Go compilé statiquement, avec le frontend Vue 3 + TypeScript + Tailwind embarqué via embed.FS
  • SQLite en mode WAL pour le stockage — pas de base de données externe, pas de Redis, pas de file de messages
  • SSE (Server-Sent Events) pour les mises à jour temps réel dans le navigateur — plus simple que les WebSockets, fonctionne à travers n'importe quel reverse proxy sans configuration particulière
  • Moins de 20 Mo de RAM au repos
  • Image multi-architecture : amd64 et arm64
  • PWA : installable sur mobile

L'authentification n'est volontairement pas intégrée — Maintenant est conçu pour fonctionner derrière un reverse proxy avec middleware d'authentification (Authelia, Authentik, OAuth2 Proxy…), exactement comme Dozzle ou Prometheus. Les endpoints de heartbeat (/ping/{uuid}) et la page de statut publique sont prévus pour être accessibles sans authentification.

La configuration est possible soit par labels Docker sur les conteneurs, soit par l'interface web :

labels:
  maintenant.endpoint.http: "https://api:3000/health"
  maintenant.endpoint.interval: "15s"
  maintenant.alert.severity: "critical"
  maintenant.group: "production"

Support Kubernetes

Maintenant détecte automatiquement s'il tourne dans un cluster Kubernetes (via le compte de service) ou sur Docker (via le socket). Un ClusterRole read-only (maintenant-reader) suffit. Le monitoring se fait au niveau des workloads (Deployments, DaemonSets, StatefulSets) avec filtrage par namespace.

Modèle économique

Le projet suit un modèle open-core :

L'édition Community est complète et utilisable sans restriction pour un usage solo : monitoring conteneurs, endpoints, heartbeats, certificats, mises à jour, sécurité réseau, page de statut, support Kubernetes, alertes par webhooks et Discord, API REST + SSE.

L'édition Pro (9 €/mois ou 90 €/an) ajoute des canaux d'alerte supplémentaires (Slack, Microsoft Teams, Email/SMTP), la détection de CVE via OSV.dev, un tableau de bord de posture sécurité, la gestion d'incidents, les fenêtres de maintenance et les notifications aux abonnés de la page de statut.

L'intégralité du code source, y compris les fonctionnalités Pro, est visible sur GitHub sous AGPL-3.0. Le tier Pro est déverrouillé au runtime par une clé de licence — même binaire, même image Docker.

Déploiement rapide

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:

Trente secondes plus tard, l'interface affiche tous vos conteneurs. Aucune configuration nécessaire.

Comparaison avec les outils existants

Maintenant Uptime Kuma Portainer Dozzle Prometheus+Grafana
Auto-découverte conteneurs Oui Non Oui Oui Via cAdvisor
Monitoring endpoints HTTP/TCP Oui Oui Non Non Via Blackbox
Monitoring cron/heartbeat Oui Oui Non Non Non
Certificats SSL Oui Oui Non Non Via exporter
Métriques CPU/RAM/réseau Oui Non Limité Non Oui
Détection mises à jour images Oui Non Oui Non Non
Sécurité réseau Oui Non Non Non Non
Page de statut Oui Oui Non Non Non
Dépendances externes Aucune Node.js Docker API Docker API 3+ conteneurs

Aller plus loin

  • # Alternative

    Posté par  (site web personnel) . Évalué à 1 (+0/-0).

    Sympa, ca ressemble par contre beaucoup à Dockhand: https://dockhand.pro/

    • [^] # Re: Alternative

      Posté par  (site web personnel) . Évalué à 5 (+4/-0).

      Hello Raoul, pas tout à fait, Dockhand est plutôt un concurrent de Portainer : c'est un outil de gestion qui démarre, arrête et redéploie tes conteneurs.

      Maintenant ne touche jamais à ta stack, c'est purement de l'observation et de l'alerte : état des conteneurs, probing HTTP/TCP, heartbeats, SSL, métriques, page de statut.

      Benjamin

  • # Cluster reader

    Posté par  (site web personnel) . Évalué à 5 (+3/-0).

    Un ClusterRole read-only (maintenant-reader) suffit.

    C'est déjà trop. C'est le gros reproche de la plupart des solutions devant superviser l'ensemble d'un cluster (ici k8s). Une compromission de la solution de monitoring suffit alors à obtenir pléthore d'informations. La logique devrait être inverse : un agent par namespace devrait remonter l'information, pas l'inverse.

    • [^] # Re: Cluster reader

      Posté par  (site web personnel) . Évalué à 3 (+2/-0).

      Je suis totalement d'accord avec toi sur le principe, un ClusterRole read-only donne effectivement une vue large sur le cluster, et dans un contexte multi-tenant strict ou en environnement très sensible, c'est un vrai sujet.

      Cela dit, c'est le compromis assumé de Maintenant : un seul déploiement, zéro config, tu vois ton cluster en 30 secondes. Demander à l'utilisateur de déployer un agent par namespace, c'est exactement le genre de complexité opérationnelle que le projet cherche à éviter — et que la plupart des outils de monitoring K8s (Prometheus, Datadog, Grafana Agent…) évitent aussi d'ailleurs, pour les mêmes raisons.

      En pratique, il y a déjà un filtrage par namespace configurable, tu peux restreindre Maintenant à un ou plusieurs namespaces spécifiques plutôt que de lui donner une vue cluster-wide. Dans ce cas un Role (namespace-scoped) suffit au lieu du ClusterRole.

      Mais oui, pour les environnements avec des exigences d'isolation fortes, Maintenant n'est probablement pas le bon outil. Et c'est OK, le positionnement c'est les petites équipes et les déploiements raisonnables, pas les clusters multi-tenant enterprise.

      Benjamin

  • # Open source washing

    Posté par  (site web personnel, Mastodon) . Évalué à 0 (+1/-1).

    Bonjour,

    Je suis très étonné qu'un tel exemple d'open source washing soit publié sur ce site.

    "Maintenant" est publié sous licence AGPLv3, ou, sous licence commerciale contre payement d'un abonnement. Les contributeurs doivent signer une CLA (contributor licensing agreement), qui permet à l'entreprise derrière "Maintenant" de choisir à son gré la licence du code contribué et sans contrepartie financière :

    You grant the Maintainer a perpetual, irrevocable, worldwide, non-exclusive, royalty-free license to use, reproduce, modify, distribute, sublicense, and otherwise exploit your Contributions, in source and binary forms, as part of the Maintenant project.

    On a vu maintes fois des projets de ce type changer la licence des versions futures vers une licence propriétaire (tout en laissant le code source disponible, pour faire croire que le logiciel est open source).

    De plus, le code contient des vérifications en dur de la licence commerciale pour limiter certaines fonctionnalités, par exemple ici pour le nombre de "heartbeats" :

    https://github.com/kOlapsis/maintenant/blob/bdbe87237b603c2caaebb47cff80a1b04c540bda/internal/heartbeat/service.go#L86

    (LicenseChecker ne semble jamais défini ailleurs, donc il doit manquer du code dans le dépôt concernant la version commerciale - ou il s'agit d'un oubli)

    Étant donné que le code est publié sous licence AGPLv3, libre à chacun de supprimer le code limitant les fonctionnalités et de recompiler une version de "Maintenant" avec les modifications (et donc avec certaines fonctionnalités "pro" débloquées sans payer l'abonnement). Et puis, hors limitation de l'usage de la marque (si elle existe), il est possible de publier cette nouvelle version du code sous AGPLv3. Comme il s'agit d'un type d'outil souvent utilisé en interne, il est tout à fait possible de garder ses modifications privées, tout en respectant cette licence, d'ailleurs ("all users interacting with it remotely through a computer network" correspondant à des utilisateurs internes).

    • [^] # Re: Open source washing

      Posté par  (site web personnel) . Évalué à 3 (+2/-0).

      Salut,
      Le code est intégralement sous AGPL-3.0, y compris les features Pro. Rien n'est caché, rien n'est dans un repo privé. Le CLA c'est le même modèle que Nextcloud ou GitLab — mécanique pour maintenir le dual-licensing.
      Oui, y'a du gating sur certaines features. Oui, on peut le retirer et recompiler. C'est exactement ce que l'AGPL permet et j'ai aucun problème avec ça.
      Le modèle open-core, on peut ne pas aimer. Mais tout le monde ne vit pas d'amour et d'eau fraîche. Le Pro à 9€/mois c'est ce qui me permet de maintenir le projet dans la durée. Si c'est de l'open source washing, alors la moitié de l'écosystème libre qu'on utilise au quotidien l'est aussi.
      Benjamin

      Benjamin

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.