La sonde de santé marque les instances comme malsaines mais les ne le sont pas

Question

J'utilise un ensemble d'échelles VM pour mon application de noeud. Mon application a une action qui est accessible au public via www.mydomain.com/api/healthcheck et imprime juste un certain json. Lorsque je configure ma sonde de santé pour utiliser le protocole TCP, tout fonctionne correctement et mon API me renvoie le json attendu (et le statut 200). Cependant, lorsque je passe maintenant ma sonde de santé pour utiliser HTTP et path = /api/healthcheck, mon site web n'est plus accessible (ERR_CONNECTION_TIMED_OUT ... Je suppose que le loadbalancer supprime toutes les instances car la sonde de santé lui dit que chaque instance est malsaine) J'utilise nginx en face de mon application de noeud, mais j'ai également essayé (pour tester) de configurer mon LoadBalancer pour router le port 80 vers backendport 8080 (où mon application de noeud tourne sur chaque machine, donc je peux éviter le proxy nginx). Mais j'ai le même comportement.

Je n'arrive pas à comprendre pourquoi mon bilan de santé personnalisé ne fonctionne pas. J'espère que vous pouvez aider.

---

Edit: Pour les tests, je ne les éléments suivants:

• exécuter une autre app nodejs sur le port 3000 sur chaque machine virtuelle, qui écrit seulement "Bonjour tout le monde"
(sans proxy nginx!)
• créer une règle LB pour le port 3000 et également configurer mon NSG pour permettre: 3000 pour tous
• au début, ma sonde de santé est configuré pour utiliser tcp
• rESU lt: mydoamin.com:3000/hello est disponible (impression bonjour et retourne 200)
• maintenant je configure ma sonde de santé à utiliser http -protocol, le port et l'emplacement 3000/hello.
• résultat: mon application web tout n'est plus disponible

Answer 1

Je ne peux pas voir le code de votre serveur est donc difficile à comprendre. Si vous partagiez du code, ce serait plus simple.

permet donc d'essayer d'analyser la situation:

Vérification initiale

Connexion aux instances a expiré

Essayez d'effectuer la commande suivante à partir de vos machines terminaux

curl –I private-IP-address-of-the-instance:port/health-check-target-page 

maintenant en fonction du tucome nous avons différentes causes possibles ...

initiale Vérifiez Résultat: réponse non-200

• Aucune page cible est configurée sur l'instance.
• La valeur de l'en-tête Content-Length dans la réponse n'est pas définie.
• L'application n'est pas configurée pour recevoir des requêtes de l'équilibreur de charge ou pour renvoyer un code de réponse 200.

initiale Vérifiez Résultat: capable de se connecter directement à l'instance

• L'instance ne parvient pas à répondre dans la réponse configurée délai d'attente.
• L'instance est soumise à une charge importante et prend plus de temps que votre période de réponse configurée pour répondre.
• Si vous utilisez une connexion HTTP ou HTTPS et que le contrôle d'intégrité est en cours d'exécution sur une page cible spécifiée dans le champ de chemin ping (par exemple, HTTP: 80/index.html), la page cible peut être en prenant plus longtemps pour répondre que votre délai d'attente configuré.

Autre: instance ne reçoit pas le trafic de l'équilibreur de charge

Problème: Le groupe de sécurité de l'instance bloque le trafic de l'équilibrage de charge. Effectuez une capture de paquet sur l'instance pour vérifier le problème.

Utilisez la commande suivante:

tcpdump port health-check-port