Ceci est difficile à mettre en œuvre en raison de la définition de ce qui est sain
Vous avez répondu à votre propre question ici. La définition d'un bilan de santé va varier, car ce qui est sain varie. Cela dépend également de ce qui délivre le bilan de santé.
Une bonne question à vous poser est: "du point de vue du demandeur, le service vérifié fonctionne-t-il comme prévu?" Si c'est vous, vous pouvez le définir. S'il s'agit d'une autre équipe / service, vous devez identifier la norme / spécification pour les contrôles de santé.
Probablement dans une grande organisation, vous aurez une sorte de norme pour ce qu'un bilan de santé devrait faire. Comprenez cela.
Plus précisément, ici, votre exemple d'application Web signifie qu'il ne devrait pas retourner sain car la Webapp n'est pas saine. Mais peut-être que votre définition de «sain» inclurait ceci comme «ok». Cela fait partie de la discussion des exigences ci-dessus (encore une fois, même si c'est juste votre propre code).
Ma recommandation, en supposant qu'il n'est pas spécifié ailleurs, serait d'avoir une sorte de code d'état associé à différentes défaillances. Lorsque vous interrogez l'application Web, elle peut renvoyer une erreur indiquant que "le service dépendant est mort" et que votre client (ou tout ce qui effectue le contrôle de santé) peut connaître la raison pour laquelle le client est mort.
Pour les questions modifiées:
Est-il suffisant de considérer le service comme sain si le système d'orchestration signale que la tâche est en cours d'exécution?
Non, simplement parce qu'un processus est en cours d'exécution ne signifie pas qu'il n'est pas bloqué, totalement non fonctionnel ou une grande variété d'autres possibilités.
Ou devrions-nous cingler manuellement chaque service?
Cela peut fonctionner, selon l'étendue des fonctionnalités de votre application. Si la vérification du service répond à un "êtes-vous vivant?" ping alors cela pourrait être tout ce qui est requis. Mais si le service peut facilement être «vivant et réactif mais ne fonctionne pas réellement», vous devrez peut-être vérifier également d'autres choses.
Ou doit-il aller plus loin et essayer de s'assurer que l'application Web fait ce qu'elle est censée faire, comme afficher une page Web?
Votre bilan de santé doit s'assurer que la fonctionnalité requise attendue fonctionne comme prévu.
Si votre application retourne "en bonne santé" et ne peut pas faire ce qu'elle doit faire, vous pourriez aussi bien vous débarrasser de la totalité du contrôle de santé car cela donnera de faux positifs (sans parler de confondre le diable des personnes essayant de déboguer le problème - 'hey notre serveur web affiche sain, pourquoi ne pouvons-nous pas voir la page? ').
Le bilan de santé doit-il également vérifier que certains services dépendants fonctionnent également? Comme une base de données ou le système d'orchestration lui-même. Ou est-ce la responsabilité d'un autre bilan de santé?
Cela dépend quelque peu. Si votre service dépend d'un autre service, la nature de cette interaction doit être reflétée dans les appels API / réseau qui lui sont envoyés dans votre application et intégrés au bilan de santé.
Par exemple, un serveur Web lisant à partir d'une base de données doit avoir des informations d'état sur la base de données intégrée - sinon l'application Web se bloquera simplement si les appels d'API échouent. Vous pouvez modifier trivialement ces appels pour les intégrer à votre bilan de santé.
Cependant, si votre service envoie des événements à des consommateurs qui écoutent, sans aucune validation, il est moins important pour la fonctionnalité de votre application que les consommateurs soient vivants. "En bonne santé" à votre application envoie les messages, pas réellement les recevoir.
Fondamentalement, si votre service a besoin de parler avec d'autres services et de vérifier de toute façon leur état de santé, il est logique d'avoir au moins un niveau de vérification basique pour le bilan de santé de votre service. Cela devrait avoir un sens conceptuellement étant donné ce que je viens de dire, car votre application va déjà gérer cela (ou planter au hasard, je suppose).
Et enfin, si l'un des services dépendants est mort et que l'application Web échoue par la suite, l'application Web doit-elle signaler une mauvaise santé, ou est-elle en bonne santé, car ce n'est pas la faute des applications Web?
Ceci est essentiellement répondu ci-dessus. Ma recommandation serait que votre bilan de santé renvoie un code / message / tout ce qui donne ces informations. Les deux informations sont importantes: que le service dépendant dont votre service a besoin est mort et que votre service ne fonctionnera pas comme prévu en conséquence.