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.