web-dev-qa-db-fra.com

Les bilans de santé doivent-ils appeler d'autres bilans de santé des applications?

J'ai deux APIs A et B que je contrôle et les deux ont des bilans de santé prêts et actifs. A a une dépendance sur B.

A
/foo - This endpoint makes a call to /bar in B
/status/live
/status/ready

B
/bar
/status/live
/status/ready

La vérification de l'état de préparation pour A doit-elle appeler la vérification de l'état de préparation pour l'API B en raison de la dépendance?

urlkubernetesapi-designhealth-monitoringkubernetes-health-check
8
Muhammad Rehan Saeed

Le service A est prêt s'il peut répondre aux demandes de l'entreprise. Donc, si pouvoir atteindre B fait partie de ce qu'il doit faire (ce qui semble être le cas), alors il devrait vérifier B.

L’avantage de cocher B est que vous pouvez alors échouer rapidement lors d’une mauvaise mise à niveau . Supposons que votre A soit mal configuré de sorte que la mise à niveau comporte un détail de connexion incorrect pour B - peut-être que le nom du service de B est injecté en tant que variable d'environnement et que la nouvelle version comporte une faute de frappe. Si vos instances A vérifient B au démarrage, vous pouvez plus facilement vous assurer que la mise à niveau échoue et qu'aucun trafic ne se dirige vers les nouveaux pods mal configurés. Pour plus d'informations, voir https://medium.com/spire-labs/utilizing-kubernetes-liveness-and-readiness-probes-to-automatiquement-recover-from-failure-2fe0314f2b2e

Il suffirait généralement à A de vérifier le point de terminaison d'activité de B ou tout point de terminaison de disponibilité minimale plutôt que le point de terminaison de disponibilité de B. Cela est dû au fait que kubernetes sera en train de vérifier la vérification de la disponibilité de B de toute façon , de sorte que toute instance de B pouvant être atteinte par A sera prête. L'appel du point de terminaison d'activité de B plutôt que de l'état de préparation peut faire la différence si le point de terminaison préparation de B effectue plus de vérifications que celui de la vivacité . Gardez à l'esprit que les kubernetes appellent ces sondes régulièrement - préparation ainsi que vivacité - elles ont toutes les deux une période . La différence est de savoir si le pod ne sert plus le trafic (si l'état de préparation échoue) ou s'il est redémarré (si l'animation échoue). Vous n'essayez pas d'effectuer des contrôles de transaction de bout en bout , vous voulez que ces contrôles contiennent un minimum de logique et ne surchargent pas la charge.

Il est préférable que le code dans la mise en œuvre de l'état de préparation de A effectue le contrôle plutôt que de le faire au niveau k8s (dans la spécification Pod elle-même). Le deuxième choix est de le faire au niveau k8s car vous voulez idéalement savoir que le code qui s'exécute dans le conteneur se connecte vraiment.

Un autre moyen de vérifier les services dépendants sont disponibles utiliser une vérification dans un initContainer . L'utilisation d'initContainers évite de voir plusieurs redémarrages au démarrage (en s'assurant d'un ordre correct), mais les vérifications des dépendances via des sondes peuvent aller plus en profondeur (si implémentées dans le code de l'application) et les sondes continueront à s'exécuter périodiquement après le démarrage. Donc, il peut être avantageux d’utiliser les deux. 

Veillez à ne pas vérifier les services de manière trop générale sur les autres services, car cela pourrait entraîner une indisponibilité en cascade. Par exemple, si un serveur tombe en panne brièvement et qu'une interface le teste, il deviendra également indisponible et ne pourra donc pas afficher un bon message d'erreur. Vous voudrez peut-être commencer avec des sondes simples et ajouter soigneusement la complexité au fur et à mesure.

3
Ryan Dawson

Référencement de Microsoft Implémentation d'applications résilientes tutoriels. En particulier le Surveillance de l'état de santé , il est suggéré que si l'état général du service actuel dépend de l'état de dépendance, l'état sain du service ne doit être sain que si ses dépendances sont saines.

Cependant, l'application Web MVC de eShopOnContainers a plusieurs dépendances sur le reste des microservices. Par conséquent, il appelle une méthode AddUrlCheck pour chaque microservice, comme indiqué dans l'exemple suivant:

// Startup.cs from the MVC web app
public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();
        services.Configure<AppSettings>(Configuration);
        services.AddHealthChecks(checks =>
        {
            checks.AddUrlCheck(Configuration["CatalogUrl"]);
            checks.AddUrlCheck(Configuration["OrderingUrl"]);
            checks.AddUrlCheck(Configuration["BasketUrl"]);
            checks.AddUrlCheck(Configuration["IdentityUrl"]);
        });
    }
}

Ainsi, un microservice ne fournira pas un statut «sain» tant que tous ses contrôles ne le seront pas non plus.

c'est moi qui souligne

Donc, pour répondre plus directement à votre question sur 

La vérification de l'état de préparation pour A doit-elle appeler la vérification de l'état de préparation pour l'API B en raison de la dépendance?

Je dirais que oui. Surtout si la santé de la dépendance B affecte directement la stabilité de A.

4
Nkosi

Il y a la disponibilité et le dynamisme. et je ne pense pas qu'il y ait une réponse évidente. seulement une ligne directrice -
Alive signifie que le service est simplement réactif. par exemple. capable de répondre avec 200/OK . Prêt signifie fonctionner selon ce que l'on est censé faire. (c'est l'API la plus utilisée)

Par exemple, au stade du démarrage, un service peut être actif, mais il n'est pas encore prêt, car les composants/services dépendants ne sont pas encore vivants ou prêts. (par exemple, la base de données n’est pas encore connectée) . Par conséquent, je dirais que, pour être prêt, vous devrez peut-être vous assurer que les autres composants essentiels sont en vie ou prêts. Tout ce que vous avez à décider, c'est quels sont les éléments essentiels à vérifier.

1
Pam Stums

Non, vous n’avez pas besoin de consulter healthchek sur d’autres microservices. Un microservice unique devrait fonctionner indépendamment des autres microservices (selon la définition de microservice). Si un microservice dépend d'un autre, vous pouvez utiliser fallBack, les modèles de disjoncteur par rapport aux autres microservices, de sorte qu'il puisse fonctionner sans échec.

0
Keaz

Lorsque j'implémente le point de terminaison d'intégrité dans une application, je suis la meilleure pratique pour vérifier toutes les dépendances requises par l'application pour fonctionner.

Si l'une de ces dépendances ne fonctionne pas, mon application ne fonctionnant pas, elle est marquée comme étant malsaine. 

0
GianArb