Les logs des équilibreurs de charge classiques restent le plus souvent au niveau de l'access log de base. Status code, temps de réponse, URL, backend, TLS, score WAAP, geo-IP et contexte utilisateur peuvent résider dans des systèmes différents ou ne pas être collectés du tout. Dans ce cas, l'équipe d'exploitation doit parser des logs, écrire un tableau de bord distinct ou demander des données à différentes équipes pour comprendre le problème.
Lorsque les logs WAAP et les logs ADC sont conservés à des endroits différents, la corrélation devient difficile. Pour voir à la fois le contexte de performance et de sécurité de la même requête, il faut apparier manuellement l'ID de requête, l'horodatage, l'IP, le chemin et l'information de session. Au moment de l'incident, cette corrélation manuelle fait perdre du temps.
Dans les structures multi-tenant ou multi-vService, la rétention et le reporting deviennent aussi un problème distinct. Pendant qu'un tenant produit des logs intensifs, les données d'un autre ne doivent pas être perdues ; les applications relevant d'une réglementation critique doivent être conservées plus longtemps, tandis que le trafic web public peut être conservé avec une rétention plus courte.
La bonne approche consiste à traiter les logs au niveau de la requête L7 conjointement avec des métriques de séries temporelles. Request rate, SSL TPS, distribution des status code, WAAP attack rate, temps de réponse backend, dropped log et métriques de contrôle de santé doivent être surveillés dans la même famille de tableaux de bord.
Le Module L7 Reporting TR7 offre ce modèle : il rend visibles les données de requête L7, de WAAP, de backend, de contrôle de santé et de QoS dans une couche de tableaux de bord et de reporting intégrée.
Le L7 Reporting TR7 fonctionne avec un flux de logs enrichi, des métriques de séries temporelles, des tableaux de bord intégrés et des variables de drill-down.
TR7 porte les logs de trafic L7 et les événements WAAP dans une chaîne de reporting commune. Ainsi, les signaux de performance, d'erreur et d'attaque peuvent être examinés dans le même contexte vService.
Les métriques de request rate, status code, SSL TPS, throughput, contrôle de santé et QoS peuvent être conservées dans le temps. Cette structure peut être utilisée pour la planification de capacité, l'analyse post-incident et le suivi périodique des performances.
TR7 fournit prêts à l'emploi les panneaux d'exploitation de base avec une structure de tableau de bord vService détaillé et de tableau de bord global. Dès le premier jour, l'opérateur peut surveiller les métriques de trafic, SSL, backend, mémoire, CPU et WAAP.
Des filtres de tableau de bord peuvent être appliqués avec les variables de vService, de backend et d'hôte. On peut mener l'examen depuis une hausse des 5xx jusqu'à une URL précise, et de là jusqu'au backend ralenti.
Le Module L7 Reporting rend le trafic applicatif observable, du niveau de la requête à l'ensemble de la plateforme, avec 50+ panneaux/éléments.
Le tableau de bord détaillé montre les métriques de request rate HTTP/HTTPS, nouvelles requêtes, session requests, total connection, SSL TPS, throughput, CPU, mémoire, SSL cache et erreurs dans le contexte du vService. L'opérateur peut examiner le comportement d'une seule application sans qu'il se mêle au bruit de l'ensemble de la plateforme. Cette vue isole rapidement quel vService est affecté au moment de l'incident. Les signaux de performance et de sécurité s'interprètent sur le même écran.
Le tableau de bord global montre l'utilisation CPU moyenne, le nombre total de vServices, le nombre total de backends, l'uptime et les métriques HTTP/SSL générales. Cet écran résume l'état général de la plateforme aux équipes d'administration et d'exploitation. Dans les environnements multi-vService, on comprend rapidement quels domaines sont sous pression. Il peut servir d'écran de premier regard pour la planification de capacité.
Les panneaux Health Check Status, Health Check Time et Health Check State montrent l'état d'accessibilité et le temps de réponse des backends. Des états comme UP, DOWN ou NOCHECK peuvent être suivis dans le temps. Une hausse du temps de réponse peut signaler une dégradation des performances avant qu'une panne complète ne survienne. Ces métriques facilitent la compréhension du comportement de failover et de pool.
Les panneaux de compteurs de réponses 1xx, 2xx, 3xx, 4xx et 5xx classifient le comportement de réponse de l'application. Une hausse des 5xx peut signaler une erreur de backend ou d'application, une hausse des 4xx un effet client, bot ou WAAP. L'opérateur peut examiner d'abord la classe d'erreur, puis le détail de l'URL et du backend. Cette structure raccourcit le temps de triage d'incident.
TR7 peut synthétiser les événements d'attaque WAAP et montrer les types d'attaque au niveau d'agrégation. Au lieu de logs WAAP bruts individuels, on suit la catégorie d'attaque, l'intensité et la distribution temporelle. L'équipe sécurité voit plus rapidement quel vService fait face à quelle famille d'attaque. Cela facilite la revue SOC quotidienne et le reporting de sécurité mensuel.
La métrique `tr7_tm_vservice_waf_attack_rate` peut montrer le taux d'attaque WAAP au niveau du vService. Des hausses soudaines peuvent être le signal d'une vague de bots, d'un scan d'exploit ou d'une attaque ciblée. Interprétée conjointement avec le volume de trafic, cette métrique permet de comprendre plus précisément l'intensité de l'attaque. Elle a une grande valeur dans les scénarios d'alarme et de tableau de bord.
Côté backend, des métriques comme session, new session, response code, trafic entrant/sortant, connection error, response error, queue time, connect time, response time et total time peuvent être suivies. Cette séparation aide à comprendre si le problème se situe côté ADC, dans le réseau ou dans le backend. Par exemple, une hausse du connect_time peut être un problème de réseau ou d'acceptation de service, une hausse du response_time une latence applicative. L'analyse d'incident est menée avec plus de précision.
Lorsqu'un trafic intense ou un problème de pipeline de logs survient, le nombre de dropped logs peut augmenter. Le panneau Logs Dropped aide à surveiller la fiabilité des données d'observation. En cas de perte de logs, les interprétations du tableau de bord doivent être prises avec prudence. L'équipe d'exploitation suit non seulement le trafic, mais aussi la santé de la chaîne de mesure.
Les métriques Compress in/out montrent le comportement de compression. L'opérateur peut suivre l'impact de la compression sur le trafic dans quels vServices. Ces valeurs sont évaluées conjointement avec le coût WAN, l'expérience utilisateur et la consommation CPU. Les politiques de compression sont gérées par la donnée et non par l'intuition.
Des métriques comme `tr7_tm_vservice_memory_usage` et `tr7_tm_vservice_memory_alloc` peuvent suivre le comportement mémoire du vService. Les tendances de hausse dans le temps sont précieuses pour la planification de capacité et les analyses de fuite éventuelles. L'opérateur peut voir non seulement la panne instantanée, mais aussi la pression de capacité future. Cela assure une montée en charge planifiée pour un trafic applicatif croissant.
Des métriques comme `tr7_tm_qos_cpu_count`, `tr7_tm_qos_cpu_percent_limit` et `tr7_tm_qos_memory_limit` rendent visibles les limites de ressources de la plateforme. Ces valeurs sont surveillées conjointement avec les métriques de trafic pour comprendre la pression de ressources. Si la production d'erreurs d'un vService est liée à son approche d'une limite de ressources, elle est détectée plus rapidement. La visibilité QoS soutient les décisions de capacité et d'isolation.
TR7 peut gérer les configurations d'intervalle pour les tableaux de bord détaillé et global dans des fichiers distincts. Cela rend plus cohérent le comportement de rafraîchissement et de plage temporelle du tableau de bord. L'analyse de tendance long terme et l'analyse d'incident court terme peuvent être réalisées avec des intervalles différents. L'opérateur ajuste le timing des panneaux selon les différents scénarios d'usage.
Le L7 reporting s'opère avec le namespace de métriques, les métriques frontend/backend, le health check state, les champs QoS et les variables de tableau de bord.
Les métriques TR7 sont groupées sous le namespace `tr7_tm_*`. Cette structure facilite la distinction des métriques frontend, backend, contrôle de santé, QoS et appareil. Les règles de tableau de bord et d'alarme deviennent standard via cette nomenclature.
Les métriques de request rate, total connection, octets entrant/sortant, request error, réponses 1xx-5xx, SSL connection, SSL rate, SSL cache, compression, dropped log et mémoire peuvent être suivies côté frontend. Ces métriques expliquent le comportement du vService face à l'utilisateur. On distingue si le problème provient du trafic externe, du TLS ou du comportement de réponse.
Côté backend, les métriques de session, response code, trafic, erreur de connexion, erreur de réponse et de temps peuvent être collectées. La séparation queue, connect, response et total time est critique dans l'analyse de performance. Les problèmes d'application, de réseau et d'acceptation de service deviennent visibles via des métriques différentes.
`tr7_tm_bservice_hc_state` peut exprimer l'état de santé du backend comme UP, DOWN ou NOCHECK. `tr7_tm_bservice_hc_time` peut montrer le temps de réponse du contrôle de santé au niveau de la milliseconde. Les tendances de contrôle de santé facilitent la compréhension du comportement de failover.
Des champs QoS comme le nombre de CPU, la limite de pourcentage CPU et la limite de mémoire peuvent être portés vers le tableau de bord. Ces métriques permettent de comprendre l'effet des limites de ressources lors des moments de trafic intense. Elles soutiennent la décision de capacité en particulier dans les services multi-tenant ou à haute intensité.
Les panneaux peuvent être filtrés avec des variables comme `$vservice`, `$bservice` et `$host`. L'opérateur peut descendre du graphique global vers un vService précis, puis vers un backend précis. Ce flux de drill-down accélère l'investigation d'incident.
L'opérateur peut descendre du panneau des 5xx vers l'URL concernée, et de là vers le backend ralenti. Les métriques connect_time et response_time aident à distinguer si le problème provient du réseau ou de l'application.
L'équipe sécurité peut intégrer les métriques SSL et les valeurs de WAAP attack rate dans un rapport périodique. Ces données augmentent la visibilité des contrôles de sécurité applicative et de protection du trafic.
Une rétention plus longue peut être appliquée à un vService relevant de la santé ou d'une réglementation, et une rétention plus courte au trafic web public. Ainsi, le coût de conservation et le besoin de conformité sont équilibrés.
En suivant les tendances de memory alloc, request rate et throughput, le besoin de capacité futur peut être estimé. L'opérateur prend la décision de montée en charge non par intuition instantanée, mais avec des données de séries temporelles.
Lorsque le WAAP attack rate augmente, les catégories d'attaque peuvent être synthétisées et les vServices affectés filtrés. L'équipe SOC peut voir le type et l'intensité de l'attaque sans se perdre dans les logs bruts.
Tableaux de bord intégrés, métriques de drill-down et reporting WAAP — parcourons tout cela ensemble sur une installation en direct.