Monitoring de Conteneurs
Docker, containerd et tous les services qui tournent dans vos conteneurs
Visibilité totale sur votre parc de conteneurs — CPU, mémoire, I/O, réseau et health checks par conteneur, plus la découverte automatique des services qui s'exécutent à l'intérieur. Fonctionne sur n'importe quel hôte Docker ou containerd, avec ou sans Kubernetes.
Essai gratuit 15 jours · Sans carte bancaire · Installation en 30 secondes
500+ entreprises nous font confiance pour surveiller leurs conteneurs
Une Vue en Direct de Chaque Conteneur sur Chaque Hôte
Les conteneurs sont éphémères par conception — ils démarrent, s'arrêtent et changent d'hôte plusieurs fois par jour. Bleemeo transforme ce brassage en une couche d'observabilité stable en lisant directement la socket du runtime et en suivant chaque conteneur tout au long de son cycle de vie.
Agnostique au Runtime
Prise en charge native de Docker et containerd. Connectez-vous à la socket et Bleemeo énumère chaque conteneur, qu'il tourne ou soit arrêté.
Métriques par Conteneur
CPU, mémoire, I/O disque, débit réseau et statut du health check — chaque métrique est étiquetée avec le nom du conteneur, l'image et l'ID.
Health Checks
Les résultats de HEALTHCHECK Docker sont exposés comme métrique de première classe et pilotent les alertes automatiquement.
Compatible Docker Compose
Chaque projet Compose est reconnu et regroupé dans une application unique pour un dashboarding immédiat.
Découverte de Services
PostgreSQL, Redis, NGINX, RabbitMQ et 100+ services sont détectés à l'intérieur des conteneurs et monitorés sans aucune configuration.
Natif Prometheus
Ajoutez prometheus.io/scrape: "true" sur un conteneur et l'agent scrape automatiquement son endpoint /metrics.
Ce que Bleemeo Collecte par Conteneur
Chaque métrique est récupérée directement du runtime des conteneurs — aucun sidecar, aucune instrumentation manuelle.
CPU et Mémoire
Suivez la consommation des ressources de l'hôte par les conteneurs dans le temps, en valeurs brutes et en pourcentage.
-
container_cpu_used— pourcentage CPU -
container_mem_used— mémoire en octets -
container_mem_used_perc— pourcentage mémoire - Métrique de statut qui franchit des seuils configurables
I/O Disque
Débit lecture et écriture par conteneur, agrégé sur tous les volumes montés.
-
container_io_read_bytes— octets/s lus -
container_io_write_bytes— octets/s écrits - Corrélez avec les métriques disque de l'hôte
- Repérez instantanément un conteneur avec un I/O qui dérape
Réseau
Bande passante entrante et sortante par conteneur, quelle que soit la configuration réseau du conteneur.
-
container_net_bits_recv— bits/s reçus -
container_net_bits_sent— bits/s envoyés - Réseaux bridge, host et user-defined pris en charge
- Trafic étiqueté avec nom de conteneur et image
Santé et Cycle de Vie
La sortie de la directive Docker HEALTHCHECK est exposée directement, avec l'état du conteneur.
-
container_health_status— starting / healthy / unhealthy - Horodatages created, started, stopped
- Compteur de redémarrages
- Événements kill et OOM
Métadonnées
Une copie de la sortie de Docker/containerd inspect est attachée pour savoir exactement ce que vous regardez.
- Nom et ID du conteneur
- Nom et tag de l'image
- Entrypoint et commande
- Labels et projet Compose
Métriques Applicatives Internes
Les services reconnus qui tournent dans les conteneurs obtiennent leurs métriques spécifiques — retard de réplication pour les bases, profondeur de file pour les brokers, taux de requêtes pour les serveurs web.
- Détection à partir de l'image et de la signature de processus
- Métriques spécifiques par type de service
- Aucune configuration requise
- 100+ services — voir le catalogue ci-dessous
Services Découverts Automatiquement dans les Conteneurs
Quand un service reconnu s'exécute dans un conteneur, Bleemeo le détecte à partir de l'image et de la signature de processus et commence à collecter ses métriques spécifiques — aucun sidecar, aucun exporter, aucune configuration. Voici une sélection des plus populaires ; le catalogue en contient 60+ avec intégration native Prometheus et bien d'autres via Telegraf.
Fonctionnalités Natives pour les Conteneurs
🐳 Docker et containerd
Connectez-vous à /var/run/docker.sock ou /run/containerd/containerd.sock. Les deux runtimes sont des citoyens de première classe, sans plugin requis.
🏷️ Configuration par Labels
Contrôlez le monitoring avec les labels Docker : glouton.enable, glouton.check.ignore.port.*, glouton.allow_metrics, glouton.deny_metrics.
🪶 Prêt pour OpenTelemetry
Ingérez traces et logs OTLP depuis vos conteneurs aux côtés des métriques natives. Utilisez l'agent comme collecteur OpenTelemetry local sans déployer un binaire séparé.
📊 Scraping Prometheus
Annotez un conteneur avec prometheus.io/scrape: "true" et son endpoint /metrics est intégré aux mêmes tableaux de bord que les métriques du runtime.
📜 Logs Centralisés
Les stdout et stderr des conteneurs peuvent être capturés et centralisés aux côtés des métriques pour un diagnostic avec contexte complet.
🔔 Alertes Intégrées
Alertes pré-configurées pour OOM de conteneur, boucles de redémarrage, statut unhealthy et saturation de ressources — aucune règle à écrire.
🧹 Filtrage
Liste allow/deny avec jokers (bleemeo_*, *_builder) pour écarter les runners CI éphémères, les conteneurs builder et les sidecars de debug.
⚡ Faible Empreinte
L'agent lui-même tourne comme un unique conteneur (ou sur l'hôte) et utilise moins de 100 Mo de mémoire, même en surveillant des centaines de conteneurs.
Déployez en Trois Étapes
Lancez le Conteneur de l'Agent
Démarrez le conteneur Glouton sur chaque hôte en montant la socket Docker. L'agent se connecte au runtime et commence immédiatement à découvrir les conteneurs.
docker run -d --name="bleemeo-agent" --restart unless-stopped \
-v /var/lib/glouton:/var/lib/glouton \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /:/hostroot:ro \
-e GLOUTON_BLEEMEO_ACCOUNT_ID=your_account_id \
-e GLOUTON_BLEEMEO_REGISTRATION_KEY=your_registration_key \
--pid=host --net=host \
--cap-add SYS_PTRACE --cap-add SYS_ADMIN \
bleemeo/bleemeo-agentLes Conteneurs Apparaissent Automatiquement
Chaque conteneur en cours d'exécution apparaît dans l'interface web en quelques secondes, avec les métriques en temps réel. Les nouveaux conteneurs rejoignent la vue dès leur création.
Ajustez avec des Labels
Ajoutez optionnellement des labels sur vos conteneurs Compose ou Docker pour exposer des métriques personnalisées ou exclure certains conteneurs.
services:
api:
image: my/api
labels:
- prometheus.io/scrape=true
- prometheus.io/port=8080
ephemeral-worker:
image: my/worker
labels:
- glouton.enable=falseComment l'Agent Voit Vos Conteneurs
Glouton s'exécute une fois par hôte et se connecte au runtime. Il interroge les statistiques des conteneurs, s'abonne aux événements de cycle de vie, et transmet le tout à Bleemeo Cloud.
Un Agent, Deux Runtimes
Glouton ne se soucie pas de savoir si l'hôte exécute Docker, containerd, ou les deux simultanément. Il se connecte à chaque socket disponible, déduplique les conteneurs qui apparaissent dans les deux (courant sur les nœuds Kubernetes qui gardent Docker pour des raisons historiques), et expose une seule vue consolidée.
Configuration Pilotée par Labels
Le comportement est contrôlé via les labels Docker : glouton.enable pour exclure un conteneur entièrement, glouton.check.ignore.port.* pour ignorer un port de service détecté à tort, prometheus.io/scrape pour les métriques personnalisées. Aucune modification de configuration centrale, aucun redémarrage de l'agent — il suffit de redéployer le conteneur pour que le changement prenne effet.
Événements de Cycle de Vie en Temps Réel
L'agent s'abonne au flux d'événements du runtime (start, stop, kill, destroy) et les reflète immédiatement dans la plateforme Bleemeo. Un conteneur défaillant cesse de reporter les métriques CPU et produit un événement visible sur la timeline — vous savez toujours si un trou vient d'une panne ou d'un conteneur arrêté.
Filtrage Allow/Deny
Utilisez la configuration container.filter pour concentrer le monitoring sur les workloads de production. Les listes allow et deny prennent en charge les jokers (bleemeo_*, *_builder) et la deny list gagne toujours — parfait pour exclure les runners CI éphémères, les builders de courte durée ou les sidecars de debug de votre surface d'alerte.
Alertes Intégrées pour les Défaillances Courantes
Soyez notifié avant qu'un seul conteneur n'entraîne toute la stack — sans écrire la moindre règle d'alerte.
Cycle de Vie
- Conteneur OOM-killed
- Sortie inattendue avec code non nul
- Boucle de redémarrage détectée
- Conteneur arrêté alors qu'il devait tourner
Santé
- HEALTHCHECK Docker unhealthy
- Statut de santé instable
- Service découvert automatiquement hors service
- Check TCP/HTTP personnalisé en échec
Pression sur les Ressources
- CPU soutenu au-dessus du seuil
- Pourcentage mémoire au-dessus du seuil
- I/O disque qui dérape
- Saturation du réseau
Runtime
- Démon Docker injoignable
- Socket containerd indisponible
- Échec du pull d'image
- Erreur du storage driver
Pourquoi Choisir Bleemeo pour le Monitoring de Conteneurs ?
Découverte Zéro Config
Les conteneurs apparaissent automatiquement en quelques secondes. Aucun sélecteur de pod, aucun exporter, aucune configuration de scrape par conteneur à maintenir.
Dimensionnement Précis
Comparez l'utilisation CPU et mémoire réelle aux limites définies dans vos fichiers Compose et identifiez les conteneurs sur- ou sous-provisionnés.
Agent Léger
Moins de 100 Mo de mémoire par hôte, même en surveillant des centaines de conteneurs. Un seul conteneur, pas de prolifération de sidecars.
Rétention 13 mois
Conservez l'historique des conteneurs suffisamment longtemps pour les post-mortems, la planification de capacité et l'analyse de tendances.
Qu'est-ce que le Monitoring de Conteneurs ?
Le monitoring de conteneurs consiste à suivre la santé, les performances et la consommation de ressources des workloads conteneurisés — qu'ils tournent sous Docker, containerd, Podman ou CRI-O. Parce que les conteneurs sont éphémères et partagent le noyau de l'hôte, ils nécessitent une approche différente du monitoring de serveurs traditionnel : l'agent doit énumérer les conteneurs depuis l'API du runtime, lire les statistiques cgroup et suivre chaque conteneur tout au long de son cycle de vie — start, stop, restart, kill, destroy.
Une solution complète de monitoring de conteneurs couvre trois couches. D'abord, les
métriques de runtime : nombre de conteneurs en cours d'exécution, santé du démon, erreurs de pull
d'image. Ensuite, les métriques par conteneur : pourcentage CPU, octets mémoire, I/O disque,
débit réseau et résultat de la directive HEALTHCHECK. Enfin, les métriques
à l'intérieur du conteneur : les applications qui y tournent — bases de données, serveurs web,
files de messages — découvertes automatiquement et monitorées avec leurs plugins spécifiques.
Le monitoring de conteneurs est distinct du monitoring Kubernetes : vous n'avez pas besoin d'un orchestrateur pour en profiter. Stacks Docker Compose, serveurs Docker mono-hôte, pods Podman et installations containerd autonomes bénéficient tous des mêmes métriques et de la même surface de requête compatible Prometheus. Que vous adoptiez Kubernetes plus tard ou non, les signaux au niveau conteneur restent la fondation de votre stack d'observabilité.
Les Métriques de Conteneurs en Détail
Utilisation CPU
Rapportée en pourcentage d'un cœur CPU complet de l'hôte (container_cpu_used). Suit le temps CPU total consommé par tous les processus du conteneur, normalisé par rapport au quota CPU du conteneur et au nombre de cœurs disponibles. Utile pour repérer les workers qui dérapent ou les thread pools mal calibrés.
Utilisation Mémoire
Rapportée en octets (container_mem_used) et en pourcentage de la limité du conteneur (container_mem_used_perc). Inclut RSS et cache. Un conteneur qui s'approche de 100 % risque un OOM kill — Bleemeo vous alerte avant.
I/O Disque
Débit lecture et écriture en octets par seconde (container_io_read_bytes, container_io_write_bytes). Agrégés sur chaque device bloc que le conteneur touche. Essentiel pour repérer les conteneurs I/O-bound avant qu'ils ne saturent le disque de l'hôte.
Débit Réseau
Bits reçus et envoyés par seconde (container_net_bits_recv, container_net_bits_sent). Fonctionne sur les réseaux bridge, host et user-defined en lisant les compteurs d'interface depuis le namespace réseau du conteneur.
Statut de Santé
Le résultat de la directive Docker HEALTHCHECK, exposé sous container_health_status avec les valeurs starting, healthy ou unhealthy. Les alertes se déclenchent automatiquement sur unhealthy, et l'instabilité de statut est suivie explicitement.
Runtime Global
Agrégats au niveau du runtime comme containers_count, plus les faits de santé du démon Docker et de containerd. Utile pour détecter des runtimes cassés avant que les métriques par conteneur ne disparaissent de vos tableaux de bord.
Cas d'Usage
Stacks Docker Compose
Chaque docker compose up est automatiquement regroupé dans une application via son nom de projet. Les stacks de développement et de petite production obtiennent un tableau de bord pré-construit avec statut de service, CPU, mémoire et I/O par conteneur — sans configuration.
Docker Mono-Hôte
Idéal pour les petits produits SaaS, l'outillage auto-hébergé et les homelabs. Un hôte, une poignée de conteneurs, tout visible depuis un seul tableau de bord — avec alertes OOM et health check unhealthy natives.
Migration depuis les VMs
Monitorez la nouvelle version conteneurisée aux côtés de la VM historique. Comparez empreintes CPU et mémoire, latences de requêtes et taux d'erreur pour justifier la bascule avec des données réelles plutôt qu'avec l'intuition.
containerd sans Kubernetes
Exécutez containerd directement comme runtime léger pour les nœuds multi-tenants, les serveurs edge ou les scripts d'orchestration sur mesure. Bleemeo se branche sur la socket containerd et traite vos conteneurs exactement comme ceux de Docker.
Couche Basse des Nœuds Kubernetes
Même sur Kubernetes, les métriques au niveau conteneur restent précieuses. Utilisez la vue conteneur de Bleemeo pour repérer les sidecars intempestifs, corréler les redémarrages aux événements noyau et déboguer les problèmes que la couche Kubernetes abstrait.
Analyse Post-Incident
Avec 13 mois de métriques et d'événements de cycle de vie conservés, reconstruisez la séquence exacte de starts, redémarrages et OOM kills pendant une panne — sans dépendre des logs Docker volatiles.
Bonnes Pratiques du Monitoring de Conteneurs
Déclarez un HEALTHCHECK dans Chaque Image
Un HEALTHCHECK Docker est le moyen le moins coûteux de transformer un conteneur boîte noire en workload monitoré. Ajoutez-en un dans chaque Dockerfile que vous possédez — même un simple curl sur un endpoint /health — et Bleemeo alerte gratuitement sur le statut unhealthy.
Définissez des Limites Mémoire sur Tous les Conteneurs
Sans limité mémoire, la métrique container_mem_used_perc n'a pas de sens : le conteneur peut consommer tout l'hôte avant de taper contre un mur. Déclarez toujours une limité dans Compose ou la commande docker run afin que les décisions de dimensionnement reposent sur de vrais pourcentages.
Excluez les Conteneurs Éphémères
Runners CI, builders d'image et jobs de migration ponctuels inondent les tableaux de bord de bruit à courte durée. Utilisez les labels glouton.enable=false ou la configuration container.filter.deny_list (*_builder, ci_runner_*) pour concentrer le signal sur les workloads de longue durée.
Exposez les Métriques Applicatives via des Labels
Pour les applications personnalisées, ajoutez les labels prometheus.io/scrape: "true" et prometheus.io/port pour exposer un endpoint /metrics. Bleemeo le scrape automatiquement et les métriques applicatives apparaissent sur le même tableau de bord que CPU et mémoire.
Corrélez avec les Logs de Conteneurs
Un compteur de redémarrages qui monte vous dit que quelque chose ne va pas ; les logs du conteneur vous disent exactement quoi. Activez la collecte de logs en parallèle des métriques — Bleemeo capture stdout et stderr par conteneur et les relie à la même timeline que vos alertes.
Envie d'aller plus loin ?
Lire la documentationQuestions Fréquentes
Tout ce que vous devez savoir sur le monitoring de conteneurs
Qu'est-ce que le monitoring de conteneurs ?
Le monitoring de conteneurs consiste à surveiller la santé, les performances et la consommation de ressources des workloads conteneurisés — Docker, containerd, Podman ou CRI-O — ainsi que les applications qui s'exécutent à l'intérieur. Il fournit les métriques CPU, mémoire, I/O, réseau et health check par conteneur, avec la découverte automatique des services pour que chaque nouveau conteneur soit monitoré sans configuration manuelle.
Pourquoi le monitoring de conteneurs est-il important ?
Les conteneurs sont éphémères : ils démarrent, s'arrêtent, passent à l'échelle et changent d'hôte plusieurs fois par jour. Sans monitoring, les équipes ne peuvent pas corréler les incidents aux événements de cycle de vie, détecter les OOM kills ou les boucles de redémarrage, ni dimensionner correctement les limites de ressources. Un bon monitoring de conteneurs expose tôt la saturation, réduit le temps moyen de résolution et transforme le parc de conteneurs éphémères en surface d'observabilité stable.
Quelles métriques surveiller pour un conteneur Docker ?
Le jeu de base : utilisation CPU en pourcentage, mémoire utilisée (absolue et en pourcentage), I/O disque en lecture et en écriture, réseau en octets reçus et envoyés, compteur de redémarrages et statut du health check. Suivez aussi les événements au niveau du conteneur (start, stop, kill, OOM) et, pour chaque service découvert, les métriques applicatives pertinentes comme le taux de requêtes et la latence.
Quelle est la différence entre monitoring de conteneurs et monitoring Kubernetes ?
Le monitoring de conteneurs se concentre sur les conteneurs individuels et leur runtime (Docker ou containerd) — utile sur n'importe quel hôte, avec ou sans orchestrateur. Le monitoring Kubernetes ajoute des concepts au niveau du cluster : pods, nœuds, namespaces, API server, etcd, scheduler, DaemonSets. Vous pouvez faire du monitoring de conteneurs sur un nœud Kubernetes, mais le monitoring Kubernetes requiert un agent conscient du cluster.
Le monitoring de conteneurs fonctionne-t-il sans Kubernetes ?
Oui. Le monitoring de conteneurs est antérieur à Kubernetes et est très courant pour les stacks Docker Compose, les déploiements Docker mono-hôte, les environnements Podman et les installations containerd seules. L'agent de monitoring se connecte à la socket du runtime (typiquement /var/run/docker.sock ou la socket containerd) et collecte les métriques directement, sans aucun orchestrateur.
Comment monitorer Docker Compose ?
Le monitoring Docker Compose fonctionne en pointant un agent conscient des conteneurs sur la socket Docker de l'hôte qui exécute votre stack Compose. L'agent énumère chaque conteneur du projet et collecte automatiquement les métriques CPU, mémoire, I/O et health par conteneur. Les agents modernes reconnaissent aussi le label com.docker.compose.project et regroupent chaque service du projet dans une vue d'application unique, de sorte qu'un simple docker compose up produit un tableau de bord prêt à l'emploi sans configuration manuelle.
Comment un agent collecte-t-il les métriques d'un conteneur Docker ?
L'agent interroge l'API Docker Engine (ou l'API gRPC containerd) pour énumérer les conteneurs et lire leurs statistiques au niveau cgroup : temps CPU, mémoire utilisée, compteurs d'I/O bloc et compteurs réseau. Il lit aussi le résultat des commandes Docker HEALTHCHECK, inspecte les métadonnées du conteneur (image, commande, labels, dates) et écoute les événements du conteneur (start, stop, kill) en temps réel.
Comment monitorer les conteneurs containerd ?
Pointez l'agent de monitoring sur la socket containerd (typiquement /run/containerd/containerd.sock) et il énumérera namespaces et conteneurs via l'API containerd, collectant les mêmes métriques CPU, mémoire, I/O et réseau que pour Docker. C'est la configuration courante sur les nœuds Kubernetes qui ont abandonné Docker, mais cela fonctionne aussi sur des hôtes autonomes exécutant containerd directement.
Comment filtrer les conteneurs à monitorer ?
Utilisez des listes allow/deny de noms de conteneurs avec prise en charge des jokers dans la configuration de l'agent, ainsi que des labels Docker (par ex. glouton.enable=false) pour exclure des conteneurs spécifiques inline. Les allow lists servent à monitorer un sous-ensemble ; les deny lists à écarter les runners CI éphémères, les conteneurs builder ou les sidecars de debug. La deny list a toujours priorité sur la allow list.
Puis-je monitorer un service qui tourne dans un conteneur ?
Oui. Les agents de monitoring modernes découvrent automatiquement les services à l'intérieur des conteneurs — PostgreSQL, Redis, NGINX, RabbitMQ et des centaines d'autres — en inspectant l'image et la signature de processus. Ils exécutent ensuite le plugin Telegraf approprié ou scrapent un endpoint Prometheus sur l'IP et le port du conteneur. Vous pouvez aussi ajouter des annotations Prometheus (prometheus.io/scrape: "true") pour exposer des métriques applicatives personnalisées.
Qu'est-ce que le monitoring des Docker health checks ?
HEALTHCHECK Docker est une directive dans un Dockerfile ou un fichier Compose qui exécute une commande à intervalles réguliers pour évaluer si le conteneur est sain. Une plateforme de monitoring expose le résultat de ce check (starting, healthy, unhealthy) comme une métrique et déclenche une alerte dès que le conteneur passe en unhealthy — sans nécessiter de logique de sondage supplémentaire à l'extérieur du conteneur.
Comment monitorer les logs de conteneurs ?
Le monitoring des logs de conteneurs capture les flux stdout et stderr de chaque conteneur via l'API de logs du runtime (API Docker Engine, CRI containerd). Une plateforme complète transfère ces logs vers les logs centralisés aux côtés des métriques, pour corréler une ligne d'erreur avec le pic CPU ou le OOM kill qui l'a causée. Ajoutez un parseur — JSON, CRI, syslog — pour extraire des champs structurés, et utilisez les labels ou annotations pour inclure ou exclure certains flux de logs.
Démarrez le Monitoring de Vos Conteneurs
Un agent par hôte. Docker et containerd. Toutes les métriques, tous les événements, tous les services.