¿Cuál debería ser el alcance de una comprobación de estado para un sistema que implementa una aplicación web?

Hoy tuve la tarea de "escribir un chequeo de salud" para un servicio de larga ejecución que es un sistema de orquestación para implementar una aplicación web.

Estoy tratando de determinar cuál sería el alcance de dicho control de salud, y se me ocurrieron estas preguntas relacionadas con el alcance del control de salud:

1. ¿Es lo suficientemente bueno para considerar que el servicio es correcto si el sistema de orquestación informa que la tarea se está ejecutando?
2. ¿O deberíamos hacer ping manualmente a cada servicio?
3. ¿O debería ir más allá e intentar asegurarse de que la aplicación web haga lo que se supone que debe hacer, como mostrar una página web?
4. ¿El chequeo de salud también tiene que verificar que algunos servicios dependientes también se estén ejecutando? Como una base de datos o el propio sistema de orquestación. ¿O es responsabilidad de otro control de salud?
5. Y, por último, si uno de los servicios dependientes está muerto y la aplicación web falla posteriormente, ¿debería la aplicación web informar un mal estado, o es bueno, porque no es culpa de las aplicaciones web?

Sé que estas son 5 preguntas separadas, pero todas se relacionan con el alcance de una verificación de estado para un servicio de larga duración que implementa una aplicación web, por lo que pensé que tendría más sentido mantenerlas agrupadas en una sola pregunta.

Esto es difícil de implementar para mí porque no estoy seguro de la definición de lo que es saludable, o cómo debería ser un control de salud estándar para algo como esto.

¿Qué debe contener un chequeo de salud para este servicio específico?

Esto es difícil de implementar debido a la definición de lo que es saludable

Respondiste tu propia pregunta aquí. La definición de un chequeo de salud variará, porque lo que es saludable varía. También depende de lo que está emitiendo el chequeo de salud.

Una buena pregunta que debe hacerse es: "desde la perspectiva del autor de la pregunta, ¿funciona el servicio verificado como se esperaba?" Si es usted, puede definirlo. Si se trata de otro equipo / servicio, debe identificar cuáles son los estándares / especificaciones para los controles de salud.

Probablemente en una organización grande, tendrá algún tipo de estándar para lo que debe hacer un chequeo de salud. Darse cuenta de eso.

Específicamente aquí, su ejemplo de aplicación web significa que no debería volver saludable porque la aplicación web no es saludable. Pero tal vez su definición de "saludable" incluiría esto como "ok". Esto es parte de la discusión de requisitos anterior (nuevamente, incluso si es solo su propio código).

Mi recomendación suponiendo que no se especifique en otro lugar sería tener algún tipo de código de estado asociado con diferentes fallas. Cuando consulta la aplicación web, puede devolver un error que dice "el servicio dependiente está muerto" y así su cliente (o lo que sea que esté realizando la verificación de salud) puede saber la razón por la que el cliente está muerto.

Para las preguntas editadas:

¿Es lo suficientemente bueno para considerar que el servicio es correcto si el sistema de orquestación informa que la tarea se está ejecutando?

No, solo porque un proceso se esté ejecutando no significa que no esté colgado, que sea totalmente no funcional o que exista una gran variedad de otras posibilidades.

¿O deberíamos hacer ping manualmente a cada servicio?

Esto podría funcionar, dependiendo del alcance de la funcionalidad de su aplicación. Si la verificación del servicio responde a un "¿estás vivo?" ping entonces esto podría ser todo lo que se requiere. Pero si el servicio podría estar "vivo y receptivo, pero en realidad no funciona", entonces quizás deba verificar otras cosas también.

¿O debería ir más allá e intentar asegurarse de que la aplicación web haga lo que se supone que debe hacer, como mostrar una página web?

Su comprobación de estado debe garantizar que la funcionalidad requerida que se espera funcione como se espera.

Si sus declaraciones de aplicaciones "sano" y no puede hacer lo que tiene que hacer, que también podría deshacerse de todo el HealthCheck ya que le dará los falsos positivos (por no hablar de confundir a los diablos de personas que tratan de depurar el problema - 'Hey nuestro servidor web se muestra saludable, ¿por qué no podemos ver la página? ').

¿El chequeo de salud también tiene que verificar que algunos servicios dependientes también se estén ejecutando? Como una base de datos o el propio sistema de orquestación. ¿O es responsabilidad de otro control de salud?

Esto depende un poco. Si su servicio depende de otro servicio, la naturaleza de esa interacción debe reflejarse en las llamadas de API / red que se le envían en su aplicación e incorporarse en el chequeo de salud.

Por ejemplo, un servidor web que lee una base de datos debe tener información de estado sobre la base de datos integrada, o la aplicación web simplemente se bloqueará si fallan las llamadas a la API. Puede modificar trivialmente estas llamadas para incorporarlas a su chequeo de salud.

Sin embargo, si su servicio está enviando eventos a consumidores que escuchan, sin ninguna validación, entonces es menos importante para la funcionalidad de su aplicación que los consumidores estén vivos. "Saludable" para su aplicación es enviar los mensajes, en realidad no recibirlos.

Básicamente, si su servicio necesita hablar con otros servicios y verificar su salud de todos modos, tiene sentido al menos tener un nivel básico de verificación en esto para la verificación de salud de su servicio. Esto debería tener sentido conceptual dado lo que acabo de decir, ya que su aplicación ya se encargará de esto (o se bloqueará al azar, supongo).

Y, por último, si uno de los servicios dependientes está muerto y la aplicación web falla posteriormente, ¿debería la aplicación web informar un mal estado, o es bueno, porque no es culpa de las aplicaciones web?

Esto es básicamente respondido anteriormente. Mi recomendación sería que su chequeo de salud devuelva un código / mensaje / lo que sea que proporcione esta información. Ambas piezas de información son importantes: que el servicio dependiente que su servicio necesita está muerto y que su servicio no funcionará como se esperaba como resultado.

En general, un control de salud solo significa "está vivo y está respondiendo". Las comprobaciones adicionales que son altamente especializadas y dependen completamente del uso del sistema. Si usted hace un esfuerzo adicional para verificar que un sistema esté procesando las solicitudes correctamente, depende de usted, pero primero debe hacer lo básico: verifique que esté allí, verifique que pueda recibir solicitudes y le devolverá una respuesta.

La forma más fácil de implementar una comprobación de estado es simplemente escribir un comando que el servicio procesa utilizando el mismo mecanismo que utilizan otros comandos, que no hace nada más que devolver un acuse de recibo. Eso mostrará vida y que el sistema está recibiendo y procesando respuestas.

La comprobación de los sistemas dependientes no forma parte de la comprobación de estado, debe mantenerla simple y autónoma. Agregue un chequeo de salud a cada servicio dependiente a su vez. De esa manera, puede obtener una lista de sistemas en funcionamiento y saludables y saber fácilmente cuándo falla uno, ¿cuál es?

En mi experiencia, los servicios críticos tienden a tener las siguientes características:

Latido del corazón

Si el servicio se ejecuta regularmente, esto solo escribe una línea en un archivo de registro o similar junto con una marca de tiempo para indicar que el cuerpo del servicio se activó en un momento dado.

Migas de pan

De manera similar a lo anterior, las migas de pan suelen ser solo un volcado del nombre del método (y ocasionalmente parámetros) para mostrar que el servicio está procesando el cuerpo del servicio como se esperaba y la ubicación del flujo. Dado que estos pueden generar más resultados, estos son comúnmente controlados por archivos de configuración o similares, por lo que pueden desactivarse una vez que el servicio se ha instalado.

Puede ser tentador agregar muchas otras cosas, como el estado de varios servidores, servicios y bases de datos y similares. Si bien esto es sin duda valioso, aconsejaría no escribir nada demasiado extenso. Estos pueden ser útiles para su propia tranquilidad, pero tales protecciones tienden a ser abusadas una vez que las partes a cargo de los diversos puntos de contacto saben que están allí. Antes de que te des cuenta, podrías estar escribiendo una aplicación de diagnóstico para toda la empresa.