Glouton :un agent de monitoring mono-binaire qui fonctionne, tout simplement.
Découverte automatique, TSDB embarquée et panneau local orienté statut — prêt à l'emploi.
L'agent que nous utilisons chez Bleemeo pour faire tourner notre produit SaaS de monitoring, publié en open source. Éprouvé sur serveurs Linux, Docker et Kubernetes.
Démarrage rapide
Le plus court chemin pour voir Glouton à l'œuvre
Sans compte, sans inscription.
docker run -d --name=glouton \
-v /var/lib/glouton:/var/lib/glouton \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /:/hostroot:ro \
-e GLOUTON_BLEEMEO_ENABLE=false \
--pid=host --net=host \
--cap-add SYS_PTRACE --cap-add SYS_ADMIN \
bleemeo/bleemeo-agentOuvrez ensuite http://localhost:8015. Avec Bleemeo désactivé, la TSDB sur disque démarre automatiquement : les plages longues du tableau de bord (24 h, 7 j, 30 j) fonctionnent immédiatement.
À quoi servent ces options Docker
| Option | Pourquoi |
|---|---|
-v /var/lib/glouton:/var/lib/glouton | Conserve le fichier d'état, la TSDB et les données d'enregistrement d'un redémarrage du conteneur à l'autre. |
-v /var/run/docker.sock:/var/run/docker.sock | Détecte les conteneurs qui tournent sur l'hôte et lit leurs statistiques. |
-v /:/hostroot:ro | Accès en lecture seule au système de fichiers de l'hôte (points de montage, disques, ligne de commande du noyau, /proc/<pid> des processus de l'hôte). |
--pid=host | Voit les processus de l'hôte, pour l'explorateur de processus et la découverte par service. |
--net=host | Lit les métriques des interfaces réseau telles que l'hôte les voit, et non celles de l'espace de noms du conteneur. |
--cap-add SYS_PTRACE | Inspecte l'empreinte mémoire des processus et leurs descripteurs de fichiers ouverts. |
--cap-add SYS_ADMIN | Lit les informations de système de fichiers et de cgroup rattachées aux espaces de noms. |
Pour une installation durcie (sans partage du PID ni du réseau de l'hôte, montages plus restreints), suivez la documentation d'installation.
À chaque démarrage, Glouton envoie une unique charge anonyme : un identifiant d'installation aléatoire, la version et le format d'installation de Glouton, l'OS et la version du noyau, le CPU et la mémoire, et le fuseau horaire. Aucune valeur de métrique, aucun nom de service, aucun nom d'hôte, aucune adresse IP. Pour la désactiver : GLOUTON_AGENT_TELEMETRY_ENABLE=false.
Panneau local
Un panneau en direct sur localhost:8015
Cartes KPI, ligne des services découverts et graphiques colorés par statut pour le système, le réseau et les E/S — avec l'historique de la TSDB embarquée. Zoom par glissement sur chaque graphique, filtrage des systèmes de fichiers et des disques par périphérique ou point de montage, et thème aligné sur celui de votre système.
Ce qu'il fait
Un seul binaire : collecter, stocker, exposer
Glouton détecte automatiquement ce qui tourne sur votre hôte ou dans vos conteneurs, collecte les bonnes métriques et les bons contrôles, les stocke localement et expose l'ensemble dans un panneau et une API compatible Prometheus. Tout transfert ailleurs est optionnel.
La tête de la TSDB représente environ la moitié de la mémoire résidente et reste bornée par la cardinalité des métriques, pas par la rétention : conserver plus d'historique sur disque ne coûte pas de RAM.
Collecter
- Découverte automatique des services en cours avec des jeux de métriques choisis — plus de 30 applications et protocoles (nginx, postgres, redis…).
- Runtimes de conteneurs : Docker (y compris Docker Desktop sur macOS, détecté automatiquement), containerd, Kubernetes.
- Métriques applicatives : n'importe quel endpoint Prometheus, JMX pour les applications Java, StatsD pour vos compteurs et jauges.
- Métriques dérivées des logs : journald, syslog, auditd ou logs de conteneurs analysés par un pipeline OpenTelemetry, qui en tire des compteurs. Les lignes elles-mêmes ne sont ni stockées ni transmises.
- Sondes et contrôles : HTTP/HTTPS, TCP, scripts de type Nagios, NRPE.
- Réseau et matériel : SNMP, SMART, IPMI, NVIDIA.
- Natif Kubernetes : métriques et contrôles par pod, pilotés par les labels du cluster.
Stocker
- TSDB intégrée — le moteur sur disque de Prometheus, embarqué. Rétention de 15 jours par défaut, configurable, sans processus supplémentaire.
- Activée automatiquement lorsque Bleemeo est désactivé : l'historique du panneau fonctionne dès le docker run.
- Endpoint Prometheus sur /metrics pour n'importe quel collecteur externe.
- Requêtes de plage en PromQL sur /api/v1/query_range, avec la même forme de réponse qu'un serveur Prometheus. Les requêtes instantanées et les endpoints de labels ne sont pas servis : un outil de tableaux de bord veut donc toujours un vrai Prometheus devant.
Exposer
- Panneau local orienté statut : cartes KPI, services découverts et graphiques avec zoom par glissement.
- Page de détail par conteneur, avec ses propres graphiques historiques.
- Logs de l'agent en direct dans le panneau, avec recherche et coloration par sévérité.
- Archive de diagnostic téléchargeable depuis l'interface pour les demandes de support.
Installation
Toutes les cibles, un seul agent
Le même binaire et les mêmes clés de configuration, quelle que soit la méthode de déploiement.
Docker
La commande de démarrage rapide ci-dessus. Un fichier Docker Compose avec jmxtrans aux côtés de Glouton se trouve dans le dépôt.
Paquets Linux
Paquets .deb (Debian, Ubuntu) et .rpm (RHEL, CentOS, Fedora) construits officiellement. Le guide s'adresse aux utilisateurs Bleemeo, mais il fonctionne tout aussi bien sans compte dès lors que bleemeo.enable vaut false.
Kubernetes
kubectl apply -f k8s.yaml depuis la racine du dépôt vous donne un DaemonSet par défaut et son RBAC. Le chart Helm et les options par cluster sont dans la documentation.
Windows
Un installeur MSI, construit depuis packaging/windows/ dans le dépôt et couvert par la même documentation d'installation.
macOS n'a pas encore d'installeur packagé : utilisez l'image Docker publiée, ou compilez depuis un clone (go run .). Les sockets Docker Desktop et Colima sont détectées automatiquement, vos conteneurs apparaissent donc sans configuration supplémentaire.
Rester autonome sur une installation par paquet
Les valeurs par défaut conviennent à la plupart des cas. Se passer du connecteur Bleemeo tient en deux lignes — à déposer dans /etc/glouton/conf.d/30-install.conf pour une installation par paquet, ou à passer avec -e GLOUTON_BLEEMEO_ENABLE=false avec l'image Docker.
# /etc/glouton/conf.d/30-install.conf
bleemeo:
enable: falseL'autre réglage que l'on vient chercher, c'est la quantité d'historique conservée par la TSDB embarquée :
agent:
local_store:
retention: 15dSur les paquets Linux, glouton-auto-upgrade.timer est activé par défaut et récupère les nouveaux paquets depuis le dépôt configuré. Pour maîtriser vous-même les montées de version, masquez-le avec systemctl disable --now glouton-auto-upgrade.timer. Côté Docker : docker pull bleemeo/bleemeo-agent && docker restart glouton, ou épinglez un tag CalVer.
Documentation:InstallationRéférence de configurationServices et métriques découverts
Périmètre
Ce que Glouton n'est pas
Autant poser les attentes honnêtement.
Pas un collecteur de logs
Glouton sait dériver des métriques depuis les logs applicatifs, et il affiche ses propres logs d'exécution dans le panneau pour le débogage, mais il ne stocke, n'indexe et ne transmet pas les lignes de log elles-mêmes. Pour cela, utilisez Vector, Fluent Bit ou le collecteur OpenTelemetry.
Pas un agent de tracing ni d'APM
Ni spans, ni suivi de transactions. Associez-le à un SDK OpenTelemetry côté application si vous en avez besoin.
Pas un remplaçant de Prometheus à lui seul
Glouton expose un endpoint compatible Prometheus et embarque une TSDB adaptée à un hôte unique, mais pour une installation à l'échelle d'un cluster il vous faut toujours un vrai Prometheus, un backend Mimir/Thanos, ou Bleemeo Cloud.
Sorties
Trois façons de sortir de l'agent
Tout arrive d'abord sur le disque local. La suite vous appartient — les trois chemins sont de premier ordre.
Prometheus & Grafana
Collectez /metrics avec votre propre Prometheus, puis pointez Grafana — ou Dashglass, notre propre application de tableaux de bord mono-binaire — sur ce Prometheus. Une stack Compose prête à l'emploi se trouve dans examples/prometheus.
MQTT & SquirrelDB
Publiez vers le broker de votre choix sur v1/agent/<fqdn>/data, en JSON compressé zlib, et associez SquirrelDB Ingestor pour un stockage Prometheus longue durée auto-hébergé.
Bleemeo Cloud
Transmettez vers notre SaaS pour la rétention longue, les alertes, les notifications et des tableaux de bord à l'échelle du compte, sur tous vos agents.
Les questions qu'on nous pose sur Glouton
L'utiliser seul, et comment il se situe par rapport aux outils que vous avez déjà.
Peut-on utiliser Glouton sans compte Bleemeo ?
Oui — c'est le point de départ de cette page. Mettez bleemeo.enable: false (ou GLOUTON_BLEEMEO_ENABLE=false avec Docker) et l'agent fonctionne entièrement seul : il découvre les services, collecte les métriques, conserve 15 jours d'historique dans sa TSDB embarquée et sert à la fois le panneau local et l'endpoint Prometheus. Aucune valeur de métrique ne quitte l'hôte — le seul appel sortant restant est la charge anonyme de démarrage décrite dans le démarrage rapide, et elle se désactive aussi.
Glouton est-il vraiment open source ?
Licence Apache 2.0, sur GitHub, et c'est le même agent que celui que nous exploitons pour la flotte Bleemeo Cloud — pas une édition communautaire allégée. Le connecteur Bleemeo est une sortie optionnelle parmi d'autres, pas la raison d'être du binaire.
Glouton a-t-il besoin d'une connexion Internet ?
Non. Le panneau, la TSDB et l'endpoint Prometheus sont tous locaux à l'hôte. Du trafic sortant n'apparaît que si vous activez une sortie — le connecteur Bleemeo ou un broker MQTT — ou si vous laissez la télémétrie anonyme active.
Quelle différence avec node_exporter ou Telegraf ?
Il embarque les deux : node_exporter fournit les métriques système et les entrées Telegraf la collecte par service, sous forme de bibliothèques dans un binaire unique. Ce que Glouton ajoute par-dessus, c'est la couche de découverte qui décide quoi collecter et contrôler, la TSDB embarquée et le panneau — un seul processus à installer au lieu d'un exportateur par service plus un Prometheus pour stocker le résultat.
Peut-il conserver plus de 15 jours d'historique en local ?
Oui, agent.local_store.retention est configurable. La tête de la TSDB reste bornée par la cardinalité des métriques plutôt que par la rétention : un historique plus long coûte de l'espace disque, pas de la RAM.
Quelles plateformes sont prises en charge ?
Linux via les paquets officiels .deb et .rpm, Windows via un installeur MSI, Kubernetes en DaemonSet ou via le chart Helm, et Docker partout. macOS n'a pas encore d'installeur packagé : utilisez l'image Docker, ou compilez depuis les sources — les sockets Docker Desktop et Colima sont détectées automatiquement dans les deux cas.
Construit sur des outils que vous connaissez déjà
Glouton embarque plusieurs projets open source comme bibliothèques : Prometheus pour le moteur de TSDB, PromQL et le modèle de données, node_exporter pour les métriques système, Telegraf pour les entrées par service, le Blackbox exporter pour les sondes HTTP/TCP/DNS et l'expiration des certificats, le collecteur OpenTelemetry pour le pipeline de traitement des logs, et gopsutil pour l'inspection multiplateforme des processus et de l'hôte.