Monitorización de contenedores: más allá de cAdvisor
Actualizado: 2026-05-03
cAdvisor democratizó la monitorización de contenedores y sigue siendo relevante: kubelet lo incluye internamente. Pero en 2024, observar contenedores bien requiere más capas: métricas de cluster state, eBPF para visibilidad profunda, APM para contexto de aplicación. Este artículo mapea qué combinar y cómo evitar el sobre-ingeniería que convierte el stack de observabilidad en el problema más caro de mantener.
Puntos clave
- El stack mínimo moderno es cAdvisor + kube-state-metrics + node-exporter + Prometheus + Grafana: cubre el 80% de lo necesario.
- cAdvisor da métricas de superficie (CPU, RAM, red, disco); eBPF añade latencia de syscalls, latencias de red entre pods y CPU profiling.
- Las herramientas eBPF de referencia son Pixie (CNCF sandbox), Grafana Beyla y Parca para continuous profiling.
- OpenTelemetry es el estándar de APM: instrumentar las apps críticas, no todas.
- La trampa es el over-engineering: más herramientas equivale a más mantenimiento y más ruido de alertas.
La stack mínima moderna
Para Kubernetes serio en 2024, el baseline OSS que cubre la mayor parte del trabajo:
- kubelet / cAdvisor: métricas de CPU, memoria, red y disco por contenedor.
- kube-state-metrics: estado de Deployments, Pods, ReplicaSets y HPA.
- node-exporter: métricas de los nodos subyacentes.
- Prometheus como motor de scraping y agregación.
- Grafana para dashboards y alertas.
Este stack tiene un overhead de aproximadamente el 5% del cluster en CPU/RAM, que es aceptable para cualquier instalación productiva.
Qué falta sin eBPF
cAdvisor da métricas “superficie”:
- CPU usage %.
- Memory RSS.
- Network bytes.
- Disk I/O.
Pero no responde preguntas como: ¿está el pod bloqueado en I/O de sistema de ficheros? ¿Cuál es la latencia de red entre pods A y B? ¿Qué función específica consume el 80% del CPU? Para esas preguntas, eBPF es la herramienta correcta.
eBPF: la capa que cambia el diagnóstico
Herramientas eBPF que han madurado lo suficiente para producción:
Pixie[1] (CNCF sandbox): auto-instrumentación de HTTP, gRPC y DNS sin sidecar ni cambios en el código. Flame graphs en vivo, service map automático y consultas con PxL. Un agente eBPF por nodo más UI web. Es el punto de entrada más accesible para quien empieza con eBPF.
Grafana Beyla[2]: auto-instrumentación para apps Go, Java y Node que genera trazas OpenTelemetry sin modificar el código. Más simple que Pixie, foco en traces y métricas. Se integra directamente con el stack Grafana existente.
Parca[3]: continuous profiling del cluster completo. Flame graphs vía eBPF específicamente para identificar hotpaths de CPU. Se integra con Grafana.
Para la parte de seguridad runtime, Falco complementa este stack con detección de comportamientos anómalos también vía eBPF.
APM: la capa de aplicación
eBPF da visibilidad de infraestructura; APM da visibilidad de la lógica de negocio. El estándar moderno es OpenTelemetry:
- Spans de requests con latencia por operación.
- Métricas de negocio correladas con la infraestructura.
- Logs correlados con trace IDs para navegar de la métrica al log sin saltar de herramienta.
Beyla puede generar spans automáticamente para muchos casos; para métricas de negocio específicas (número de pedidos procesados, valor medio de transacción), se necesita el SDK. Los backends de trazas más comunes son Jaeger y Grafana Tempo; para el stack completo, observabilidad con Loki a escala complementa la parte de logs.
Combinar sin saturar
El error más frecuente es instalar todas las herramientas a la vez. El sweet spot:
- cAdvisor + kube-state-metrics + node-exporter: base ligera, siempre activa.
- eBPF (Pixie o Beyla): añadir cuando se necesite visibilidad profunda en debugging o diagnóstico de rendimiento.
- APM con OTel: para apps críticas de negocio, no para todos los microservicios.
- APM comercial (Datadog, New Relic, Dynatrace): solo si el caso de uso justifica el coste frente al stack OSS.
Cada capa debe aportar valor distinto. Duplicar es desperdicio.
Métricas esenciales por contenedor
Las que monitorizamos siempre, sin excepción:
- CPU throttling: el pod está consumiendo más CPU de su limit.
- Memory working set: el uso real de memoria, no RSS.
- OOM kills: siempre se investigan, sin excepción.
- Network errors: drops de TX y RX.
- Restart count: flapping es señal de problema.
Para Kubernetes adicionalmente: pod phase, readiness probe failures, HPA desired vs current y PVC usage.
Alertas que valen la pena
Pocas pero efectivas:
- Pod restart > N en Y minutos: flapping.
- CPU throttling > 50% sostenido: sizing insuficiente.
- OOM kills: siempre.
- Memory > 90% del limit sostenido: leak o sizing.
- Node not ready > X minutos: incidente.
- HPA en max replicas durante > Y minutos: problema de capacidad.
Menos alertas útiles siempre gana a muchas alertas ignoradas.
Conclusión
Monitorizar contenedores bien en 2024 requiere más que cAdvisor, pero no requiere todo a la vez. La base OSS (Prometheus + kube-state-metrics + node-exporter + Grafana) es sólida y suficiente para la mayoría de equipos. eBPF añade visibilidad profunda cuando el problema lo justifica. APM con OpenTelemetry completa el cuadro para las apps de negocio críticas. La disciplina está en añadir capas solo cuando el caso de uso lo pide, y en mantener las alertas pocas y bien pensadas.
