Empezamos el Capítulo 24: Observabilidad, una de las habilidades que más distingue a un profesional que sabe operar en producción. Tener una aplicación funcionando no basta: necesitas saber qué está pasando dentro de ella en todo momento. ¿Va bien? ¿Hay errores? ¿Está saturada? Para eso existe la observabilidad, y en AWS la herramienta central es CloudWatch. Empezamos por sus tres pilares: logs, métricas y alarmas.

Imagina que tienes tu aplicación desplegada en producción. Los usuarios la usan. Y de repente... empieza a ir lenta, o algunos usuarios reportan errores. Sin observabilidad, estás a ciegas:

• ¿Cuántos errores se están produciendo? No lo sabes.
• ¿El servidor está saturado de CPU? Ni idea.
• ¿Qué pasó exactamente cuando falló? No hay rastro.
• ¿Cuándo empezó el problema? Imposible saberlo.

Operar así es como conducir con los ojos cerrados. La observabilidad son los instrumentos del salpicadero de tu aplicación: te dicen qué pasa, para que puedas reaccionar.

CloudWatch es el servicio de observabilidad de AWS: recopila y muestra información sobre el funcionamiento de tus recursos y aplicaciones. Es donde miras para saber si todo va bien. Tiene varios componentes; en este subcapítulo vemos los tres fundamentales.

Los logs son los mensajes de texto que tus aplicaciones y servicios van escribiendo sobre lo que hacen. Son el diario de tu aplicación:

CloudWatch Logs recopila y guarda estos mensajes de forma centralizada. En vez de tener los logs dispersos en cada servidor (y perderlos si el servidor se apaga), llegan todos a CloudWatch, donde puedes buscarlos, filtrarlos y consultarlos.

Analogía: los logs son como el diario de a bordo de un barco: el capitán anota todo lo que ocurre («10:00 zarpamos», «12:00 tormenta a la vista», «12:30 reparada una vía de agua»). Si algo sale mal, revisas el diario para entender qué pasó y cuándo. CloudWatch Logs es el lugar donde se guardan todos esos diarios juntos, listos para consultar.

Los logs son tu primera herramienta cuando algo falla: vas a los logs del momento del fallo y lees qué pasó.

Las métricas son valores numéricos medidos a lo largo del tiempo: el uso de CPU, la cantidad de memoria, el número de peticiones por segundo, los errores por minuto... Mientras los logs son texto («qué pasó»), las métricas son números («cuánto»):

CloudWatch recopila automáticamente muchas métricas de tus recursos (CPU de las EC2, peticiones de un ALB, invocaciones de una Lambda...) y tú puedes enviar las tuyas propias (métricas de negocio, como «pedidos completados por minuto»). Con las métricas ves tendencias y detectas cuándo algo se sale de lo normal.

Analogía: las métricas son como los indicadores del salpicadero del coche: velocidad, revoluciones, temperatura del motor, nivel de gasolina. Son números que miras de un vistazo para saber si todo va bien. Si la aguja de la temperatura sube demasiado, sabes que hay un problema antes de que el motor se rompa.

Aquí está la pieza que hace la observabilidad proactiva. No puedes estar mirando las métricas 24 horas al día. Una alarma vigila una métrica por ti y te avisa automáticamente cuando cruza un umbral que tú defines:

Cuando se dispara una alarma, puede notificarte (por email, Slack, etc., usando SNS, recuerda el subcapítulo 15.2) o incluso disparar una acción automática (como añadir más servidores con un Auto Scaling Group, recuerda el subcapítulo 13.3).

Analogía: una alarma es como el testigo rojo del salpicadero que se enciende cuando la temperatura del motor es peligrosa, acompañado de un pitido. No tienes que mirar la aguja constantemente: el coche te avisa cuando algo importante requiere tu atención.

Los tres pilares trabajan en equipo para que operes con los ojos abiertos:

El flujo típico de un incidente: salta una alarma («¡errores altos!»), miras las métricas para ver el alcance y cuándo empezó, y vas a los logs de ese momento para entender la causa exacta y arreglarlo.

Ejemplo del mundo real: una tienda online tiene una alarma sobre la métrica «errores HTTP 500». Un domingo por la noche, un cambio introduce un bug y los errores se disparan. La alarma salta y notifica al equipo de guardia por Slack en un minuto. El ingeniero mira las métricas: los errores empezaron justo tras el último despliegue, a las 22:14. Va a los logs de las 22:14 y ve: «ERROR: campo 'precio' nulo en el carrito». En 10 minutos identifica y revierte el cambio. Sin observabilidad, se habría enterado a la mañana siguiente por las quejas de clientes y la caída de ventas.

• Operar sin observabilidad es conducir con los ojos cerrados; necesitas saber qué pasa dentro de tu aplicación en todo momento.
• CloudWatch es el servicio de observabilidad de AWS, con tres pilares fundamentales:
• Logs: los mensajes de texto que escriben tus apps («qué pasó»), recopilados y consultables de forma centralizada. Son el diario de a bordo.
• Métricas: valores numéricos en el tiempo («cuánto»: CPU, peticiones, errores...). Son los indicadores del salpicadero; revelan tendencias.
• Alarmas: vigilan una métrica y te avisan automáticamente (o disparan acciones) cuando cruza un umbral. Son el testigo rojo que te avisa sin tener que mirar.
• Trabajan en equipo: las alarmas avisan, las métricas muestran el alcance, los logs explican la causa.

En el siguiente subcapítulo veremos cómo juntar todas estas métricas en paneles visuales con CloudWatch Dashboards.