Semana 4

Un dashboard que cuenta la historia

Latencia — ¿responde rápido?
Peticiones — ¿cuánta carga llega?
Errores 5XX — ¿cuántas fallas?
CPU / memoria — ¿cuántos recursos consume?
Destinos sanos — ¿cuántas tareas sirven tráfico?

Una alarma

Métrica cruza el umbral
  → estado ALARM
  → acción: publicar en SNS
  → (mismo tema) → Teams / toast

Vigila sola; avisa por el canal que ya usa el equipo.

Ejercicio 16

Componer un dashboard y armar una alarma

Crear un dashboard de CloudWatch con, al menos, la CPU del servicio, la latencia del ALB, y los errores 5XX. Luego crear una alarma sobre la CPU del servicio (umbral 70%) cuya acción publique en el tema de SNS del taller.

Dos niveles de detalle

Métricas básicas	Container Insights
Promedio del servicio	Detalle por tarea
"La CPU subió"	"Esta tarea es la que subió"
Sin costo adicional	Recolección adicional (tiene costo)

De un síntoma a la causa

Síntoma (usuario: "va lento")
  → métrica del ALB (TargetResponseTime ↑)
  → métrica de ECS (¿qué tarea? CPU ↑)
  → log del contenedor (¿qué hacía esa tarea?)

Cada paso acota; el log da la respuesta.

Ejercicio 17

Activar Insights y seguir un hilo

Activar Container Insights en el clúster. Luego recorrer el camino completo: observar la CPU por tarea del servicio, identificar una ventana de tiempo, y leer en Logs Insights las líneas del contenedor en esa ventana.

Abrir ECS → Clusters, seleccionar el clúster, y en Update cluster activar Container Insights. Guardar.
Esperar unos minutos; abrir CloudWatch → Insights → Container Insights y seleccionar el clúster.
Observar la métrica de CPU por tarea del servicio y anotar una ventana de tiempo reciente.
Abrir CloudWatch → Logs → Logs Insights, seleccionar el grupo de logs del contenedor, y ejecutar:
```
fields @timestamp, @message
| sort @timestamp desc
| limit 50
```
Leer las líneas del intervalo: se recorrió el camino de la métrica (qué tarea, cuándo) al log (qué hacía). Ese es el método de diagnóstico operacional.

El flujo completo

commit → CodeCommit
       → CodePipeline
       → CodeBuild → ECR
       → ECS / Fargate (detrás del ALB)
       → CloudWatch (métricas, logs, alarmas)
       → Teams (notificaciones)

El método de diagnóstico

¿Qué cambió?
¿El tráfico llega? (ALB → tarea)
¿La tarea está sana? (stoppedReason)
¿Qué dicen las métricas? (acotan)
¿Qué dice el log? (explica)

Ejercicio 18

Del error a la corrección, por el pipeline

Provocar una falla en la aplicación, detectarla por la observabilidad montada, diagnosticarla con el método de la caja de herramientas, y corregirla con un commit que fluya por el pipeline hasta el despliegue.

Del código a la operación

Se construyó, desplegó, automatizó, y observó un sistema real en AWS.

Gracias por participar en el taller.