Monitorización de contenedores: más allá de cAdvisor

javi
Pantalla con gráficos de rendimiento de múltiples servicios y métricas

cAdvisor fue la herramienta que 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 deep, APM para context de aplicación. Este artículo mapea qué combinar y cómo.

La stack mínima moderna

Para Kubernetes serious en 2024:

  • kubelet / cAdvisor: métricas de CPU, memoria, red, disk por container.
  • kube-state-metrics: state de Deployments, Pods, ReplicaSets, HPA.
  • node-exporter: métricas de los nodos.
  • Prometheus scrapea todo, agrega.
  • Grafana visualiza.

Esto cubre el 80% de lo que necesitas monitorizar. Y es solid stack OSS.

Qué falta sin eBPF

cAdvisor da métricas “superficie”:

  • CPU usage %.
  • Memory RSS.
  • Network bytes.
  • Disk I/O.

Pero no:

  • Latencia de syscalls: ¿el pod está pegado en I/O?
  • Network latencies entre pods específicos.
  • Profile de CPU: qué funciones consumen.
  • Function-level detail: hotpaths.

Para esto, eBPF es la herramienta moderna.

eBPF: la capa que cambia todo

Herramientas eBPF modernas:

Pixie

Pixie (CNCF sandbox, originalmente New Relic):

  • Auto-instrumentation HTTP/gRPC/DNS sin sidecar ni code changes.
  • Flame graphs live.
  • Service map automático.
  • Queries PxL language.

Un agente eBPF per nodo + UI web. Developer-friendly.

Grafana Beyla

Beyla:

  • Auto-instrumentation para apps Go, Java, Node.
  • Genera traces OpenTelemetry sin modificar código.
  • Integración con Grafana stack.

Más simple que Pixie, foco en traces/metrics.

Parca

Parca:

  • Continuous profiling de todo el cluster.
  • Flame graphs via eBPF.
  • Integrable con Grafana.

Específico para CPU profiling.

Inspektor Gadget

Herramienta de Kinvolk/Microsoft para debugging con eBPF:

  • kubectl trace equivalents.
  • Network snapshots por pod.
  • Profiling on-demand.

APM: la capa de aplicación

eBPF da visibilidad infra; APM da visibilidad de aplicación:

  • OpenTelemetry: estándar abierto, cada vez más adoptado.
  • Jaeger / Tempo: backends para traces.
  • Datadog / New Relic / Dynatrace: comerciales completos.
  • Grafana Tempo: tempo.

Con OTel SDK, tu app instrumenta:

  • Spans de requests.
  • Metrics de negocio.
  • Logs correlados.

Beyla puede generar algunos de esos automáticamente, pero para business metrics, necesitas SDK.

Combinar sin saturar

Error común: poner todas las herramientas = overhead masivo. Sweet spot típico:

  • cAdvisor + kube-state-metrics + node-exporter: base ligera.
  • eBPF (Pixie o Beyla): añadir cuando necesites deep visibility.
  • APM con OTel: para apps críticas, no todas.
  • Commercial APM: solo si tienes caso de uso claro vs OSS.

Cada capa debe aportar value distinto. Duplicar es waste.

Métricas esenciales por contenedor

Las que monitorizamos siempre:

  • CPU throttling: ¿pod está rate-limited?
  • Memory working set: uso real, no RSS.
  • OOM kills: contador clave.
  • Network errors: TX/RX drops.
  • Disk pressure: fullness + I/O saturation.
  • Restart count: flapping = problema.

Para K8s adicionalmente:

  • Pod phase: Pending, Running, Failed.
  • Readiness probe failures.
  • HPA desired vs current.
  • PVC usage.

Alertas que valen la pena

Pocas pero efectivas:

  • Pod restart > N en Y minutos: flapping.
  • CPU throttling > 50% sostenido: resource insuficiente.
  • OOM kills: always investigate.
  • Memory > 90% limit sostenido: leak o sizing.
  • Node not ready > X minutos: incidente.
  • HPA at max replicas durante > Y min: capacity issue.

Menos alertas útiles > muchas alertas ignoradas.

Dashboards: qué mostrar

Niveles típicos:

  • Cluster overview: recursos totales, nodes, pods.
  • Namespace: por equipo/aplicación.
  • Workload: deploy específico, pods, containers.
  • Pod detail: drill-down para troubleshoot.

Grafana dashboards oficiales de Kubernetes (IDs 315, 6417, etc) son buen punto de partida.

Logging integration

Métricas sin logs es mitad del picture. Stack típico:

  • Fluent Bit o Loki-native shippers para log collection.
  • Loki para storage + Grafana para visualization.
  • Correlation con traces via trace IDs.

Cuando investigas un incidente, necesitas métricas + logs + traces en la misma timeline.

Observabilidad de seguridad

Complementaria:

  • Falco: eBPF runtime security.
  • Tracee (Aqua): similar, eBPF-based.
  • Audit logs de Kubernetes API.

No son “monitoring” estándar pero forma parte del cuadro completo.

Herramientas que ya no recomiendo

  • Telegraf: válido pero Prometheus ecosystem es default ahora.
  • InfluxDB standalone: Loki + Prometheus cubren.
  • Stackdriver legacy: GCP-only, lock-in.
  • ELK para métricas: Elastic mejor para logs solo.

Un ejemplo práctico

Cluster típico de 50 nodos, 500 pods:

  • Prometheus federation: ~2000 targets, 5M series.
  • Retention: 30 días hot + objeto storage.
  • Grafana con 10-15 dashboards curados.
  • Alertas 20-30 útiles.
  • Beyla en algunos namespaces para traces.
  • Loki para logs.

Stack OSS, overhead ~5% del cluster total en CPU/RAM.

Conclusión

Monitorizar contenedores bien en 2024 requiere más que cAdvisor. La base OSS (Prometheus + kube-state-metrics + node-exporter + Grafana) es sólida y suficiente para la mayoría. eBPF (Pixie, Beyla, Parca) añade visibilidad deep cuando lo necesitas. APM con OpenTelemetry complementa con visión de aplicación. La trampa es over-engineering: más herramientas = más mantenimiento y noise. Empieza con base sólida, añade capas cuando el caso de uso lo justifica, y mantén disciplina en alertas — menos y bien pensadas ganan.

Síguenos en jacar.es para más sobre observabilidad, Kubernetes y eBPF.

Entradas relacionadas