Como leer una estadistica de CloudWatch sin retos
CloudWatch tiene 12 estadisticas, pero la mayoria de los equipos usa 3. Esta guia recorre las 12 con un solo dataset numerico para que veas exactamente que revela y que esconde cada una, con un arbol de decision y los 4 patrones que aplican a cualquier servicio de AWS.
El problema: tu dashboard miente
Son las 3 a.m. Tu dashboard esta verde. La alarma usa Average ≤ 15s y marca 8.7 segundos. Todo bien. A las 3:15 suena el telefono. Un cliente reporta que sus usuarios esperan casi un minuto. Revisas el p99: 50 segundos. Un usuario sufrio. Y el Average no te dijo nada.
El problema no fue el sistema, fue la estadistica. El Average escondio la cola y tu alarma no vio el incendio.
"Performance metrics reported as averages hide critical information." - AWS Solutions Library
CloudWatch ofrece 12 estadisticas. La mayoria de los equipos usa 3. Esta guia cubre las 12 con un solo dataset para que veas exactamente como se comporta cada una con los mismos numeros.
Usaremos el mismo dataset en toda la guia: 10 tiempos de respuesta en segundos.
Suma todos los valores del periodo. Usala para conteos: total de solicitudes, total de errores, bytes transferidos, dinero facturado. Si la pregunta es "cuantos en total?" la respuesta es Sum.
# 10 solicitudes (segundos) |
|---|
50 2 3 3 2 4 5 4 8 6 |
Las 5 basicas
Estadistica | Uso |
|---|---|
Sum = 87 | Suma todos los valores del periodo. Usala para conteos: total de solicitudes, total de errores, bytes transferidos, dinero facturado. Si la pregunta es "cuantos en total?" la respuesta es Sum. |
Average = 8.7 | Sum / SampleCount = 87 / 10 = 8.7. Funciona bien para metricas acotadas como utilizacion de CPU (0-100%). Pero fijate: 8.7 no describe a ningun dato real. Nueve valores estan entre 2 y 8. Uno es 50. El promedio cae en un lugar que no representa a nadie. |
Maximum = 50 | El valor mas alto del periodo. Usalo para medidores instantaneos: profundidad de cola, ejecuciones concurrentes, edad del mensaje mas viejo. Quieres saber lo peor que llego a estar. |
Minimum = 2 | El valor mas bajo. Usalo para verificar recuperacion: se vacio la cola? El conteo de errores volvio a cero? |
SampleCount = 10 | Cuantos datos entraron al calculo. Parece trivial, pero recuerda este numero para las siguientes estadisticas. |
El resto que muchos no utilizan:
Usaremos el mismo dataset como menciones, pero la regla especial de las siguientes estadisticas es que toman la responsabilidad de ordernarla de forma ascendiente.
# 10 solicitudes (segundos), menor a mayor |
|---|
2 2 3 3 4 4 5 6 8 50 |
Percentil (p): ver la cola
Imagina 100 personas en fila, de la mas rapida a la mas lenta:
- p50 es la del medio (lo tipico).
- p99 es la penultima: solo una fue mas lenta. Es "que tan mal le fue al desafortunado?"
Con nuestro dataset: p50 = 4s (el del medio), p90 = 8s, p99 ≈ 50s (el que se atasca).
Average = 8.7s > El dashboard dice verde" | p99 ≈ 50s -> Alguien espero casi un minuto" |
|---|
A escala importa enormemente. Un servicio con 1 millon de solicitudes al dia y p99 = 1,200ms significa 10,000 solicitudes dolorosamente lentas cada dia. Son usuarios reales.
La regla: para todo lo que mida duracion o latencia, usa percentiles.
- p99 para tu SLO.
- p50 para la linea base.
- Nunca Average para latencia.
Medias robustas: TM, IQM, WM
El Average fallo porque un valor atipico (50) lo arrastro de un valor tipico cercano a 4 hasta 8.7. Pero a veces no quieres la cola, quieres "lo tipico" sin la distorsion. CloudWatch te da tres formas de sacar un valor central que resiste los outliers, y se diferencian en que le hacen al dato extremo: la Trimmed Mean lo elimina, la Winsorized Mean lo reemplaza, y la IQM es una Trimmed Mean con limites fijos.
Trimmed Mean (TM) = 4.375
La Trimmed Mean es el promedio de todos los valores que caen entre dos limites que tu defines. Los valores fuera de esos limites se ignoran por completo antes de promediar. Defines los limites de dos maneras:
TM(10%:90%) elimina el 10% inferior (el 2) y el 10% superior (el 50), y promedia el resto:
# Datos restantes (Elimino el 1er y ultimo numero de la lista) : 2, 3, 3, 4, 4, 5, 6, 8 |
|---|
# Suma = 35 / 8 = 4.375 |
- Como porcentajes: TM(10%:90%) usa solo los valores entre el percentil 10 y el 90. tm90 (una sola cifra, en minusculas) equivale a TM(:90%), es decir elimina el 10% mas alto y nada del lado bajo.
- Como valores absolutos: TM(150:1000) elimina todo lo que sea menor o igual a 150 y todo lo que sea mayor a 1000.
Con nuestro dataset, TM(10%:90%) elimina el 10% inferior (un 2) y el 10% superior (el 50), y promedia los 8 que quedan: 2, 3, 3, 4, 4, 5, 6, 8 suman 35, entre 8 da 4.375. Compara con Average = 8.7. El atipico ya no distorsiona.
La TM tiene tres sabores segun que cola te moleste. TM(10%:) recorta solo los valores mas bajos, por ejemplo latencias artificialmente rapidas por cache hits. tm99 recorta solo el 1% mas alto, los outliers de red o error humano. TM(10%:99%) recorta las dos colas a la vez.
Vale la pena entender la diferencia entre p99 y tm99, porque miden cosas parecidas pero no iguales. Los dos ignoran el 1% de valores mas altos. Despues, p99 es el valor maximo del 99% restante, mientras que tm99 es el promedio de ese 99% restante. En latencia, p99 te dice la peor experiencia de cliente ignorando outliers, y tm99 te dice la experiencia promedio ignorando outliers. AWS recomienda TM para monitorear latencia: "We recommend that you use trimmed mean for monitoring latency." - AWS CloudWatch Statistics Definitions.
Nota de limites: cuando defines los limites como valores absolutos (no porcentajes), el calculo incluye los valores iguales al limite superior pero excluye los iguales al limite inferior.
Interquartile Mean (IQM) = 4.167
La IQM es simplemente la Trimmed Mean del rango intercuartil, es decir el 50% central de los datos. Equivale exactamente a TM(25%:75%). La diferencia con la TM es que aqui no eliges los limites: estan fijos en el cuartil inferior y el superior.
Con nuestro dataset, descarta el 25% mas bajo y el 25% mas alto y promedia los 6 valores del medio: 3, 3, 4, 4, 5, 6 suman 25, entre 6 da 4.167.
Es la opcion mas estable cuando quieres cero sensibilidad a los extremos y no quieres calibrar limites. Para un KPI que reportas de forma recurrente y que debe ser comparable mes a mes, la IQM te da un numero central que no se mueve porque un dia hubo un pico raro.
Winsorized Mean (WM) = 4.5
La Winsorized Mean se parece a la Trimmed Mean, pero con una diferencia clave: los valores fuera del limite no se ignoran, se reemplazan por el valor que esta en el borde del limite correspondiente. Despues de esa normalizacion, se calcula el promedio. Como no se descarta ningun dato, el conteo de muestras se conserva.
Con WM(10%:90%) sobre nuestro dataset, el 50 (que cae en el 10% superior) se trata como si valiera lo que hay en el borde del percentil 90, es decir 8. El resto queda igual. Ahora promedias 2, 2, 3, 3, 4, 4, 5, 6, 8, 8, que suman 45, entre 10 da 4.5.
La sintaxis sigue el mismo patron: wm98 trata el 2% de valores mas altos como iguales al valor del percentil 98. WM(10%:90%) aplica el reemplazo en las dos colas.
Cuando la eliges sobre TM: cuando quieres que cada punto de dato siga contando (no botar nada) pero limitar cuanto puede jalar un outlier. La TM dice "ignora al extremo"; la WM dice "cuenta al extremo, pero como si fuera el borde".
Requisito comun de las tres: necesitan datos crudos (raw data points) y no admiten valores negativos.
PR, TC, TS: el reparto de apoyo
Percentile Rank: PR(:5) = 70%
El Percentile Rank invierte la pregunta del percentil. Un percentil parte de un porcentaje y te devuelve un valor (p99 = "cual es la latencia por debajo de la cual esta el 99%?"). El Percentile Rank parte de un umbral y te devuelve un porcentaje: que porcentaje de mis valores cumple un umbral fijo.
PR(:5) = 70%
PR(:5) devuelve el porcentaje de puntos con valor de 5 o menos. En nuestro dataset, 7 de los 10 valores son 5 o menos (2, 2, 3, 3, 4, 4, 5), asi que PR(:5) = 70%.
Un detalle que cambia el conteo: el Percentile Rank es exclusivo en el limite inferior e inclusivo en el superior. PR(100:2000) devuelve el porcentaje de valores mayores a 100 (exclusivo) y hasta 2000 (inclusivo).
Donde brilla es en el monitoreo orientado al negocio. En vez de preguntar "cual es mi latencia p99?", preguntas "que porcentaje de solicitudes se proceso dentro de mi objetivo de 15 segundos?". Eso es PR(:15000) en milisegundos. Es un numero auditable, lo entiende el negocio, y mapea directo a un compromiso contractual o a un SLO. Ojo con las unidades: si tu metrica esta en milisegundos, el umbral va en milisegundos.
El Percentile Rank tambien sirve para construir un histograma a mano. Divides tus valores en rangos (bins) como PR(:1), PR(1:5), PR(5:10), y PR(10:), pones cada uno como barra en una visualizacion, y tienes la distribucion completa en vez de un solo punto.
Trimmed Count: TC(2:8) = 7
Cuantos datos cayeron dentro del rango recortado. TC(2:8): valores estrictamente mayores que 2 y hasta 8: {3, 3, 4, 4, 5, 6, 8} = 7. AWS recomienda vigilar TC siempre que uses TM:
"It is a good idea to keep watch on trimmed count whenever you are using trimmed mean." - AWS CloudWatch Statistics Definitions
Trimmed Sum: TS(2:8) = 33
La suma de los valores dentro del rango: 3 + 3 + 4 + 4 + 5 + 6 + 8 = 33.
Hay una relacion limpia: TS = TM x TC. El TM de ese rango es 4.714, por 7 da 33. Cuadra.
Gran valores basado de una linea
Ocho reglas que cubren casi toda decision de monitoreo.
Necesidad | Estadistica |
|---|---|
Duraciones (latencia) | Percentiles (p99 para SLO, p50 para base) |
Conteos / dinero | Sum |
Utilizacion % | Average |
Medidores instantaneos | Maximum |
"Se recupero a 0?" | Minimum |
Promedio robusto | TM / IQM / WM |
"% dentro del objetivo" | PR(:umbral) |
Validar muestra | SampleCount / TC |
Puedes usar las estadisticas extendidas?
Dos preguntas determinan si puedes usar las 7 estadisticas extendidas (percentiles, TM, IQM, WM, PR, TC, TS).
1. Como publicas tus datos?
- Datos crudos (raw data points): las 12 estadisticas disponibles.
- Statistic sets agregados (Min/Max/Sum/SampleCount): solo las 5 basicas. No hay percentiles, no hay TM, no hay PR.
- Las metricas vended de AWS (ALB, Lambda, etc.) ya publican datos crudos. Pero si tu aplicacion agrega antes de publicar, pierdes las extendidas.
2. Tus valores pueden ser negativos?
- No (siempre >= 0): las 12 disponibles. Latencia, conteos, duraciones, utilizacion.
- Si (puede ir negativo): solo Average para tendencia central. Ajustes contables, deltas, ganancias/perdidas.
Conclusion: si quieres percentiles, TM o PR, publica datos crudos y manten los valores no negativos. Un patron, cada servicio
AWS tiene mas de 200 servicios. No necesitas memorizar una tabla. Casi toda metrica cae en uno de 4 tipos, y el tipo decide la estadistica.
CONTEO | LATENCIA | MEDIDOR | TASA / % |
|---|---|---|---|
Conteo→ SumALB RequestCount
Lambda Invocations
API GW 4XX/5XX (count)
CloudFront Requests"The only meaningful statistic is Sum." | Latencia→ PercentilesALB TargetResponseTime
Lambda Duration
API GW Latency
DynamoDB RequestLatency"Duration also supports percentile (p) statistics." | Medidor→ MaximumLambda ConcurrentExec
SQS Message Age
SQS Messages Visible
DAX CPUUtilization"We recommend that you use the maximum stat." | Tasa / %→ AverageAPI GW error rate
CloudFront error rate
EC2 CPUUtilization
RDS CPUUtilization"The Average statistic represents the error rate." |
La regla en una linea: identifica el tipo de metrica, aplica la regla. Este patron se repite en ALB, Lambda, API Gateway, DynamoDB, CloudFront, SQS y cualquier otro servicio.
Arbol de decision
Responde las siguientes preguntas y llega a la estadistica correcta.
P1: Tu metrica es un conteo (eventos, errores, dinero)?
- Si → Sum
- No → continua a P1b
P1b: Es un medidor instantaneo ("vale X ahora mismo") o una medida por evento?
- Medidor instantaneo → P_medidor
- Medida por evento → P2
P_medidor: Que te importa del medidor?
- El pico (profundidad de cola, concurrencia) → Maximum
- Se recupero al piso? (errores a 0, cola vacia) → Minimum
- Utilizacion tipica 0-100% (CPU, memoria) → Average
P2: Necesitas el peor caso (la cola)?
- Si → Percentil (p99). Si necesitas "% dentro del umbral" → PR(:umbral)
- No, el valor tipico → P3
P3: Tus datos pueden tener valores atipicos (outliers)?
- No → Average
- Si → P4
P4: Tu metrica admite valores negativos?
- Si → Average (unica opcion valida)
- No → TM / IQM / WM
Siempre acompana percentiles y TM con SampleCount o TC para validar significancia. Sin muestra suficiente, la estadistica no tiene senal.
Fuentes
Todas las definiciones, citas y recomendaciones de esta guia estan verificadas contra documentacion oficial de AWS:
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article