Introduction

Lorsque la production tombe en panne, trois questions importent : Que s'est-il passé ? Quand cela s'est-il passé ? Pourquoi cela s'est-il passé ?

En pratique, les réponses sont souvent dispersées : les métriques à un endroit, les journaux de trafic à un autre, et l'historique des modifications ailleurs.

Il y a une autre réalité : les exportations vers les systèmes externes sont généralement sélectives. Si le signal dont vous avez besoin lors d'un incident n'a jamais été sélectionné pour l'exportation, vous ne l'aurez pas.

L'approche de TR7 est claire : les intégrations d'exportation sont importantes, mais l'investigation ne doit pas dépendre uniquement d'elles. C'est pourquoi TR7 conserve les signaux critiques sur l'appliance, alignés sur une chronologie unique.

Un signal qui n'est pas capturé est un risque qui reste invisible.

Pourquoi l'exportation seule ne suffit-elle pas ?

Les plateformes SIEM, serveurs de journaux et Prometheus/Grafana sont précieuses pour la visibilité d'entreprise. Cependant, le succès de l'investigation dépend de la disponibilité des bonnes données au moment où vous en avez besoin.

La collecte sélective est inévitable

Les coûts et le bruit signifient que toutes les métriques/journaux ne sont pas exportés. Lorsqu'un incident se produit, le signal critique peut manquer.

La corrélation devient plus difficile avec la dispersion des données

Lorsque les métriques, événements, audit et journaux de trafic sont à différents endroits, construire une chronologie unique prend plus de temps.

Le pipeline est une autre zone à risque

Les problèmes d'agent, de réseau, de quota/limite ou d'indexation peuvent causer une perte de données, surtout pendant les incidents.

Prêt pour l'investigation

Consacrez du temps à résoudre, pas à collecter des données. TR7 maintient les signaux critiques prêts sur l'appliance.

Dynamic Flow Panel : visibilité runtime et point de départ rapide

Dans l'interface de TR7, la topologie des services peut être surveillée en direct (runtime) via le Dynamic Flow Panel. Contrôle complet →

Le panneau affiche l'état du service avec des couleurs. Par exemple, si la liaison d'interface servant l'IP d'un vService tombe en panne, le système génère un avertissement et le nom du service passe du vert au jaune.

Cela permet aux opérateurs de voir immédiatement ce qu'il faut investiguer. Le triage commence plus rapidement et le temps d'investigation diminue.

Couleurs d'état

Les couleurs dans le Flow Panel vous aident à lire rapidement l'état du service :

Vert : Normal

Les connexions de service et les vérifications de santé fonctionnent comme prévu.

  • Tous les backends sains
  • Liaisons d'interface actives
  • Vérifications de santé réussies
Surveillance de routine
Jaune : Attention

Il y a une condition qui nécessite une surveillance.

  • Liaison d'interface inactive (le service peut toujours fonctionner)
  • Échec d'une vérification de santé backend
  • Approche du seuil de ressources
Vérification rapide via métriques + notification + audit
Rouge : Critique

Il y a un problème affectant le service.

  • Backends en panne
  • vService inaccessible
  • Erreur de configuration critique
Triage rapide : métrique + événement + audit

Exemples de scénarios d'investigation

Les exemples suivants montrent comment une investigation typique progresse sur TR7.

Scénario A : Augmentation de la latence

  • Plainte : 'L'application est lente'
  • Vérifier la tendance du temps de réponse vService → Y a-t-il des pics ?
  • Vérifier la distribution du temps de réponse backend → Quel backend est lent ?
  • Vérifier avec les vérifications de santé et les distributions de connexion
  • Y a-t-il des alertes de ressources dans les journaux de notification pendant la même période ?
  • Piste d'audit : Y a-t-il eu des changements récents ?
  • Résultat : Couche LB ou backend spécifique — rapidement clarifié

Scénario B : Augmentation des blocages WAF

  • Plainte : 'Les soumissions de formulaires échouent'
  • Vérifier la métrique de blocage WAF → Y a-t-il des pics ?
  • Trouver la règle déclenchée dans les journaux HTTP/WAF
  • Déterminer à partir des détails de la requête : faux positif ou attaque réelle ?
  • Piste d'audit : Y a-t-il eu des changements de règle/politique ?
  • Utiliser le débogage ciblé si nécessaire pour inspecter uniquement le trafic pertinent
  • Résultat : Ajustement de règle ou action de sécurité — décider avec des données

Aperçu de l'appareil : point de départ de l'investigation

L'investigation d'incident commence toujours par l'aperçu de l'appareil. CPU, mémoire, utilisation du disque et santé du système — évaluez l'état global de l'appareil d'un coup d'œil. La sélection de plage de temps permet une forensics rétrospective.

Tableau de bord système TR7 - métriques d'aperçu de l'appareil
Résumé système : Temps de fonctionnement, total des requêtes, charge CPU, mémoire, bande passante — évaluer rapidement l'état de l'appareil lors d'un incident.
Surveillance disque TR7 - métriques d'utilisation et d'E/S
Disque et E/S : Utilisation, inode, latence, IOPS — l'écriture de journal ou les performances du cache sont-elles affectées ?

Service et backend : métriques de performance et de santé

Après l'aperçu du système, descendez au niveau de la couche service. Distribution des requêtes de tous les vServices, codes de réponse, santé backend et topologie de service via le Dynamic Flow Panel — tout d'un coup d'œil. Chaque vService a son propre tableau de bord.

Aperçu des vServices TR7
Aperçu vService : Distribution des requêtes et codes de réponse (2xx/3xx/4xx/5xx) sur tous les services — quel service présente des anomalies ?
Tableau de bord vService TR7 - résumé du service et panneau de flux
Résumé vService : Temps de fonctionnement, requêtes frontend, nombre de blocages WAF et Dynamic Flow Panel — état actuel du service.
Métriques personnalisables vService TR7
Métriques personnalisables : Réutilisation SSL, compression, taux de succès du cache — ajouter les métriques nécessaires pour l'investigation.
Métriques backend TR7 - distribution des requêtes et santé
Distributions backend : Quel backend est lent ? Lequel reçoit plus de requêtes ? Métriques de temps de réponse et de connexion.

Réseau et interface : état de connexion et flux de trafic

Le problème est-il dans le service ou dans le réseau ? La topologie, la bande passante, la distribution de l'état TCP et les métriques d'interface répondent à cette question. Les changements d'état de liaison et les erreurs de paquets révèlent rapidement les problèmes de la couche réseau.

Surveillance réseau TR7 - topologie et états TCP
Topologie réseau : Bande passante, distribution de l'état TCP — premier indice pour séparer les problèmes de service et de réseau.
Tableau de bord résumé réseau TR7 - bande passante et paquets d'interface
Métriques d'interface : Bande passante RX/TX, nombre de paquets, erreurs — performances et santé de la liaison.
Métriques réseau vService TR7
Réseau vService : Débit et états de connexion par service — le modèle de trafic est-il normal ?

Journaux HTTP et WAF : investigation au niveau requête

Le trafic HTTP et les événements WAF sont visibles sans activer le débogage. Si nécessaire, le débogage ciblé capture les détails complets uniquement pour un host/path/header spécifique. Forensics au niveau requête sans impact sur la production.

Journaux HTTP TR7 - détails de requête et codes de réponse
Journaux HTTP : IP source, destination, code de réponse, taille, durée — visibilité de base même avec débogage désactivé.
Journaux de débogage HTTP TR7 - informations complètes d'en-tête
Débogage ciblé : En-têtes et cookies complets pour le trafic pertinent uniquement — détails sans impact sur la production.
Journaux WAF TR7 - analyse IA pour la détection d'attaque
Journaux WAF : Règle déclenchée, détails de requête, analyse alimentée par IA — données pour l'évaluation des faux positifs.

Intelligence IP et WAF : profil de menace

Les scores de réputation IP et les métriques WAF révèlent rapidement le profil de l'attaquant. La première réponse à 'faux positif ou attaque réelle ?' est ici. Les catégories de menaces (botnet, proxy, VPN, Tor) montrent la nature de l'IP source.

Intelligence IP TR7 - scores de réputation IP et catégories de menaces
Intelligence IP : Score de réputation, catégories de menaces — le profil de l'attaquant devient rapidement clair.
Tableau de bord WAF TR7 - requêtes bloquées et distribution d'inspection
Métriques WAF : Tendance de blocage, distribution d'inspection — aperçu des événements de sécurité.

Chronologie des événements : notifications et piste d'audit

Les métriques seules ne suffisent pas. Quelles alertes ont été déclenchées ? Qui a changé quoi et quand ? Dans l'investigation d'incident, 'quel changement a affecté quoi ?' est critique. TR7 conserve ensemble les enregistrements de notification/événement et la piste d'audit, accélérant cette corrélation.

Types de notifications TR7 - configuration des alertes
Types de notifications : CPU, mémoire, disque, bande passante, état du service — quels événements sont surveillés ?
Journaux de notifications TR7 - historique des événements
Historique des notifications : Chronologie des alertes déclenchées — quels avertissements sont arrivés pendant l'incident ?
Journaux utilisateur TR7 - piste d'audit
Piste d'audit : Qui a changé quoi, quand ? Preuve pour corréler rapidement les incidents avec les changements.

Console Web : vérifier l'hypothèse

Les métriques fournissent une hypothèse ; parfois des commandes sont nécessaires pour la vérification. Exécutez ping, traceroute, curl, tcpdump depuis la Console Web. Pas de SSH requis — les résultats apparaissent sur le même écran.

Console Web TR7 - CLI interactif
Console Web : Commandes de diagnostic depuis l'interface web — connectivité backend, DNS, vérification de route effectuée rapidement.
Console Web TR7 - exemple de sortie de commande
Sortie de commande : Résultats affichés instantanément — exemple de capture de trafic ciblé avec tcpdump.

Console Web et CLI TR7 : diagnostics instantanés et collecte de preuves depuis l'interface

L'investigation sur TR7 ne s'arrête pas aux graphiques. La Console Web permet d'exécuter les commandes système et réseau les plus nécessaires depuis l'interface web en production. Pas de SSH requis. Le CLI TR7 apporte la même capacité à la ligne de commande ; les formats de sortie (JSON/CSV/tab) et les commandes pipe rendent les étapes d'investigation reproductibles.

Vérification réseau : ping, traceroute, dig, iftop

Vérifier la connectivité backend, la résolution DNS, l'analyse de chemin et la distribution de bande passante en temps réel depuis l'appliance.

Capture de trafic ciblé : tcpdump, ssldump

Capturer des paquets pour un host/port spécifique. Inspecter les poignées de main TLS. Enregistrer uniquement le trafic pertinent dans un fichier.

Test backend : curl, wrk

Mesurer le code de réponse et le temps backend du point de vue de l'ADC. Exécuter des tests de charge contrôlés si nécessaire.

État système : netstat, ps, df, journalctl

Afficher les états TCP, les processus, l'utilisation du disque et les journaux système depuis un seul écran.

Console Web : exemples de flux d'investigation

Vous avez repéré un avertissement dans le Flow Panel. Les flux suivants sont des exemples pratiques pour un triage rapide.

Timeout backend ou problème réseau ?

  • Les métriques montrent un timeout
  • ping backend-ip → Est-il accessible ?
  • curl -I http://backend:8080/health → Quel est le code de réponse ?
  • traceroute backend-ip → Y a-t-il des coupures le long du chemin ?
  • Résultat : Réseau ou application — séparé rapidement

Erreur TLS : client ou serveur ?

  • Erreur de connexion SSL existe
  • ssldump -i wan0 host client-ip → Capturer la poignée de main
  • Identifier la non-concordance de certificat, protocole ou chiffrement
  • Résultat : Configuration client ou serveur — prouvé avec des paquets

Pic de trafic soudain : attaque ou charge réelle ?

  • Le nombre de requêtes a soudainement augmenté
  • iftop -i wan0 → Voir les top talkers en temps réel
  • netstat -an | grep ESTABLISHED | wc → Nombre de connexions
  • tcpdump -c 1000 port 443 | to-file spike.pcap → Capture d'échantillon
  • Résultat : DDoS, bot ou trafic légitime — décider avec des données

Backend 'rapide' mais l'utilisateur dit 'lent'

  • L'équipe d'application ne voit aucun problème
  • curl -w '%{time_total}' http://backend/api → Temps du point de vue de l'ADC
  • wrk -t2 -c10 -d10s http://backend/api → Test sous charge
  • Résultat : Chaîne Client–ADC–backend — la différence devient claire

N'activez pas le débogage — ciblez-le.

Bibliothèque de métriques : surveillance rétrospective et graphiques d'analyse

Les titres ci-dessous sont les titres de groupes de graphiques de métriques dans l'interface de TR7. Chaque groupe contient des graphiques où les métriques associées peuvent être surveillées et analysées rétrospectivement. Ces graphiques vous permettent d'examiner des plages de temps spécifiques pendant ou après un incident, de voir les tendances et de détecter les anomalies.

Total de requêtes Frontend
Total de requêtes
What?Affiche le nombre total de requêtes HTTP/HTTPS vers le service au fil du temps.
Why important?Référence fondamentale pour comprendre les pics de trafic, les chutes soudaines et l'impact sur la capacité. Permet la comparaison avant/après incident.
Distribution des codes d'état Frontend
Distribution des codes d'état
What?Affiche la distribution des codes de réponse HTTP (2xx succès, 3xx redirection, 4xx erreur client, 5xx erreur serveur) au fil du temps.
Why important?Repérer rapidement les augmentations du taux d'erreur. Un pic 5xx peut indiquer des problèmes backend ; un pic 4xx peut indiquer des problèmes côté client ou de configuration.
Nouvelles connexions Frontend
Nouvelles connexions
What?Affiche les nouvelles connexions TCP ouvertes par seconde.
Why important?Une augmentation soudaine des connexions peut indiquer des attaques DDoS, une activité de bot ou des problèmes de reconnexion côté client.
Sessions concurrentes Frontend
Sessions concurrentes
What?Affiche le nombre de sessions actives simultanément.
Why important?Aide à comprendre à quel point vous êtes proche des limites de capacité. L'approche des limites de session peut causer une dégradation des performances.
Débit Frontend
Débit
What?Affiche le volume total de données passant par le service (bits/sec ou octets/sec).
Why important?Utilisé pour comprendre l'utilisation de la bande passante et les tendances de trafic. Les chutes de débit peuvent indiquer des problèmes réseau ou backend.
Connexions concurrentes SSL
Concurrence SSL
What?Affiche le nombre de connexions TLS chiffrées actives simultanément.
Why important?Les opérations SSL/TLS sont gourmandes en CPU ; cette métrique est critique pour la planification de capacité et l'analyse des performances.
Nouvelles connexions SSL (TPS)
TPS poignée de main TLS
What?Affiche les poignées de main TLS effectuées par seconde.
Why important?Une augmentation soudaine du taux de poignée de main peut indiquer que la réutilisation de session ne fonctionne pas ou des problèmes côté client. Des taux de poignée de main élevés augmentent la charge CPU.
Réutilisation de session SSL
Réutilisation de session SSL
What?Affiche le taux de réutilisation de session TLS et les statistiques.
Why important?Une faible réutilisation de session cause une utilisation CPU inutile et une latence plus élevée. Cette métrique guide l'optimisation des performances TLS.
Compression
Compression
What?Affiche le taux de compression de réponse HTTP et le volume de données compressées.
Why important?La compression économise la bande passante mais utilise du CPU. Comprendre cet équilibre est important pour l'optimisation des performances.
Requêtes bloquées WAF
Requêtes bloquées WAF
What?Affiche le nombre de requêtes bloquées par le Web Application Firewall au fil du temps.
Why important?Une augmentation soudaine des blocages peut indiquer une vague d'attaque ou une nouvelle règle produisant des faux positifs. Dans les deux cas, une investigation est nécessaire.
Requêtes d'attaque détectées WAF
Attaques détectées WAF
What?Affiche le nombre et les types de tentatives d'attaque détectées par le WAF.
Why important?Permet de suivre le niveau de menace et les tendances d'attaque. Comprendre quels types d'attaque sont tentés et à quelle fréquence est précieux pour la stratégie de sécurité.
Distribution d'inspection WAF
Distribution d'inspection WAF
What?Affiche quelle proportion de règles et catégories WAF sont déclenchées.
Why important?Montre quels ensembles de règles sont actifs et lesquels se déclenchent le plus souvent. Données fondamentales pour les décisions d'ajustement et d'optimisation de règles.
Bande passante Frontend
Bande passante
What?Affiche la bande passante entrante et sortante utilisée par le service.
Why important?Utilisé pour surveiller la saturation de liaison et les changements de débit. L'approche des limites de bande passante peut causer des problèmes de performances.
Intégrations : disponibles, mais l'investigation n'en dépend pas

TR7 peut s'intégrer à l'écosystème de surveillance et de gestion de journaux de votre organisation. La différence critique : l'investigation d'incident ne dépend pas uniquement des pipelines externes. Les systèmes externes ajoutent de la valeur ; les enregistrements sur l'appliance servent de référence fondamentale.

Questions fréquemment posées

L'objectif est d'avoir les données nécessaires à l'investigation toujours prêtes sur l'appliance. L'exportation externe et l'archivage centralisé sont pris en charge. Cependant, le succès de l'investigation ne dépend pas uniquement de la configuration d'exportation.

L'objectif n'est pas de tout regarder tout le temps. Les catégories, la recherche et le filtrage vous permettent d'atteindre rapidement le bon signal lorsque nécessaire.

L'objectif de la Console Web n'est pas un accès non restreint mais des diagnostics contrôlés. Lorsqu'elle est utilisée avec une autorisation appropriée et des runbooks, elle raccourcit le temps d'investigation.

Il est en temps réel. Les états de service sont surveillés au runtime et les changements sont immédiatement reflétés comme des changements de couleur. De plus, des enregistrements de métriques et d'événements rétrospectifs sont conservés.

Le débogage normal capture généralement tout le trafic et nécessite un filtrage par la suite. Le débogage ciblé capture les enregistrements uniquement pour un host, port, path ou header spécifique dès le départ. Cela réduit le bruit, accélère l'investigation et minimise l'impact sur la production.

TR7 prend en charge l'exportation Prometheus et le transfert de journaux SIEM. Les intégrations conservent leur valeur. La différence : les données nécessaires à l'investigation ne dépendent pas uniquement des systèmes externes — elles sont aussi prêtes sur l'appliance.

La période de rétention est configurable. Ce qui compte, c'est que les actions utilisateur et les changements de configuration sont conservés sur la même chronologie que les métriques et les enregistrements d'événements.

Le détail est une préparation, pas une complexité. Même dans les petites équipes, atteindre rapidement les bonnes données lors d'un incident fait gagner du temps. La structure catégorisée et les fonctionnalités de recherche facilitent la concentration uniquement sur les données nécessaires.

Conclusion

L'affirmation de TR7 n'est pas 'plus de graphiques' — c'est de rendre la couche ADC/WAF prête pour l'investigation. Les métriques vService/backend/interface, les enregistrements d'événements/notifications, la piste d'audit et la visibilité HTTP/WAF se combinent sur une chronologie unique ; la forensics rétrospective et le débogage ciblé accélèrent l'analyse des causes profondes.

Les intégrations d'exportation sont précieuses ; mais pour minimiser le risque 'n'a pas été envoyé, donc n'existe pas' pendant les moments critiques, la chaîne de preuves doit rester accessible à l'intérieur du produit en permanence.

Ces capacités et d'autres similaires — des détails qui n'apparaissent pas sur les fiches techniques, sont difficiles à saisir dans les démos, mais définissent la qualité opérationnelle en pratique — sont la raison principale pour laquelle presque toutes les organisations qui évaluent TR7 décident de faire le changement.

La différence se montre quand vous l'utilisez.

Demander une démo en direct