Contrôles de santé actifs ou passifs : Qu'est-ce qui vous convient le mieux ?

Tout comme des visites régulières chez un médecin sont essentielles pour rester en bonne santé, des contrôles réguliers de l’état de santé de vos applications sont essentiels pour des performances fiables. Lors du proxy inverse et de l'équilibrage de charge du trafic, NGINX utilise des contrôles de santé passifs pour protéger les utilisateurs de votre application contre les pannes en détournant automatiquement le trafic des serveurs qui ne répondent pas aux demandes. NGINX Plus ajoute des contrôles de santé actifs , en envoyant des sondes spéciales qui peuvent détecter les serveurs défectueux avant même qu'ils ne parviennent à traiter une demande. Quel type de contrôle de santé est judicieux pour vos applications ? Dans cet article, nous vous donnons les informations dont vous avez besoin pour prendre cette décision.

Qu'est-ce qu'un bilan de santé ?

Dans son sens le plus basique, un contrôle de santé est une méthode permettant de déterminer si un serveur est capable de gérer le trafic. NGINX utilise des contrôles de santé pour surveiller les serveurs pour lesquels il effectue un proxy inverse ou équilibre la charge du trafic, ce qu'il appelle les serveurs en amont .

Contrôles de santé passifs

Les contrôles de santé passifs, disponibles dans NGINX Open Source et NGINX Plus, reposent sur l'observation du comportement du serveur lors de la gestion des connexions et du trafic. Ils aident à empêcher les utilisateurs de subir des pannes dues à des dépassements de délai d'attente du serveur, car lorsque NGINX découvre qu'un serveur n'est pas sain, il transmet immédiatement la demande à un autre serveur, arrête d'envoyer des demandes au serveur défectueux et répartit les demandes futures entre les serveurs sains restants dans le groupe en amont.

Notez que les contrôles de santé passifs ne sont efficaces que lorsque le groupe en amont est défini pour avoir plusieurs membres. Lorsqu’un seul serveur en amont est défini, il n’est jamais marqué comme indisponible et les utilisateurs voient une panne lorsqu’il n’est pas sain.

Comment fonctionnent les contrôles de santé passifs

Voici un aperçu détaillé du fonctionnement des contrôles de santé passifs, mais passez directement aux contrôles de santé actifs si cela ne vous intéresse pas.

Par défaut, NGINX considère qu'un serveur TCP/UDP (flux) est défectueux s'il y a une seule erreur ou un délai d'attente lors de l'établissement d'une connexion avec lui.

NGINX considère qu'un serveur HTTP est défectueux s'il y a une seule erreur ou un délai d'attente lors de l'établissement d'une connexion avec lui, de la transmission d'une requête ou de la lecture de l'en-tête de réponse (ne recevoir aucune réponse compte comme ce type d'erreur). Vous pouvez utiliser la directive proxy_next_upstream pour personnaliser ces conditions pour le proxy HTTP , et il existe une directive parallèle pour les protocoles FastCGI , gRPC , memcached , SCGI , TCP/UDP et uwsgi .

Pour HTTP et TCP/UDP, NGINX attend par défaut dix secondes avant de réessayer de se connecter et d'envoyer une requête à un serveur défectueux. Vous pouvez utiliser le paramètre fail_timeout de la directive server [ HTTP ][ Stream ] pour modifier ce laps de temps.

Vous pouvez utiliser le paramètre max_fails de la directive server pour augmenter le nombre d'erreurs ou de délais d'attente qui doivent se produire pour que NGINX considère le serveur comme défectueux ; dans ce cas, le paramètre fail_timeout définit la période pendant laquelle ce nombre d'erreurs ou de délais d'attente doit se produire, ainsi que la durée pendant laquelle NGINX attend pour réessayer le serveur après l'avoir marqué comme défectueux.

Bilans de santé actifs

Les contrôles de santé actifs, exclusifs à NGINX Plus, sont des demandes spéciales qui sont régulièrement envoyées aux points de terminaison des applications pour s'assurer qu'ils répondent correctement. Ils sont distincts et s'ajoutent aux contrôles de santé passifs. Par exemple, NGINX Plus peut envoyer une requête HTTP périodique au serveur Web de l’application pour garantir qu’il répond avec un code de réponse valide et le contenu correct. Les contrôles de santé actifs permettent une surveillance continue de l’état de santé de composants et de processus d’application spécifiques. Il s'agit d'une mesure directe de la disponibilité de l'application, bien que cela dépende de la représentativité du contrôle de santé spécifié par rapport à l'état de santé global de l'application.

Vous pouvez personnaliser de nombreux aspects d'un contrôle de santé actif ; voir Cas d'utilisation des contrôles de santé actifs .

Cas d'utilisation des contrôles de santé passifs

Les contrôles de santé passifs sont des enjeux de base. Il est recommandé à chaque équipe de développement d’applications, DevOps, DevSecOps et Platform Ops d’exécuter des contrôles de santé passifs dans le cadre de son programme de surveillance de l’infrastructure de production. NGINX exécute des contrôles d’intégrité passifs sur le trafic à charge équilibrée par défaut, y compris les configurations HTTP, TCP et UDP.

Les avantages des bilans de santé passifs incluent :

• Disponible en NGINX Open Source
• Activé par défaut pour les serveurs inclus dans un bloc de configuration en amont
• Aucune charge supplémentaire sur les serveurs en amont
• Configurable en termes de nombre minimum d'échecs sur une période donnée, comme décrit dans Comment fonctionnent les contrôles de santé passifs
• Démarrage lent configurable (exclusif à NGINX Plus) – lorsqu'un serveur retrouve sa santé, NGINX Plus augmente progressivement la quantité de trafic qui lui est transmise, pour lui donner le temps de « se réchauffer »

Les avantages de NGINX Open Source sont le coût (aucun, évidemment), la configurabilité et une vaste bibliothèque de modules tiers. Étant donné que le code source est disponible, les développeurs peuvent modifier et étendre les fonctionnalités pour répondre à leurs besoins spécifiques.

Pour de nombreuses applications (et leurs développeurs), les contrôles de santé passifs sont suffisants. Par exemple, les contrôles de santé actifs peuvent être excessifs pour les microservices qui ne sont pas en contact avec les clients et qui exécutent des tâches plus petites. De même, ils peuvent ne pas être nécessaires pour les applications où la mise en cache peut réduire les risques de problèmes de latence ou où les réseaux de distribution de contenu (CDN) peuvent prendre en charge certaines des tâches de l’application. Pour résumer, les contrôles de santé passifs seuls sont les meilleurs pour :

• Surveillance du trafic HTTP
• Surveillance de l'infrastructure séparément des applications
• Surveillance des applications où la latence est tolérable
• Surveillance des applications internes où les performances élevées ne sont pas importantes

Cas d'utilisation des contrôles de santé actifs

Pour les applications critiques, les contrôles de santé actifs sont souvent cruciaux, car les clients et les processus clés sont directement impactés par les problèmes. Avec ces applications, il est essentiel de tester l’application essentiellement comme le fait le client ou le consommateur de l’application, ce qui nécessite des contrôles de santé actifs. Les contrôles de santé actifs sont similaires aux outils de surveillance des performances des applications tels que New Relic et AppDynamics, qui utilisent des contrôles hors bande pour mesurer la latence et les réponses des applications. Pour les contrôles de santé actifs, NGINX Plus inclut un certain nombre de fonctionnalités et de capacités non incluses dans NGINX Open Source :

• Contrôles de santé hors bande pour la disponibilité des applications
• Testez les points de terminaison configurés et recherchez des réponses spécifiques
• Testez des ports différents de ceux qui gèrent le trafic d'application réel
• Connexions HTTP Keepalive pour les contrôles de santé, éliminant ainsi le besoin de configurer une nouvelle connexion pour chaque contrôle
• Meilleur contrôle sur les conditions d'échec et de réussite
• Vous pouvez éventuellement tester tous les serveurs nouvellement ajoutés avant qu'ils ne reçoivent un trafic d'application réel.

Grâce aux contrôles de santé actifs, les développeurs peuvent configurer NGINX Plus pour détecter automatiquement lorsqu'un serveur back-end est en panne ou rencontre des problèmes, puis acheminer le trafic vers des serveurs sains jusqu'à ce que le problème soit résolu. La plus grande configurabilité des contrôles de santé actifs permet d'effectuer des contrôles de santé plus sophistiqués, détectant éventuellement les problèmes d'application avant qu'ils n'impactent les utilisateurs réels de l'application. Cela peut minimiser les temps d’arrêt et empêcher les interruptions de l’accès des utilisateurs à l’application.

Comment configurer les contrôles de santé

Les contrôles de santé passifs sont activés par défaut, mais vous pouvez personnaliser leur fréquence et le nombre d'échecs qui se produisent avant qu'un service ne soit marqué comme défectueux, comme décrit dans Fonctionnement des contrôles de santé passifs . Pour obtenir des instructions de configuration complètes pour les contrôles de santé passifs et actifs, consultez notre documentation :

• Vérifications de santé HTTP
• Contrôles de santé TCP
• Contrôles de santé UDP
• Contrôles de santé gRPC

Conclusion: Choisissez les bilans de santé qui correspondent aux exigences de votre candidature

Les contrôles de santé sont un élément important pour assurer le bon fonctionnement et la réactivité de toute application de production. Ils constituent le meilleur moyen de détecter les problèmes et d’identifier les sources croissantes de latence avant qu’elles n’affectent les utilisateurs finaux. Pour de nombreuses applications, les contrôles de santé passifs sont suffisants.

Pour les applications plus critiques, où des informations directes sur les comportements des applications au niveau de l'utilisateur sont nécessaires, les contrôles actifs sont meilleurs. NGINX Open Source est gratuit et fournit des contrôles de santé passifs configurables. NGINX Plus offre des fonctionnalités avancées de contrôle de santé actif ainsi qu'un support commercial.

Vous souhaitez essayer les contrôles de santé actifs avec NGINX Plus ? Commencez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .