El módulo 4 terminó con una frase incómoda: está todo montado, y nadie está mirando. MercadoFresco tiene una tienda que escala sola, una base de datos replicada, una CDN que sirve el 96 % del tráfico, identidades mínimas, datos cifrados y dos cortafuegos de aplicación. Y sin embargo, si el viernes a las 19:10 la tienda empieza a devolver errores, la primera persona en enterarse será un cliente por Twitter.

Amazon CloudWatch es el servicio que resuelve eso. No es «los gráficos de AWS»: es el repositorio central donde todos los servicios que has montado escriben lo que les pasa, el sitio donde se almacenan los registros de tu aplicación, y el motor que decide cuándo despertar a alguien. Marta lo lleva usando de refilón desde 02-01 —cada vez que hemos mirado CPUUtilization o creado una alarma estábamos en CloudWatch— pero nunca lo hemos montado en serio.

Esta lección lo monta en serio. Al final, MercadoFresco tendrá un panel que Marta abre cada mañana con el café, métricas de negocio propias, todos sus registros en un solo sitio consultables con SQL-ish, y —lo más importante— la certeza comprobada de que un aviso llega a un teléfono a las cuatro de la madrugada.

Aviso de coste. CloudWatch es de los servicios de AWS que más fácilmente se descontrolan, y casi nunca por las métricas: por los registros. Un grupo de registros con retención infinita, o una aplicación con DEBUG activado en producción, pueden costar más que las instancias EC2 que los generan. Cada sección de esta lección indica su coste, y hay una sección entera dedicada a ello.

1. Qué es CloudWatch y qué no es
2. Los tres pilares
3. Métricas: espacios de nombres y dimensiones
4. Resolución estándar frente a alta resolución
5. Estadísticas: por qué la media miente
6. Periodos, agregación y retención
7. Las métricas que importan de verdad de lo que ya está montado
8. Por qué EC2 no publica el uso de memoria
9. Publicar métricas personalizadas con boto3
10. PutMetricData por lotes y valores estadísticos
11. El agente unificado de CloudWatch en las instancias del ASG
12. Embedded Metric Format desde Lambda
13. Registros: grupos, flujos y retención
14. Los registros que MercadoFresco tiene dispersos
15. Logs Insights: sintaxis y consultas reales
16. Responder a «¿por qué tardó ocho segundos ese pedido?»
17. Filtros de métricas: de un patrón de log a una alarma
18. Suscripciones y exportación a S3
19. Alarmas: umbrales, evaluación y datos faltantes
20. Alarmas compuestas
21. Detección de anomalías
22. Acciones de alarma
23. Comprobar que el aviso llega de verdad
24. El panel mercadofresco-produccion
25. ServiceLens y Synthetics
26. Coste de CloudWatch y cómo se dispara
27. Limpieza

CloudWatch es un servicio regional de observabilidad que hace tres cosas: almacenar series temporales numéricas (métricas), almacenar texto con marca de tiempo (registros), y evaluar condiciones sobre lo anterior para disparar acciones (alarmas).

Lo que no es, y conviene fijarlo desde el principio porque evita mucha confusión:

La confusión más común es la primera. Si Luis busca «quién borró el bucket», eso no está en CloudWatch: está en CloudTrail. CloudWatch guarda lo que tu aplicación y los servicios dicen de sí mismos, no quién habló con la API de AWS.

Históricamente el bus de eventos se llamó «CloudWatch Events» y todavía verás ese nombre en documentación antigua y en algunas respuestas de la CLI. Hoy es EventBridge y se estudia en 07-03; esta lección no lo toca.

Fíjate en la flecha que va de registros a métricas: un filtro de métricas convierte un patrón de texto en una serie numérica. Es el puente que permite alarmar sobre algo que solo aparece en un log, como ERROR pago rechazado. Y fíjate también en que el ALB escribe sus registros de acceso en S3, no en CloudWatch Logs: eso tendrá consecuencias en la sección de Logs Insights.

Una métrica es una serie temporal identificada por tres cosas:

• Espacio de nombres (namespace): el contenedor. Los de AWS empiezan por AWS/ (AWS/EC2, AWS/ApplicationELB, AWS/RDS, AWS/Lambda, AWS/S3, AWS/CloudFront). El tuyo no puede empezar por AWS/: MercadoFresco usa MercadoFresco/Tienda.
• Nombre de la métrica: CPUUtilization, TargetResponseTime, PedidosConfirmados.
• Dimensiones: hasta 30 pares clave/valor que identifican de qué es la medida. InstanceId=i-0abc..., LoadBalancer=app/alb-mercadofresco-tienda/..., DBInstanceIdentifier=mercadofresco-pedidos.

El detalle que más despista al principio: cada combinación distinta de dimensiones es una métrica diferente y se factura por separado. Estas son tres métricas, no una:

Y CloudWatch no agrega automáticamente entre ellas. Si publicas solo la tercera y luego consultas la primera, no habrá datos. Esto tiene dos consecuencias prácticas:

1. Si quieres el total y también el desglose, publica ambos.
2. Nunca uses como dimensión algo de cardinalidad alta. Poner PedidoId como dimensión crea una métrica nueva por pedido: 900 métricas a la hora, 650.000 al mes, a 0,30 USD cada una. Eso son más de 190.000 USD mensuales por un descuido de una línea. La identidad de un pedido va en un registro o en una anotación de X-Ray (05-02), nunca en una dimensión.

Regla de MercadoFresco: las dimensiones son categorías cerradas y pequeñas —entorno, componente, tipo de pago, provincia— nunca identificadores.

La alta resolución sirve para procesos que cambian en segundos: una cola que se llena, un pico de latencia de 20 segundos que a resolución de minuto queda diluido en la media. MercadoFresco no la usa: sus problemas se ven perfectamente a un minuto, y las alarmas de 10 segundos generan ruido nocturno. Es una herramienta de diagnóstico puntual, no un valor por defecto.

Las métricas básicas de EC2 son de 5 minutos salvo que actives la monitorización detallada (2,10 USD por instancia y mes en eu-west-1, aproximadamente), que las baja a 1 minuto. Para el ASG de MercadoFresco sí merece la pena: con datos de 5 minutos, el escalado reacciona tarde al pico de los viernes.

CloudWatch no guarda cada punto individual: guarda agregados por periodo. Al consultar eliges qué agregado quieres:

El error clásico —y el que más incidentes esconde— es alarmar sobre Average de una latencia. Un minuto real de la tienda de MercadoFresco:

Average = 0,17 s. Perfecto. Verde. Ninguna alarma salta.

p99 = 9,4 s. Diez clientes por minuto están viendo una rueda girar durante casi diez segundos mientras intentan pagar. Son exactamente los clientes que importan: los que están comprando.

Regla: para cualquier métrica de latencia, alarma sobre p95 o p99, nunca sobre Average. La media te dice cómo va el servidor; el percentil te dice cómo lo vive el cliente.

Un matiz importante: los percentiles solo están disponibles si la métrica se publica con datos suficientes. Las métricas del ALB los soportan de forma nativa. Para métricas propias, hay que publicar valores individuales o usar StatisticValues con cuidado (lo veremos: los StatisticValues no permiten percentiles, porque ya llegan agregados).

El periodo es la ventana de agregación de la consulta o la alarma: 60 s, 300 s, 3600 s… Es independiente de la frecuencia con la que publicas. Si publicas cada 10 segundos y consultas con periodo 300, CloudWatch agrega 30 puntos en uno.

La retención es automática, gratuita y no configurable:

Dos consecuencias operativas:

• No puedes consultar con periodo 60 un día de hace dos meses. Los datos ya están agregados a 5 minutos. Si necesitas comparar el Black Friday del año pasado al minuto, tienes que haberlo exportado antes.
• Marta exporta cada mes las métricas de negocio (PedidosConfirmados) a mercadofresco-informes-analitica con get-metric-data, precisamente para que Sara pueda comparar campañas de años distintos.

Esta es la tabla que Marta se ha impreso. De los cientos de métricas que publican los servicios de MercadoFresco, estas son las que de verdad deciden algo:

Tres observaciones que separan a quien entiende esto de quien copia umbrales:

• HTTPCode_ELB_5XX_Count y HTTPCode_Target_5XX_Count no son lo mismo. El primero significa que el balanceador no pudo entregar la petición a nadie (no hay destinos sanos, tiempo de espera agotado). El segundo significa que tu aplicación respondió 500. Confundirlos hace perder horas buscando en el sitio equivocado.
• FreeStorageSpace de RDS está en bytes. El umbral de 20 GB se escribe 21474836480. Un cero de más y la alarma no salta nunca.
• Throttles de Lambda con umbral > 0, no > 10. Un solo estrangulamiento significa que has tocado el techo de concurrencia y hay clientes viendo errores. No hay un «poco de throttling aceptable».

Es la pregunta que hace todo el mundo al llegar aquí, y la respuesta explica cómo funciona la nube.

El hipervisor de AWS ve la máquina virtual desde fuera. Puede medir CPU consumida, tráfico de red, operaciones de disco del volumen EBS: todo eso pasa por su capa. Pero la memoria libre es un concepto del sistema operativo invitado. Solo Linux sabe cuánta RAM está en buff/cache y podría liberarse, y eso el hipervisor no lo puede saber sin entrar dentro.

Lo mismo pasa con el espacio libre del disco: EBS es un dispositivo de bloques, y solo el sistema de ficheros de dentro sabe qué está ocupado.

Consecuencia práctica: para memoria y disco de EC2 necesitas instalar un agente dentro de la instancia. Se hace más abajo. Y consecuencia de diseño: por eso Lambda, Fargate y RDS —donde AWS gestiona el sistema operativo— sí publican memoria sin que hagas nada.

Las métricas de infraestructura dicen cómo va la máquina. Las de negocio dicen cómo va la empresa, y son las que de verdad detectan incidentes. En 04-04 vimos por qué: si llegan 5.000 peticiones por segundo y PedidosPorHora no se mueve, no son clientes.

MercadoFresco ya publicaba PedidosPorHora. Ahora añadimos las dos que faltan:

El código, en la tienda:

Detalles que importan y que no son obvios:

• Timestamp es opcional; si no lo pones, CloudWatch usa la hora de recepción. Puedes publicar datos con hasta 2 semanas de antigüedad y hasta 2 horas en el futuro. Esto permite recuperar métricas de un proceso por lotes que falló.
• La unidad importa poco a CloudWatch pero mucho a las alarmas. Si publicas en Milliseconds y la alarma espera Seconds, la alarma no encuentra datos y se queda en INSUFFICIENT_DATA para siempre. Sé consistente.
• Publicar Value: 1 repetidamente es correcto. CloudWatch suma los valores del periodo cuando consultas con Sum. No hace falta que la aplicación mantenga un contador.
• provincia no se usa como dimensión en este ejemplo. España tiene 52 provincias: sería aceptable, pero multiplicaría por 52 el número de métricas (15,60 USD/mes solo por eso). Marta decidió que ese desglose vive en los informes de Sara sobre mercadofresco-informes-analitica, no en CloudWatch.

El código anterior hace una llamada HTTPS a la API de CloudWatch dentro de la ruta crítica de una compra. Con 900 pedidos/hora funciona; con un pico serio, esa llamada de 40 ms se suma al tiempo de respuesta que el cliente percibe, y si la API de CloudWatch se ralentiza, tu tienda se ralentiza.

Tres soluciones, de peor a mejor:

1. Envolver en try/except y no fallar nunca. Mínimo indispensable: una métrica no debe tumbar una venta.
2. Acumular en memoria y publicar por lotes cada 20 segundos desde un hilo aparte (siguiente sección).
3. Escribir la métrica en el log en formato EMF y dejar que CloudWatch la extraiga (sección de Lambda). Coste cero en la ruta crítica.

PutMetricData acepta hasta 1.000 puntos por llamada (con un límite de 1 MB de cuerpo). Publicar por lotes reduce el coste de API (0,01 USD por cada 1.000 llamadas) y saca la latencia de la ruta crítica.

Si solo necesitas Sum, Average, Min y Max, puedes preagregarlo tú y enviar un único punto con StatisticValues. Una llamada en lugar de novecientas:

El precio de esta optimización: con StatisticValues pierdes los percentiles. CloudWatch solo recibe cuatro números; no puede calcular un p99 a partir de ellos. Como el p95 de TiempoConfirmacionPedido es precisamente lo que Marta quiere vigilar, MercadoFresco no usa StatisticValues para esa métrica. Sí la usa para ImportePedido, donde el Sum y el Maximum son todo lo que interesa.

Una tercera opción, intermedia, es el campo Values + Counts, que envía valores distintos con su multiplicidad y sí conserva percentiles:

Para memoria y disco hace falta un agente dentro de la instancia. El agente unificado de CloudWatch (amazon-cloudwatch-agent) hace dos trabajos a la vez: publica métricas del sistema y envía ficheros de log a CloudWatch Logs. Sustituye a los antiguos scripts de Perl y al awslogs, que ya no se usan.

El rol rol-mercadofresco-tienda necesita esto añadido a pol-mercadofresco-tienda:

Fíjate en dos cosas. cloudwatch:PutMetricData no admite ARN de recurso —por eso "Resource": "*" con la condición de espacio de nombres, exactamente el patrón que estudiamos en 04-01—. Y la configuración del agente se guarda en Parameter Store (04-03), que es la forma limpia de que todas las instancias del ASG compartan la misma sin hornearla en la AMI.

Repaso de las decisiones tomadas ahí, porque cada una tiene su motivo:

• namespace propio MercadoFresco/Sistema, separado de MercadoFresco/Tienda. Métricas de máquina y métricas de negocio no se mezclan: facilita los permisos y los paneles.
• append_dimensions con ${aws:AutoScalingGroupName}: el agente resuelve esas variables solo, consultando los metadatos de la instancia. No hay que generar un fichero por instancia.
• aggregation_dimensions con [] (lista vacía) publica también la métrica agregada de todo el grupo. Es la que se usa en el panel: a Marta le interesa «memoria media del ASG», no la de la instancia i-0abc.
• multi_line_start_pattern: sin esto, una traza de Python de 30 líneas se convierte en 30 eventos de log inconexos y las consultas de Insights no encuentran nada.
• retention_in_days en la propia configuración: el agente crea el grupo con retención finita desde el primer día. Es la línea que más dinero ahorra de todo el fichero.
• procstat vigila el proceso gunicorn concreto. Si el proceso muere y systemd lo reinicia en bucle, la CPU de la instancia parece normal pero procstat lo delata.

Y el fragmento que se añade al user data de la plantilla lt-mercadofresco-tienda (02-01):

Después de actualizar el user data hay que crear una nueva versión de la plantilla de lanzamiento y hacer un instance refresh del ASG:

Coste del agente: el software es gratuito; se paga por lo que publica. Con 4 métricas del sistema agregadas a nivel de ASG más las de cada instancia, MercadoFresco publica unas 20 métricas personalizadas: 6 USD al mes. La verificación importa: si dejas las dimensiones por instancia sin agregar y el ASG rota instancias todo el día, cada InstanceId nuevo crea métricas nuevas. Son métricas que dejan de recibir datos —y por tanto de facturarse tras el periodo de facturación—, pero ensucian los paneles.

En Lambda, llamar a PutMetricData es especialmente caro: la función está facturada por milisegundo, así que esperar 40 ms a la API de CloudWatch se paga literalmente. Y si la Lambda se invoca 50.000 veces al día, son 50.000 llamadas de API.

El Embedded Metric Format (EMF) resuelve esto de forma elegante: escribes un JSON con una estructura especial en stdout, y CloudWatch Logs extrae las métricas automáticamente al ingerirlo. Coste en la función: el de un print.

La clave conceptual está en las dos últimas secciones del documento:

Es decir: EMF te permite tener la clave del objeto de S3 y el ID de la petición junto a la métrica, sin pagar el precio de la cardinalidad. Cuando el p99 de TiempoProceso se dispare, una consulta de Insights te dirá exactamente qué ficheros fueron los lentos. Eso con PutMetricData es imposible.

Nota práctica: la librería aws-embedded-metrics de AWS hace todo esto por ti con un decorador. Aquí se ha escrito el JSON a mano para que se vea la estructura, que es lo que hay que entender.

Coste de EMF: se paga la ingesta del log (unos 0,63 USD/GB en eu-west-1) y las métricas extraídas (0,30 USD cada una). No se pagan llamadas de API. Para funciones de alta frecuencia sale claramente a cuenta.

La jerarquía es simple y conviene tenerla clara:

• Grupo de registros (log group): el contenedor. Aquí se configura la retención, el cifrado con KMS y las suscripciones. Ejemplo: /mercadofresco/tienda/aplicacion.
• Flujo de registros (log stream): una secuencia de eventos de una sola fuente. Una instancia, una ejecución de Lambda. Ejemplo: i-0abc123def456.
• Evento: una línea con marca de tiempo y mensaje. Máximo 256 KB.

Por defecto, un grupo de registros se crea con retención Never expire. Nadie lo cambia. Tres años después, MercadoFresco tendría 400 GB de logs de nginx de 2023 costando 0,03 USD/GB/mes —12 USD mensuales por datos que nadie va a leer jamás— y creciendo.

Y hay algo peor que el coste: una consulta de Logs Insights escanea lo que le pidas, y a 0,0063 USD por GB escaneado, una búsqueda descuidada sobre tres años de logs cuesta más que la búsqueda misma.

La política de MercadoFresco:

Y el comando que hay que ejecutar el mismo día que se crea un grupo:

Una auditoría útil que Marta ejecuta una vez al mes, para encontrar los grupos que se le han colado sin retención:

En 05-04 veremos cómo AWS Config convierte esta auditoría manual en una regla que salta sola.

CloudWatch Logs tiene dos clases de almacenamiento:

Para flowlogs-mercadofresco, que se consulta solo cuando hay una investigación de red, la clase Infrequent Access ahorra la mitad. Para /mercadofresco/tienda/aplicacion, del que dependen filtros de métricas y alarmas, hay que quedarse en Standard.

Esta era una de las cinco preguntas abiertas del módulo 4: «los registros de WAF, VPC, ALB y Lambda se acumulan en cinco sitios sin correlacionar». Vamos a ver el mapa real:

La honestidad importa aquí: CloudWatch Logs no lo centraliza todo. Los registros de acceso del ALB y de CloudFront van a S3 por diseño, porque su volumen haría prohibitiva la ingesta en Logs. La centralización real de MercadoFresco es a dos niveles:

• Diagnóstico en caliente (últimos días): CloudWatch Logs Insights.
• Análisis histórico y forense: S3 + Athena, que se ve en 05-03.

Activar los registros de PostgreSQL en la instancia RDS, que sí falta:

Ese log_min_duration_statement=1000 va a ser decisivo en la sección del pedido de ocho segundos.

CloudWatch Logs Insights es un lenguaje de consulta sobre los registros. No es SQL, aunque se le parece: es una tubería de comandos separados por |.

Los campos @timestamp, @message, @logStream y @log existen siempre. Si tu log es JSON, Insights lo descompone solo y puedes referirte a nivel, pedido_id, duracion_ms directamente. Esa es la razón número uno para loguear en JSON desde el primer día.

bin(5m) agrupa por ventanas de cinco minutos: es lo que convierte una lista de errores en un gráfico de tendencia. Al ejecutarla, Insights ofrece «Visualization» y ese resultado se puede añadir directamente al panel.

Esta es la consulta que en 04-05 decidía el paso de Count a Block. Ahora sabes exactamente dónde se ejecuta.

Los campos @duration, @billedDuration, @maxMemoryUsed y @initDuration los genera Lambda automáticamente en la línea REPORT de cada invocación. @maxMemoryUsed frente a la memoria configurada es la forma más directa de ajustar el tamaño de una función: si usa 80 MB de 512 configurados, estás pagando de más.

Alguien intentando llegar al puerto 5432 y siendo rechazado por sg-mercadofresco-basedatos. Si esa IP es interna, es un error de configuración. Si es externa, es un escaneo.

parse con expresión regular y grupos con nombre convierte el log de acceso de nginx en campos consultables. Es el rescate para todo el software que no loguea en JSON.

Aviso de coste: cada ejecución cobra por GB escaneados, no por resultados devueltos. Acotar el rango temporal es lo que decide la factura: la misma consulta sobre 1 hora o sobre 30 días cuesta 720 veces más en el segundo caso. Reduce siempre la ventana antes de refinar la consulta.

Esta es la segunda pregunta que dejó abierta el módulo 4. Un cliente escribe: «el jueves por la tarde tardé como ocho segundos en que se confirmara el pedido». Marta tiene su correo y la hora aproximada.

Requisito previo: un identificador de correlación que atraviese todos los componentes. Sin él, esto es imposible. MercadoFresco añade en nginx una cabecera X-Peticion-Id que la aplicación propaga a la Lambda y escribe en cada línea de log.

Paso 1. Confirmar que el problema existe y acotarlo.

Aparecen 34 peticiones lentas el jueves entre las 18:40 y las 19:20. No era cosa de un cliente.

Paso 2. Encontrar la petición concreta.

Sale una: peticion_id = 7f3a9b2c, duracion_ms = 8140.

Paso 3. Seguir ese identificador por todos los grupos a la vez. Insights permite consultar hasta 50 grupos de registros en una sola consulta, y esa es la respuesta real a «los registros están en cinco sitios sin correlacionar»:

Paso 4. Leer la cronología.

Encontrado. No era la tienda (27 + 57 + 52 + 10 + 34 = 180 ms), ni la Lambda (550 ms): eran 7,4 segundos dentro de PostgreSQL. Los registros de log_min_duration_statement que activamos antes son los que han cantado.

Paso 5. Ver qué consulta era.

Y aparece una consulta que hace un SELECT de precio por cada línea del pedido, en un bucle, en lugar de un solo SELECT ... WHERE id IN (...). Es el patrón N+1: un pedido con 38 productos ejecuta 39 consultas.

Qué acabamos de hacer y qué no. Hemos localizado el problema con registros correlacionados, y ha funcionado porque MercadoFresco tenía un identificador de petición propagado a mano. Pero fíjate en el esfuerzo: cuatro consultas, una cronología montada manualmente, y todo apoyado en que alguien se acordó de propagar la cabecera. Existe una herramienta diseñada exactamente para esto, que hace el paso 4 automáticamente y en un gráfico: es X-Ray, y es la lección 05-02. Volveremos a este mismo pedido de 8,14 segundos allí.

No se puede alarmar sobre un log; sí sobre una métrica. Un filtro de métricas es la conversión.

Tres detalles de campo:

• La sintaxis de --filter-pattern no es la de Insights. Para logs JSON usa { $.campo = "valor" } con &&, ||, =, !=, >, <. Para texto plano, comillas y términos: "ERROR" -"ERROR de prueba".
• defaultValue=0 es imprescindible. Sin él, cuando no hay errores no se publica ningún dato, la alarma se queda en INSUFFICIENT_DATA y la métrica tiene huecos que rompen la detección de anomalías. Con defaultValue=0 la serie es continua.
• Los filtros solo se aplican a eventos nuevos. No hay efecto retroactivo sobre lo ya ingerido.

También se puede extraer un valor numérico del log en lugar de contar:

Y probar el patrón antes de crearlo, contra eventos reales, que evita el clásico filtro que nunca coincide:

Dos formas de sacar registros de CloudWatch, con propósitos distintos:

Suscripción en tiempo real hacia una Lambda que reenvía a Slack lo crítico:

Exportación a S3 para archivo barato de los flow logs, que se van a mirar una vez al año:

El bucket necesita una política que permita a logs.eu-west-1.amazonaws.com escribir. Y ojo: solo puede haber una tarea de exportación activa por cuenta a la vez, y no es incremental. Para archivado continuo, la opción moderna es una suscripción hacia Data Firehose con destino S3.

Una alarma tiene tres estados:

Y cuatro parámetros que casi nadie configura bien a la primera:

• --period: la ventana de agregación. 60, 300…
• --evaluation-periods: cuántos periodos se miran.
• --datapoints-to-alarm: cuántos de esos deben incumplir. Si se omite, son todos.
• --treat-missing-data: qué hacer con los huecos.

La combinación evaluation-periods + datapoints-to-alarm se llama «M de N» y es la herramienta contra el ruido. Compara:

Con «2 de 3», un pico de un solo minuto —un despliegue, un garbage collector, una copia de seguridad— no despierta a nadie, pero un problema real que oscila sí se detecta. La configuración «3 de 3» se pierde exactamente esos problemas intermitentes.

Y --treat-missing-data, cuatro opciones:

El caso que lo explica todo: la alarma sobre PedidosConfirmados. Si la tienda se cae del todo, deja de publicarse la métrica. Con notBreaching, la alarma se queda en OK mientras la tienda está muerta. Es el fallo silencioso más común de CloudWatch, y por eso esa alarma concreta lleva --treat-missing-data breaching.

Las alarmas que MercadoFresco crea en esta lección:

Nota sobre --ok-actions en la alarma 1: enviar también la recuperación. Sin ella, alguien recibe un aviso de madrugada y no tiene forma de saber si sigue pasando. Con --ok-actions, el segundo mensaje dice «ya está bien». Es un detalle pequeño que cambia mucho la experiencia de estar de guardia.

Y una advertencia sobre la alarma 8: PedidosConfirmados < 1 en 15 minutos es correcto para el horario comercial, pero a las 4 de la mañana un domingo puede ser perfectamente normal que no haya pedidos. Esa alarma genera falsos positivos nocturnos. La forma correcta de resolverlo no es subir el periodo: es la detección de anomalías, dos secciones más abajo.

Una alarma compuesta se evalúa sobre otras alarmas, con AND, OR y NOT. Sirve para dos cosas distintas:

1. Reducir ruido: solo avisar si varias señales coinciden.
2. Suprimir alarmas hijas durante un mantenimiento conocido.

El problema real de MercadoFresco: cuando la base de datos se satura un viernes, saltan a la vez mercadofresco-rds-conexiones-altas, mercadofresco-alb-latencia-alta y mercadofresco-pedidos-fallidos. Tres SMS a las 19:15 describiendo el mismo incidente.

Y ahora el paso que la mayoría olvida: quitar la acción de SNS de las alarmas hijas. Si no, sigues recibiendo cuatro avisos en lugar de tres.

La alarma hija sigue existiendo, sigue cambiando de estado y sigue viéndose en el panel: simplemente ya no notifica. El aviso lo da la compuesta, que contiene el diagnóstico.

Supresión durante mantenimiento: el parámetro --actions-suppressor permite indicar otra alarma —por ejemplo, una que Marta pone en ALARM a mano durante un despliegue— que silencia la compuesta mientras esté activa.

Coste: 0,50 USD por alarma compuesta y mes. Suele salir a cuenta solo por dejar de despertar a alguien tres veces.

En lugar de un umbral fijo, CloudWatch entrena un modelo con hasta dos semanas de historia y aprende el patrón: los picos de los viernes, los valles de la madrugada, el ciclo semanal. La alarma salta cuando el valor sale de la banda esperada.

Es exactamente lo que resuelve el falso positivo nocturno de mercadofresco-sin-pedidos: a las 4 de la mañana el modelo espera 3 pedidos, y 0 es anómalo; a las 19:00 espera 900, y 400 también lo es. Un umbral fijo no puede expresar eso.

Detalles clave:

• LessThanLowerThreshold: solo avisa si hay menos pedidos de lo esperado. Que haya más es una buena noticia, no una alarma. Existen también GreaterThanUpperThreshold y LessThanLowerOrGreaterThanUpperThreshold.
• El 2 de ANOMALY_DETECTION_BAND(m1, 2) es el número de desviaciones. Más alto = banda más ancha = menos avisos. Empieza en 2 y ajusta con datos reales.
• Necesita historia. Los primeros días la banda es enorme y la alarma no sirve de nada. Hay que crearla y esperar.
• Se puede excluir un periodo del entrenamiento con --configuration y ExcludedTimeRanges: si hubo un incidente de 6 horas, no quieres que el modelo aprenda que eso es normal.

Coste: 0,30 USD por métrica analizada y mes, más 0,30 USD por alarma de anomalía.

Y una advertencia honesta: la detección de anomalías no es magia. Detecta desviaciones del patrón histórico, no problemas. Una degradación lenta y constante durante tres semanas se convierte en el nuevo «normal» y deja de avisar. Complementa a los umbrales fijos; no los sustituye.

Las acciones automáticas de EC2 son útiles pero peligrosas. arn:aws:automate:eu-west-1:ec2:recover sobre StatusCheckFailed_System migra la instancia a otro anfitrión cuando falla el hardware subyacente, conservando IP y volúmenes: eso es claramente bueno. En cambio arn:aws:automate:eu-west-1:ec2:reboot sobre memoria alta es una mala idea: reinicias en bucle una instancia con una fuga de memoria y ocultas el problema en lugar de arreglarlo.

Para las instancias del ASG, además, la acción correcta casi nunca es reiniciar: es dejar que fallen el health check /salud y que el propio ASG las reemplace, que es lo que montamos en 02-01 y 03-03.

Aquí está la primera pregunta abierta del módulo 4, y la más importante de esta lección: nadie ha comprobado que un aviso de SNS llegue a un teléfono a las cuatro de la madrugada.

Una alarma que dispara hacia un tema de SNS sin suscriptores confirmados es peor que no tener alarma: da una falsa sensación de cobertura.

Paso 1. Ver quién está suscrito de verdad.

Si en la columna SubscriptionArn aparece PendingConfirmation, esa suscripción no recibe nada. Es el hallazgo más frecuente al hacer esta comprobación por primera vez: alguien creó la suscripción hace meses, el correo de confirmación se fue a la carpeta de correo no deseado, y nadie lo supo.

Paso 2. Suscribir los destinos que faltan.

Nota sobre SMS. Desde hace unos años, enviar SMS con SNS en muchas regiones exige salir del «sandbox» de SMS y, para números españoles, registrar remitente y caso de uso. Si tu SMS de prueba no llega, revisa el estado del sandbox antes de dar por rota la alarma. El detalle completo de SNS —temas FIFO, políticas de entrega, filtros de suscripción— es la lección 07-02.

Paso 3. El simulacro. Forzar el estado de la alarma.

Este es el comando que cierra la pregunta del módulo 4:

Esto no toca la métrica: fuerza el estado de la alarma y dispara sus acciones de verdad. El SMS y el correo salen. Es la única forma honesta de saber que el canal funciona.

Después se devuelve a la realidad:

En el siguiente periodo de evaluación, CloudWatch recalcula el estado real con los datos de la métrica y lo corrige solo si hiciera falta.

Paso 4. El protocolo que adopta MercadoFresco.

Y una comprobación más, que suele descubrir el problema real: hacer el simulacro a las 4 de la madrugada de verdad, una vez. Marta lo hizo. Descubrió que el móvil de guardia estaba en «no molestar» y que los SMS de números cortos no rompían el silencio. La solución no fue de AWS: fue configurar una excepción en el teléfono. La cadena de aviso incluye el teléfono, y el teléfono también hay que probarlo.

Un panel de CloudWatch es un documento JSON con una cuadrícula de 24 columnas de ancho. Los widgets se posicionan con x, y, width, height.

El criterio con el que Marta lo ha diseñado —y que es lo que hay que copiar, más que el JSON— es: arriba lo que responde «¿está bien el negocio?», en medio «¿qué componente falla?», abajo el detalle. Cuando suena el teléfono, se mira de arriba abajo y en 30 segundos se sabe dónde ir.

Y la creación:

Detalles del JSON que merecen explicación:

• "start": "-PT3H" fija la ventana por defecto en las últimas 3 horas. Sintaxis ISO 8601 de duración: -PT1H, -P1D, -P7D.
• ["...", { "stat": "p95" }] repite la métrica anterior cambiando solo la estadística. Ahorra repetir el ARN largo tres veces.
• El widget del borde lleva "region": "us-east-1". Las métricas de CloudFront y de la Web ACL de CloudFront viven ahí, la misma trampa de 03-04 y 04-05. Un panel puede mezclar regiones widget a widget, y eso lo convierte en el único sitio donde MercadoFresco lo ve todo junto.
• Las annotations horizontales dibujan la línea del umbral. Ver el gráfico acercarse a la línea roja antes de que salte la alarma es la mitad del valor de un panel.
• El widget log ejecuta una consulta de Insights cada vez que se carga el panel. Cuidado: eso cuesta dinero cada vez, y si el panel está en una pantalla de la oficina refrescando cada minuto, son 1.440 consultas al día. Marta le puso limit 20 y una ventana corta por esa razón.

Coste de los paneles: los 3 primeros son gratuitos; a partir de ahí, 3 USD por panel y mes. MercadoFresco tiene dos: mercadofresco-produccion y mercadofresco-negocio (el de Sara, con pedidos e importes). Coste: 0 USD.

Dos funciones de CloudWatch que se mencionan aquí y se aprovechan en 05-02:

ServiceLens une métricas, registros y trazas de X-Ray en un mapa de servicios único. Necesita que X-Ray esté activo, así que se ve en la lección siguiente.

CloudWatch Synthetics ejecuta «canarios»: pequeños scripts que se comportan como un cliente, desde fuera, cada N minutos. Es monitorización sintética: no espera a que haya un cliente real para detectar que la tienda está rota. Con 900 pedidos/hora eso no parece importante, pero a las 3 de la madrugada un domingo pueden pasar dos horas sin una sola compra, y ese es exactamente el hueco por el que se cuela una caída.

El canario de MercadoFresco, canario-mercadofresco-compra, se ejecuta cada 5 minutos y hace el recorrido completo: portada, buscar «tomate», abrir la ficha, añadir al carrito, llegar al formulario de pago (sin pagar). Si algún paso falla, dispara alertas-mercadofresco.

Dos advertencias prácticas:

• Un canario que compra de verdad genera pedidos de verdad. El de MercadoFresco se detiene antes de confirmar, y el usuario de prueba está marcado para que Sara lo excluya de sus informes.
• Coste: 0,0012 USD por ejecución. Cada 5 minutos son 8.640 ejecuciones al mes: 10,37 USD, más las capturas de pantalla en S3 y las trazas. No es despreciable; es la partida más cara de esta lección después de los registros.

Precios de referencia en eu-west-1 (aproximados; consulta siempre la calculadora oficial):

El cálculo de MercadoFresco:

Las cinco formas de disparar esta factura, por orden de frecuencia real:

1. Retención infinita en los grupos de registros. Crece sin parar y nunca lo notas de golpe.
2. DEBUG activado en producción. Multiplica la ingesta por diez de un día para otro. La ingesta es la partida cara: 0,63 USD/GB.
3. Una dimensión de cardinalidad alta. PedidoId como dimensión: decenas de miles de USD. Es el error más caro que se puede cometer en CloudWatch, y se comete en una línea.
4. Consultas de Insights sobre 30 días para depurar. Cada refinamiento de la consulta vuelve a escanear todo.
5. Un panel con widgets de log en una pantalla de oficina. Ejecuta consultas cada minuto para siempre.

Y la defensa: un presupuesto de AWS Budgets filtrado por el servicio CloudWatch (módulo 11) con aviso al 80 %. En 05-04 veremos además cómo AWS Config detecta automáticamente los grupos de registros sin retención.

Dos avisos:

• Las métricas personalizadas no se pueden borrar. Dejan de facturarse cuando dejan de recibir datos (tras el periodo correspondiente), pero permanecen visibles un tiempo. Es una razón más para no crear dimensiones a la ligera.
• Borrar un grupo de registros elimina sus datos de forma irreversible. Si puede haber una obligación de conservación, expórtalo a S3 primero y consúltalo con quien lleve el cumplimiento.

1. Alarmar sobre la media de una latencia. Es el error número uno. Average de TargetResponseTime se queda plano mientras el p99 está en 9 segundos. Usa --extended-statistic p95 o p99 para todo lo que sea tiempo.

2. Dejar la retención de registros en «Never expire». Es el valor por defecto. Es el error más caro a medio plazo. Pon retención el mismo día que creas el grupo, y audita mensualmente con describe-log-groups.

3. Usar un identificador como dimensión. PedidoId, UserId, RequestId en una dimensión crean una métrica nueva cada vez. Miles de USD. Esos datos van en el log o en una anotación de X-Ray.

4. --treat-missing-data mal elegido. Para una métrica cuya ausencia es el problema —PedidosConfirmados, HealthyHostCount— hay que poner breaching. Con notBreaching la alarma está tranquila mientras la tienda está muerta.

5. Confundir HTTPCode_ELB_5XX_Count con HTTPCode_Target_5XX_Count. El primero es del balanceador (no hay destinos sanos, tiempo de espera); el segundo es tu aplicación. Buscar en el sitio equivocado cuesta horas.

6. Umbrales en unidades equivocadas. FreeStorageSpace está en bytes; Duration de Lambda en milisegundos; TargetResponseTime en segundos. Un cero de más o de menos y la alarma nunca salta.

7. Crear una alarma sin comprobar la suscripción de SNS. Si el ARN es correcto pero nadie ha confirmado la suscripción, la alarma dispara al vacío. Comprueba con list-subscriptions-by-topic y haz un simulacro con set-alarm-state.

8. No configurar --ok-actions. Quien recibe un aviso de madrugada necesita saber cuándo se ha recuperado. Sin la notificación de vuelta a OK, alguien se levanta para nada o, peor, no se levanta cuando debe.

9. Buscar en CloudWatch quién borró un recurso. Eso está en CloudTrail (05-03). CloudWatch registra lo que tu aplicación dice de sí misma.

10. Métricas de CloudFront buscadas en eu-west-1. Están en us-east-1, siempre. Igual que los certificados de ACM (03-04) y la Web ACL de CloudFront (04-05).

11. Consultas de Insights sobre rangos enormes mientras se depura. Empieza por 15 minutos, afina la consulta, y solo entonces amplía la ventana. Se paga por GB escaneado en cada ejecución.

12. Loguear texto plano en lugar de JSON. Con JSON, Insights descompone los campos solos y las consultas son triviales. Con texto plano hay que escribir expresiones regulares con parse. Cambiar el formato del log el primer día cuesta una hora; hacerlo tres años después, semanas.

13. Un filtro de métricas sin defaultValue=0. La serie tiene huecos, la alarma se queda en INSUFFICIENT_DATA y la detección de anomalías no funciona.

14. Olvidar quitar las acciones de las alarmas hijas al crear una compuesta. Se acaba recibiendo un aviso más, no menos.

Consejo final: la métrica más valiosa de un sistema casi nunca es técnica. PedidosConfirmados detecta más incidentes reales que CPUUtilization, porque puede haber mil formas de que la tienda falle con la CPU al 30 %, pero solo hay una forma de que los pedidos caigan a cero.

MercadoFresco despliega una versión nueva de la tienda un martes a las 11:00. La versión tiene un error que solo afecta a los pedidos pagados con tarjeta de un banco concreto: aproximadamente el 12 % de las compras. El resto funciona con normalidad.

Datos del incidente: CPUUtilization sin cambios (42 %), HealthyHostCount en 2, TargetResponseTime p95 estable en 0,6 s, HTTPCode_Target_5XX_Count con 3 errores cada 5 minutos (antes: 1). PedidosConfirmados pasa de 900/h a 792/h. En los logs aparecen líneas {"nivel":"ERROR","tipo_error":"PAGO_RECHAZADO","pasarela":"banco-x"}.

Ninguna alarma actual salta. El error se descubre 6 horas después por una queja en redes sociales.

Diseña la detección: qué métrica o métricas usarías, cómo las obtendrías (filtro de métricas, métrica personalizada, expresión), qué tipo de alarma y con qué parámetros exactos de periodo, evaluación y datos faltantes. Escribe los comandos. Justifica por qué tu propuesta habría saltado en menos de 30 minutos sin generar falsos positivos el resto del mes.

Sara pregunta si el buscador de la tienda está funcionando bien. La aplicación escribe una línea JSON por búsqueda:

Escribe:

• a) Una consulta de Insights que dé, por hora, el número de búsquedas, la duración media, el p95 y el porcentaje de búsquedas sin resultados.
• b) Una consulta que liste los 20 términos más buscados que devuelven cero resultados (son productos que MercadoFresco debería tener en catálogo: valor directo para Sara).
• c) Un filtro de métricas y una alarma que avisen si el porcentaje de búsquedas sin resultados supera el 20 % durante 15 minutos, que es la señal de que el índice de búsqueda se ha corrompido. Ojo: un filtro de métricas cuenta, no calcula porcentajes. Necesitarás una expresión de métrica en la alarma.

Marta recibe la factura y CloudWatch ha pasado de 44 a 610 USD en un mes. El desglose:

Pistas de la investigación:

• El grupo /mercadofresco/tienda/aplicacion ha pasado de 8 GB a 620 GB en el mes.
• El espacio MercadoFresco/Tienda tiene ahora 320 métricas; el mes pasado tenía 8.
• Hay 11.200 ejecuciones de Insights, todas con ventana de 30 días.
• Hay un canario nuevo, canario-mercadofresco-admin, ejecutándose cada minuto.
• Luis desplegó hace tres semanas una función de «pedidos recomendados» que registra la actividad de cada cliente.

Diagnostica cada partida, di exactamente qué hizo Luis mal en cada caso, escribe las acciones correctivas con los comandos, y propón tres controles preventivos para que no vuelva a pasar. Estima la factura resultante.

Solución 1

Por qué no saltó nada. Todas las alarmas actuales miran a la infraestructura, y la infraestructura está perfecta. Un fallo del 12 % en una pasarela concreta es invisible para la CPU, para el número de destinos sanos y para el p95 de latencia (un pago rechazado responde rápido, incluso más rápido que uno correcto). Y la caída de pedidos de 900 a 792 —un 12 %— queda dentro de la variación normal de un martes. Ningún umbral fijo razonable detecta un 12 %.

Esto es lo que se llama un fallo parcial, y es el tipo de incidente que más tarda en detectarse en sistemas reales.

Detección propuesta: tres capas.

Capa 1 — la señal directa. Filtro de métricas sobre el error concreto, desglosado por pasarela.

Capa 2 — la alarma de proporción, que es la buena. Un umbral absoluto de «más de N rechazos» falla en los dos sentidos: de noche 3 rechazos son muchísimo, en el pico del viernes son nada. Lo correcto es alarmar sobre el porcentaje, con una expresión de métrica:

Con 12 % de rechazos frente a un umbral del 5 %, y «2 de 3» periodos de 5 minutos, esta alarma salta en 10-15 minutos. El requisito es publicar también IntentosPago (un segundo filtro de métricas o una métrica personalizada); sin denominador no hay proporción.

Capa 3 — la red de seguridad genérica: detección de anomalías sobre PedidosConfirmados. Una caída del 12 % sostenida durante 6 horas sí sale de la banda de anomalía, porque el modelo conoce el patrón de un martes por la mañana con precisión. Es la alarma mercadofresco-pedidos-anomalos que ya creamos: habría saltado, probablemente en la primera hora. Es más lenta que la capa 2, pero es la única que detecta problemas que nadie ha anticipado.

Por qué no genera falsos positivos. La capa 2 mira una proporción, y una proporción es independiente del volumen: funciona igual a las 4 de la mañana que el viernes a las 19:00. Con «2 de 3» periodos de 5 minutos, un pico aislado de rechazos —un banco que reinicia su pasarela un minuto— no dispara nada.

La lección de fondo: las alarmas de infraestructura detectan caídas totales. Los fallos parciales, que son los más frecuentes y los que más dinero cuestan, solo los detectan las métricas de negocio y las proporciones.

Solución 2

a) Panorama por horas.

La clave está en sum(resultados = 0): en Insights, una expresión booleana vale 1 o 0, así que sumarla cuenta los casos verdaderos. Es el idioma para calcular porcentajes en este lenguaje.

b) Términos sin resultados: valor de negocio directo.

Esto no es monitorización técnica: es una lista de productos que los clientes buscan y MercadoFresco no vende. Marta la envía a Sara cada lunes. Es el mejor ejemplo de que los registros de una aplicación valen para mucho más que depurar.

c) Filtro de métricas y alarma de proporción.

Dos filtros, porque hacen falta numerador y denominador:

Y la alarma con expresión:

Tres decisiones justificadas:

• MAX([total, 1]) en el denominador evita la división por cero cuando no hay búsquedas de madrugada. Sin eso, la expresión produce valores no numéricos y la alarma se comporta de forma errática.
• 3 de 3 periodos de 5 minutos = 15 minutos, tal como pedía el enunciado. Aquí sí conviene «3 de 3» y no «2 de 3»: un índice corrompido no se arregla solo, así que la señal será sostenida, y esperar 15 minutos evita el ruido de un despliegue del índice de búsqueda.
• notBreaching porque de madrugada puede no haber búsquedas, y eso no es un incidente.

Solución 3

Diagnóstico partida por partida.

1. Ingesta de registros: 412 USD (8 GB → 620 GB). La función de «pedidos recomendados» de Luis registra la actividad de cada cliente en cada visita. Probablemente escribe una línea por producto visto, y muy probablemente con nivel: DEBUG porque así lo dejó tras depurar. 612 GB extra a 0,63 USD/GB son 386 USD. Es la causa principal.

Error de Luis: dejar DEBUG en producción y registrar en el log de aplicación un flujo de eventos de analítica que no es un log de aplicación.

Corrección, en dos tiempos:

De fondo: los eventos de comportamiento de cliente no van a CloudWatch Logs. Van a mercadofresco-informes-analitica en S3, vía Firehose, donde el almacenamiento cuesta 0,023 USD/GB en lugar de 0,63 USD/GB de ingesta. Es 27 veces más barato y es donde Sara los quiere de todos modos.

2. Métricas personalizadas: 96 USD (8 → 320 métricas). 320 × 0,30 = 96 USD. Casi con seguridad, la función de recomendaciones publica una métrica con una dimensión de cardinalidad media —CategoriaProducto con 300 valores, o ModeloRecomendador—.

Error de Luis: usar como dimensión algo que no es una categoría pequeña y cerrada.

Corrección: quitar esa dimensión y, si el desglose se necesita, ponerlo como propiedad EMF, que es consultable con Insights y no cuesta 0,30 USD por valor. Nota importante para el examen mental: la factura de métricas no baja hasta el mes siguiente, porque las métricas ya creadas se facturan mientras reciban datos. No se pueden borrar; hay que dejar de publicarlas.

Y la prevención de verdad, en la política IAM del rol —el patrón de 04-01—:

Esto no limita la cardinalidad —IAM no puede—, pero sí impide que una aplicación cree espacios de nombres nuevos sin control, que es la otra mitad del problema.

3. Logs Insights: 71 USD (11.200 ejecuciones a 30 días). 11.200 consultas escaneando volúmenes enormes. Dos causas superpuestas: alguien depurando con la ventana en «30 días» sin cambiarla, y muy probablemente un widget de log en un panel abierto en una pantalla que reejecuta la consulta cada vez que se refresca.

Corrección: reducir la ventana por defecto de los widgets de log, poner limit bajo, y establecer la norma de empezar siempre por 15 minutos. Como el grupo baja de 620 GB a ~8 GB al arreglar el punto 1, esta partida cae sola en más de un 95 %.

4. Synthetics: 27 USD. canario-mercadofresco-admin cada minuto son 43.200 ejecuciones al mes. Para un panel de administración que usan tres personas en horario de oficina, es absurdo.

Corrección:

De 43.200 a 2.880 ejecuciones: de 51,84 a 3,46 USD. Y si solo importa en horario de oficina, se puede programar con una expresión cron en lugar de rate.

5. Alarmas y paneles: 4 USD. Correcto. No se toca.

Factura estimada tras las correcciones:

Tres controles preventivos:

1. Presupuesto de AWS Budgets filtrado por servicio = CloudWatch, con umbral de 60 USD y aviso al 80 % a [email protected]. Detecta la desviación en días, no en la factura del mes siguiente. Se ve en el módulo 11.
2. Regla de AWS Config que marque como no conforme cualquier grupo de registros sin retentionInDays, con remediación automática que le ponga 30 días. Es exactamente el caso de uso de la lección 05-04.
3. Revisión en el proceso de despliegue: nadie despliega código que escribe logs nuevos sin que otra persona revise el volumen estimado y el nivel de log. Es una casilla en la revisión de código, no una herramienta. El módulo 8 la integra en el pipeline.

Y un cuarto, cultural, que es el que de verdad funciona: enseñar la factura. Cuando Luis vio que sus logs de depuración costaban 386 USD al mes —más que las instancias EC2 que los generaban— no volvió a dejar DEBUG activado.

MercadoFresco ya tiene una mirada. Sabes que CloudWatch son tres cosas —métricas, registros y alarmas— y sabes qué no es: ni el registro de quién llamó a la API (CloudTrail, 05-03), ni el rastreador de peticiones (X-Ray, 05-02), ni el evaluador de cumplimiento (Config, 05-04), ni el bus de eventos (EventBridge, 07-03).

Dominas el modelo de métricas: espacio de nombres, nombre y dimensiones, con la regla de oro de que cada combinación de dimensiones es una métrica facturable y que un identificador en una dimensión es el error más caro de este servicio. Sabes elegir la estadística —Sum para contadores, Average para utilización, p95/p99 siempre para latencia— y por qué la media de 0,17 s ocultaba que diez clientes por minuto esperaban nueve segundos para pagar. Conoces la retención automática que agrega los datos a 5 minutos tras 15 días, y la tabla de las métricas que de verdad deciden algo en cada servicio que has montado, con la diferencia crítica entre HTTPCode_ELB_5XX_Count y HTTPCode_Target_5XX_Count.

Has publicado las métricas de negocio PedidosConfirmados y TiempoConfirmacionPedido en MercadoFresco/Tienda, primero con PutMetricData directo y después por lotes desde un hilo aparte para sacar la llamada de la ruta crítica de una compra. Sabes por qué EC2 no publica memoria —el hipervisor no ve dentro del sistema operativo invitado— y has desplegado el agente unificado en lt-mercadofresco-tienda con su configuración en Parameter Store, sus append_dimensions resueltas solas y su retention_in_days puesta desde el primer día. Y conoces el Embedded Metric Format, que en Lambda te da métricas gratis en la ruta crítica y —esto es lo importante— te permite guardar la clave de S3 y el ID de petición junto a la métrica sin pagar cardinalidad.

En registros, has centralizado lo que se podía centralizar y sabes lo que no: los accesos del ALB y de CloudFront viven en S3 y se consultan con Athena. Tienes la política de retención por grupo, la clase Infrequent Access para los flow logs, y las consultas de Logs Insights que responden preguntas reales —los bloqueos de WAF por regla, el p99 de una Lambda con @duration, los rechazos al puerto 5432, y parse con expresión regular para el software que no loguea en JSON—. Y, sobre todo, has respondido a la pregunta del pedido de ocho segundos: cuatro grupos de registros consultados a la vez con un identificador de correlación, una cronología montada evento a evento, y el culpable identificado —7.402 ms dentro de PostgreSQL, un patrón N+1 con 39 consultas para un pedido de 38 productos—.

Sabes convertir un patrón de log en métrica con un filtro de métricas (y por qué defaultValue=0 no es opcional), y sacar registros con suscripciones en tiempo real o exportación a S3.

En alarmas, dominas lo que separa una alarma útil de una fuente de ruido: la combinación «M de N» con --datapoints-to-alarm 2 --evaluation-periods 3, el tratamiento de datos faltantes —con breaching para las métricas cuya ausencia es el incidente, como PedidosConfirmados—, las alarmas compuestas que convierten tres SMS en uno y que exigen quitar las acciones de las hijas, y la detección de anomalías que sabe que 0 pedidos a las 4 de la mañana es normal y a las 19:00 es una catástrofe. Has montado ocho alarmas nuevas —que se suman a las de los módulos 2 y 4 hasta trece en total—, la compuesta mercadofresco-tienda-degradada y el detector de anomalías sobre PedidosConfirmados.

Y has respondido a la primera pregunta que dejó abierta el módulo 4, que era la más incómoda de todas: el aviso llega de verdad. Has comprobado las suscripciones buscando el temido PendingConfirmation, has suscrito el correo y el teléfono de guardia, y has hecho el simulacro con set-alarm-state, que dispara las acciones reales sin tocar la métrica. Y sabes que la cadena incluye el teléfono: el «no molestar» de un móvil ha silenciado más alarmas que cualquier error de configuración de AWS.

Todo ello se ve junto en el panel mercadofresco-produccion, ordenado de arriba abajo —negocio, componentes, detalle—, con las métricas de CloudFront en su widget de us-east-1, las líneas de anotación que enseñan lo cerca que estás del umbral antes de que salte, y el widget de log con los últimos errores. Y con el canario canario-mercadofresco-compra recorriendo la tienda cada cinco minutos para que un domingo de madrugada, sin un solo cliente real, alguien siga comprobando que se puede comprar. Todo por unos 44 USD al mes, con las cinco formas de disparar esa cifra identificadas y la retención puesta el mismo día que se crea cada grupo.

Queda, sin embargo, una insatisfacción concreta. La investigación del pedido de ocho segundos funcionó, pero costó cuatro consultas, una cronología montada a mano en una hoja de cálculo, y dependió por completo de que alguien se hubiera acordado de propagar la cabecera X-Peticion-Id por todos los componentes. Si mañana el cuello de botella está dentro de la Lambda, o en la llamada a la pasarela de pago, o en el tiempo de conexión a la base de datos, habrá que repetir el trabajo entero y adivinar otra vez dónde mirar.

Existe una herramienta que hace ese trabajo sola, que dibuja la cronología en un gráfico y que dice, para una petición concreta, cuánto tardó cada tramo del recorrido: AWS X-Ray. En la lección 05-02, «AWS X-Ray y trazabilidad distribuida», veremos qué es una traza, un segmento y un subsegmento, cómo se propaga el identificador con X-Amzn-Trace-Id, por qué no se trazan todas las peticiones y cómo se configura el muestreo, cómo instrumentar la tienda con aws_xray_sdk y activar el rastreo en mercadofresco-estado-pedido con una casilla y un permiso, cómo leer el mapa de servicios y buscar con filtros como annotation.pedido_id, y volveremos a este mismo pedido de 8,14 segundos para verlo, esta vez, en un solo gráfico.