Monitoreo de Contenedores
Docker, containerd y cada servicio que corre dentro de tus contenedores
Visibilidad total sobre tu flota de contenedores — CPU, memoria, E/S, red y health checks por contenedor, más el descubrimiento automático de los servicios que corren dentro. Funciona en cualquier host Docker o containerd, con o sin Kubernetes.
Prueba gratuita 15 días · Sin tarjeta de crédito · Configuración en 30 segundos
Más de 500 empresas confían en nosotros para monitorear sus contenedores
Una Vista en Vivo de Cada Contenedor en Cada Host
Los contenedores son efímeros por diseño — arrancan, se detienen y se mueven varias veces al día. Bleemeo convierte este cambio constante en una capa de observabilidad estable leyendo directamente el socket del runtime y siguiendo cada contenedor durante todo su ciclo de vida.
Agnóstico al Runtime
Soporte nativo para Docker y containerd. Conéctate al socket y Bleemeo enumera cada contenedor, en ejecución o detenido.
Métricas por Contenedor
CPU, memoria, E/S de disco, throughput de red y estado del health check — cada métrica está etiquetada con nombre del contenedor, imagen e ID.
Health Checks
Los resultados de HEALTHCHECK Docker se exponen como métrica de primera clase y disparan alertas automáticamente.
Listo para Docker Compose
Cada proyecto Compose es reconocido y agrupado en una única aplicación para un dashboarding inmediato.
Descubrimiento de Servicios
PostgreSQL, Redis, NGINX, RabbitMQ y más de 100 servicios son detectados dentro de los contenedores y monitoreados sin configuración alguna.
Nativo Prometheus
Añade prometheus.io/scrape: "true" en un contenedor y el agente hace scraping de su endpoint /metrics automáticamente.
Qué Recopila Bleemeo por Contenedor
Cada métrica se obtiene directamente del runtime del contenedor — sin sidecar, sin instrumentación manual.
CPU y Memoria
Sigue cómo los contenedores consumen los recursos del host a lo largo del tiempo, en valores brutos y porcentuales.
-
container_cpu_used— porcentaje CPU -
container_mem_used— memoria en bytes -
container_mem_used_perc— porcentaje de memoria - Métrica de estado que cruza umbrales configurables
E/S de Disco
Throughput de lectura y escritura por contenedor, agregado en todos los volúmenes montados.
-
container_io_read_bytes— bytes/s leídos -
container_io_write_bytes— bytes/s escritos - Correlaciona con las métricas de disco del host
- Detecta al instante un contenedor con E/S fuera de control
Red
Ancho de banda entrante y saliente por contenedor, sin importar cómo esté configurada la red del contenedor.
-
container_net_bits_recv— bits/s recibidos -
container_net_bits_sent— bits/s enviados - Redes bridge, host y user-defined soportadas
- Tráfico etiquetado con nombre de contenedor e imagen
Salud y Ciclo de Vida
La salida de la directiva Docker HEALTHCHECK se expone directamente, junto con el estado del contenedor.
-
container_health_status— starting / healthy / unhealthy - Marcas de tiempo created, started, stopped
- Contador de reinicios
- Eventos kill y OOM
Metadatos
Se adjunta una copia de la salida de Docker/containerd inspect para que siempre sepas qué estás mirando.
- Nombre e ID del contenedor
- Nombre y etiqueta de la imagen
- Entrypoint y comando
- Etiquetas y proyecto Compose
Métricas Aplicativas Internas
Los servicios reconocidos que corren dentro de los contenedores obtienen sus propias métricas específicas — retraso de replicación en bases de datos, profundidad de cola en brokers, tasa de solicitudes en servidores web.
- Detección a partir de la imagen y firma de proceso
- Métricas específicas por tipo de servicio
- Cero configuración requerida
- 100+ servicios — ver el catálogo abajo
Servicios Descubiertos Automáticamente Dentro de los Contenedores
Cuando un servicio reconocido corre dentro de un contenedor, Bleemeo lo detecta a partir de la imagen y la firma de proceso y empieza a recopilar sus métricas específicas — sin sidecars, sin exporters, sin configuración. Aquí una selección de los más populares; el catálogo contiene 60+ con integración nativa Prometheus y muchos más vía Telegraf.
Funcionalidades Nativas para Contenedores
🐳 Docker y containerd
Conéctate a /var/run/docker.sock o /run/containerd/containerd.sock. Ambos runtimes son ciudadanos de primera clase, sin plugin requerido.
🏷️ Configuración por Etiquetas
Controla el monitoreo con etiquetas Docker: glouton.enable, glouton.check.ignore.port.*, glouton.allow_metrics, glouton.deny_metrics.
🪶 Listo para OpenTelemetry
Ingesta trazas y logs OTLP desde tus contenedores junto a las métricas nativas. Usa el agente como collector OpenTelemetry local sin desplegar un binario separado.
📊 Scraping Prometheus
Anota un contenedor con prometheus.io/scrape: "true" y su endpoint /metrics se integra en los mismos dashboards que las métricas del runtime.
📜 Logs Centralizados
Los stdout y stderr de los contenedores pueden capturarse y centralizarse junto a las métricas para un debugging con contexto completo.
🔔 Alertas Integradas
Alertas preconfiguradas para OOM de contenedor, bucles de reinicio, estado unhealthy y saturación de recursos — sin necesidad de escribir reglas.
🧹 Filtrado
Lista allow/deny con comodines (bleemeo_*, *_builder) para saltar runners CI efímeros, contenedores builder y sidecars de depuración.
⚡ Bajo Overhead
El agente corre como un único contenedor (o en el host) y usa menos de 100 MB de memoria incluso monitoreando cientos de contenedores.
Despliegue en Tres Pasos
Ejecuta el Contenedor del Agente
Arranca el contenedor Glouton en cada host, montando el socket Docker. El agente se conecta al runtime y empieza a descubrir contenedores inmediatamente.
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-agentLos Contenedores Aparecen Automáticamente
Cada contenedor en ejecución aparece en la interfaz web en segundos, con las métricas en vivo. Los nuevos contenedores se unen a medida que son creados.
Ajusta con Etiquetas
Opcionalmente añade etiquetas en tus contenedores Compose o Docker para exponer métricas personalizadas o excluir contenedores específicos.
services:
api:
image: my/api
labels:
- prometheus.io/scrape=true
- prometheus.io/port=8080
ephemeral-worker:
image: my/worker
labels:
- glouton.enable=falseCómo Ve el Agente Tus Contenedores
Glouton corre una vez por host y se conecta al runtime. Consulta las estadísticas de los contenedores, se suscribe a los eventos de ciclo de vida y reenvía todo a Bleemeo Cloud.
Un Agente, Dos Runtimes
A Glouton no le importa si el host ejecuta Docker, containerd, o ambos simultáneamente. Se conecta a cada socket disponible, deduplica los contenedores que aparecen en ambos (común en nodos Kubernetes que mantienen Docker por razones históricas) y expone una única vista consolidada.
Configuración Primero con Etiquetas
El comportamiento se controla mediante etiquetas Docker: glouton.enable para excluir un contenedor por completo, glouton.check.ignore.port.* para saltar un puerto de servicio detectado erróneamente, prometheus.io/scrape para métricas personalizadas. Sin modificaciones de configuración central, sin reinicios del agente — basta con redesplegar el contenedor y el cambio surte efecto.
Eventos de Ciclo de Vida en Tiempo Real
El agente se suscribe al flujo de eventos del runtime (start, stop, kill, destroy) y los refleja inmediatamente en la plataforma Bleemeo. Un contenedor que falla deja de reportar métricas de CPU y produce un evento visible en la línea de tiempo — siempre sabes si un hueco se debe a una caída o a un contenedor detenido.
Filtrado Allow/Deny
Usa la configuración container.filter para mantener el monitoreo centrado en las cargas de trabajo de producción. Las allow lists y deny lists soportan comodines (bleemeo_*, *_builder) y la deny list siempre gana — perfecto para excluir runners CI efímeros, builders de corta vida o sidecars de depuración de tu superficie de alertas.
Alertas Integradas para Fallos Comunes de Contenedores
Recibe notificaciones antes de que un solo contenedor arrastre todo el stack — sin escribir ni una sola regla de alerta.
Ciclo de Vida
- Contenedor OOM-killed
- Salida inesperada con código no cero
- Bucle de reinicio detectado
- Contenedor detenido cuando debería correr
Salud
- HEALTHCHECK Docker unhealthy
- Estado de salud inestable
- Servicio descubierto automáticamente caído
- Check TCP/HTTP personalizado fallando
Presión de Recursos
- CPU sostenida sobre el umbral
- Porcentaje de memoria sobre el umbral
- E/S de disco fuera de control
- Saturación de red
Runtime
- Daemon Docker inaccesible
- Socket containerd no disponible
- Fallo en pull de imagen
- Error del storage driver
¿Por Qué Elegir Bleemeo para el Monitoreo de Contenedores?
Descubrimiento Cero Config
Los contenedores aparecen automáticamente en segundos. Sin selectores de pod, sin exporters, sin configuraciones de scrape por contenedor que mantener.
Dimensiona Recursos con Precisión
Compara el uso real de CPU y memoria con los límites configurados en tus archivos Compose e identifica contenedores sobre- o infra-provisionados.
Agente Ligero
Menos de 100 MB de memoria por host, incluso monitoreando cientos de contenedores. Un solo contenedor, sin proliferación de sidecars.
Retención 13 meses
Conserva el historial de contenedores lo suficiente para post-mortems, planificación de capacidad y análisis de tendencias.
¿Qué Es el Monitoreo de Contenedores?
El monitoreo de contenedores es la práctica de seguir la salud, el rendimiento y el uso de recursos de las cargas de trabajo contenedorizadas — ya corran bajo Docker, containerd, Podman o CRI-O. Como los contenedores son efímeros y comparten el kernel del host, requieren un enfoque diferente al monitoreo de servidores tradicional: el agente debe enumerar los contenedores desde la API del runtime, leer las estadísticas cgroup y seguir a los contenedores durante todo su ciclo de vida — start, stop, restart, kill, destroy.
Una solución completa de monitoreo de contenedores cubre tres capas. Primero, las
métricas de runtime: número de contenedores en ejecución, salud del daemon, errores de pull de
imagen. Segundo, las métricas por contenedor: porcentaje de CPU, bytes de memoria, E/S de disco,
throughput de red y resultado de la directiva HEALTHCHECK. Tercero, las métricas
dentro del contenedor: las aplicaciones que corren dentro — bases de datos, servidores web,
colas de mensajes — descubiertas automáticamente y monitoreadas con sus plugins específicos.
El monitoreo de contenedores es distinto del monitoreo de Kubernetes: no necesitas un orquestador para beneficiarte. Stacks Docker Compose, servidores Docker de un solo host, pods Podman e instalaciones containerd autónomas se benefician todos de las mismas métricas y de la misma superficie de consulta compatible con Prometheus. Ya adoptes Kubernetes más tarde o no, las señales a nivel de contenedor siguen siendo la base de tu stack de observabilidad.
Métricas de Contenedores en Detalle
Uso de CPU
Reportado como porcentaje de un núcleo CPU completo del host (container_cpu_used). Sigue el tiempo total de CPU consumido por todos los procesos dentro del contenedor, normalizado contra la cuota CPU del contenedor y el número de núcleos disponibles. Útil para detectar workers fuera de control o thread pools mal ajustados.
Uso de Memoria
Reportado en bytes (container_mem_used) y como porcentaje del límite del contenedor (container_mem_used_perc). Incluye RSS y caché. Un contenedor cercano al 100% corre el riesgo de ser OOM-killed — Bleemeo te alerta antes de que ocurra.
E/S de Disco
Throughput de lectura y escritura en bytes por segundo (container_io_read_bytes, container_io_write_bytes). Agregado en cada dispositivo de bloque que el contenedor toca. Esencial para detectar contenedores limitados por E/S antes de que saturen el disco del host.
Throughput de Red
Bits recibidos y enviados por segundo (container_net_bits_recv, container_net_bits_sent). Funciona en redes bridge, host y user-defined por igual leyendo los contadores de interfaz desde el namespace de red del contenedor.
Estado de Salud
El resultado de la directiva Docker HEALTHCHECK, expuesto como container_health_status con valores starting, healthy o unhealthy. Las alertas se disparan automáticamente en unhealthy, y la inestabilidad de estado se sigue explícitamente.
Runtime Global
Agregados a nivel de runtime como containers_count más hechos de salud del daemon Docker y containerd. Útiles para detectar runtimes rotos antes de que las métricas de contenedores individuales empiecen a desaparecer de tus dashboards.
Casos de Uso
Stacks Docker Compose
Cada docker compose up se agrupa automáticamente en una aplicación a través de su nombre de proyecto. Los stacks de desarrollo y de pequeña producción obtienen un dashboard prefabricado con estado de servicio, CPU, memoria y E/S por contenedor — sin configuración.
Docker de Un Solo Host
Ideal para pequeños productos SaaS, tooling self-hosted y homelabs. Un host, un puñado de contenedores, todo visible desde un único dashboard — con alertas nativas de OOM y health checks unhealthy.
Migración desde las VMs
Monitorea la nueva versión contenedorizada junto a la VM heredada. Compara la huella de CPU y memoria, las latencias de solicitudes y las tasas de error para justificar el cambio con datos reales en lugar de intuición.
containerd sin Kubernetes
Ejecuta containerd directamente como runtime ligero para nodos multi-tenant, servidores edge o scripts de orquestación personalizados. Bleemeo se conecta al socket containerd y trata tus contenedores exactamente como los de Docker.
Capa Subyacente de Nodos Kubernetes
Incluso en Kubernetes, las métricas a nivel de contenedor siguen siendo valiosas. Usa la vista de contenedor de Bleemeo para detectar sidecars indeseados, correlacionar reinicios con eventos del kernel y depurar problemas que la capa Kubernetes abstrae.
Revisión Post-Incidente
Con 13 meses de métricas y eventos de ciclo de vida conservados, reconstruye la secuencia exacta de arranques de contenedores, reinicios y OOM kills durante una caída — sin depender de los logs volátiles de Docker.
Buenas Prácticas del Monitoreo de Contenedores
Declara un HEALTHCHECK en Cada Imagen
Un HEALTHCHECK Docker es la forma más barata de convertir un contenedor caja negra en una carga de trabajo monitoreada. Añade uno a cada Dockerfile que poseas — incluso un simple curl a un endpoint /health — y Bleemeo alertará gratis en el estado unhealthy.
Fija Límites de Memoria en Todos los Contenedores
Sin límites de memoria, la métrica container_mem_used_perc no tiene sentido: el contenedor puede usar todo el host antes de topar con un muro. Declara siempre un límite en Compose o en el comando docker run para que las decisiones de dimensionamiento se basen en datos porcentuales reales.
Excluye los Contenedores Efímeros
Runners CI, builders de imagen y jobs de migración one-shot inundan los dashboards con ruido de corta vida. Usa etiquetas glouton.enable=false o la configuración container.filter.deny_list (*_builder, ci_runner_*) para mantener la señal centrada en cargas de trabajo de larga duración.
Expón Métricas Aplicativas mediante Etiquetas
Para aplicaciones personalizadas, añade las etiquetas prometheus.io/scrape: "true" y prometheus.io/port para exponer un endpoint /metrics. Bleemeo lo scrape automáticamente y las métricas aplicativas aparecen en el mismo dashboard del contenedor junto a CPU y memoria.
Correlaciona con los Logs del Contenedor
Un contador de reinicios que sube te dice que algo va mal; los logs del contenedor te dicen exactamente qué. Habilita la recopilación de logs junto a las métricas — Bleemeo captura stdout y stderr por contenedor y los enlaza a la misma línea de tiempo que tus alertas.
¿Quieres profundizar?
Lee la documentaciónPreguntas Frecuentes
Todo lo que necesitas saber sobre el monitoreo de contenedores
¿Qué es el monitoreo de contenedores?
El monitoreo de contenedores es la práctica de seguir la salud, el rendimiento y el uso de recursos de las cargas de trabajo contenedorizadas — Docker, containerd, Podman o CRI-O — junto con las aplicaciones que corren dentro. Proporciona métricas de CPU, memoria, E/S, red y health check por contenedor, además de descubrimiento automático de servicios para que cada nuevo contenedor sea monitoreado sin configuración manual.
¿Por qué es importante el monitoreo de contenedores?
Los contenedores son efímeros: arrancan, se detienen, escalan y se mueven entre hosts varias veces al día. Sin monitoreo, los equipos no pueden correlacionar incidentes con eventos de ciclo de vida, detectar OOM kills o bucles de reinicio, ni dimensionar bien los límites de recursos. Un buen monitoreo de contenedores expone pronto la saturación, reduce el tiempo medio de resolución y convierte la flota de contenedores efímeros en una superficie de observabilidad estable.
¿Qué métricas debería monitorear para un contenedor Docker?
El conjunto básico: uso de CPU en porcentaje, memoria usada (absoluta y en porcentaje), throughput de E/S de disco de lectura y escritura, bytes de red recibidos y enviados, contador de reinicios y el estado del health check. Sigue también los eventos a nivel de contenedor (start, stop, kill, OOM) y, para cada servicio descubierto, las métricas aplicativas relevantes como tasa de solicitudes y latencia.
¿Cuál es la diferencia entre monitoreo de contenedores y monitoreo de Kubernetes?
El monitoreo de contenedores se enfoca en los contenedores individuales y su runtime (Docker o containerd) — útil en cualquier host, con o sin orquestador. El monitoreo de Kubernetes añade conceptos a nivel de clúster: pods, nodos, namespaces, API server, etcd, scheduler, DaemonSets. Puedes hacer monitoreo de contenedores en un nodo Kubernetes, pero el monitoreo Kubernetes requiere un agente consciente del clúster.
¿El monitoreo de contenedores funciona sin Kubernetes?
Sí. El monitoreo de contenedores es anterior a Kubernetes y es especialmente común para stacks Docker Compose, despliegues Docker de un solo host, entornos Podman e instalaciones solo con containerd. El agente de monitoreo se conecta al socket del runtime (típicamente /var/run/docker.sock o el socket containerd) y recopila métricas directamente, sin ningún orquestador.
¿Cómo monitoreo Docker Compose?
El monitoreo Docker Compose funciona apuntando un agente consciente de contenedores al socket Docker del host que ejecuta tu stack Compose. El agente enumera cada contenedor del proyecto y recopila automáticamente métricas de CPU, memoria, E/S y health por contenedor. Los agentes modernos también reconocen la etiqueta com.docker.compose.project y agrupan cada servicio del proyecto en una única vista aplicativa, así un docker compose up produce un dashboard prefabricado sin configuración manual.
¿Cómo recopila un agente las métricas de un contenedor Docker?
El agente consulta la API Docker Engine (o la API gRPC containerd) para enumerar los contenedores y leer sus estadísticas a nivel de cgroup: tiempo de CPU, uso de memoria, E/S de bloque y contadores de red. También lee el resultado de los comandos Docker HEALTHCHECK, inspecciona los metadatos del contenedor (imagen, comando, etiquetas, fechas) y escucha en tiempo real los eventos del contenedor (start, stop, kill).
¿Cómo monitoreo contenedores containerd?
Apunta el agente de monitoreo al socket containerd (típicamente /run/containerd/containerd.sock) y enumerará namespaces y contenedores mediante la API containerd, recopilando las mismas métricas de CPU, memoria, E/S y red que con Docker. Es la configuración común en nodos Kubernetes que abandonaron Docker, pero también funciona en hosts autónomos que ejecutan containerd directamente.
¿Cómo filtro qué contenedores se monitorean?
Usa listas allow/deny de nombres de contenedor con soporte de comodines en la configuración del agente, y etiquetas Docker (por ej. glouton.enable=false) para excluir contenedores específicos inline. Las allow lists sirven para monitorear solo un subconjunto; las deny lists para saltar runners CI efímeros, contenedores builder o sidecars de depuración. La deny list siempre tiene prioridad sobre la allow list.
¿Puedo monitorear un servicio que corre dentro de un contenedor?
Sí. Los agentes de monitoreo modernos descubren automáticamente los servicios dentro de los contenedores — PostgreSQL, Redis, NGINX, RabbitMQ y cientos más — inspeccionando la imagen y la firma de proceso. Luego ejecutan el plugin Telegraf adecuado o hacen scraping Prometheus contra la IP y el puerto del contenedor. También puedes añadir anotaciones Prometheus (prometheus.io/scrape: "true") para exponer métricas aplicativas personalizadas.
¿Qué es el monitoreo de Docker health check?
Docker HEALTHCHECK es una directiva en un Dockerfile o archivo Compose que ejecuta un comando a intervalos regulares para evaluar si el contenedor está sano. Una plataforma de monitoreo expone el resultado de ese check (starting, healthy, unhealthy) como métrica y dispara una alerta cuando el contenedor pasa a unhealthy — sin requerir lógica de sondeo extra fuera del contenedor.
¿Cómo monitoreo los logs de contenedores?
El monitoreo de logs de contenedores captura los flujos stdout y stderr de cada contenedor mediante la API de logs del runtime (API Docker Engine, CRI containerd). Una plataforma completa reenvía estos logs a los logs centralizados junto a las métricas, para correlacionar una línea de log de error con el pico de CPU o el OOM kill que lo causó. Añade un parser — JSON, CRI, syslog — para extraer campos estructurados, y usa etiquetas o anotaciones para incluir o excluir flujos de logs específicos.
Empieza a Monitorear Tus Contenedores
Un agente por host. Docker y containerd. Cada métrica, cada evento, cada servicio.