Les plateformes ADC et WAAP d'entreprise ne se résument pas à un seul processus monolithique. Les worker qui collectent les statistiques de trafic, les opérations réseau, la gestion du pare-feu, les services CLI, les processus de routing console, les collecteurs de logs et de RRD fonctionnent ensemble. Si l'un de ces processus s'arrête en silence ou fonctionne avec un mauvais profil de ressources, le problème commence sur le plan de gestion et de visibilité avant le plan de trafic.
Dans l'approche classique, la surveillance des processus est laissée à des agents externes ou à des outils de process manager génériques. Ces outils peuvent voir si le processus fonctionne ou non ; mais ils ne connaissent pas le rôle du processus au sein de TR7, le profil de ressources avec lequel il doit fonctionner ou s'il faut faire un reload ou un restart en cas d'erreur. Au final, la surveillance reste générale, l'action devient manuelle.
Dans les systèmes multi-processus basés sur Node.js, les réglages de ressources sont aussi critiques. Donner à chaque processus la même limite de heap et la même valeur de thread pool n'est pas correct. Si un processus CLI léger et un RRD collector intensif sont exécutés avec le même profil, soit il y a gaspillage de ressources, soit le processus intensif est bridé par des limites insuffisantes.
Le comportement de restart doit aussi être conçu avec soin. Un restart trop fréquent masque la cause racine ; un restart trop tardif laisse un processus défaillant agir longtemps. Sur les containers ADC qui portent le trafic, un soft reload doit d'abord être tenté, et un hard restart fallback en cas d'échec.
La Surveillance des processus TR7 garde les processus internes de la plateforme sous contrôle opérationnel grâce à des profils de performance par type de processus, une gestion des sous-processus basée sur ForkManager, une collecte de statistiques basée sur RRD et un flux de restart soft-to-hard.
TR7 traite la surveillance des processus non pas seulement comme un contrôle « le processus est-il actif ? », mais avec le type de processus, le profil de ressources et le comportement de restart.
Chaque type de processus est exécuté avec l'un des profils default, light, heavy, worker ou ioIntensive selon sa charge de travail. Les réglages de heap, semi-space et UV thread pool sont produits selon ce profil.
Les processus RRD collector collectent les événements CPU, mémoire, disque et réseau dans une logique de série temporelle. Ces données fournissent la base des écrans de surveillance, de la logique d'alarme et de l'analyse d'opération.
Les processus internes de TR7 sont lancés comme child process et suivis sous le registry ForkManager. Si un processus plante, le manager peut gérer le flux de redémarrage et l'arbre de processus est séparé sur le plan opérationnel.
Lorsque les erreurs de statistiques ADC atteignent un certain seuil, un soft reload est d'abord tenté. Si le soft reload échoue, le container est redémarré de façon contrôlée avec un hard restart fallback.
La Surveillance des processus exploite les composants internes de TR7 avec une gestion des ressources basée sur profil, un restart automatique et un suivi centralisé des processus.
TR7 utilise cinq profils de performance : default, light, heavy, worker et ioIntensive. Chaque profil possède des réglages différents de max-old-space-size, max-semi-space-size et UV thread pool. Les processus légers fonctionnent avec un heap plus faible, tandis que les processus collector intensifs sont lancés avec des ressources plus larges. Ce modèle réduit l'erreur consistant à donner une limite unique à tous les processus.
La valeur UV_THREADPOOL_SIZE est calculée selon le nombre de CPU du système. La valeur est déterminée selon la logique du double du nombre de cœurs CPU, avec un minimum de 4 et un maximum de 32. Cela évite que le thread pool reste trop petit sur les processus à forte activité I/O. En même temps, cela limite une consommation de ressources inutile par des valeurs élevées non contrôlées.
Lors du lancement des processus Node.js, la valeur max-old-space-size est fournie via le profil. Le profil default peut fonctionner avec 1024 Mo de heap, les profils light et worker avec 512 Mo, le profil heavy avec 2048 Mo, le profil ioIntensive avec 1024 Mo. Ce réglage limite l'usage mémoire des processus selon leur tâche. Les gros processus collector et les petits processus de gestion ne sont pas forcés dans le même profil mémoire.
La valeur semi-space est un paramètre de fonctionnement important qui influence le comportement du garbage collection. Des valeurs comme 8 Mo en profil light, 16 Mo en profil default, 32 Mo en profil heavy peuvent être utilisées. Cette distinction permet aux processus traitant des données intensives de fonctionner plus à l'aise, tandis que les processus légers restent avec une faible empreinte. Les réglages de ressources deviennent plus prévisibles selon le type de processus.
Les processus à forte intensité de données comme rrd-collector et rrd-websocket peuvent être liés au profil heavy. pool-stats-worker peut être exécuté avec le profil worker, network-fork avec le profil ioIntensive, frr-console et cli-server avec le profil light. Ce mapping établit un standard opérationnel et réduit le risque de mauvais choix de profil. Lorsqu'un nouveau processus est ajouté, le profil auquel il sera lié est clairement défini.
Le flux buildExecArgv produit les arguments de fonctionnement Node.js nécessaires à partir des valeurs du profil lors du lancement du processus. Des paramètres comme max-old-space-size et max-semi-space-size ne sont pas laissés à une édition manuelle en ligne de commande. Cela améliore la cohérence du déploiement. Différents environnements produisent un comportement similaire en utilisant les mêmes définitions de profil.
Le flux buildEnvVars produit les réglages d'environnement comme UV_THREADPOOL_SIZE selon le profil du processus. La bonne valeur de thread pool est importante pour la performance et la stabilité, notamment sur les processus à forte intensité I/O. Cette approche réduit le besoin de l'administrateur système de gérer un fichier d'environnement séparé pour chaque processus. Le comportement des ressources est lié au modèle de profil centralisé.
Les familles de processus comme network_fork, firewall_fork et stat_fork sont suivies sous l'infrastructure ForkManager. Chaque sous-processus fonctionne comme un child process indépendant. En cas de plantage ou de sortie inattendue, le manager peut exécuter le flux de redémarrage et de mise à jour d'état. Cette structure évite que les services internes restent invisibles au sein d'un seul processus principal.
Les événements de gestion des processus peuvent être surveillés via un canal de log distinct. Les événements de démarrage, d'arrêt, d'erreur, de restart et d'internal exception sont enregistrés de manière à pouvoir être examinés par l'équipe opérationnelle. Ces enregistrements facilitent l'analyse de cause racine sur les problèmes de processus récurrents. La surveillance ne se limite pas à l'état instantané, le comportement passé peut aussi être examiné.
Lorsque les compteurs d'erreurs de stat ADC atteignent un certain seuil, le système peut lancer un flux d'amélioration automatique. La première étape est un soft reload ; en cas d'échec, un hard restart fallback est appliqué. Ce comportement aide les pannes runtime temporaires à se rétablir sans attendre d'intervention manuelle. Les situations qui se répètent en continu nécessitent en outre un examen opérationnel.
La surveillance des processus s'exploite avec les valeurs de profil, le mapping de type de processus, les limites du UV thread pool, la gestion des fork et le comportement de restart.
Le profil default peut être utilisé pour les processus à usage général avec 1024 Mo de heap et 16 Mo de semi-space. La valeur du UV thread pool suit la valeur par défaut calculée selon le nombre de CPU. Il fournit un point de départ équilibré pour les processus sans besoin spécifique défini.
Le profil light fonctionne avec des valeurs de ressources plus faibles comme 512 Mo de heap et 8 Mo de semi-space. Il convient aux processus légers comme FRR console et CLI server. Ce profil réduit une consommation mémoire inutile.
Le profil heavy est réservé aux processus collector intensifs avec 2048 Mo de heap et 32 Mo de semi-space. Il peut être utilisé sur les processus traitant plus de données comme rrd-collector et rrd-websocket. La limite supérieure du UV thread pool peut monter jusqu'à 32.
Le profil worker est utilisé pour des processus plus étroits et orientés tâche avec 512 Mo de heap. La valeur du UV thread pool peut être ajustée avec un minimum de 8 et selon le nombre de CPU, la limite supérieure étant tenue de façon plus contrôlée. Il peut être préféré sur des processus comme pool-stats-worker.
Le profil ioIntensive est utilisé pour les processus à dominante I/O avec 1024 Mo de heap. Le UV thread pool est agrandi selon le nombre de cœurs CPU et peut monter jusqu'à la limite supérieure de 32. Il convient aux travaux à dominante réseau et I/O comme network-fork.
La structure PROCESS_TYPE_PROFILES lie les types de processus au profil de performance correspondant. rrd-collector peut être mappé sur heavy, pool-stats-worker sur worker, network-fork sur ioIntensive, frr-console sur light et cli-server sur light. Ce mapping établit un standard opérationnel.
Si pool-stats-worker subit une pression de ressources après une nouvelle fonctionnalité, le profil du processus peut être déplacé de worker vers un profil plus adapté. Les valeurs de heap et de UV thread pool sont mises à jour avec le modèle de profil centralisé. L'équipe opérationnelle n'a pas à éditer un par un les arguments de runtime.
Si les erreurs de statistiques ADC dépassent un certain seuil, TR7 peut tenter un soft reload automatique. Si le soft reload réussit, le processus se rétablit en réduisant l'impact sur le trafic. En cas d'échec, un hard restart fallback est appliqué.
L'équipe d'opération réseau peut évaluer la santé du processus concerné dans un seul flux d'opération avec l'état des processus, les commandes système et les sorties de surveillance. L'état des network fork, firewall fork ou processus collector accélère l'examen de l'incident.
Après un failover ou une maintenance, on peut examiner depuis les enregistrements d'opération quels processus ont redémarré et quand. Ces enregistrements sont utilisés pour l'analyse d'interruption et les processus de change management. Les restart de processus individuels peuvent être corrélés au comportement global du système.
Limites de ressources basées sur profil, flux de restart automatique et visibilité centralisée des processus. Faisons-vous une visite guidée d'une installation en direct dans votre propre environnement.