AWS Builder Center

Builder Center

Tu dashboard miente si esta organizado por servicio

Tienes las estadisticas correctas, los SLIs correctos, las formulas correctas, pero si tu dashboard esta organizado por servicio, toda esa precision queda enterrada en la pestaña equivocada.

vtjean

El dashboard que nadie lee

Conoces este dashboard. Tiene 47 widgets. Una pestaña para EC2, otra para Lambda, otra para RDS, otra para ALB. Cada pestaña tiene CPU, memoria, latencia, errores, conexiones. Todo se ve verde.
Entonces el cliente llama. "Mi transaccion tarda 50 segundos." Abres el dashboard. ¿Donde miras primero? EC2 se ve bien. Lambda se ve bien. RDS se ve bien. ALB... tiene 47 widgets y ninguno responde la pregunta que el cliente acaba de hacer.
El problema no es que falten metricas. El problema es la organizacion. Un dashboard organizado por servicio responde "¿como esta EC2?" Un dashboard organizado por SLO responde "¿estamos cumpliendo lo que prometimos?"
Los tres blogs anteriores de esta serie construyeron las piezas: cual estadistica usar ( Blog 1 ), que errores rompen el SLO ( Blog 2 ), y las formulas de Metric Math que conectan metricas crudas con SLIs ( Blog 3 ). Este post es donde todo converge: como organizar un dashboard de Amazon CloudWatch para que lo primero que veas sea si estas cumpliendo o no.

Dos formas de organizar un dashboard

Por servicio (como lo hace casi todo el mundo)

Plain text
Dashboard
├── EC2
│   ├── CPUUtilization (Average)
│   ├── NetworkIn/Out (Sum)
│   └── StatusCheckFailed (Maximum)
├── Lambda
│   ├── Duration (Average)    ← Blog 1: deberia ser p99
│   ├── Errors (Sum)
│   └── ConcurrentExecutions (Maximum)
├── ALB
│   ├── RequestCount (Sum)
│   ├── TargetResponseTime (Average)  ← Blog 1: deberia ser p99
│   └── HTTPCode_5XX (Sum)
└── RDS
    ├── CPUUtilization (Average)
    ├── ReadLatency (Average)
    └── FreeableMemory (Minimum)

Esto te dice el estado de cada recurso individualmente. No te dice si tu servicio esta cumpliendo lo que prometiste.

Por SLO (lo que nadie hace)

Plain text
Dashboard
├── Salud del SLO (fila 1 — lo primero que ves)
│   ├── SLO: Latencia p99 < 500ms    [98.3% — verde]
│   ├── SLO: Disponibilidad ≥ 99.5%  [99.7% — verde]
│   └── SLO: Saturacion < 80%        [65% — verde]
├── SLIs que alimentan los SLOs (fila 2 — cuando algo esta amarillo)
│   ├── p99 TargetResponseTime (ALB)
│   ├── Disponibilidad: ((m2-m1)/m2)*100   ← Blog 3, Formula 2
│   └── Max ConcurrentExecutions / Limite
├── Presupuesto de error (fila 3 — cuanto margen queda)
│   ├── Budget restante: 172 de 201 min
│   └── Burn rate: 0.8 (saludable)
└── Metricas por servicio (fila 4 — solo cuando investigas)
    ├── EC2, Lambda, ALB, RDS...
    └── (las mismas metricas de siempre, pero al final, no al inicio)

La diferencia: abres el dashboard y en 2 segundos sabes si estas cumpliendo. Si algo esta amarillo o rojo, bajas a la fila 2 para ver cual SLI esta fallando. Luego a la fila 3 para ver cuanto presupuesto queda. Solo si necesitas investigar la causa raiz bajas a la fila 4 con las metricas por servicio.

Fila 1: Salud del SLO

El widget mas importante del dashboard. Usa widgets de tipo Number o Gauge para mostrar el cumplimiento actual de cada SLO.
Que poner:
Para un SLO de latencia, la Formula 3 del Blog 3 te da el cumplimiento por periodo:
Plain text
m1 = TargetResponseTime  [Statistic: p99]
e1 = IF(m1 <= 0.5, 1, 0)
e2 = RUNNING_SUM(e1)
e3 = TIME_SERIES(DATAPOINT_COUNT(m1))
e4 = (e2 / e3) * 100

Muestra e4 en un widget de tipo Number con umbrales de color:
  • Verde: ≥ 99.5% (cumple el SLO)
  • Amarillo: 99.0% a 99.5% (en la zona de reaccion)
  • Rojo: < 99.0% (bajo el SLA)
Para disponibilidad, la Formula 2 del Blog 3:
Plain text
m1 = HTTPCode_Target_5XX_Count  [Sum]
m2 = RequestCount               [Sum]
e1 = ((m2 - m1) / m2) * 100

Si usas Amazon CloudWatch Application Signals, los SLOs ya aparecen nativamente en el dashboard de Application Signals con attainment, budget restante y burn rate calculados automaticamente. No necesitas construir la Fila 1 a mano.

Fila 2: SLIs que alimentan el SLO

Cuando la Fila 1 muestra amarillo, necesitas saber cual SLI esta causando el problema. Usa widgets de tipo Line para ver la tendencia.
Que poner:
  • p99 de TargetResponseTime (ALB) con una linea de referencia en 500ms (tu umbral)
  • Tasa de errores 5xx con Metric Math:  (m1/m2)*100  (Blog 3, Formula 1)
  • Maximum de ConcurrentExecutions con una linea de referencia en tu limite
Que NO poner:
  • Average de TargetResponseTime. Si leiste el Blog 1, sabes por que: Average = 8.7s se ve verde mientras p99 = 50s. El dashboard te mentiria en la fila mas importante.
  • Metricas de infraestructura sin conexion al SLO. CPUUtilization de EC2 no te dice si el usuario esta teniendo una buena experiencia. Puede estar al 90% y el servicio funcionando perfecto, o al 20% y el servicio caido por un bug logico.

Fila 3: Presupuesto de error y burn rate

Esta fila responde: "¿cuanto margen tengo?" y "¿a que velocidad lo estoy gastando?"
Que poner:
  • Widget de tipo Number con minutos de presupuesto restante
  • Widget de tipo Line con burn rate a lo largo del tiempo
  • Linea de referencia en burn rate = 1 (el umbral de sostenibilidad del Blog 2)
Si usas Application Signals, esta informacion esta disponible directamente en el dashboard de SLOs. Si no, puedes calcular el burn rate con Metric Math usando la formula del Blog 2:
Plain text
Burn Rate = (unhealthy_min / lookback_min) x (interval_min / budget_min)

Esto requiere construir la expresion en pasos. No es trivial en Metric Math puro, lo cual es otra razon para considerar Application Signals.

Fila 4: Metricas por servicio (Investigacion)

Aqui es donde van las metricas que antes estaban en la Fila 1 de tu dashboard viejo. No desaparecen; bajan de prioridad.
Que poner:
Las mismas metricas de siempre, pero con las estadisticas correctas del Blog 1:
Metrica
Estadistica correcta
No uses
TargetResponseTime
p99
Average
Lambda Duration
p99
Average
RequestCount
Sum
Average
ConcurrentExecutions
Maximum
Average
CPUUtilization
Average
Maximum (excepto DAX)
HTTPCode_5XX
Sum
Average
SQS MessageAge
Maximum
Average
Organizacion: agrupa por servicio aqui. En esta fila, "¿como esta Lambda?" es una pregunta valida porque ya sabes que algo fallo (la Fila 1 te lo dijo) y estas buscando donde.

El anti-patron del dashboard de 47 widgets

Hay un patron comun que arruina dashboards incluso cuando las estadisticas son correctas: el dashboard que crece sin control.
Cada vez que alguien agrega un servicio, agrega 5-8 widgets mas. Nadie quita widgets viejos. Despues de un año tienes 47 widgets en una sola pagina. El scroll es infinito. Nadie sabe que es importante. El dashboard existe pero nadie lo mira.
La regla: la Fila 1 no debe tener mas de 5 widgets. Si tienes mas de 5 SLOs, necesitas dashboards separados, no una pagina mas larga.
Piensa en cada fila como un nivel de zoom:
  • Fila 1: vista de avion (¿estamos cumpliendo?)
  • Fila 2: vista de helicoptero (¿cual SLI falla?)
  • Fila 3: vista de calle (¿cuanto margen queda?)
  • Fila 4: vista de microscopio (¿que recurso tiene el problema?)
Si todo esta en el mismo nivel de zoom, no ves nada.

Implementacion paso a paso

  1. Identifica tus SLOs. Si no tienes SLOs definidos, empieza con los 3 mas criticos: latencia p99, disponibilidad, y saturacion. El Blog 2 cubre como definirlos.
  1. Crea un dashboard nuevo. No modifiques el existente. Crea uno llamado "SLO Health" o el nombre de tu servicio seguido de "-SLO."
  1. Construye la Fila 1 con widgets Number. Usa las formulas del Blog 3 o, si tienes Application Signals, simplemente agrega los widgets de SLO attainment.
  1. Construye la Fila 2 con widgets Line. Agrega los SLIs (p99, error rate, concurrencia) con lineas de referencia en los umbrales del SLO.
  1. Agrega la Fila 3 si calculas burn rate manualmente, o apunta a los dashboards de Application Signals que ya lo muestran.
  1. Mueve las metricas por servicio a la Fila 4. Esto es lo que ya tenias. Solo baja de posicion.
  1. Elimina widgets que no conecten a ningun SLO. Si no puedes explicar como un widget afecta al cumplimiento de un SLO, probablemente no necesitas verlo en este dashboard. Ponlo en un dashboard separado de investigacion si quieres conservarlo.

Que NO hace este enfoque

Esto no es un sustituto de Application Signals. Application Signals automatiza lo que aqui construyes a mano: calcula attainment, presupuesto de error y burn rate nativamente, y los muestra en un dashboard dedicado.
"You can use any CloudWatch metric or metric expression as an SLI." -  CloudWatch Service Level Objectives 
Si ya tienes Application Signals configurado, este post te da el marco mental para interpretar lo que ves. Si no lo tienes, este post te muestra como construir una version manual que te lleva al mismo lugar.
Tampoco es un tutorial de widgets. AWS tiene documentacion completa sobre como crear dashboards y agregar widgets:

Conclusiones

  1. Un dashboard organizado por servicio responde "¿como esta EC2?" Un dashboard organizado por SLO responde "¿estamos cumpliendo?" La segunda pregunta es la que importa a las 3am.
  1. Cuatro filas, en orden de prioridad: salud del SLO, SLIs que lo alimentan, presupuesto de error, metricas por servicio. Lo primero que ves es lo que mas importa.
  1. La Fila 1 no debe tener mas de 5 widgets. Si necesitas mas, necesitas dashboards separados.
  1. Las metricas por servicio no desaparecen. Bajan a la Fila 4, donde pertenecen: son herramientas de investigacion, no indicadores de salud.
  1. Application Signals automatiza la Fila 1, 2 y 3. Si puedes usarlo, usalo. Si no, las formulas del Blog 3 te permiten construirlo a mano.
La proxima vez que abras tu dashboard, preguntate: ¿lo primero que veo responde la pregunta mas importante? Si la respuesta es "no," reorganizalo.

Recursos

# monitoring-observability# observability# amazon-cloudwatch# aws-cloudwatch# dashboard
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article