Les besoins en métriques pour un gestionnaire de trafic d'entreprise sont simples : quelle est la charge du système, combien de requêtes chaque vService gère-t-il, quel backend ralentit, quel health check est DOWN, le taux d'attaques WAAP est-il en hausse ? Pourtant, dans de nombreuses architectures, répondre à ces questions signifie déployer, superviser, mettre à jour et récupérer un binaire exporteur séparé.
Le problème s'amplifie dans les architectures multi-processus et fork. Chaque worker génère ses propres statistiques ; ces chiffres doivent être fusionnés en un seul point de scraping. Si l'agrégation est mal réalisée, Prometheus se retrouve avec des métriques manquantes, des valeurs comptées en double ou des panneaux incohérents. L'équipe opérationnelle finit par gérer le pipeline de métriques comme une deuxième application.
Le côté tableau de bord a son propre coût. Connecter des données à une instance Grafana vierge n'est qu'un début — panneaux, labels, alertes, seuils et découpages par service doivent tous être construits à partir de zéro. Sans le bon modèle de labels vService, groupe de backends, état de health check et locataire, le tableau de bord ne produit que des graphiques système génériques plutôt qu'une information opérationnelle exploitable.
La discipline des types de métriques est une autre préoccupation critique. Les valeurs monotoniquement croissantes doivent être exposées comme des counters ; les lectures instantanées et les valeurs limites comme des gauges. Une attribution de type incorrecte casse les calculs de taux, les règles d'alerte et l'analyse des tendances à long terme.
L'Intégration Native Prometheus + Grafana de TR7 supprime cette charge : 50+ métriques, agrégation multi-processus, séparation correcte gauge/counter, un modèle de labels vService et backend et des fichiers JSON de tableaux de bord Grafana prêts à l'emploi font de l'observabilité une partie naturelle de la plateforme.
TR7 résout la publication de métriques via un endpoint intégré, l'agrégation des processus et un package de tableaux de bord prêts à l'emploi — aucun exporteur externe requis.
TR7 publie les métriques au format exposition Prometheus, incluant les lignes HELP et TYPE. Les valeurs gauge et counter sont présentées sous une forme directement scrapable sans configuration supplémentaire.
Les statistiques de trafic des workers fork et des processus enfants sont agrégées dans le publisher de métriques principal. Prometheus scrape un seul endpoint et reçoit la vue consolidée ; les opérateurs n'ont pas d'exporteurs par processus à gérer.
Les counters monotoniquement croissants et les gauges instantanées sont correctement typés dans le schéma. Cette séparation fournit le bon modèle de données pour les calculs de taux Prometheus, les règles d'alerte et les panneaux de tableau de bord.
TR7 fournit des fichiers JSON de tableaux de bord Grafana pour les vues globales et détaillées. Les équipes opérationnelles les importent et travaillent avec un modèle de métriques prêt pour la production plutôt que de construire les panneaux à partir de zéro.
L'Intégration Native Prometheus + Grafana regroupe les métriques device, vService, backend, QoS et health check dans un seul modèle d'observabilité.
`tr7_device_uptime` rapporte l'uptime du device par hôte en secondes. `tr7_device_cpu_detailed` expose le détail CPU par utilisateur, système, nice et irq sous forme de gauges. `tr7_device_mem_detailed` suit les valeurs de mémoire totale, active, mise en cache et tampon à la granularité MB. Ces métriques constituent la base pour corréler le comportement du trafic avec les ressources système sous-jacentes.
`tr7_tm_qos_cpu_count` rapporte le nombre de cœurs CPU alloués à un vService. `tr7_tm_qos_cpu_percent_limit` expose la limite de pourcentage CPU et `tr7_tm_qos_memory_limit` expose la limite mémoire. Ces métriques sont essentielles pour la planification de capacité et le suivi des ressources par locataire. Les opérateurs peuvent visualiser la croissance du trafic aux côtés de l'enveloppe de ressources allouées, pas seulement comme des comptages de requêtes bruts.
Au niveau du vService, les métriques comprennent l'uptime, le pourcentage d'inactivité du processus, les connexions SSL, les totaux SSL, le taux SSL, la compression in/out, les logs abandonnés, l'utilisation mémoire, la limite de session, le total de sessions, le taux de requêtes et le total de requêtes. Les comptages de codes de réponse de 1xx à 5xx sont exposés comme counters. Les totaux de connexions, bytes in/out et erreurs de requêtes clarifient le comportement du service. Ces métriques sont les données de panneau principales pour le suivi des SLA, l'analyse de capacité et le diagnostic d'erreurs.
`tr7_tm_vservice_waf_attack_rate` transporte le taux d'attaques WAAP vers le côté Prometheus. Les équipes sécurité peuvent écrire des règles d'alerte contre cette métrique et suivre les tendances d'attaques sur leurs tableaux de bord. Le volume de trafic et le taux d'attaques partagent le même modèle de labels vService, de sorte que le signal de sécurité reste connecté au contexte opérationnel.
Au niveau du backend, les métriques couvrent newsession, session, compteurs de classes de réponse, bytes in/out, erreur de connexion, erreur de réponse et état du pool de connexions. Les métriques queue time, connect time, response time et total time aident à analyser la latence du backend. Ces mesures font apparaître quel backend spécifique ralentit ou commence à générer des erreurs — rendant le comportement réel du backend visible derrière le graphique agrégé du vService.
`tr7_tm_bservice_hc_state` rapporte l'état du health check avec les labels host, vservice, bservice_group, bservice et state. UP est encodé comme 1, DOWN comme 0 et NOCHECK comme 2. Ce modèle numérique est pratique pour les règles d'alerte Prometheus — un backend DOWN peut déclencher une alerte directement. `tr7_tm_bservice_hc_time` suit également la durée du health check en millisecondes.
Le modèle de labels backend inclut un champ bservice_group qui distingue le groupe par défaut des groupes de backends assignés dynamiquement ou conditionnellement. Dans les grandes configurations vService, les opérateurs peuvent identifier quel groupe est affecté directement depuis le panneau du tableau de bord. L'équipe opérationnelle gagne en visibilité topologique plutôt qu'une liste plate de cibles.
Les métriques des processus workers TR7 sont fusionnées dans le publisher principal. Prometheus scrape un seul endpoint `/metrics` et reçoit une visibilité complète. Cela élimine le besoin de scraping par processus et d'agrégation manuelle, ce qui est particulièrement critique pour produire des tableaux de bord cohérents dans les déploiements multi-fork à fort trafic.
Les champs de métriques sans valeur ne sont pas émis. Cela empêche la pollution par des gauges null sans signification du côté Prometheus. Les panneaux du tableau de bord n'affichent que les valeurs qui existent réellement. Les champs absents de la configuration actuelle ne gonflent pas le comptage des séries de métriques.
Les packages JSON TR7_Detailed_Dashboard et TR7_Global_Dashboard peuvent être importés directement dans Grafana. Le tableau de bord global fournit une vue d'ensemble du device et des services ; le tableau de bord détaillé se concentre sur les découpages par vService et par backend. Les équipes opérationnelles n'ont pas besoin de construire les panneaux à partir de zéro. Les deux tableaux de bord sont structurés autour du modèle de labels Prometheus fourni par TR7.
L'intégration Prometheus est exploitée via des préfixes de métriques, un modèle de labels défini, la séparation des types et des codes d'état numériques pour le health check.
Les métriques du gestionnaire de trafic sont publiées sous le préfixe `tr7_tm_*`. Les métriques au niveau système utilisent le préfixe `tr7_device_*`. Cette convention de nommage facilite la localisation de la famille de métriques dans les requêtes PromQL et les sélecteurs de variables Grafana.
Les métriques vService sont publiées avec un ensemble de labels `{host, vservice}`. La valeur host provient du hostname du device. Le label vservice est utilisé pour le filtrage par service et les variables de tableau de bord Grafana.
Les métriques backend sont publiées avec un ensemble de labels `{host, vservice, bservice_group, bservice}`. Ce modèle prend en charge l'analyse au niveau du service, du groupe de backends et des cibles individuelles. Les règles d'alerte peuvent être réduites à un backend spécifique.
La métrique d'état du health check porte le label state avec les valeurs UP, DOWN ou NOCHECK. L'encodage numérique simplifie l'écriture des règles d'alerte. Les correspondances DOWN peuvent être directement liées aux définitions d'alerte Prometheus.
Les valeurs monotoniquement croissantes — req_tot, ssl_tot, session_total, comptages de codes de réponse, bytes in/out et erreurs de requêtes — sont exposées comme counters. Ces valeurs doivent être analysées avec les fonctions rate ou increase de Prometheus. Ce sont les types de métriques corrects pour l'analyse des tendances de trafic à long terme.
Les lectures instantanées — taux de requêtes, nombre de connexions actuel, valeurs limites, temps de health check, queue time, connect time et response time — sont exposées comme gauges. Les gauges reflètent l'état actuel et sont utilisées pour les règles d'alerte basées sur des seuils. Les valeurs de limite et d'utilisation peuvent être affichées côte à côte sur le même panneau de tableau de bord.
Les équipes SRE ajoutent l'endpoint `/metrics` de TR7 comme cible de scraping Prometheus. L'importation des fichiers JSON de tableaux de bord Grafana prêts à l'emploi ouvre immédiatement les vues globales et détaillées. Aucun déploiement d'exporteur séparé n'est requis.
Les équipes opérationnelles peuvent suivre `tr7_tm_vservice_memory_alloc` et les métriques mémoire associées au fil du temps. Une alerte peut se déclencher lorsque l'utilisation approche d'un seuil défini. Les décisions de capacité sont basées sur des tendances mesurées plutôt que sur des estimations.
Les équipes sécurité peuvent définir une règle d'alerte Prometheus sur `tr7_tm_vservice_waf_attack_rate`. Lorsque le taux d'attaques monte sur un vService spécifique, le workflow de gestion des incidents est déclenché. La visibilité sur le trafic et la sécurité converge sur le même tableau de bord.
Lorsque `tr7_tm_bservice_hc_state` rapporte une condition DOWN comme 0, une alerte peut être levée. L'alerte identifie la cible affectée directement via ses labels host, vservice, bservice_group et bservice. Les équipes SRE peuvent identifier quel backend est tombé sans parcourir les logs.
50+ métriques intégrées, agrégation multi-processus et fichiers JSON de tableaux de bord prêts à l'emploi. Parcourons ensemble une configuration en direct dans votre propre environnement.