¿Qué es el Cloud Monitoring?
Cloud monitoring observa workloads y servicios gestionados en AWS, GCP, Azure: métricas CloudWatch, latencia ALB, conexiones RDS, Lambda, contenedores.
¿Qué es el cloud monitoring?
El cloud monitoring es la observación continua de workloads, servicios y componentes gestionados que corren en una nube pública (AWS, GCP, Azure, OCI) o en una mezcla híbrida de cloud y on-prem. Tira métricas, logs, traces y eventos de fuentes cloud-native (CloudWatch, Cloud Monitoring, Azure Monitor, el control plane de EKS o ECS, RDS performance insights, S3 request metrics, ALB access logs, invocaciones de Lambda) y de cualquier agente que despliegues en VMs o contenedores, y expone el resultado como dashboards, alertas y workflows de incidentes.
La salida tiene la misma forma que el monitoring clásico (gráficas, alertas, rotaciones on-call) pero las fuentes de datos y la unidad de trabajo son distintas: contenedores efímeros en lugar de hosts longevos, servicios gestionados en lugar de daemons auto-administrados, billing por invocación en lugar de servidores de coste fijo. Herramientas del espacio incluyen Datadog, New Relic, Dynatrace, Grafana Cloud, AWS CloudWatch, Google Cloud Operations y Azure Monitor.
Cloud monitoring vs on-prem monitoring vs APM
Las disciplinas se solapan pero la forma del dato difiere:
- Cloud monitoring consume métricas de servicios gestionados y compute efímero (contenedores, funciones). La unidad de trabajo churnea por minuto y los tags impulsan la agrupación (account, region, service, environment).
- On-prem monitoring vigila hardware fijo: hosts nombrados en DNS durante años, switches, storage arrays. Tooling como Nagios, Zabbix o PRTG se centra en SNMP e instalaciones por host.
- APM es ortogonal a ambos: instrumenta código de aplicación independientemente de dónde corra y reporta latencia y errores por endpoint. Ver application performance monitoring para la capa de aplicación.
La mayoría de equipos sobre cloud necesitan cloud monitoring para infraestructura y APM para el código de la aplicación; el camino on-prem se reduce pero sigue siendo relevante para workloads regulados.
Qué cubre cloud monitoring
- Salud de compute: CPU, memoria, disco de EC2/GCE/Azure VM; conteo de contenedores, reinicios, pods pending en ECS/EKS/GKE/AKS.
- Métricas de servicios gestionados: RDS connections, ElastiCache hit rate, throttles de DynamoDB, S3 4xx/5xx, profundidad de cola SQS, ALB target response time.
- Serverless: conteo de invocaciones Lambda, duración, errores, throttles, ejecuciones concurrentes; lo mismo para Cloud Functions y Azure Functions.
- Red y edge: hit rate de caché CloudFront, bytes de NAT gateway, VPC flow logs, volumen de queries Route 53.
- Señales de coste: spend diario por cuenta, coste unblended por servicio o tag, alertas de anomalía cuando el spend diario salta.
- Seguridad y auditoría: eventos CloudTrail, hallazgos GuardDuty, IAM access analyzer; no sustituye un SIEM pero es la capa de early warning.
Métricas clave de cloud monitoring
- Availability por servicio: CloudWatch HealthyHostCount, ALB target health, RDS instance state, agregado a un target de SLA.
- Latencia por componente gestionado: latencia de query RDS, ALB TargetResponseTime p50/p95/p99, latencia first-byte de S3.
- Error rate por capa: ALB HTTPCode_Target_5XX_Count, Lambda Errors, deadlocks de RDS, profundidad de dead-letter de SQS.
- Saturación: CPU credits remaining en instancias burstable, saturación de CPU y conexiones RDS, evictions de ElastiCache, autoscaling group desired vs in-service.
- Throughput: requests por segundo por servicio, bytes por segundo por ruta de red, mensajes por minuto vía SQS/SNS/Kinesis.
- Coste por request: spend dividido por trabajo útil, la métrica de eficiencia long-term que la mayoría de equipos ignora hasta que la factura sube.
Cómo correr cloud monitoring
Empieza con el metric stream nativo del proveedor (CloudWatch metric streams a Firehose, o polling directo de API para una nube) y reenvíalo a un backend central (Datadog, Grafana, tu propio Prometheus + Mimir). Tagea cada recurso de forma consistente (service, environment, team, cost-center) para que la misma query del dashboard slice por cualquier dimensión. Añade encima logs (CloudWatch Logs o Cloud Logging) y traces (X-Ray, Cloud Trace, OpenTelemetry al mismo backend). Conecta alertas a PagerDuty u Opsgenie con rotaciones on-call por servicio. Poda periódicamente métricas que ningún equipo posea: las facturas de cloud monitoring crecen más rápido que la infraestructura.
El cloud monitoring se sitúa junto al load testing en la launch readiness pipeline. Corre load testing o spike testing desde fuera de la red cloud, observa los dashboards de cloud monitoring en vivo y captura qué componente gestionado satura primero (conexiones de base, lag de autoscaling, profundidad de dead-letter queue). Ver también observability para el framework de investigación más amplio que alimenta el cloud monitoring.
Si tu equipo necesita runs de carga production-shape que correlacionen limpiamente con tus dashboards de cloud monitoring, LoadFocus ofrece servicios de load testing con runs programados para alinearse con tus ventanas de dashboard, reportes resumen con referencias cruzadas a tus capturas de CloudWatch o Datadog.
Herramientas LoadFocus relacionadas
Lleva este concepto a la práctica con LoadFocus — la misma plataforma que potencia todo lo que acabas de leer.