En breve, un healthcheck es un endpoint que se implementa en una aplicación web, cuyo propósito es reportar mediante su código de estado HTTP el comportamiento actual del servicio.
Cuando se implementa un healthcheck, se devuelve HTTP 200 si la aplicación está operativa y lista para aceptar tráfico. Todas las dependencias de la aplicación están correctamente configuradas y los servidores y otros recursos externos que hacen falta están funcionando correctamente.
Sin embargo, la idea de este endpoint es al hacerle una petición, haga un sondeo por su cuenta a todas estas dependencias. Si una de ellas está fallando, por ejemplo, si se ha perdido la conexión con la base de datos, este endpoint debe devolver un código de estado erróneo, como HTTP 500; esto señaliza que algo le pasa a la aplicación y que no funciona correctamente. Por ejemplo, si no hay base de datos, tal vez algún endpoint que extraiga información de ella va a fallar.
Los health checks se suelen utilizar junto a una herramienta de monitorización que se ocupe cada pocos segundos o minutos de atacar ese endpoint. 24x7, en bucle, se comprueba todo el rato que la aplicación continúe operativa. Así sabemos todo el tiempo que la aplicación está bien. Y si en algún momento, la base de datos u otro servicio externo comienza a fallar, el reporte comenzará a ser erróneo.
¿Por qué HTTP? Porque es universal, y da igual el lenguaje de programación y el framework que estés utilizando. También da igual si tu aplicación opera desde un servidor con Windows Server, con Linux o con BSD. Si usas la nube de Amazon o si utilizas un hosting compartido. Mientras responda HTTP 200 o HTTP 500, es suficiente. Sin embargo, en la mayoría de los casos también será habitual que el endpoint responda en formato texto o en formato JSON con información extra para alguien que consulte el endpoint a mano, o para crear gráficas más sofisticadas. Se suele usar en compañía también de endpoints de métricas, por ejemplo, para generar una gráfica mediante herramientas como Prometheus.
La magia de los healthchecks está en integrarla con herramientas como Docker, Kubernetes, o algún cloud como AWS. Docker permite utilizar la palabra clave HEALTHCHECK en un Dockerfile para especificar el comando que se debe correr, como curl -fs http://api:5000/health. En cuanto el endpoint empiece a devolver error, el comando también devolverá un error.
En la mayoría de casos, estas comprobaciones permiten que el motor tome acciones correctivas o genere alertas. Imagina los siguientes casos:
- Herramientas como Docker Compose o algunos cloud como AWS son capaces de tirar abajo el contenedor y recrearlo en caso de error. La gracia de Docker es precisamente poder deshacerse rápidamente de un contenedor y crearlo de nuevo en caso de necesidad.
- Otra opción es integrarlo con herramientas como Pingdom o UptimeRobot y generar alertas de e-mail en caso de que el endpoint empiece a fallar. También hay herramientas que permiten mandar alertas por SMS, Slack, Teams o Discord.
Otro uso interesante de los healthchecks es durante los despliegues. Por ejemplo, un orquestador de despliegues puede esperar a que un contenedor recién levantado con una nueva versión de la aplicación se estabilice y responda consistentemente HTTP 200 antes de tirar la versión anterior de la aplicación.
En definitiva, si estás haciendo aplicaciones web y backends más avanzadas, un healthcheck es el primer punto para tener una mejor calidad en la infraestructura de red que hace funcionar la aplicación.