Monitoring y observabilidad en AWS: CloudWatch, X-Ray y más allá

Si tu equipo se entera de un problema en producción porque un cliente llama, tu observabilidad ha fallado. No es una cuestión de herramientas. Es una cuestión de disciplina: qué mides, cómo lo mides y qué haces cuando los números cambian.

Monitoring es saber que el servidor tiene un 95% de CPU. Observabilidad es entender por qué tiene un 95% de CPU, qué servicio lo está causando, qué petición lo desencadenó y cuántos usuarios están afectados. La diferencia entre ambos conceptos es la diferencia entre saber que hay un incendio y saber dónde está, qué lo causó y cómo apagarlo.

Este artículo cubre las herramientas de observabilidad disponibles en AWS, cómo configurarlas correctamente, y los patrones que separan a los equipos que reaccionan a los incidentes de los que los previenen.

Los tres pilares de la observabilidad

La observabilidad se sostiene sobre tres tipos de datos:

Métricas

Valores numéricos que miden el estado de un sistema a lo largo del tiempo. CPU, memoria, latencia, tasa de errores, peticiones por segundo. Las métricas son eficientes en almacenamiento y permiten detectar tendencias y anomalías.

Ejemplo: La latencia P99 de tu API pasó de 200ms a 1.500ms en los últimos 15 minutos.

Logs

Registros textuales de eventos que ocurren en el sistema. Cada log tiene un timestamp, un nivel de severidad y un mensaje. Los logs son el detalle: te dicen exactamente qué pasó, en qué orden, y con qué datos.

Ejemplo: 2025-12-08T14:23:45Z ERROR [PaymentService] Timeout connecting to Stripe API after 30s. OrderId: 12345, UserId: 67890

Trazas (Traces)

Registros del recorrido de una petición a través de múltiples servicios. Una traza muestra que la petición del usuario entró por API Gateway, fue procesada por Lambda A, que llamó a Lambda B, que consultó DynamoDB, que respondió en 5ms, pero Lambda B tardó 3 segundos en procesar la respuesta.

Ejemplo: Una traza que muestra que el 85% de la latencia de una petición ocurre en una sola función Lambda que hace una consulta ineficiente a la base de datos.

CloudWatch: la base de todo

CloudWatch es el servicio de monitoring nativo de AWS. No es la herramienta más potente del mercado, pero tiene una ventaja decisiva: recibe métricas de todos los servicios AWS automáticamente. No necesitas instalar agentes, configurar exporters ni mantener infraestructura de monitoring.

CloudWatch Metrics

Todos los servicios AWS publican métricas en CloudWatch automáticamente:

• EC2: CPUUtilization, NetworkIn, NetworkOut, DiskReadOps.
• Lambda: Invocations, Duration, Errors, Throttles, ConcurrentExecutions.
• RDS: CPUUtilization, DatabaseConnections, FreeStorageSpace, ReadLatency, WriteLatency.
• ALB: RequestCount, TargetResponseTime, HTTPCode_Target_5XX_Count.
• DynamoDB: ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, ThrottledRequests.
• SQS: ApproximateNumberOfMessagesVisible, ApproximateAgeOfOldestMessage.

Estas métricas básicas son gratuitas con resolución de 5 minutos (1 minuto para EC2 con Detailed Monitoring activado, que cuesta 3,50 dolares por instancia al mes).

Métricas personalizadas: Puedes publicar tus propias métricas con PutMetricData. Cada métrica personalizada cuesta 0,30 dolares al mes. Métricas típicas que deberías publicar:

• Número de registros de usuarios por hora.
• Tiempo de procesamiento de pedidos.
• Tasa de conversión en tiempo real.
• Cola de trabajos pendientes.

CloudWatch Alarms

Las alarmas son el componente más importante de CloudWatch. Una alarma monitoriza una métrica y ejecuta acciones cuando cruza un umbral.

Configuración de alarmas críticas:

Alarma de tasa de errores:

Métrica: ALB HTTPCode_Target_5XX_Count
Periodo: 5 minutos
Umbral: > 10 errores 5XX en 5 minutos
Acción: Notificación SNS -> Email + Slack

Alarma de latencia:

Métrica: ALB TargetResponseTime
Estadística: p99
Periodo: 5 minutos
Umbral: > 2 segundos
Acción: Notificación SNS -> PagerDuty

Alarma de base de datos:

Métrica: RDS FreeStorageSpace
Periodo: 15 minutos
Umbral: < 5 GB
Acción: Notificación SNS -> Email del equipo de ops

Recomendación: No crees alarmas para todo. Crea alarmas solo para las métricas que requieren acción humana inmediata. Una alarma que nadie atiende es peor que no tener alarma, porque entrena al equipo a ignorar notificaciones.

CloudWatch Logs

CloudWatch Logs almacena y permite consultar logs de todos tus servicios. La estructura es:

• Log Group: Agrupa logs por servicio o aplicación. Ejemplo: /aws/lambda/mi-funcion, /ecs/mi-servicio.
• Log Stream: Agrupa logs dentro del grupo, normalmente por instancia o invocación.
• Log Events: Los registros individuales.

Configuración esencial:

Retención: Por defecto, los logs se guardan indefinidamente. Esto acumula coste sin generar valor. Configura políticas de retención:

• Logs de producción: 30-90 días en CloudWatch, exportación a S3 para retención a largo plazo.
• Logs de desarrollo/staging: 7-14 días.
• Logs de auditoría (CloudTrail): 1 año mínimo, según requisitos de compliance.

Formato estructurado: Emite logs en formato JSON, no en texto plano. Un log como:

{
  "timestamp": "2025-12-08T14:23:45Z",
  "level": "ERROR",
  "service": "payment-service",
  "orderId": "12345",
  "userId": "67890",
  "message": "Timeout connecting to Stripe API",
  "duration_ms": 30000
}

permite filtrar y buscar por cualquier campo. Un log de texto plano requiere regex para extraer la misma información.

CloudWatch Logs Insights

Logs Insights es el motor de consultas de CloudWatch. Permite buscar patrones en millones de registros en segundos. La sintaxis es propia de AWS (no es SQL):

fields @timestamp, @message
| filter @message like /ERROR/
| filter service = "payment-service"
| stats count() as error_count by bin(5m)
| sort error_count desc

Esta consulta muestra el número de errores por intervalo de 5 minutos en el servicio de pagos.

Coste: 0,0076 dolares por GB escaneado. Si tus logs ocupan 100 GB y ejecutas una consulta que escanea 10 GB, cuesta 0,076 dolares. Es significativamente más barato que mantener un cluster de Elasticsearch.

CloudWatch Dashboards

Los dashboards son paneles visuales que agrupan métricas, logs y alarmas. Cada dashboard cuesta 3 dolares al mes.

Dashboard mínimo recomendado:

1. Panel de salud general: Tasa de errores 5XX, latencia P99, peticiones por segundo.
2. Panel de base de datos: Conexiones activas, latencia de lectura/escritura, espacio libre.
3. Panel de Lambda (si usas serverless): Invocaciones, errores, throttles, duración.
4. Panel de costes: Gasto diario vs presupuesto, tendencia mensual.

AWS X-Ray: trazas distribuidas

Qué resuelve X-Ray

Cuando una petición cruza múltiples servicios (API Gateway, Lambda, DynamoDB, SQS, otra Lambda), identificar dónde está el cuello de botella sin trazas es casi imposible. X-Ray registra el recorrido completo de cada petición y muestra el tiempo que cada servicio consumió.

Cómo funciona

1. El SDK de X-Ray instrumenta tu código. En Node.js, por ejemplo, wrappea los clientes de AWS SDK y las librerías HTTP para capturar automáticamente las llamadas.
2. El daemon de X-Ray envía los segmentos de traza al servicio X-Ray. En Lambda y Fargate, el daemon está integrado. En EC2, necesitas instalarlo.
3. X-Ray correlaciona los segmentos usando un Trace ID único que se propaga entre servicios a través de headers HTTP.

Instrumentación en Lambda

Para Lambda, la instrumentación es sencilla. Activa “Active Tracing” en la configuración de la función:

aws lambda update-function-configuration \
  --function-name mi-funcion \
  --tracing-config Mode=Active

Esto automáticamente captura:

• El tiempo total de la invocación.
• El cold start (si ocurre).
• Las llamadas a servicios AWS (DynamoDB, S3, SQS) si usas el SDK instrumentado.

Para capturar llamadas HTTP externas (a APIs de terceros), necesitas instrumentar el cliente HTTP.

Service Map

El Service Map de X-Ray genera automáticamente un diagrama de tu arquitectura basándose en las trazas. Muestra cada servicio, las conexiones entre ellos, la latencia y la tasa de errores de cada conexión.

Este diagrama se genera automáticamente. No necesitas dibujarlo ni mantenerlo. Si tu equipo no tiene un diagrama actualizado de la arquitectura, el Service Map de X-Ray es un buen punto de partida.

Muestreo (Sampling)

X-Ray no captura todas las peticiones por defecto. Usa un algoritmo de muestreo que captura la primera petición por segundo y un 5% del resto. Esto reduce costes sin perder visibilidad significativa.

Puedes personalizar el muestreo por ruta, servicio o cualquier atributo. Para endpoints críticos (pagos, autenticación), configura un muestreo del 100%.

Coste: 5 dolares por millón de trazas registradas, 0,50 dolares por millón de trazas recuperadas. Para una aplicación con 10 millones de peticiones al mes y muestreo del 5%, el coste es aproximadamente 2,50 dolares al mes.

Más allá de las herramientas nativas de AWS

CloudWatch vs Datadog vs Grafana Cloud

Las herramientas nativas de AWS cubren la funcionalidad básica. Pero para equipos con más de 10-15 servicios, las alternativas de terceros ofrecen ventajas significativas:

Recomendación:

• Equipos de 1-5 personas: CloudWatch + X-Ray. Sin coste adicional significativo.
• Equipos de 5-15 personas: Evalúa Grafana Cloud (open source core, menor coste que Datadog).
• Equipos de 15+ personas: Datadog ofrece la experiencia más completa pero al mayor coste.

Prometheus + Grafana en AWS

Si prefieres herramientas open source, AWS ofrece servicios gestionados:

• Amazon Managed Service for Prometheus (AMP): Prometheus gestionado. Ingestas métricas, AWS las almacena y escala. Coste: 0,003 dolares por 10.000 muestras ingestadas + 0,03 dolares por millón de consultas.
• Amazon Managed Grafana (AMG): Grafana gestionado con integración nativa con AMP, CloudWatch, X-Ray y otros. Coste: desde 9 dolares por editor al mes.

Esta combinación es especialmente relevante para equipos que usan EKS, donde Prometheus es el estándar de facto para monitoring de Kubernetes.

Patrones de observabilidad que funcionan

Patrón 1: SLOs antes que métricas

No monitorices CPU. Monitoriza la experiencia del usuario. Define SLOs (Service Level Objectives):

• Disponibilidad: 99.9% de peticiones exitosas (menos de 43 minutos de downtime al mes).
• Latencia: P99 inferior a 500ms.
• Tasa de errores: Menos del 0.1% de peticiones con error 5XX.

Crea alarmas basadas en error budgets: si en los últimos 30 días has consumido más del 50% de tu presupuesto de errores, investiga antes de que se agote.

Patrón 2: alertas de síntomas, no de causas

Mal: Alerta cuando CPU supera el 80%. Bien: Alerta cuando la latencia P99 supera los 500ms.

La CPU al 80% puede ser normal si tu servicio está procesando un batch esperado. La latencia alta siempre afecta a los usuarios. Alerta sobre lo que importa, investiga las causas después.

Patrón 3: logs estructurados con correlation IDs

Cada petición que entra al sistema recibe un ID único (correlation ID o request ID). Ese ID se propaga a todos los servicios que participan en el procesamiento. Cuando algo falla, buscas por correlation ID y obtienes la traza completa de la petición.

Implementación mínima:

1. API Gateway genera un request ID (o usa el X-Request-ID del cliente).
2. Lambda recibe el ID en los headers y lo incluye en todos los logs.
3. Si Lambda llama a otro servicio (SQS, otra Lambda), propaga el ID.
4. Logs Insights permite buscar por correlation ID para reconstruir el flujo completo.

Patrón 4: canary monitoring

Un canary es un test sintético que simula el comportamiento de un usuario real. CloudWatch Synthetics permite crear canaries que:

• Hacen peticiones HTTP a tus endpoints cada N minutos.
• Verifican el código de respuesta y el contenido.
• Miden la latencia desde múltiples regiones.
• Alertan cuando fallan.

Coste: Cada canary cuesta 0,0012 dolares por ejecución. Un canary que se ejecuta cada 5 minutos (8.640 ejecuciones al mes) cuesta aproximadamente 10 dolares al mes.

Los canaries detectan problemas antes que los usuarios porque ejecutan peticiones continuamente, incluso cuando no hay tráfico real.

Patrón 5: detección de anomalías

CloudWatch Anomaly Detection usa machine learning para establecer patrones de comportamiento normal de tus métricas y alertar cuando una métrica se desvía significativamente del patrón esperado.

Es especialmente útil para métricas con patrones estacionales (más tráfico de lunes a viernes, picos a las 10:00, valles a las 3:00). Un umbral fijo no funciona bien con estas métricas porque lo que es normal a las 10:00 es anómalo a las 3:00.

Gestión de incidentes: de la alerta a la resolución

Estructura de on-call

La observabilidad sin un proceso de respuesta es inútil. Las alertas necesitan llegar a la persona correcta en el momento correcto:

1. Nivel 1 (automatizado): Alertas que se resuelven automáticamente. Auto-scaling que responde a picos de carga, Lambda retries, circuit breakers que se abren y cierran.
2. Nivel 2 (equipo de guardia): Alertas que requieren intervención humana. Un ingeniero de guardia investiga y resuelve. Rotación semanal o bisemanal.
3. Nivel 3 (escalado): Incidentes que el equipo de guardia no puede resolver. Se escalan al equipo propietario del servicio o al líder técnico.

Herramientas de gestión de incidentes: PagerDuty, Opsgenie (parte de Atlassian) o AWS Incident Manager (incluido en Systems Manager). PagerDuty es el estándar del mercado, con integración nativa con CloudWatch, Datadog y la mayoría de herramientas de monitoring.

Post-mortems

Cada incidente significativo debería generar un post-mortem escrito. El formato mínimo:

• Resumen: Qué pasó, cuánto duró, cuántos usuarios se vieron afectados.
• Timeline: Cronología detallada desde la primera alerta hasta la resolución.
• Causa raíz: No “se cayó el servidor”, sino “el Security Group se modificó manualmente eliminando el acceso de la aplicación a la base de datos”.
• Acciones correctivas: Qué cambios se implementan para evitar que vuelva a ocurrir. Cada acción con un responsable y una fecha.

Los post-mortems deben ser blameless (sin culpabilización). El objetivo es mejorar el sistema, no señalar personas.

Runbooks automatizados

CloudWatch puede ejecutar acciones automáticas cuando se dispara una alarma. A través de Systems Manager Automation, puedes crear runbooks que:

• Reinician un servicio ECS cuando la tasa de errores supera un umbral.
• Aumentan la capacidad de DynamoDB cuando se detecta throttling.
• Revocan un Access Key comprometido cuando GuardDuty detecta actividad sospechosa.
• Crean un snapshot de una instancia EC2 antes de aplicar un cambio de emergencia.

Los runbooks automatizados reducen el tiempo medio de resolución (MTTR) de horas a minutos para los incidentes más comunes.

Costes de observabilidad: cuánto deberías gastar

Regla general

Un presupuesto razonable de observabilidad es el 3-5% de tu factura total de AWS. Si gastas 1.000 dolares al mes en infraestructura, entre 30 y 50 dolares al mes en observabilidad es razonable.

Desglose típico para una startup con 10 servicios

Cómo reducir costes de logs

Los logs son el componente más caro de la observabilidad. Estrategias para controlar el coste:

1. Filtra antes de enviar: No envíes logs DEBUG a producción. Configura el nivel de log en INFO o WARN.
2. Compresión: CloudWatch comprime automáticamente, pero asegúrate de que no estás enviando datos innecesarios.
3. Retención adecuada: 30 días suele ser suficiente en CloudWatch. Para retención a largo plazo, exporta a S3 (10 veces más barato).
4. Muestreo de logs: Para logs de acceso de alta frecuencia, considera emitir solo un porcentaje.

Conclusión

La observabilidad no es un proyecto. Es una disciplina que se construye incrementalmente. Empieza con CloudWatch y X-Ray, que ya están ahí. Configura las alarmas que importan. Estructura tus logs. Propaga correlation IDs. Y cuando la complejidad de tu sistema lo justifique, evalúa herramientas de terceros.

El objetivo no es tener más dashboards. Es detectar problemas antes que tus usuarios, entender las causas rápidamente y resolverlos sin pánico.

Si necesitas ayuda para diseñar tu estrategia de observabilidad en AWS, en NERVICO trabajamos con equipos técnicos para implementar monitoring que funciona. Solicita una auditoría gratuita y evaluamos el estado actual de tu observabilidad.