Observabilidad y cierre

Dashboards y alarmas

De leer métricas a vigilarlas

La Semana 3 abrió la observabilidad: ya se sabe leer una métrica y consultar un log. Pero abrir la consola a buscar cada número no es vigilar un sistema. Esta semana cierra la observabilidad con las dos herramientas que convierten métricas sueltas en vigilancia real: los dashboards, que reúnen lo importante en una vista, y las alarmas, que avisan sin que nadie tenga que mirar.

Dashboards: una vista, varias métricas

Un dashboard de CloudWatch es un tablero de gráficas que se compone. En lugar de abrir cada métrica por separado, se juntan las que cuentan la historia del sistema en una sola pantalla. Para la aplicación, un dashboard útil reúne:

• Latencia del ALB (TargetResponseTime) — cuán rápido responde.
• Peticiones (RequestCount) — cuánta carga llega.
• Errores 5XX (HTTPCode_Target_5XX_Count) — cuántas fallas devuelve.
• CPU y memoria del servicio ECS — cuántos recursos consume.
• Destinos sanos del target group — cuántas tareas reciben tráfico.

Leídas juntas, estas gráficas responden de un vistazo: ¿el sistema está sano, y aguanta la carga que recibe?

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?

Alarmas: que el sistema avise solo

Un dashboard sirve cuando alguien lo mira. Una alarma vigila una métrica todo el tiempo y actúa cuando cruza un umbral, sin que nadie esté presente.

Una alarma tiene tres estados:

• OK — la métrica está dentro del umbral.
• ALARM — la métrica cruzó el umbral durante el período definido.
• INSUFFICIENT_DATA — no hay datos suficientes para evaluar (al inicio, o si la métrica deja de llegar).

Lo valioso es la acción que dispara al entrar en ALARM: publicar en un tema de SNS. Y ese es el mismo tema que ya alimenta las notificaciones del pipeline hacia Teams. Así, una alarma de CPU alta o de errores 5XX llega al mismo canal donde el equipo ya recibe los avisos del pipeline —sin montar nada nuevo.

Práctica guiada: dashboard y alarma

Crear el dashboard

1. Abrir CloudWatch → Dashboards y pulsar Create dashboard. Nombrarlo taller-<su-nombre>.
2. Agregar un widget de línea con la métrica CPUUtilization del servicio de ECS.
3. Agregar otro widget con TargetResponseTime del ALB.
4. Agregar un tercero con HTTPCode_Target_5XX_Count. Guardar el dashboard.

Crear la alarma de CPU

1. Abrir CloudWatch → Alarms → All alarms y pulsar Create alarm.
2. Select metric: ECS → por servicio → CPUUtilization del servicio.
3. En la condición, elegir Greater than con un umbral de 70 (por ciento), evaluado durante un período.
4. En Notification, seleccionar el tema de SNS del taller (el mismo de las notificaciones del pipeline).
5. Nombrarlo cpu-alta-<su-nombre> y crearlo.

La alarma comienza en INSUFFICIENT_DATA, pasa a OK cuando hay datos, y entraría en ALARM —publicando en SNS— si la CPU superara el 70%.

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.

Container Insights y trazabilidad

Más detalle, y cómo conectarlo

Las métricas básicas dicen cómo está el servicio en conjunto. Pero cuando algo falla, la pregunta suele ser más fina: ¿qué tarea consume de más?, ¿desde cuándo?, ¿qué decía el log en ese momento? Esta sección agrega el detalle (Container Insights) y la disciplina para conectarlo (trazabilidad): seguir un síntoma desde la métrica hasta la línea de log que lo explica.

Container Insights

Container Insights es una capa de observabilidad específica para contenedores. Activada sobre el clúster, recolecta métricas más detalladas que las básicas: uso de CPU y memoria por tarea y por servicio, número de tareas en ejecución, y vistas de rendimiento listas para usar.

La diferencia con las métricas de la Semana 3: aquellas dan el promedio del servicio; Container Insights permite ver cuál tarea se sale de lo normal, no solo que el promedio subió. Cuando un servicio tiene varias tareas y una se comporta distinto, ese detalle es la diferencia entre adivinar y diagnosticar.

Dos niveles de detalle

Trazabilidad: de un síntoma a una causa

La observabilidad no es acumular gráficas: es poder seguir un hilo. Un usuario reporta que la aplicación va lenta. ¿Por dónde se empieza? La trazabilidad es el camino ordenado de un síntoma visible hasta la causa concreta.

El recorrido típico:

1. El síntoma: el usuario percibe lentitud, o el dashboard muestra latencia alta (TargetResponseTime).
2. Acotar en el ALB: ¿es toda la aplicación o algunas peticiones? ¿coincide con un pico de RequestCount o de errores 5XX?
3. Bajar a ECS / Container Insights: ¿hay una tarea con CPU o memoria al límite? ¿cuándo empezó?
4. Leer el log: en el grupo de logs de esa tarea, en esa ventana de tiempo, buscar qué estaba haciendo —con Logs Insights, filtrando por el período del síntoma.

Cada paso reduce el espacio de búsqueda; el log es donde casi siempre está la respuesta final. Esa secuencia —métrica que alerta, métrica que acota, log que explica— es el método de troubleshooting operacional que el taller deja como herramienta.

Práctica guiada: activar y recorrer

Activar Container Insights

1. Abrir ECS → Clusters y seleccionar el clúster.
2. En Update cluster, activar Container Insights. Guardar.
3. Tras unos minutos, abrir CloudWatch → Insights → Container Insights y seleccionar el clúster: se verán las métricas por servicio y por tarea.

Recorrer un hilo

1. En Container Insights, observar la CPU por tarea del servicio.

2. Anotar la ventana de tiempo de cualquier pico (o del período reciente).

3. Abrir Logs Insights, seleccionar el grupo de logs del contenedor, y consultar las líneas de esa ventana:

   fields @timestamp, @message
   | sort @timestamp desc
   | limit 50
   

4. Leer qué hacía la aplicación en ese intervalo. Con esto se recorre el hilo de la métrica al log.

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.

Cierre del curso

El flujo completo, de una pieza

El taller comenzó con código en una máquina. Termina con un sistema que se construye, se despliega, se opera, y se reporta solo, sobre infraestructura de AWS. Vale la pena verlo entero, porque cada semana fue un eslabón de la misma cadena:

El flujo completo

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

flowchart LR
  C["commit"] --> CC["CodeCommit"]
  CC --> PP["CodePipeline"]
  PP --> CB["CodeBuild"]
  CB --> ECR[("ECR")]
  ECR --> ECS["ECS / Fargate"]
  ECS --> ALB["ALB"]
  ECS --> CW["CloudWatch"]
  PP -.-> TM["Teams"]
  CW -.-> TM

• CodeCommit guarda el código versionado (Semana 1).
• CodeBuild construye la imagen y la publica en ECR (Semana 1).
• CloudFormation define la infraestructura como código (Semana 2).
• ECS/Fargate ejecuta los contenedores detrás de un ALB (Semanas 2–3).
• CodePipeline automatiza el camino del commit al despliegue, con aprobación manual (Semana 3).
• CloudWatch observa el sistema: métricas, logs, dashboards, alarmas, Container Insights (Semanas 3–4).
• Teams recibe las notificaciones del pipeline y de las alarmas (Semanas 3–4).

Ninguna pieza es un ejemplo aislado: es el sistema que se ha venido construyendo, y desde el cual se lee esta misma guía.

La caja de herramientas de diagnóstico

Más allá de los servicios, el taller deja un método para cuando algo se sale de lo esperado. La secuencia es siempre la misma:

1. ¿Qué cambió? Un despliegue reciente, un commit, un cambio manual. El pipeline y los eventos de CloudFormation dejan el rastro.
2. ¿El tráfico llega? ALB → target group → tarea. Un 503 con tareas corriendo apunta a health checks o grupos de seguridad.
3. ¿La tarea está sana? Una tarea detenida tiene un stoppedReason. Si apunta a la aplicación, la respuesta está en los logs.
4. ¿Qué dicen las métricas? Latencia, errores 5XX, CPU. Acotan dónde y cuándo.
5. ¿Qué dice el log? En el grupo de logs, en la ventana del síntoma, con Logs Insights. Casi siempre, la respuesta final.

Qué sigue, más allá del taller

Lo construido es una base sólida, no el final del camino. Hacia dónde seguir:

• Despliegues sin interrupción: estrategias blue/green con CodeDeploy, para desplegar sin cortar el servicio ni arriesgar un rollback manual.
• El pipeline también como código: definir el propio pipeline en CloudFormation, de modo que la automatización sea tan reproducible como la infraestructura que despliega.
• Múltiples ambientes: separar desarrollo, staging, y producción, cada uno con su stack y su rama, promoviendo cambios entre ellos.
• Pruebas en el pipeline: agregar una etapa de pruebas automáticas entre Build y Deploy, para que solo avance lo que pasa las verificaciones.

Cada uno de estos pasos reutiliza lo ya aprendido: son extensiones del mismo flujo, no temas nuevos desde cero.

Ejercicio final (opcional): el ciclo completo

Para cerrar el taller con todo en movimiento a la vez, este ejercicio integrador recorre el sistema entero de punta a punta.

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.