Un serveur qui renvoie 200 OK n'est pas sain ; un service défaillant peut encore répondre à une sonde protocolaire externe.
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.
Notre approche
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.
CPU, RAM, IO et swap affluent en direct directement depuis le serveur
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.
Le signal de santé au niveau applicatif se combine aux métriques
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.
La décision de routing de l'ADC s'adapte en direct selon le score de ressources
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, deux extrémités, une seule vue
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.
Capacités
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.
La charge CPU, le load average par cœur et l'état thermique sont surveillés
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.
L'usage mémoire, la pression du swap et le risque OOM sont suivis
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.
Saturation du disque, temps d'attente IO et santé du système de fichiers
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.
Santé des processus, état des services en cours et boucle de redémarrage
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.
Métriques applicatives (limite de connexions de base de données, queue depth, temps de GC)
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.
Throughput des interfaces réseau, taux d'erreur et nombre de connexions
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.
Validité des certificats TLS et intégrité des fichiers critiques
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.
Configuration drift et détection de changement de configuration
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.
Le score de santé est transmis en direct à l'algorithme de l'ADC
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.
La predictive degradation signale un futur problème à partir d'anciennes métriques
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.
Profondeur opérationnelle
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.
Intégration en direct avec l'ADC
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.
Combinaison avec la sonde de santé
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).
Configuration de la période et du metric scope
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.
Faible empreinte et sensibilité aux performances
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.
Intégration SIEM et plateforme d'observabilité
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é.
Scalabilité
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.
Dans quels scénarios c'est utilisé
Lorsque la limite de connexions du serveur de base de données est saturée, la distribution du trafic change en douceur
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.
Un serveur atteignant le seuil de remplissage du disque est automatiquement retiré du pool
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.
Prédictif : le trafic est retiré d'un serveur dont la tendance de consommation mémoire est élevée
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.
Alerte automatique + politique pour un serveur dont la date de validité du certificat TLS approche
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.
Questions fréquentes
Cette fonctionnalité est-elle différente de l'active health monitoring ?
L'agent sur le serveur a-t-il un impact sur les performances ?
Quelles plateformes serveur sont prises en charge ?
Le load balancing classique continue-t-il de fonctionner sans la télémétrie ETM ?
Liez la décision de routing à l'état du serveur en direct
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.