L’industrie du monitoring souffre d’une addiction à la complexité. Prometheus a besoin de cAdvisor, Grafana, node_exporter et Alertmanager. Datadog a besoin d’un agent et d’un compte SaaS. Même des outils « simples » comme Uptime Kuma ont besoin de Node.js et d’une base de données séparée.
Ce n’est plus la seule option. Le paysage de 2026 est très différent d’il y a cinq ans : les coûts du monitoring SaaS ont grimpé au point que les factures Datadog dépassent régulièrement les coûts d’hébergement des petites équipes, et les outils self-hosted ont mûri jusqu’à ce qu’un seul binaire Go remplace une stack de cinq conteneurs.
Ce que « binaire unique » veut dire
Un outil de monitoring en binaire unique se livre sous la forme d’un seul exécutable. Aucune dépendance d’exécution, aucune base de données externe, aucun serveur frontend séparé. Le moteur de monitoring, l’interface web, la base de données et le système d’alertes sont compilés dans un seul artefact.
En termes Docker : une image, un conteneur, un volume.
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
volumes:
maintenant-data:
Pas de conteneur Postgres. Pas de conteneur Redis. Pas de nginx devant. Pas de processus worker séparés.
Ce qui a changé
Trois tendances ont convergé :
embed.FSde Go a rendu trivial l’embarquement d’une interface web complète dans un seul binaire. Plus besoin de serveur frontend séparé.- Le mode WAL de SQLite a prouvé qu’une base embarquée encaisse des charges de monitoring temps réel sans PostgreSQL ni InfluxDB.
- La domination de Docker dans le self-hosting a permis aux outils de supposer un runtime de conteneurs et d’éviter la complexité du « marche sur bare metal, VM, conteneurs et Kubernetes ».
Le résultat : une génération d’outils radicalement plus simples que leurs prédécesseurs.
| Ancienne façon (2020) | Nouvelle façon (2026) | |
|---|---|---|
| Architecture | Prometheus + Grafana + cAdvisor + Alertmanager | Binaire unique |
| Base de données | InfluxDB ou Prometheus TSDB | SQLite embarqué |
| Frontend | Application React/Angular séparée | Embarqué via embed.FS |
| Config | prometheus.yml + grafana.ini + alertmanager.yml | Zéro (auto-découverte) |
| RAM | 500+ Mo combiné | 20 Mo |
| Temps d’installation | 1 à 2 heures | 30 secondes |
Pourquoi le self-hosted compte plus que jamais
Souveraineté des données
Les réglementations sur la résidence des données n’ont fait que se renforcer. RGPD, DORA, NIS2 — les acronymes se multiplient. Envoyer ses données d’infrastructure à un fournisseur SaaS américain est un casse-tête de conformité, même pour une petite entreprise.
Un outil self-hosted garde tout sur votre serveur. Aucune donnée ne quitte votre réseau.
Coût
Une tarification à l’hôte, au Go et à la métrique custom fait grimper les coûts plus vite que l’infrastructure. Une startup avec 30 conteneurs peut facilement dépenser 20 000 €/an rien qu’en monitoring. Un binaire unique self-hosted coûte le compute sur lequel il tourne : un coût marginal quasi nul.
Indépendance
Le monitoring SaaS crée une dépendance à l’infrastructure de quelqu’un d’autre. Quand le fournisseur tombe, votre monitoring tombe pendant que vos services, eux, continuent de tourner. L’ironie est épaisse. Le monitoring self-hosted ne tombe que quand votre propre infrastructure tombe — avec une réserve traitée plus bas.
Pourquoi un seul binaire, précisément
Moins de modes de panne
Chaque composant supplémentaire est un point de panne potentiel. Prometheus peut planter indépendamment de Grafana. Une config Alertmanager peut se désynchroniser de ses règles Prometheus. cAdvisor peut se faire tuer par l’OOM killer pendant que Grafana affiche des données périmées.
Avec un binaire unique, soit l’ensemble fonctionne, soit il ne fonctionne pas. Il n’y a pas d’état de panne partielle à déboguer.
Efficacité mémoire
| Composant | RAM (au repos) |
|---|---|
| Prometheus | 150-300 Mo |
| Grafana | 100-200 Mo |
| cAdvisor | 100-200 Mo |
| node_exporter | 20-50 Mo |
| Alertmanager | 30-50 Mo |
| Total | 400-800 Mo |
| Maintenant | 20 Mo |
Sur un VPS de 2 Go, c’est la différence entre avoir de la place pour vos vrais services et se battre pour la mémoire.
Zéro configuration
Un binaire unique embarque des valeurs par défaut sensées pour tout, parce qu’il contrôle toute la chaîne. 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 à surveiller.
La seule configuration tient dans des labels Docker sur vos propres services :
labels:
maintenant.endpoint.http: "http://api:3000/health"
maintenant.endpoint.interval: "30s"
Votre configuration de monitoring vit avec votre code. Versionnée, reproductible, et sans interface séparée à manipuler.
Sauvegardes et mises à jour plus simples
Un fichier SQLite dans un volume. Sauvegardez-le comme vos autres volumes — pas de pg_dump, pas de snapshot TSDB, pas d’export de dashboards. Mettre à jour, c’est docker compose pull && docker compose up -d : une image, un conteneur, aucune matrice de compatibilité entre Prometheus, Grafana et leurs plugins.
Couverture unifiée
Un seul outil couvre conteneurs, endpoints HTTP/TCP, certificats SSL, tâches cron, ressources système et détection de mises à jour. Les alertes et la page de statut publique sont incluses, pas boulonnées comme des services séparés.
L’avantage Go
La plupart des outils de monitoring en binaire unique sont écrits en Go, pour de bonnes raisons :
- Compilation statique : aucune dépendance d’exécution, aucune bibliothèque partagée.
- Faible empreinte mémoire : les goroutines coûtent peu, le ramasse-miettes est efficace.
- Compilation croisée : un seul build produit linux/amd64, linux/arm64 et macOS.
- Assets embarqués :
embed.FSembarque tout le frontend dans le binaire.
Maintenant embarque son interface web, son moteur SQLite et toute sa logique de monitoring dans un binaire d’environ 20 Mo.
Les compromis
Les outils en binaire unique sont opinionnés par nature. On échange de la flexibilité contre de la simplicité :
- Pas de tracing distribué. Si vous avez besoin d’une observabilité de niveau OpenTelemetry, ce n’est pas la bonne classe d’outil.
- Pas de rétention infinie. SQLite embarqué n’est pas une base time-series taillée pour des années de données.
- Pas de dashboards personnalisés ni de langage de requête. Les vues sont préconstruites, il n’y a pas d’équivalent PromQL et pas d’écosystème de plugins.
- Limites de mise à l’échelle. Un binaire par hôte ou par cluster, pas un système distribué. L’agrégation multi-région reste le domaine des stacks distribuées.
- Un hôte à perdre. Si la machine qui l’exécute meurt, le monitoring meurt avec elle. Faites-le tourner ailleurs que sur l’infrastructure qu’il surveille.
Quand le choisir
Choisissez un outil en binaire unique si vous vous auto-hébergez sur un à cinq serveurs, si vous exploitez Docker Compose ou un Kubernetes mono-nœud, si vous voulez un monitoring qui fonctionne sans configuration, si vous préférez la simplicité à la personnalisation, ou si votre VPS manque de RAM.
Si vous gérez des centaines de serveurs chez plusieurs fournisseurs cloud et qu’il vous faut des dashboards sur mesure avec des requêtes ad hoc, une stack distribuée est le bon outil. Pour tous les autres, un seul binaire suffit.
Installer Maintenant : monitoring self-hosted pour Docker et Kubernetes → · Comparer les éditions →