¿Qué es Infrastructure Monitoring?

¿Qué es infrastructure monitoring?

Infrastructure monitoring trackea la salud de los hosts, containers, redes y servicios cloud managed que están debajo del código de tu aplicación. El conjunto estándar de señales es CPU utilization, memory pressure, disk I/O y espacio libre, network throughput y packet loss, más métricas específicas del servicio: profundidad de queue en SQS, replica lag en una base de datos, uso de connection pool en un load balancer, target health en un ECS service. Infrastructure monitoring responde la pregunta "¿está la capa debajo de mi app sana?" antes de preguntarte por qué tu app está lenta.

Un agent de infrastructure monitoring (Datadog Agent, Prometheus node_exporter, AWS CloudWatch Agent, Telegraf, Beats) corre en cada host o como sidecar en cada container. Scrapea contadores de OS (procfs, /sys, performance counters en Windows), pollea la API de métricas del cloud provider (CloudWatch, Azure Monitor, GCP Monitoring) y envía las series temporales a un backend para storage, query y alerting.

Infrastructure monitoring vs application monitoring

Dos capas, ambas necesarias, confundidas a menudo:

• Infrastructure monitoring: el host, el container, el servicio cloud. CPU, memoria, disco, profundidad de queue. Responde "¿está la plataforma sana?"
• Application monitoring (APM): el código encima. Latencia de endpoint, error rate, traces. Responde "¿se comporta la app?" Ver APM.

Ambas capas fallan de maneras características. CPU clavado en 100% es señal de infrastructure. p95 de latencia subiendo mientras CPU está plano es señal de application. Las plataformas modernas de observability correlacionan ambas: observability como disciplina emergió en parte porque alertar sobre métricas de host aisladas producía demasiados falsos positivos sin contexto de app.

Qué cubre infrastructure monitoring

• Hosts y VMs: CPU, load average, memoria, swap, disk I/O, disco libre, uso de inodes, file descriptor count, process count.
• Containers (Docker, Kubernetes): CPU per-container, memoria, restart count, eventos OOMKilled, pod readiness, node pressure, fallos de image pull.
• Redes: throughput in/out, packet loss, retransmisiones, llenura de tabla de connection tracking, security group flow logs.
• Load balancers: target health, request count, 5xx rate, latencia p95 en la capa LB, connection counts.
• Bases de datos: connections usados, replica lag, query throughput, slow query log, cache hit ratio, lock contention.
• Message queues: profundidad de queue, message age, consumer lag, dead letter count.
• Servicios cloud managed: profundidad SQS, S3 4xx/5xx, requests throttled de DynamoDB, concurrencia Lambda, CPU y connections de RDS.

Alerts clave de infrastructure

1. Disco libre bajo 15% en cualquier host. Atrapa fallos de log rotation y temp files descontrolados.
2. CPU sostenido sobre 80% por 10+ minutos. Te dice que un host está at capacity, a menudo antes de que la latencia de app spikee.
3. Memory pressure o eventos OOMKilled en cualquier container. A menudo el primer síntoma de un memory leak.
4. Load balancer target unhealthy por 2+ minutos. Señal directa de que el tráfico está siendo desviado.
5. Profundidad de queue sobre N donde N es tu número "consumer puede procesar en 15 min". Atrapa crashes de consumer o lentitud downstream.
6. Packet loss de red sobre 1% sostenido. Usualmente un switch, una mala configuración de security group, o una NIC defectuosa.

Cómo configurar

Para stacks cloud-native: habilita CloudWatch (o el monitoring nativo de tu provider) como baseline, luego instala el Datadog Agent, Prometheus node_exporter más Grafana, o el módulo de infrastructure de tu vendor APM en cada host. Para Kubernetes: kube-state-metrics más node_exporter scrapeado por Prometheus es el default OSS. Añadir alerts incrementalmente.

Combinar infrastructure monitoring con load tests para validar los alerts. Correr load testing, spike testing o capacity testing contra staging y observar qué métrica de host sube primero.

Si tu equipo necesita correlación infrastructure-load bajo tráfico de producción, LoadFocus ofrece servicios de load testing donde ingenieros corren la matriz y producen el breakdown.