Fundamentos de las métricas de CloudWatch

A las 09:14 se dispara una alerta: la API de checkout está dando timeout. Abres la consola de EC2, miras la instancia y ves la CPU en 22 por ciento. Nada se ve mal. Nada se ve mal porque la instancia se quedó sin memoria, y CloudWatch no tiene ninguna métrica de memoria para EC2 salvo que tú la pongas ahí.

Cada lección de este curso termina leyendo un número de CloudWatch. Antes de confiar en esos números necesitas saber cómo los guarda: qué hace que una métrica sea distinta de otra, con qué frecuencia llegan los valores, cuánto sobreviven y qué estadística responde qué pregunta. Si esta capa te queda mal, todo lo que se construye encima (alarmas, políticas de escalado, dashboards) te va a dar respuestas muy seguras a la pregunta equivocada.

La dirección de una métrica

Una métrica es un conjunto de puntos de datos ordenados en el tiempo. Cada punto tiene un valor, un timestamp y opcionalmente una unidad. Así solo, eso es una lista de números, así que CloudWatch necesita una forma de distinguir una lista de otra.

La dirección tiene tres partes:

• Namespace: el contenedor. Los servicios de AWS usan el patrón AWS/servicio, así que las métricas de EC2 viven en AWS/EC2 y las de Lambda en AWS/Lambda. No hay namespace predeterminado, y tienes que nombrar uno en cada punto de datos que publicas.
• Nombre de la métrica: CPUUtilization, Invocations, FreeStorageSpace.
• Dimensiones: cero o más pares nombre/valor, como InstanceId=i-0a1b2c3d. Una métrica admite hasta 30.

Los namespaces aíslan. Las métricas de namespaces distintos nunca se agregan juntas, y por eso una métrica de aplicación llamada Errors no contamina la métrica Errors de Lambda. Las métricas también existen solo en la Región donde se crearon. Un dashboard en eu-west-1 no va a encontrar una métrica publicada en us-east-1 a menos que construyas una vista cross-Region a propósito.

Las dimensiones son parte de la identidad, no un filtro

Esta es la parte donde tropieza casi todo el mundo, así que veámosla con valores reales.

Supón que publicas cuatro puntos de datos en un namespace llamado Checkout, todos con el nombre de métrica OrdersProcessed:

Dimensions: Service=api,    Stage=prod  Value: 105
Dimensions: Service=api,    Stage=beta  Value: 115
Dimensions: Service=worker, Stage=prod  Value: 95
Dimensions: Service=worker, Stage=beta  Value: 97

Puedes recuperar estadísticas exactamente de esas cuatro combinaciones. No puedes recuperar Service=api por su cuenta, ni Stage=prod por su cuenta, porque nunca publicaste un punto de datos solo con esas dimensiones. La consulta no devuelve nada, lo que en un dashboard se lee como "la métrica está rota" cuando en realidad significa "esa métrica nunca se creó".

Nombremos la confusión en voz alta: las dimensiones se sienten como filtros sobre una tabla grande, así que la gente espera que Stage=prod recorte los datos. No son filtros. CloudWatch trata cada combinación única de dimensiones como una métrica separada. Agregar un valor nuevo de dimensión crea una variación nueva de la métrica, no una fila nueva dentro de la vieja.

Hay una excepción que empeora la confusión. Para métricas de ciertos servicios de AWS, EC2 entre ellos, CloudWatch sí agrega entre dimensiones: busca CPUUtilization en AWS/EC2 sin dimensiones y obtienes un promedio de tus instancias. CloudWatch nunca hace esto con métricas personalizadas. O sea que el comportamiento que aprendes haciendo clic en las gráficas de EC2 es justo el que no va a ocurrir con las métricas que publica tu propio código.

Si quieres un total además del desglose por instancia en una métrica personalizada, publica los dos: un punto de datos con el conjunto completo de dimensiones y otro con las dimensiones sobre las que quieres el rollup.

Resolución: cada cuánto llega un número

Toda métrica es de una de dos resoluciones.

La resolución estándar tiene granularidad de un minuto. Todo lo que publican los servicios de AWS es de resolución estándar.

La alta resolución guarda datos con granularidad de 1 segundo y solo está disponible para métricas personalizadas que publicas tú. Después las puedes leer con un período de 1, 5, 10 o 30 segundos, o cualquier múltiplo de 60.

Un período es el lapso que cubre una estadística. Los valores válidos son 1, 5, 10, 30 o cualquier múltiplo de 60 segundos, y el valor predeterminado es 60. Los datos agregados se estampan con el inicio de su período, así que los datos que cubren de 19:00 a 20:00 quedan estampados 19:00.

La alta resolución cuesta más en dos lugares. Cada llamada a PutMetricData se factura, así que publicar cada segundo multiplica ese cargo, y una alarma de alta resolución con período de 10 o 30 segundos tiene un cargo mayor que una normal. Úsala cuando de verdad necesitas reaccionar en menos de un minuto, no por costumbre.

Monitoreo básico y detallado en EC2

EC2 publica gratis un conjunto fijo de métricas cada 5 minutos: CPUUtilization, NetworkIn, NetworkOut, DiskReadOps, DiskWriteOps, DiskReadBytes, DiskWriteBytes y algunas más. Eso es el monitoreo básico y viene activo de forma predeterminada.

El monitoreo detallado es una opción de pago por instancia que baja el intervalo a 1 minuto. Las mismas métricas, cinco veces la resolución.

aws ec2 monitor-instances --instance-ids i-0a1b2c3d4e5f67890

Ninguna de las dos opciones agrega uso de memoria ni uso del sistema de archivos. Esos números viven dentro del sistema operativo invitado, y el hipervisor que publica las métricas de EC2 no puede ver hacia adentro. Recolectarlos necesita el agente de CloudWatch, que es el tema de una lección más adelante en este mismo tema.

La consecuencia que cae en el examen: el período de una alarma tiene que ser al menos tan largo como la resolución de la métrica. Pon un período de 60 segundos sobre una métrica de monitoreo básico y cuatro de cada cinco períodos quedan sin datos, así que la alarma se estaciona en INSUFFICIENT_DATA y nunca te dice nada. Usa un período de 300 segundos o activa el monitoreo detallado.

Retención: tus datos envejecen hacia cubetas más gruesas

CloudWatch no guarda tus datos de 1 minuto para siempre, y tampoco los tira. Los agrega.

Sigue un punto de datos publicado hoy con resolución de 1 minuto. Durante 15 días lo puedes graficar minuto a minuto. El día 16 el detalle por minuto ya no está, pero el dato sigue existiendo como agregados de 5 minutos, y queda así hasta el día 63. Después solo sobrevive el rollup horario, hasta un total de 455 días.

Dos consecuencias que aparecen en incidentes reales. Primero, un post mortem escrito tres semanas después del evento no te puede mostrar el minuto exacto en que empezó el pico, solo la cubeta de 5 minutos donde cayó. Si el detalle por minuto importa para cumplimiento o análisis, expórtalo o mándalo a algún lugar durable mientras todavía existe. Segundo, una métrica que deja de recibir datos desaparece de la búsqueda de la consola a las dos semanas aunque get-metric-data todavía la devuelva. Una métrica que nadie encuentra en la consola no es lo mismo que una métrica borrada.

Las métricas no se pueden borrar en absoluto. Expiran solas después de 15 meses sin datos nuevos. Eso convierte a una dimensión mal elegida, a un ID de instancia incrustado en el nombre de una métrica o a un namespace suelto en algo con lo que convives, no en algo que limpias.

Estadísticas: los mismos datos, historias distintas

Una estadística es una agregación sobre un período. La elección cambia la respuesta.

• Average suaviza. Sirve para tendencias de capacidad, no sirve para encontrar la instancia mala, porque un promedio de flota de 40 por ciento esconde la instancia al 99 por ciento.
• Maximum es lo contrario. Un pico anómalo fija el techo de toda la gráfica y hace ver enfermo a un sistema sano.
• Sum es la correcta para contadores. Errores, invocaciones, conteo de solicitudes: la pregunta es "cuántos", no "qué tan grande".
• SampleCount te dice cuántos puntos de datos entraron en el período, que es como notas que una métrica dejó de reportar en silencio.
• Los percentiles viven entre Average y Maximum. p95 es el valor por debajo del cual cae el 95 por ciento de tus datos, así que muestra la carga alta sostenida e ignora el valor atípico ocasional. Puedes especificar hasta diez decimales, como en p95.0123456789.

Los percentiles vienen con condiciones. CloudWatch necesita los puntos de datos crudos y sin resumir para calcularlos, así que si publicaste un statistic set preagregado los percentiles normalmente no están disponibles. Tampoco funcionan en métricas con valores negativos. Entre los servicios cuyas métricas admiten percentiles están API Gateway, Application Load Balancer, EC2, ELB, Kinesis, Lambda y RDS.

Una elección concreta: para "¿la latencia es aceptable para la mayoría de los usuarios?", usa p95 sobre Duration. Para "¿se rompió algo?", usa Sum sobre Errors. Para "¿estoy por chocar con un límite de concurrencia?", usa Maximum sobre ConcurrentExecutions.

Publicar tus propias métricas

Todo lo que CloudWatch no mide por ti lo puedes publicar tú con PutMetricData.

aws cloudwatch put-metric-data \
  --namespace Checkout \
  --metric-name QueueDepth \
  --dimensions Service=worker,Stage=prod \
  --value 47 \
  --unit Count

Tres detalles deciden si esto funciona en producción.

Timestamps. Un punto de datos se puede estampar hasta dos semanas en el pasado y hasta dos horas en el futuro. Si omites el timestamp, CloudWatch lo estampa al recibirlo. Las alarmas evalúan contra la hora UTC actual, así que una métrica que llega con un reloj desfasado cae en períodos que la alarma ya evaluó. El síntoma es una alarma atascada en INSUFFICIENT_DATA o disparándose mucho después del evento, no un error de la API, y eso hace del desfase de reloj un bug genuinamente difícil de ver.

Volumen. Cada llamada a PutMetricData se factura. Si necesitas muchas muestras por minuto, publica un statistic set: le das a CloudWatch el Min, Max, Sum y SampleCount de un lote de observaciones en una sola llamada. El costo de eso es perder las estadísticas de percentil, porque los puntos crudos ya no están.

Misma identidad, muchas fuentes. A CloudWatch no le importa qué host mandó un punto de datos. Veinte servidores web publicando al mismo namespace, nombre de métrica y dimensiones producen una sola métrica que los describe a todos. Eso suele ser exactamente lo que quieres para un número de latencia a nivel de flota.

Para aplicaciones que ya escriben logs estructurados vale la pena conocer el embedded metric format (EMF): escribes un evento de log JSON con una estructura específica en CloudWatch Logs, y CloudWatch extrae métricas de él automáticamente. Container Insights y Lambda Insights funcionan así, como verás más adelante en este tema.

Consejos para el examen

• "Uso de memoria" y "espacio usado en el sistema de archivos" siempre apuntan al agente de CloudWatch, nunca al monitoreo básico o detallado. El monitoreo detallado cambia la frecuencia, no la cobertura.
• Monitoreo básico es 5 minutos, detallado es 1 minuto. Una alarma en INSUFFICIENT_DATA con período de 60 segundos sobre una métrica de EC2 es la trampa clásica del monitoreo básico.
• Una consulta que no devuelve datos para un conjunto parcial de dimensiones no es un bug. Revisa si esa combinación exacta se publicó alguna vez, y recuerda que las métricas personalizadas nunca agregan entre dimensiones.
• Alta resolución significa 1 segundo y aplica solo a métricas personalizadas. Las alarmas de alta resolución admiten períodos de 10 o 30 segundos y cuestan más.
• Memoriza la escalera de retención como 3 horas, 15 días, 63 días, 455 días. Las preguntas la formulan como "¿todavía podemos ver datos por minuto de hace tres meses?", y la respuesta es no, solo el rollup horario.
• Si una pregunta contrasta esconder valores atípicos contra quedar dominado por ellos, la respuesta buscada es un percentil.

La regla que te llevas: una métrica se define por namespace más nombre más su conjunto exacto de dimensiones, y todo lo demás (resolución, retención, estadísticas) se desprende de cómo se publicó. Lo siguiente es pasar de números a texto, donde vive la evidencia cruda: CloudWatch Logs y el lenguaje de consulta que convierte un millón de líneas de log en una respuesta.