Bienvenida
Bienvenida
Una flota a escala web contiene muchas máquinas. En cualquier momento, algunas están sanas, otras están iniciándose, otras están drenando y otras están rotas silenciosamente. La flota sobrevive a esto porque cada máquina responde a dos preguntas simples bajo demanda:
- /health — ¿puedo atender actualmente solicitudes reales?
- /version — ¿qué código estoy ejecutando?
Además, un endpoint de métricas (comúnmente /metrics) que expone contadores y medidores para que las herramientas de monitoreo los extraigan.
Esta lección enseña cómo diseñar estos endpoints para que realmente reflejen la realidad, qué significan las cuatro señales doradas en una capa de proxy y cómo los datos observados impulsan las decisiones de capacidad.
Al finalizar, podrás:
- Diseñar un endpoint /health que detecte la falla real de la ruta, no solo la supervivencia del proceso
- Diseñar un endpoint /version que te permita verificar que una implementación se ha realizado
- Aplicar las cuatro señales doradas (latencia, tráfico, errores, saturación) en una capa de proxy
- Vincular las métricas de picos observadas con las decisiones de capacidad: cuándo escalar hacia arriba, cuándo drenar, cuándo alertar
- Razonar sobre los SLO y la tasa de consumo del presupuesto de errores como la disciplina operativa detrás de la pregunta "¿cuánto nos importa?"
Los dos tipos de verificación de salud
Supervivencia (Liveness) vs Listo para servir (Readiness)
Supervivencia (Liveness): ¿está el proceso vivo en absoluto? Se utiliza por los orquestadores (Kubernetes, systemd) para decidir si deben reiniciar el proceso.
Listo para servir (Readiness): ¿está el proceso listo para manejar tráfico real ahora mismo? Se utiliza por los equilibradores de carga para decidir si enviar peticiones.
Estas son preguntas diferentes. Un proceso que está vivo pero no puede alcanzar su base de datos está vivo pero no listo. Un proceso que está iniciándose está vivo pero aún no está listo.
Verificaciones de salud superficiales vs profundas
Superficial: devuelve {"status": "ok"} si el manejador HTTP se ejecuta. Es trivial. Solo detecta si el proceso está caído.
Profunda: ejercita realmente la ruta de la petición. Verifica que el pool de conexiones de la base de datos pueda devolver una conexión, que la caché sea alcanzable y que las dependencias aguas abajo respondan. Detecta interrupciones funcionales que las verificaciones superficiales pasan por alto.
El compromiso: las verificaciones profundas cuestan más (cada una es esencialmente una solicitud sintética) y pueden causar fallos en cascada (si la verificación de salud de cada réplica golpea la base de datos, una base de datos lenta marca todas las réplicas como no saludables, lo que las elimina de la rotación, lo que elimina toda la capacidad).
Mejor práctica: una verificación superficial para la supervivencia (rápida, barata, sin dependencias externas) y una verificación más profunda para la preparación (resultados en caché, con limitación de velocidad para evitar golpear a los servicios aguas abajo).
Puntos de acceso de versión
/version devuelve el commit de git, la hora de compilación y el nombre del servicio. Después de una implementación, ejecutas curl https://service.example.com/version y confirmas que el commit devuelto coincide con el que enviaste. Si no coincide, la implementación falló silenciosamente.
Sin /version, una implementación obsoleta puede parecer exitosa y permanecer oculta durante horas.
Formato mínimo de respuesta: {"service": "my-api", "git_commit": "abc1234", "build_time": "2026-05-19T10:00:00Z"}.
Latencia, tráfico, errores, saturación
Cuatro números cubren la mayoría de las operaciones
Del libro de SRE de Google. Cuatro señales que mides en cada nivel de servicio. Si instrumentas bien estas cuatro, detectas la mayoría de los problemas de producción antes que los usuarios.
Latencia: ¿cuánto tarda una solicitud? Informe distribuciones, no solo promedios. El p99 (latencia del percentil 99) es más importante que la media, porque la latencia de cola es lo que los usuarios perciben como 'lento'. Un servicio con una media de 50 ms y un p99 de 5.000 ms tiene un problema real que la mayoría de los usuarios nunca notan, pero que el 1% más afectado sí percibe absolutamente.
Tráfico: ¿cuántas solicitudes por segundo? Solicitudes totales, por punto de acceso, por código de estado, por región. Línea base conocida; alertar sobre anomalías (caída repentina = problema de entrada; pico repentino = afluencia o ataque).
Errores: tasa de solicitudes fallidas. Distinga entre 4xx (errores de cliente, no es su culpa) y 5xx (errores de servidor, es su culpa). Registre la tasa de errores como un porcentaje del tráfico, no como conteos absolutos, para que las alertas funcionen a través de diferentes niveles de carga.
Saturación: ¿qué tan lleno está el sistema? Utilización de CPU, memoria, profundidad de la piscina de conexiones, longitud de la cola. El indicador principal. La saturación aumenta antes de que la latencia o los errores se degraden. Un nivel al 90% de saturación está a un mal minuto de distancia del colapso de la cola.
En un nivel de proxy específicamente
Cada señal se ilumina en la capa de borde:
- Latencia en el proxy: duración del apretón de manos TLS, tiempo de conexión al servidor de origen, total de solicitud-respuesta. Medidos por separado porque residen en diferentes partes de la ruta.
- Tráfico en el proxy: solicitudes totales/seg, distribución por servidor de origen (un servidor de origen caliente señala un sesgo del equilibrador de carga), desglose por código de estado.
- Errores en el proxy: 4xx de los clientes (tus usuarios accediendo a puntos de entrada incorrectos), 5xx de los backends (tus servicios fallando), errores internos del proxy (502 = backend inaccesible, 504 = tiempo de espera agotado en el backend).
- Saturación en el proxy: número de sesiones TLS, profundidad de la piscina de conexiones hacia arriba (upstream), CPU en el propio proxy (la terminación TLS consume mucha CPU).
Consejo profesional: un aumento repentino de 502 con baja latencia del backend significa que el backend está colgando antes de responder (reinicio de conexión, caída, OOM). Un aumento de 504 significa que el backend es lento pero aún está respondiendo. Lee el código de error; te indica dónde reside la falla.
Lee las señales
Tu panel muestra lo siguiente durante los últimos 10 minutos:
- Tráfico: aproximadamente plano en 800 req/s (sin picos)
- Latencia: p50 estable en 40ms, p99 subió de 200ms a 2.500ms en 5 minutos y sigue subiendo
- Errores: la tasa de 4xx se mantiene estable en el 0,3 % (fondo normal); la tasa de 5xx aumentó del 0,1 % al 1,2 % (principalmente 504 Gateway Timeout)
- Saturación: la CPU del backend aumentó del 45 % al 78 % en los mismos 5 minutos; la CPU del proxy se mantiene estable en el 30 %
Cuándo escalar, cuándo drenar, cuándo alertar
Las decisiones de capacidad requieren disparadores
Observar las métricas es fácil. Saber cuándo actuar sobre ellas es la disciplina.
Escalar cuando: la saturación cruza un umbral sostenido (p. ej., CPU del backend >70% durante 5 minutos), o la profundidad de la cola crece más allá de un objetivo, o la latencia p99 excede el SLO. El disparador debe activarse antes de que las cosas fallen, no en el momento de la falla.
Drenar un réplica cuando: es consistentemente lento / con errores mientras los pares están sanos (un réplica que se calienta a menudo es un problema a nivel de host, no un problema de aplicación), o al desplegar una nueva versión, o al retirar un réplica de manera gradual.
Alertar a un humano cuando: un SLO se está agotando más rápido de lo que el presupuesto de errores puede sostener, o un disparador de saturación se activa sin que el autoescalado lo absorba, o aparece un patrón en cascada (la tasa de errores y la tasa de reintentos suben ambas).
No alertar cuando: un solo minuto malo se resuelve por sí solo, o los trabajos por lotes en segundo plano causan picos periódicos esperados, o el ruido cruza el umbral (el umbral está mal, no el sistema).
SLOs y consumo del presupuesto de errores
Un SLO (objetivo de nivel de servicio) define el rendimiento aceptable: 'tasa de éxito >= 99,9% en una ventana de 28 días'. El complemento (0,1%) es el presupuesto de errores.
Tasa de consumo (burn rate): la velocidad a la que estás consumiendo el presupuesto de errores. Si consumes el 10% del presupuesto en 1 hora, la tasa es 240 veces más rápida de lo sostenible (1 hora es 1/672 de una ventana de 28 días; consumir el 10% en esa ventana = 10% × 672 = 6720% proyectado para la ventana completa, cuando solo se permite el 100%).
Alertas de tasa de consumo multi-ventana: generar una alerta (page) cuando tanto una ventana corta (5 minutos a una tasa de 14,4x) como una ventana larga (1 hora a una tasa de 6x) consumen el presupuesto más rápido de lo sostenible. Detecta tanto las caídas rápidas como las degradaciones lentas.
Por qué esto es importante para la capacidad: un servicio que opera con un SLO del 99,9% y un margen de holgura del 1% puede absorber pequeñas fluctuaciones. Un servicio en el 99,93% (que apenas cumple el SLO) está a un mal día de incumplirlo. Las decisiones de capacidad deben apuntar a un margen de SLO cómodo, no al mínimo que lo cumple.
Una decisión de capacidad bajo observación
Tu servicio tiene un SLO del 99,9% de solicitudes exitosas en 28 días. Estado actual según el monitoreo de la última hora:
- Tasa de éxito: 99,5% (sostenida durante 30 minutos)
- CPU del backend: promedia 82% en toda la flota (objetivo 70%)
- Latencia p99: 800 ms (objetivo SLO: <500 ms)
- Tráfico: 1.400 req/s, aumentado desde la línea base de 1.000 req/s (40% por encima de lo normal; la tendencia sigue al alza)
- Escalado automático: configurado para añadir réplicas cuando el CPU > 80% durante 5 min sostenidos; actualmente en medio de un escalado hacia arriba que añadirá 3 réplicas en ~90 segundos
Diseña un plan de observabilidad para el lanzamiento
Síntesis
Ahora puedes diseñar un /health que detecte fallos reales, un /version que te permita verificar despliegues, paneles de los cuatro señales doradas en un nivel de proxy y disparadores de capacidad vinculados a la tasa de consumo de SLO.
Aplica los cuatro.
Tu equipo está lanzando search.example.com (el servicio de búsqueda de la lección sobre modos de fallo). El equipo quiere implementar observabilidad que detecte problemas antes que los usuarios, con una matriz clara de decisión de página o no. SLO: 99,9 % de solicitudes exitosas, latencia p99 < 300 ms, en una ventana de 28 días.
Cierre del curso
Cierre del curso
Has completado las cinco lecciones:
- Proxies y Orígenes: la forma de la capa de borde que casi todos los servicios web públicos utilizan
- Escala Horizontal Sin Estado: por qué una capa sin estado se multiplica de forma económica y cómo dimensionarla
- Separación de Ingreso y Salida: por qué un nodo se convierte en dos, y el modo de fallo que lo obliga
- Modos de Fallo y Alcance del Impacto: puntos únicos de fallo, cascadas, análisis de incidentes y acciones correctivas sin culpas
- Observabilidad y Capacidad (esta lección): qué medir para que los problemas aparezcan antes de que los usuarios los noten
El hilo conductor: un sistema distribuido a escala web no es magia. Es un pequeño conjunto de patrones (proxy inverso, réplicas sin estado, separación de ingreso/salida, bulkheads y circuit breakers, las cuatro señales doradas) compuestos de manera cuidadosa. Una vez que reconoces los patrones, los ves en todas las arquitecturas de producción.
Lecciones complementarias: cinco lecciones de geometría-* reinterpretan el mismo material como teoría de grafos y geometría. Funcionan bien en cualquier orden.
Buen trabajo.