Comprobaciones de estado de aplicaciones autoalojadas: ¿qué debería significar realmente «saludable»?
Un marco práctico para definir comprobaciones de estado que reflejen resultados reales para los usuarios, distingan entre inicio, actividad y preparación, y tengan en cuenta las dependencias sin convertir cada fallo externo en una caída de la aplicación.
Por qué una URL accesible no implica necesariamente una aplicación saludable
Que un navegador alcance una URL HTTPS y reciba HTTP 200 es una prueba útil, pero no constituye una definición completa de estado saludable. Puede demostrar que una ruta, un proxy o un controlador de la aplicación respondió a una solicitud. No demuestra necesariamente que los usuarios puedan iniciar sesión, leer datos actuales, guardar cambios, cargar archivos, enviar trabajo a una cola o utilizar una integración obligatoria.
El error inverso también es habitual: considerar que una conexión fallida con cualquier dependencia demuestra que toda la aplicación no está disponible. Una API opcional temporalmente inaccesible puede afectar a una función mientras los usuarios aún pueden realizar su trabajo más importante. Un diseño útil de comprobaciones de estado distingue estos casos en lugar de reducir todas las condiciones a una única luz verde o roja.
Docker hace explícita esta distinción: un contenedor puede estar en ejecución mientras un servidor web dentro de él está bloqueado y no puede gestionar nuevas conexiones. Kubernetes separa de forma similar las sondas destinadas a establecer si una aplicación se ha iniciado, si se debe reiniciar y si debe recibir tráfico. Estos conceptos ofrecen un vocabulario inicial sólido, pero las comprobaciones adecuadas siguen dependiendo del comportamiento documentado de cada aplicación y de sus propios flujos de trabajo probados.
- Una comprobación de URL puede establecer la accesibilidad externa, pero no la capacidad completa del servicio.
- Un contenedor o proceso en ejecución es una pista operativa, no una prueba de que esté preparado para los usuarios.
- Un fallo de dependencia debe clasificarse según su efecto en los flujos de trabajo reales.
- La mejor definición de saludable es específica: el trabajo previsto puede completarse dentro de los límites que ha elegido supervisar.
Haga tres preguntas diferentes: inicio, actividad y preparación
No pida a una única comprobación que responda a todas las preguntas operativas. Kubernetes documenta tres tipos distintos de sondas. Una sonda de inicio establece si la aplicación de un contenedor se ha iniciado; cuando está configurada, evita las sondas de actividad y preparación hasta que tiene éxito. Esto es importante para aplicaciones que necesitan tiempo para inicializarse antes de que pueda evaluarse su funcionamiento normal.
Una señal de actividad responde si la aplicación en ejecución sigue avanzando lo suficiente como para que sea apropiado reiniciarla. Kubernetes describe las sondas de actividad como un medio para decidir cuándo reiniciar un contenedor y utiliza un interbloqueo como ejemplo: el proceso existe, pero no puede avanzar. Como una comprobación de actividad defectuosa puede reiniciar contenedores bajo carga y contribuir a fallos en cascada, debe ser deliberadamente limitada y conservadora.
Una señal de preparación responde si la aplicación puede aceptar actualmente el tráfico que pretende enviarle. Kubernetes indica que la preparación puede reflejar fallos temporales o sobrecarga, y que una sonda de preparación fallida impide que los Services coincidentes envíen tráfico al Pod afectado. En un entorno autoalojado sin Kubernetes, los mecanismos son diferentes, pero la decisión sigue siendo útil: ¿deberían dirigirse usuarios o sistemas ascendentes a esta instancia ahora mismo?
- Inicio: ¿La inicialización se ha completado lo suficiente para que comiencen las comprobaciones normales?
- Actividad: ¿El proceso de la aplicación está avanzando o se justifica una intervención como un reinicio?
- Preparación: ¿Esta instancia puede recibir de forma segura el tráfico previsto en este momento?
- Disponibilidad orientada al usuario: ¿Puede un usuario externo completar una acción representativa y permitida?
- Estado de dependencias: ¿Los servicios requeridos por los flujos de trabajo críticos responden como se espera?
Empiece por los recorridos de usuario, no por los endpoints
La forma más fiable de definir comprobaciones de estado para aplicaciones autoalojadas es comenzar por los resultados que los usuarios necesitan, en lugar de por el endpoint más fácil de solicitar. Enumere los recorridos que importan para la instancia concreta. Un sitio de publicación puede priorizar la entrega de páginas públicas y las actualizaciones editoriales. Un CRM puede priorizar el inicio de sesión, la búsqueda de registros, la creación de registros y las comunicaciones salientes. Una aplicación de IA puede necesitar inicio de sesión, solicitudes de recuperación o de modelos, ingesta de archivos y procesamiento en segundo plano.
Para cada recorrido, describa la prueba segura más pequeña que demuestre que funciona. Una prueba debe evitar modificar datos de producción innecesariamente, exponer credenciales o generar acciones externas no deseadas. Si la documentación de la aplicación no establece un endpoint, comando o flujo de trabajo con cuenta de prueba adecuado, trátelo como una incertidumbre que debe resolverse mediante documentación del proveedor y pruebas controladas, no como autorización para asumir que una URL genérica demuestra preparación.
No todos los recorridos pertenecen a la misma alerta. Un fallo al crear registros es diferente de que una integración analítica opcional no esté disponible. El objetivo es hacer visible esa distinción antes de que un incidente obligue a quienes responden a decidirla bajo presión.
- Inicio de sesión: ¿Puede un usuario autorizado establecer una sesión mediante la ruta de identidad prevista?
- Lecturas de datos: ¿Pueden los usuarios recuperar los registros, páginas o resultados que necesitan?
- Escrituras: ¿Puede un usuario autorizado crear o actualizar un elemento representativo?
- Cargas y almacenamiento: ¿Puede la aplicación aceptar y recuperar un objeto de prueba cuando esto es crítico?
- Procesamiento en segundo plano: ¿Se completan las tareas en cola o programadas cuando el flujo de trabajo depende de ellas?
- Integraciones: ¿Puede completarse una interacción requerida con identidad, correo electrónico, pagos, IA o una API externa?
Mapee los componentes que hay detrás de cada recorrido crítico
Un recorrido falla a través de una cadena, no de un único proceso de aplicación. Mapee los componentes directos que participan en cada flujo de trabajo crítico: el proceso de aplicación, la base de datos, la caché, el almacenamiento persistente, la cola o el worker, el servicio de identidad, la ruta de correo electrónico y las API externas. El SRE Workbook de Google recomienda supervisar las dependencias directas porque pueden cambiar o tener problemas aunque la aplicación en sí no haya cambiado.
Este mapa hace que las comprobaciones sean más diagnósticas. Si el acceso público falla pero la comprobación operativa interna de la aplicación tiene éxito, investigue el enrutamiento, DNS, TLS o la ruta entre el usuario y la aplicación. Si la aplicación es accesible pero falla una prueba de escritura, inspeccione la base de datos, el almacenamiento, los permisos, la capacidad o la ruta de cola relevante para esa escritura. La señal de estado debe ayudar a quienes responden a acotar la siguiente pregunta, no limitarse a anunciar que algo va mal.
Incluya también los recursos con límites estrictos o prácticos. La guía SRE de Google destaca la RAM, el disco, la cuota de CPU, los descriptores de archivos, los hilos, el tiempo de espera de las colas y el volumen de registros. La supervisión de recursos no sustituye a las comprobaciones de flujos de trabajo, pero puede revelar un fallo inminente antes de que se interrumpa un recorrido crítico.
- Para cada flujo de trabajo, registre las dependencias directas y la dirección de su impacto.
- Identifique si cada dependencia es interna, está gestionada por otro equipo o es externa.
- Registre los límites de recursos relevantes y cómo pueden inspeccionarlos quienes respondan al incidente.
- Identifique el conjunto mínimo de señales necesario para distinguir las rutas de fallo habituales.
Elija comprobaciones de actividad superficiales y comprobaciones de preparación limitadas
Una comprobación de actividad normalmente debe establecer que la propia aplicación puede responder o avanzar, sin convertirla en rehén de todos los servicios posteriores. Su finalidad no es certificar todas las funciones empresariales, sino evitar que una aplicación realmente bloqueada permanezca en ejecución indefinidamente. Cuando una aplicación publique un endpoint de actividad o comando de estado documentado, utilice la documentación como punto de partida y pruebe su comportamiento real en su entorno.
La preparación puede tener justificadamente más profundidad. Kubernetes documenta un patrón para aplicaciones con dependencias estrictas de backend: la actividad puede cubrir la propia aplicación mientras la preparación también comprueba los servicios de backend requeridos, evitando que el tráfico alcance instancias que solo pueden devolver errores. La palabra requerido es importante. Incluya una dependencia en la preparación cuando su ausencia impida que el tráfico previsto tenga éxito, no simplemente porque exista.
Mantenga limitadas las comprobaciones profundas. Una comprobación de preparación que realice una consulta costosa, escriba registros de producción o llame a todas las API de terceros puede generar carga, fallos ruidosos y resultados ambiguos. Prefiera una verificación limitada y representativa que esté alineada con el propósito de la comprobación. Si la aplicación no ofrece una interfaz de estado documentada, utilice una comprobación externa de flujo de trabajo cuidadosamente diseñada y documente sus limitaciones.
- Utilice endpoints o comandos de estado de la aplicación documentados solo después de verificar su semántica para la aplicación desplegada.
- Mantenga la actividad centrada en el progreso de la aplicación y en decisiones de reinicio seguras.
- Añada una dependencia a la preparación solo cuando sea necesaria para el tráfico que se está admitiendo.
- Evite pruebas costosas, destructivas o con una amplia dispersión de llamadas en comprobaciones frecuentes.
- Utilice múltiples señales focalizadas en vez de un endpoint de estado sobredimensionado siempre que esto produzca decisiones más claras.
Defina una política de dependencias antes de que se produzcan fallos
Para cada dependencia, decida de antemano su clase operativa. Una dependencia bloqueante implica que los usuarios no pueden completar un flujo de trabajo crítico sin ella. Una dependencia degradante implica que una función se ve afectada, pero la aplicación aún puede proporcionar su servicio principal. Una dependencia solo de alerta merece atención, pero no debería cambiar por sí sola el estado de disponibilidad de la aplicación para los usuarios.
Esta política evita dos extremos perjudiciales. La supervisión basada solo en puertos no detecta un sistema que acepta conexiones pero no puede realizar trabajo útil. Por otro lado, una comprobación de preparación de todo o nada puede declarar una aplicación no disponible cada vez que un servicio opcional es lento o temporalmente inaccesible. Ambas generan malas decisiones ante incidentes: la primera produce confianza falsa, mientras que la segunda provoca interrupciones innecesarias y fatiga de alertas.
La política debe indicar la consecuencia, no solo la comprobación. Si una dependencia es bloqueante, decida si debe retenerse el tráfico, si la función afectada debe aparecer claramente como no disponible o si se requiere una acción de recuperación. Si es degradante, defina cómo reconocen usuarios y responsables la modalidad reducida. Si es solo de alerta, identifique quién es responsable del seguimiento y por qué no bloquea el flujo de trabajo crítico.
- Bloqueante: El fallo impide un flujo de trabajo crítico concreto; puede hacer que la instancia no esté preparada para su tráfico previsto.
- Degradante: El fallo afecta a una función definida; alerte y comunique la limitación sin declarar caída toda la aplicación.
- Solo de alerta: El fallo requiere investigación, pero no afecta actualmente al resultado de servicio seleccionado.
- Desconocida: El comportamiento de la dependencia no se ha documentado ni probado; no la clasifique silenciosamente como opcional.
Separe las comprobaciones públicas de las comprobaciones operativas internas
Las comprobaciones externas e internas responden a preguntas diferentes. Google SRE describe la supervisión de caja negra como la prueba de comportamiento visible externamente tal como lo vería un usuario, mientras que la supervisión de caja blanca utiliza información expuesta desde dentro del sistema. Ambas son valiosas para las aplicaciones autoalojadas.
Una comprobación pública puede verificar que el dominio, la ruta, la ruta TLS y la respuesta básica de aplicación previstos están disponibles desde el exterior. Un flujo de trabajo sintético autenticado puede validar un recorrido de usuario cuidadosamente seleccionado, siempre que las credenciales, los datos de prueba y los efectos secundarios se gestionen de forma segura. Las comprobaciones internas pueden revelar el estado del contenedor, diagnósticos de la aplicación, conexiones de dependencias, la profundidad de la cola o el comportamiento del worker y la presión sobre los recursos.
No exponga públicamente endpoints operativos solo por comodidad. Decida qué diagnósticos requieren autenticación o acceso mediante red privada, y evite colocar secretos en URL, registros o configuraciones de supervisión simplistas. Su modelo de acceso, tratamiento de datos y requisitos de gobernanza siguen siendo responsabilidad de los propietarios de la aplicación incluso cuando las operaciones de infraestructura estén gestionadas por otro proveedor.
- Pública: ¿El punto de entrada previsto para el usuario es accesible y se comporta como se espera?
- Externa autenticada: ¿Puede una cuenta controlada completar un flujo de trabajo crítico y seguro?
- Aplicación interna: ¿La aplicación informa de la condición operativa esperada?
- Dependencias y recursos: ¿Los servicios requeridos y los recursos limitados se encuentran en un estado que respalda el flujo de trabajo?
- Revisión de seguridad: ¿Los endpoints de estado, las credenciales, los registros y los datos de prueba están protegidos adecuadamente?
Convierta las señales en un plan de alerta y recuperación
Una comprobación sin una decisión de respuesta es solo una medición. Para cada señal, defina un responsable, frecuencia de comprobación, tiempo de espera, número de observaciones fallidas antes de alertar, ruta de alerta y decisión de escalado. Las comprobaciones de estado de Docker proporcionan controles para el intervalo, el tiempo de espera, el período de inicialización y los fallos consecutivos; estos controles ilustran por qué una única observación fallida no debe tener automáticamente el mismo significado que una condición sostenida. Los valores adecuados son específicos de cada aplicación y deben seleccionarse a partir del comportamiento observado, no copiarse como umbrales universales.
Haga que la ruta de recuperación sea igual de explícita. Registre qué debe inspeccionar primero quien responda, qué acciones son seguras y qué evidencia justifica un reinicio, restauración, corrección de configuración o reversión. Kubernetes advierte que las sondas de actividad implementadas incorrectamente pueden causar fallos en cascada mediante reinicios bajo carga. El mismo principio operativo se aplica fuera de Kubernetes: la recuperación automatizada debe ser limitada, conocida y probada, en lugar de una respuesta refleja ante cualquier dependencia fallida.
Entre los diagnósticos útiles se incluyen el resultado observado externamente, el estado de la aplicación y del contenedor cuando esté disponible, la salida reciente de las comprobaciones de estado, las respuestas de dependencias directas y las condiciones de recursos relevantes. Docker documenta que el estado de salud configurado es visible mediante el estado del contenedor y que se puede consultar la salida de diagnóstico de las comprobaciones de estado para investigar. Conserve suficiente contexto para que la persona de guardia pueda actuar sin adivinar.
- Responsable de la señal: ¿Quién es responsable de la configuración de la comprobación y de su guía operativa?
- Política de observación: ¿Con qué frecuencia se ejecuta, cuánto puede tardar y cuántos fallos constituyen una condición significativa?
- Ruta de alerta: ¿A quién se notifica y qué condiciones justifican un escalado inmediato?
- Primera inspección: ¿Qué registros, salida de estado, comprobaciones de dependencias e indicadores de recursos deben revisarse?
- Acciones seguras: ¿Qué acciones aprobadas de reinicio, configuración, restauración o reversión existen?
- Límite de escalado: ¿Cuándo requiere el problema la participación del propietario de la aplicación, de la dependencia o del proveedor?
Preguntas frecuentes
¿Es suficiente una respuesta HTTP 200 para comprobar el estado de una aplicación autoalojada?
Normalmente no. Puede demostrar que una ruta accesible devolvió una respuesta, pero quizá no pruebe que los usuarios puedan iniciar sesión, acceder a datos actuales, guardar cambios, utilizar almacenamiento, completar trabajo en segundo plano o llegar a integraciones requeridas. Combine una comprobación externa básica con comprobaciones que reflejen los flujos de trabajo críticos de esa aplicación.
¿Cuál es la diferencia entre actividad y preparación?
La actividad pregunta si una aplicación en ejecución está avanzando o podría necesitar reiniciarse. La preparación pregunta si puede recibir de forma segura el tráfico previsto ahora. Kubernetes documenta consecuencias diferentes: una preparación fallida impide que los Services coincidentes envíen tráfico, mientras que una actividad fallida puede provocar la finalización del contenedor conforme a la política de reinicio configurada.
¿Debería fallar una comprobación de preparación cuando una API externa no está disponible?
Solo si esa API es necesaria para el tráfico o flujo de trabajo que representa la señal de preparación. Si los usuarios no pueden completar una función crítica sin ella, puede ser una dependencia bloqueante. Si afecta a una función opcional, clasifíquela como degradante o solo de alerta y defina explícitamente la experiencia para usuarios y responsables.
¿Qué debe probarse antes de confiar en las comprobaciones de estado?
Pruebe escenarios de fallo significativos de forma controlada: un proceso de aplicación detenido, una base de datos no disponible, almacenamiento agotado, un worker de cola fallido y una dependencia externa inaccesible. Confirme para cada escenario la señal observada, el comportamiento del tráfico, la ruta de alerta, los diagnósticos, la acción de recuperación segura y los criterios de restauración.
¿Cómo encaja Airbip en la supervisión de aplicaciones autoalojadas?
Airbip gestiona el despliegue de aplicaciones de catálogo como cargas de trabajo Docker en sus servidores en la nube y proporciona capacidades de infraestructura que incluyen automatización de enrutamiento y TLS, comprobaciones de DNS, gestión del ciclo de vida de servicios y copias de seguridad diarias, semanales y mensuales configurables. Los propietarios de las aplicaciones siguen necesitando definir flujos de trabajo críticos, tomar decisiones de acceso e integración, comprender el comportamiento de estado específico de cada aplicación y establecer prioridades de recuperación.
Fuentes y lecturas adicionales
- Liveness, Readiness, and Startup Probes — Kubernetes
- Dockerfile reference: HEALTHCHECK — Docker
- Running containers: Healthchecks — Docker
- Monitoring Distributed Systems — Google SRE
- Monitoring — Google SRE Workbook
- Testing for Reliability — Google SRE