Observabilidad a escala

Son las 2 de la mañana y falla el checkout. El servicio de pagos vive en una cuenta, el de inventario en otra y el frontend en una tercera. Si para ver cada log tienes que cambiar de cuenta, pierdes media hora antes de empezar a buscar.

CloudWatch resuelve una cuenta. A escala necesitas tres cosas más: ver todas las cuentas desde un solo lugar, instrumentar todo con el mismo estándar y medir lo que viven los usuarios en su navegador.

Ver sin copiar: observabilidad entre cuentas

Con CloudWatch cross-account observability eliges una cuenta de monitoreo y le conectas cuentas de origen. Desde la cuenta de monitoreo consultas métricas, logs, trazas de X-Ray, servicios y SLO de Application Signals como si fueran locales. Los datos siguen en su cuenta.

• Se configura con Observability Access Manager (OAM): la cuenta de monitoreo crea un sink y cada cuenta de origen crea un link hacia él.
• Funciona dentro de una región: hay un sink por cuenta y región.
• Si vinculas por Organizations, las cuentas nuevas de la OU quedan conectadas solas.
• Puedes filtrar qué compartir, por ejemplo solo ciertos namespaces de métricas o ciertos grupos de logs.

Copiar a un archivo central

Para retención larga, auditoría o análisis con otras herramientas necesitas una copia. Hay tres caminos:

Criterio	Reglas de centralización	Filtros de suscripción	Ver entre cuentas (OAM)
Qué hace	Copia logs de muchas cuentas y regiones a grupos de logs de una cuenta central	Envía en casi tiempo real los eventos que cumplen un patrón a Kinesis Data Streams, Firehose, Lambda u OpenSearch	Consulta los datos donde están, sin copiarlos
Alcance	Organización, OU o cuentas; varias regiones	Un grupo de logs, o toda la cuenta con un filtro a nivel de cuenta	Una región
Bueno para	Una cuenta de logs central con región de respaldo	Llevar a S3 vía Firehose, a un SIEM o a procesamiento propio	Investigar incidentes y paneles de toda la organización
Ojo con	Solo copia datos nuevos, no el histórico	Hasta cinco filtros por grupo de logs; solo clase Standard	No sirve para retener datos aparte

El patrón clásico: filtro de suscripción a nivel de cuenta → destino de CloudWatch Logs en la cuenta central → Firehose → S3 con ciclo de vida, y consultas con Athena. Las reglas de centralización hacen lo mismo dentro de CloudWatch Logs con menos piezas. También existen reglas de centralización para métricas personalizadas, EMF y OTLP.

Contenedores y OpenTelemetry

OpenTelemetry (OTel) es el estándar abierto para emitir métricas, logs y trazas. Instrumentas una vez y decides después a dónde mandar los datos. AWS recomienda OTel para trazas nuevas: los SDK de X-Ray están en mantenimiento.

• 

  AWS Distro for OpenTelemetry

  El cableado estándar de los sensores

  Distribución de OpenTelemetry soportada por AWS: SDK, autoinstrumentación y Collector, probados con servicios de AWS.
• 

  Amazon CloudWatch

  El tablero de cada servicio

  El agente de CloudWatch recibe OTLP y alimenta Application Signals: latencia, errores y volumen por servicio, mapa de dependencias y SLO. Funciona con Java, Python, Node.js y .NET.
• 

  Amazon Managed Service for Prometheus

  La bodega de lecturas de sensores

  Prometheus administrado: guarda métricas y las consultas con PromQL. Común en Kubernetes.
• 

  Amazon Managed Grafana

  Las pantallas de la central

  Grafana administrado: paneles sobre CloudWatch, Prometheus, X-Ray y otras fuentes, con acceso por IAM Identity Center o SAML.

Container Insights recoge métricas y logs de ECS, EKS (incluido Fargate) y Kubernetes en EC2, a nivel de clúster, nodo, servicio, tarea y pod. La versión con observabilidad mejorada baja al detalle de contenedor. En EKS se instala con el complemento de CloudWatch Observability; la variante OTel Container Insights usa OTLP y consultas PromQL. Para el diseño de los clústeres, mira contenedores a escala.

Los SLO de Application Signals son la forma práctica de llevar a la central lo visto en SLI y SLO: el operador ve primero qué promesa se está rompiendo, no cuál CPU subió.

Medir la experiencia real con RUM

Todo puede verse verde en el servidor mientras la página tarda ocho segundos en un celular con mala señal. CloudWatch RUM (Real User Monitoring) agrega un fragmento de JavaScript a tu sitio que envía, desde el navegador de cada usuario real:

• Tiempos de carga de página y de recursos, por página, navegador y país.
• Errores de JavaScript y respuestas HTTP 4xx y 5xx vistas por el cliente.
• Core Web Vitals: LCP (cuánto tarda el contenido principal), CLS (cuánto salta el diseño) e INP (qué tan rápido responde a una interacción). También reporta FID.
• Sesiones y recorridos, para ver dónde abandonan los usuarios.

Muestreas un porcentaje de sesiones para controlar volumen y costo. RUM también admite aplicaciones móviles. Y no reemplaza a CloudWatch Synthetics: los canarios simulan usuarios cada pocos minutos y detectan una caída aunque nadie esté entrando; RUM mide a los usuarios que sí entran.

Que la observabilidad no cueste más que la aplicación

Revisa también qué duplicas: una copia por centralización, otra por suscripción a S3 y otra en un SIEM son tres veces el mismo dato. Más ideas en controlar costos.