Dans le monde classique du load balancing, la santé du backend est toujours surveillée depuis la couche protocolaire. L'ADC envoie une requête HTTP au serveur, reçoit 200 OK, ajoute le serveur au pool. Ou il fait une sonde TCP, considère le serveur sain si le port est ouvert. Il fait peut-être même une vérification de contenu : « la réponse contient-elle tel mot ? ».
Cette approche regarde depuis la coque externe ; elle ne regarde pas de l'intérieur. Elle ne voit pas que le remplissage du disque du serveur atteint 98 %, que la RAM est tombée en swap et que les performances se sont effondrées, que la boucle de GC s'est allongée, que la limite de connexions de base de données est saturée. Le serveur renvoie encore HTTP 200 — mais l'utilisateur subit une attente de plusieurs secondes pour sa requête.
Pire : la sonde protocolaire est considérée comme locale, elle ne rapporte pas l'état propre du serveur. L'ADC ne voit que ce que la sonde voit. Une pression de ressources croissante sur le serveur ou la boucle de redémarrage d'un processus critique n'influence pas la décision de routing.
L'ETM Télémétrie serveur comble cet écart. L'agent sur le serveur transmet en continu son état interne à l'ADC. La décision de routing est prise non pas à partir d'une sonde protocolaire externe, mais à partir de la donnée en direct venue de l'intérieur.
TR7 ETM modélise la santé du serveur comme une entrée vivante de la couche de routing de l'ADC. Cette approche réunit la sécurité client et l'observabilité serveur sur la même plateforme.
L'agent sur le serveur mesure en temps réel la charge CPU, l'usage mémoire, la pression du swap, la saturation des IO disque et le throughput des interfaces réseau. La donnée est transmise à l'ADC à intervalles périodiques — de l'ordre de la seconde ; la décision de routing s'alimente de cette donnée à jour.
La santé des processus applicatifs critiques, les boucles de redémarrage, le temps de garbage collection, le nombre de descripteurs de fichiers ouverts, l'état du thread pool et les métriques propres à l'application (p. ex. limite de connexions de base de données) sont surveillés. Si l'application n'est pas saine, le trafic ne va pas vers ce serveur.
L'algorithme de load balancing de l'ADC peut fonctionner selon le score de santé issu de la télémétrie ETM. Un serveur à CPU élevé reçoit moins de trafic, un serveur en saturation IO est retiré des nouvelles connexions, un serveur tombé en swap est automatiquement nettoyé du pool.
Le même agent ETM utilisé pour la sécurité client fonctionne aussi sur les serveurs. L'équipe opérationnelle utilise un seul agent, une seule couche de gestion et un seul modèle de télémétrie. Il n'est pas nécessaire de déployer un outil séparé pour l'observabilité backend.
La télémétrie serveur n'est pas seulement de l'observabilité ; c'est la source de donnée en direct de la décision de routing de l'ADC.
Le nombre de CPU, la moyenne de charge continue, le pourcentage d'usage instantané et l'état thermique sont mesurés en temps réel. Une anomalie de charge par cœur ou une baisse de performance due à un thermal throttle se reflète dans la décision de routing.
La mémoire totale et disponible, l'usage du swap, le taux de page fault et l'activité de l'OOM killer sont surveillés. Un serveur tombé en swap peut être automatiquement placé dans un pool à faible priorité ; un serveur dont le risque OOM devient marqué peut être retiré du trafic.
Le taux de remplissage du disque, le temps d'attente IO, le nombre d'IOPS, le nombre de requêtes en file et le nombre d'erreurs SMART sont surveillés. Lorsque le seuil de remplissage du disque est dépassé ou que la saturation IO est élevée, le serveur est retiré du trafic.
Le fait que les processus critiques définis fonctionnent ou non, l'heure du dernier redémarrage et le nombre de boucles de restart sont surveillés. Une application redémarrée en continu est retirée du trafic ; le pool est signalé pour intervention opérateur.
Les métriques propres à l'application sur le serveur — métriques de runtime applicatif (temps de GC, latence de l'event loop), saturation de la limite de connexions de base de données, profondeur de file — peuvent être extraites via l'agent. L'ADC peut inclure ces métriques dans la décision de routing.
Le throughput des interfaces réseau du serveur, le taux de perte de paquets, le nombre de retransmit et le nombre de connexions TCP actives sont surveillés. Un serveur en saturation réseau est automatiquement signalé avec un poids faible.
La durée de validité des certificats TLS sur le serveur, l'intégrité par hash des fichiers de configuration critiques et les changements dans les magasins de certificats sont surveillés. Un certificat dont l'échéance approche émet à la fois une alerte à l'opérateur et peut être inclus dans la politique de routing.
L'écart par rapport à la baseline de configuration du serveur est capté instantanément. Un changement de configuration non autorisé, un compte utilisateur inattendu ou le démarrage d'un nouveau service parvient à l'ETM comme un événement. Ce signal se reflète à la fois dans les décisions de sécurité et d'opération.
La télémétrie ETM peut être convertie en un score de santé de 0 à 100 par serveur. L'algorithme de load balancing de l'ADC (round-robin, least-conn, weighted least-conn) peut utiliser ce score comme poids. Un serveur dont le score baisse reçoit moins de trafic ; un serveur tombant sous le seuil sort du pool.
Des signaux comme la vitesse d'augmentation du remplissage du disque, la tendance de consommation mémoire et la fréquence des restart peuvent être interprétés de façon prédictive. Alors qu'un serveur n'a pas encore échoué, le trafic est doucement retiré du serveur dont la probabilité d'échec à court terme augmente.
La télémétrie serveur est la source de donnée en direct de l'intelligence de routing de l'ADC — y compris l'intégration, la scalabilité et l'audit.
La télémétrie afflue périodiquement vers le control plane de l'ADC. L'algorithme de load balancing peut fonctionner selon le score ETM ; des décisions de routing spéciales peuvent être déclenchées selon les événements ETM. L'opérateur peut lier les métriques ETM au langage de politique sans écrire de custom script.
La sonde de santé active basée sur protocole (HTTP, TCP, Oracle) continue de fonctionner ; la télémétrie ETM ajoute à côté de cette sonde une couche de « vue interne ». La décision de routing évalue les deux sources ensemble : « répond-il ? » (sonde protocolaire) + « est-il sain ? » (ETM).
Les métriques à collecter et à quelle période peuvent être configurées selon le rôle du serveur. CPU/RAM/IO pour un serveur web, limite de connexions et query latency pour un serveur de base de données, GC et thread pool en priorité pour un serveur applicatif.
L'agent sur le serveur est conçu pour une utilisation minimale des ressources. Il fonctionne sans causer de perte de performance même sur les backends à haut throughput. L'intensité de collecte des métriques est configurable.
La télémétrie peut être transmise aux plateformes de surveillance et d'observabilité d'entreprise. Lorsque le stack d'observabilité standard de l'entreprise est préféré à l'interface de gestion propre à l'ETM, le flux de données est assuré.
La télémétrie de milliers de serveurs peut être collectée depuis un seul cluster TR7. Dans les structures multi-régions, les inventaires de serveurs de différentes régions sont visualisés depuis une seule console grâce au Central Management.
Lorsque la saturation de la limite de connexions de base de données du serveur applicatif approche, l'ETM le transmet à l'ADC. L'ADC réduit progressivement le poids de ce serveur ; les nouvelles connexions sont redirigées vers les autres serveurs. L'utilisateur ne voit pas de timeout ; le backend respire progressivement.
Lorsque le remplissage du disque d'un serveur dépasse 95 % en raison d'une sauvegarde ou d'une accumulation de logs, l'ETM produit un événement. Le serveur est automatiquement retiré du pool ; il est signalé pour intervention opérateur. Le remplissage total du disque et le crash du service sont évités.
Un serveur dont l'usage mémoire augmente en continu et dont le risque OOM est élevé peut être placé à faible poids par l'ETM avant même de planter. Le trafic est doucement déplacé vers les autres serveurs ; le problème est résolu avant de se transformer en incident.
Une validité de moins de 30 jours du certificat TLS sur le serveur est signalée à l'ETM. Une alerte parvient à l'opérateur ; jusqu'au renouvellement du certificat, le serveur peut ne pas recevoir de trafic critique ou l'alarme peut être escaladée. Le risque d'erreur de certificat surprise disparaît.
Voyons l'ETM Télémétrie serveur en direct sur votre propre backend — planifions une session d'installation sur un groupe pilote de serveurs.