Monitoring en Binaire Unique : Pourquoi C'est Important

L’industrie du monitoring a une addiction à la complexité. Prometheus a besoin de cAdvisor, Grafana, node_exporter et Alertmanager. Datadog nécessite un agent plus un compte SaaS. Netdata consomme 300+ Mo de RAM. Même des outils “simples” comme Uptime Kuma nécessitent Node.js et une base de données séparée.

Il y a une meilleure approche.

Ce Que “Binaire Unique” Signifie Vraiment

Un outil de monitoring en binaire unique est livré sous forme d’un seul fichier exécutable. Pas de dépendances runtime. Pas de base de données externe. Pas de serveur frontend séparé. Tout — le moteur de monitoring, l’interface web, la base de données, le système d’alertes — est compilé en un seul artefact.

En termes Docker : une image, un conteneur, un volume. C’est tout.

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
    restart: unless-stopped

Pas de conteneur postgres. Pas de conteneur redis. Pas de reverse proxy nginx devant. Pas de processus worker séparés.

Pourquoi C’est Important pour les Self-Hosters

Moins de modes de défaillance

Chaque composant supplémentaire dans votre stack de monitoring est un point de défaillance potentiel. Prometheus peut crasher indépendamment de Grafana. Votre config Alertmanager peut se désynchroniser de vos règles Prometheus. cAdvisor peut OOM pendant que Grafana continue d’afficher des données obsolètes.

Avec un binaire unique, soit tout fonctionne, soit rien ne fonctionne. Pas d’état de défaillance partielle à debugger.

Efficacité des ressources

Maintenant utilise ~17 Mo de RAM au repos. Comparez avec une stack Grafana typique :

Sur un VPS de 2 Go, c’est la différence entre avoir de la place pour vos services réels et se battre pour la mémoire.

Zéro configuration

Un binaire unique peut embarquer des valeurs par défaut sensées pour tout parce qu’il contrôle toute la stack. Pas de prometheus.yml à écrire, pas de datasource Grafana à configurer, pas d’arbre de routage Alertmanager à concevoir.

Maintenant se connecte au socket Docker, découvre vos conteneurs, et commence à monitorer. La seule “configuration” ce sont les labels Docker sur vos services pour les checks d’endpoints HTTP.

Sauvegardes simplifiées

Un fichier SQLite dans un volume. Sauvegardez-le comme vous sauvegardez vos autres volumes. Pas de pg_dump, pas de snapshots TSDB Prometheus séparés, pas d’exports de dashboards Grafana.

Mises à jour simplifiées

docker compose pull && docker compose up -d

Une seule image à tirer. Un seul conteneur à redémarrer. Pas de matrice de compatibilité entre Prometheus, Grafana et leurs plugins respectifs.

Les Compromis

Les outils en binaire unique sont opinionnés par nature. Vous échangez de la flexibilité contre de la simplicité :

• Pas de dashboards personnalisés — les vues sont pré-construites
• Pas d’écosystème de plugins — ce qui est livré est ce que vous avez
• Pas de langage de requête custom — pas d’équivalent PromQL
• Limites de scaling — un binaire par hôte ou cluster, pas un système distribué

Pour 95% des stacks Docker self-hosted, ces compromis sont une fonctionnalité, pas une limitation.

L’Avantage Go

La plupart des outils de monitoring en binaire unique sont écrits en Go, et pour une bonne raison :

• Compilation statique — pas de dépendances runtime, pas de bibliothèques partagées
• Faible empreinte mémoire — les goroutines sont peu coûteuses, le garbage collection est efficace
• Cross-compilation — un seul build produit des binaires pour linux/amd64, linux/arm64, macOS
• Assets embarqués — embed.FS permet d’embarquer tout le frontend dans le binaire

Maintenant embarque son interface web, son moteur SQLite et toute sa logique de monitoring dans un seul binaire de ~20 Mo.

Quand Choisir un Outil en Binaire Unique

Choisissez un outil de monitoring en binaire unique si vous :

• Self-hostez sur 1-5 serveurs
• Utilisez Docker Compose ou Kubernetes mono-noeud
• Voulez du monitoring qui “juste marche” sans configuration
• Valorisez la simplicité plutôt que la personnalisation infinie
• Avez des ressources limitées (VPS de 1-4 Go de RAM)

Si vous gérez des centaines de serveurs sur plusieurs fournisseurs cloud et avez besoin de dashboards personnalisés avec des requêtes ad-hoc, une stack de monitoring distribuée (Prometheus/Grafana, Datadog, etc.) est le bon outil.

Pour tous les autres, un binaire unique suffit.

Installer Maintenant — monitoring en binaire unique pour Docker →