Paneles de salud de aplicaciones

Supervisión y resolución de problemas en AWS

John Q. Martin

Principal Consultant

Diseño de panel: jerarquía de información

Pirámide de tres niveles: parte superior oscura y estrecha, parte media turquesa más ancha y base verde más ancha

Como un hospital: admisión → planta → especialista

Arriba - Resumen ejecutivo

Salud general del sistema
Métricas clave de negocio, SLA, incidencias activas

Medio - Salud del servicio

Tasas de error, percentiles de latencia, rendimiento

Abajo - Diagnóstico detallado

Trazas, registros, uso de recursos, salud de dependencias

Las cuatro señales doradas

Las cuatro señales doradas de monitorización: latencia, tráfico, errores y saturación

Si cubres estas cuatro, cubrirás la gran mayoría de problemas que te encontrarás.

El método RED

RED para servicios orientados a solicitudes:

Patrón método RED que muestra rate, errors y duration para servicios orientados a solicitudes

Relación con las señales doradas:

RED es un subconjunto enfocado de las cuatro señales doradas
Diseñado para servicios que gestionan solicitudes de usuario
Saturación (4.ª señal dorada) añadida para monitorizar infraestructura

Usa RED como punto de partida y añade saturación para un diagnóstico más profundo.

Tres orígenes de datos

Diagrama de tres orígenes de datos del panel: métricas de CloudWatch, trazas de X-Ray y CloudWatch Logs

Widgets de métricas de CloudWatch

Volumen de solicitudes:

["AWS/ApplicationELB",
 "RequestCount",
 {"stat": "Sum"}]

Tasa de error (metric math):

"metrics": [
  ["AWS/Lambda", "Errors",
   {"stat":"Sum","id":"errors"}],
  [".", "Invocations",
   {"stat":"Sum","id":"invocations"}],
  [{"expression":
    "(errors/invocations)*100",
    "label":"Error Rate %"}]
]

Percentiles de tiempo de respuesta:

["AWS/ApplicationELB",
 "TargetResponseTime",
 {"stat": "p50"}],
["AWS/ApplicationELB",
 "TargetResponseTime",
 {"stat": "p95"}],
["AWS/ApplicationELB",
 "TargetResponseTime",
 {"stat": "p99"}]

Volumen de solicitudes de ALB RequestCount
La tasa de error usa metric math: errores / invocations × 100
Tiempo de respuesta como percentiles p50, p95, p99

Widgets de X-Ray y de logs

Widgets de X-Ray:

Service map: topología de la aplicación con indicadores de salud
Trace statistics: tiempo de respuesta medio, tasa de error, tasa de fallos
Service latency: comparación del tiempo de respuesta por servicio

Widgets de CloudWatch Logs:

Consulta de errores recientes:

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

Conteo de errores por tipo:

filter @message like /ERROR/
| stats count(*) as errors
    by errorType
| sort errors desc

Diseño completo del panel

Diseño de panel de salud con widgets de resumen arriba, mapa de servicios en medio y registros de errores abajo

Flujo para resolver incidencias

Hoja de triaje de urgencias con bandas de prioridad de colores y un estetoscopio

Como el triaje de urgencias: estabilizar → diagnosticar → tratar → verificar

Identificar: indicadores rojos/amarillos, picos de errores
Acotar: ¿qué servicios?, ¿cuándo?, ¿empeora?
Correlacionar: errores + latencia, tráfico + recursos
Profundizar: service map → trazas → logs
Causa raíz: dependencia, BD, memoria, configuración
Corregir: interruptor de circuito, escalar, rollback, failover
Verificar: tasa de error normal, mapa en verde, alarmas despejadas

Escenario 1: pico de tráfico repentino

Panel de monitorización durante un pico de tráfico: gráficas en pico, indicadores en rojo, banners de alerta rojos

Lo que ves en el panel:

Volumen de solicitudes 10× lo normal
Tasa de error 25 %
Latencia 3000 ms
CPU 95 %

Análisis: Recursos saturados por un pico de tráfico

Acciones:

Escalar horizontalmente de inmediato
Activar autoescalado
Implementar limitación de tasa (rate limiting)
Añadir caché para aliviar el backend

Escenario 2: cuello de botella en la base de datos

Panel de monitorización con un cuello de botella en la base de datos: icono de BD rojo y agrietado, CPU y conexiones al máximo en rojo, latencia de consultas en fuerte ascenso, barra de pool casi llena

Lo que ves en el panel:

CPU de BD 95 %
Conexiones de BD 95/100
Latencia de consultas 5000 ms
Latencia de la app 5500 ms

Análisis: La base de datos es el cuello de botella; consultas lentas agotan el pool de conexiones

Acciones:

Identificar consultas lentas en los logs
Añadir índices, optimizar consultas
Aumentar el tamaño del pool de conexiones
Escalar la base de datos

Escenario 3: fallo en cascada

Lo que ves en el mapa de servicios:

Cascada en el mapa de servicios: nodo A ámbar con errores de cliente, B y C en rojo con fallos de servidor, D oscuro e inactivo; flechas bajan en cadena

Análisis:

Un problema pequeño en el Servicio A se ha propagado por la cadena de dependencias

Acciones:

Interruptores de circuito para frenar la cascada
Timeouts en cada nivel de servicio
Mecanismos de respaldo ante dependencias fallidas
Corregir la causa raíz en el Servicio A

Buenas prácticas de paneles

Seis prácticas recomendadas de panel para monitorizar la salud de aplicaciones

Resumen del vídeo y fin del curso

Diseña con jerarquía de información y las cuatro señales doradas
Combina métricas de CloudWatch, trazas de X-Ray y logs en una vista
Flujo de 7 pasos: identificar → acotar → correlacionar → profundizar → causa raíz → corregir → verificar

Ahora puedes:

Monitorizar con métricas, logs y paneles de CloudWatch
Configurar alarmas y notificaciones con SNS y SQS
Implementar trazado distribuido con X-Ray
Crear paneles de salud de aplicaciones para excelencia operativa

Paneles de salud de aplicaciones

Supervisión y resolución de problemas en AWS