Un contrôle de santé typique envoie une requête à un endpoint, voit une réponse 200 et marque le service comme sain. Dans les applications modernes, ce n'est pas suffisant. La page d'accueil de l'application peut répondre pendant que la connexion à la base de données est lente, que la couche de cache est défaillante, qu'une dépendance en aval est tombée ou que le flux de connexion a cessé de fonctionner. Si l'équilibreur de charge ne peut pas voir cette différence, il continue de router le trafic vers des backends qui répondent mais ne peuvent pas faire de travail réel.
Les contrôles en une seule étape sont encore plus insuffisants pour les protocoles basés sur les sessions. Pour FTP, LDAP, Oracle ou les protocoles TCP personnalisés, avoir le port ouvert ne signifie pas que le service est sain. Un vrai contrôle de santé doit se connecter, envoyer une commande, recevoir la réponse attendue, se déconnecter si nécessaire et valider le contenu de la réponse. Sinon, le service semble accessible pendant que les opérations utilisateur réelles échouent.
La validation de contenu devient fragile lorsqu'elle se limite à la correspondance de texte brut. Une API peut toujours retourner le mot « OK » pendant que l'état des dépendances, la métrique de latence ou la règle métier à l'intérieur du JSON est en échec. Lorsqu'un contrôle de santé ne peut pas interroger la signification de la réponse, les dégradations au niveau applicatif sont détectées tardivement.
La bonne approche est d'aborder les contrôles de santé avec la profondeur de protocole, des scénarios multi-étapes, des requêtes de contenu et des seuils rise/fall configurables. Les opérations de sonde doivent s'exécuter isolées du flux de trafic principal afin que les contrôles de santé lents ou bloqués ne retardent pas le trafic utilisateur.
La Supervision Active de Santé de TR7 délivre ce modèle : elle surveille 11 protocoles depuis une seule configuration, exécute des scénarios multi-étapes, valide la signification du contenu avec JSONata et ne maintient dans la rotation que les cibles véritablement saines.
TR7 transforme la vérification de santé d'un contrôle à protocole unique en un système de décision multi-protocole, basé sur des scénarios et à validation de contenu.
Les contrôles TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS et Oracle sont tous gérés depuis le même objet de contrôle de santé. Selon le checkType sélectionné, seuls les champs pertinents sont affichés, de sorte que les opérateurs ne sont pas surchargés de paramètres non pertinents.
Pour les contrôles TCP, UDP et Oracle, des flux de contrôle ordonnés sont construits en utilisant des étapes send, expect, regex et wait. Si une étape échoue, la sonde est marquée comme échouée et l'état de santé du backend est mis à jour en conséquence.
Pour les contrôles HTTP et HTTPS, des requêtes JSONata sont utilisées pour lire l'état réel à l'intérieur d'une réponse JSON. Un backend n'est pas considéré comme sain simplement pour avoir retourné 200 — des champs tels que l'état des dépendances, le score, la latence ou l'état métier peuvent également être vérifiés.
Le nombre de réponses échouées consécutives requis pour marquer un backend comme non sain et le nombre de réponses réussies consécutives requises pour le remettre dans la rotation sont configurés indépendamment. Cela empêche les fluctuations réseau transitoires de faire continuellement entrer et sortir les backends de la rotation.
La Supervision Active de Santé rend différents types de services définissables, testables et gérables avec des seuils opérationnels — le tout depuis le même éditeur.
TR7 prend en charge les contrôles de santé TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS et Oracle. Les opérateurs n'ont pas besoin d'outils séparés pour une base de données Oracle, un annuaire LDAP, un serveur DNS, un référentiel FTPS ou une API HTTP. Les champs pertinents apparaissent en fonction du type de protocole sélectionné ; les champs non pertinents sont masqués. Ce modèle rend la vérification de santé à travers des backends hétérogènes standardisée et maintenable.
Pour les contrôles TCP, des étapes sendText, expectText, expectRegex et wait peuvent être exécutées en séquence. Les bannières SMTP, les requêtes de capacité IMAP, les échanges Redis PING/PONG, les réponses MQTT et les messages de protocole TCP personnalisés sont tous testables avec ce modèle. Au lieu de simplement ouvrir une connexion, un vrai dialogue de protocole est exécuté. Si une étape ne produit pas le résultat attendu, le backend est marqué comme non sain.
Pour les contrôles UDP, des étapes send, wait, expectText et expectRegex sont disponibles. Les données à envoyer peuvent être définies en format texte, hex ou base64, offrant de la flexibilité pour les sondes de protocoles binaires. Pour les services UDP tels que DNS, NTP, RADIUS, SIP et similaires, la réponse de protocole attendue est validée — pas seulement si le port est ouvert. Cela rend les services UDP activement et significativement surveillables.
Les contrôles de santé HTTP/HTTPS prennent en charge la méthode, l'URI, une liste de headers personnalisés, le corps de la requête et l'hôte virtuel. Un endpoint API peut être sondé avec un header Authorization, un corps JSON ou un header Host personnalisé. Les codes de statut acceptables n'ont pas à être une seule valeur — 200, 204 ou 304 peuvent tous être considérés comme sains. Cette conception rapproche la vérification de santé de l'utilisation applicative réelle.
Lorsque contentCheckMode est défini à jsonata, le corps de la réponse est évalué en JSON et l'expression JSONata est exécutée. L'état du service, le résultat de dépendance, la latence de base de données ou une métrique métier peuvent tous être vérifiés dans une seule expression. Si l'expression produit un résultat vrai, le backend est sain ; un résultat faux le marque comme défaillant. Les erreurs JSONata sont journalisées afin qu'une expression incorrecte ou une structure de réponse inattendue devienne visible.
Pour les scénarios simples qui ne nécessitent pas JSONata, contentQuery effectue une recherche de texte à l'intérieur du corps de la réponse. Des chaînes marqueurs telles que « Welcome », « UP » ou « Service Ready » — ou du texte spécifique à l'application — peuvent être vérifiées rapidement. Ce mode offre une solution à faible complexité pour les endpoints de santé simples ou les applications legacy. Les opérateurs choisissent entre le contrôle basique et JSONata en fonction du scénario.
Les contrôles LDAP/LDAPS peuvent tester non seulement l'accès au port mais l'opération de bind réelle. Un bind effectué avec un nom d'utilisateur et un mot de passe valide le service d'annuaire au niveau de l'authentification. Même si le port est ouvert, un backend peut être marqué comme non sain si la queue de bind, l'autorisation ou le service a un problème. Cela fournit une visibilité critique particulièrement pour les flux AAM et d'accès en entreprise.
Les contrôles de santé Oracle prennent en charge les détails de connexion, le nom d'utilisateur, le mot de passe et les étapes de scénario. Le SQL est exécuté via executeCmd et le texte attendu ou le nombre minimum de lignes est vérifié. Au lieu d'un simple test de connexion, l'accès réel aux données et les métriques métier peuvent être interrogés. Cette approche rend la question de la disponibilité de la base de données significative du point de vue applicatif.
Les contrôles de santé opèrent conjointement avec l'intervalle, le timeout, le seuil, la composition des scénarios, l'identité des instances et les contrôles spécialisés internes au système.
testInterval est configurable de 0,5 à 3 600 secondes ; la valeur par défaut est 1 seconde. timeout est configurable de 0,01 à 3 600 secondes. Un timeout agressif permet un failover plus rapide mais peut augmenter le risque de faux positifs et doit être ajusté au comportement du service.
requiredFailure est par défaut à 2 ; requiredSuccess est par défaut à 3. Ces seuils déterminent la rapidité avec laquelle un service est retiré de la rotation et la prudence avec laquelle il est remis. Les deux côtés du seuil sont gérés indépendamment pour filtrer les fluctuations transitoires.
Un seul contrôle de santé peut combiner plusieurs contrôles atomiques en utilisant une logique AND/OR. Cela signifie que non seulement un seul résultat de sonde mais plusieurs dépendances ou étapes de protocole peuvent être évaluées ensemble. La santé complexe des services est modélisée de manière plus réaliste.
Le même contrôle de santé maintient un état séparé pour chaque backend. L'ID d'instance du contrôle de santé est différencié par contrôle et par cible. Cela signifie que même lorsque le même profil de contrôle est appliqué à plusieurs cibles, l'historique de santé de chaque cible est suivi indépendamment.
Le paramètre negate inverse la logique de succès normale. Ce mode est utilisé lorsqu'une URL spécifique est censée être inaccessible, qu'une réponse spécifique est censée ne pas être retournée, ou qu'un chemin de service est censé rester inaccessible. Une réponse réussie est traitée comme un échec ; une réponse échouée est traitée comme un succès.
Les contrôles de santé internes au système tels que les moniteurs de passerelle et les contrôles de connexion IP de cluster peuvent être générés automatiquement. Ces contrôles sont utilisés pour surveiller non seulement les backends applicatifs mais aussi la connectivité et l'accessibilité en amont autour de TR7. Le modèle peut être étendu avec des types de contrôle supplémentaires tels que les contrôles de datacenter côté GTM.
Une équipe e-commerce peut utiliser un contrôle HTTP avec JSONata pour vérifier non seulement que le service de panier retourne 200 mais aussi que la latence de base de données et les métriques de disponibilité sont dans les limites. Un backend lent ou dégradé par des dépendances est automatiquement retiré de la rotation.
Les équipes bancaires peuvent utiliser les contrôles Oracle pour aller au-delà de l'ouverture d'une connexion et exécuter réellement des requêtes SQL. Si le nombre de lignes attendu ou le résultat de la requête n'est pas satisfait, le backend est marqué comme non sain et le trafic est dirigé vers des cibles sûres.
Les applications gouvernementales peuvent vérifier qu'un service d'annuaire fonctionne non seulement au niveau du port mais via une opération de bind réelle. Si le port est ouvert mais que l'authentification échoue, le système traite cela comme un problème de santé.
Les équipes télécom peuvent exécuter de vraies requêtes d'enregistrement pour un domaine critique en utilisant un contrôle DNS. Avoir le port DNS ouvert n'est pas suffisant — le résolveur doit produire la réponse attendue pour être considéré comme sain.
Basez vos décisions de trafic sur des données de santé fiables à travers 11 protocoles, des scénarios multi-étapes et la validation de contenu JSONata. Laissez-nous vous présenter une mise en place en direct sur vos propres services.