SLI, SLO y monitoreo del servicio

Todas las instancias están en verde, la CPU está tranquila y el balanceador no reporta errores. Mientras tanto, nadie puede pagar porque el proveedor de tarjetas responde en 40 segundos. Los componentes están arriba; el servicio no funciona.

En CloudWatch viste cómo medir recursos. Aquí el foco cambia: medir lo que vive quien usa tu sistema, ponerle una meta con números y enterarte cuando te alejas de ella, incluso si la región donde corre todo se cae.

Indicador, objetivo y contrato

Los SLI más usados caben en cuatro familias:

• Disponibilidad: peticiones exitosas entre peticiones válidas. Un 404 por una URL inventada no cuenta como falla tuya; un 500, sí.
• Latencia por percentil: el p99 es el tiempo bajo el cual cae el 99 % de las peticiones. El promedio esconde el problema: si 98 peticiones tardan 100 ms y 2 tardan 10 segundos, el promedio da unos 300 ms y dos usuarios se fueron.
• Frescura: qué tan recientes son los datos que ves. «El saldo mostrado tiene menos de 1 minuto».
• Corrección: la respuesta es la correcta, no solo rápida. Un 200 con el precio equivocado es una falla.

El SLA va por debajo del SLO a propósito. Si prometes 99,9 % en contrato y apuntas a 99,95 % por dentro, tienes margen para reaccionar antes de deberle algo al cliente.

El presupuesto de error manda sobre los despliegues

Un SLO de 99,9 % en 30 días deja un 0,1 % para fallar: unos 43 minutos de caída o, contado por peticiones, 1.000 fallas por cada millón. Ese margen es el presupuesto de error, y se gasta en dos cosas: incidentes y cambios que salen mal.

• Presupuesto sano: el equipo despliega funciones nuevas con normalidad, como en despliegue continuo.
• Presupuesto agotado: se congelan los cambios que no sean de fiabilidad hasta recuperarlo. La regla se acuerda antes, entre producto e ingeniería, no en medio de la discusión.

La tasa de consumo (burn rate) dice qué tan rápido gastas el presupuesto. Una tasa de 1 lo agota justo al final de la ventana. Una tasa de 36 sostenida durante una hora gasta el 5 % de un presupuesto de 30 días en esa hora.

Antes de fijar el número, haz la cuenta de lo que tu arquitectura permite. Si «pagar» pasa en serie por cuatro componentes de 99,9 %, el techo es 0,999⁴ ≈ 99,6 %. Prometer 99,95 % sin redundancia es prometer algo imposible. Repasa las reglas de serie y paralelo en alta disponibilidad.

Un SLI por recorrido del usuario

No midas «el sistema». Mide los recorridos que importan al negocio, cada uno con su indicador y su meta. Lo ideal es medir lo más cerca posible del usuario: en el balanceador o en una prueba sintética, no dentro de cada microservicio.

Los números son de ejemplo. Una meta más alta no es mejor por sí misma: cada nueve adicional cuesta más y deja menos margen para cambiar.

Cómo se mide en AWS

• 

  CloudWatch Application Signals

  El que anota la promesa y lleva la cuenta

  Recoge latencia y disponibilidad por servicio y operación, y define SLO con presupuesto de error y tasa de consumo. Acepta cualquier métrica de CloudWatch como SLI.
• 

  Alarmas y alarmas compuestas

  Una alarma sobre el SLI o sobre la tasa de consumo. Una alarma compuesta combina otras con AND, OR y NOT para avisar una sola vez.
• 

  CloudWatch Synthetics

  El inspector que hace el viaje cada minuto

  Canaries: scripts que recorren tu sitio o tu API como un cliente, con horario fijo, aunque no haya tráfico real.
• 

  Health checks de Route 53

  Revisan un endpoint desde internet, combinan otros chequeos (calculated) o siguen el estado de una alarma de CloudWatch.
• 

  AWS X-Ray

  Trazas distribuidas: por qué salto pasó la petición y dónde se perdió el tiempo. Se instrumenta con OpenTelemetry vía AWS Distro for OpenTelemetry.

Chequeo superficial o profundo

El peligro del chequeo profundo es real: si la base de datos tiene un mal minuto, el balanceador marca a todas las instancias como enfermas y Auto Scaling empieza a reemplazar máquinas sanas. Una dependencia lenta se vuelve una caída total. El Amazon Builders' Library («Implementing health checks») recomienda chequeos locales para el balanceador y dejar las dependencias a sistemas que reaccionan con más cuidado.

Pon en el mismo panel el SLI del recorrido y las métricas de sus dependencias: así correlacionas «los pagos fallan» con «el proveedor de tarjetas tarda». Y si replicas datos a otra región, el retraso de replicación es un SLI de protección de datos: te dice cuántos datos perderías si fallaras ahora. Aurora Global Database, por ejemplo, publica métricas de ese retraso en CloudWatch. Más en RPO y RTO.

Monitoreo fuera de banda

Si tus canaries, tus alarmas y tu página de estado viven en la misma región que tu aplicación, la falla que deberían detectar también los apaga. El monitoreo tiene que sobrevivir a lo que vigila.

• Canaries y alarmas en otra región, idealmente en una cuenta de monitoreo aparte, que prueben los recorridos de la región principal desde afuera.
• Página de estado fuera de la región principal, o en un proveedor externo. Debe poder actualizarse aunque tu cuenta tenga problemas.
• Copia de los logs críticos en otra región o cuenta, para investigar aunque la principal no responda.
• Un monitor externo e independiente que no use la misma nube ni la misma red. Si todo tu monitoreo depende de AWS, un problema amplio de AWS te deja ciego.

Por último, decide qué despierta a alguien. Alerta por síntomas: el SLO se está quemando rápido. Las causas (CPU alta, una instancia reiniciada) van al panel o a un ticket. Una CPU al 90 % que no afecta a nadie no justifica una llamada a las 3 de la mañana; un 2 % de pagos fallando, sí. El paso siguiente, cuando la alarma suena, está en runbooks y simulacros.