Comprendre F5 · LTM

F5 AVR : lire les statistiques et localiser la latence

Configurer les entités collectées, comparer les membres de pool et éviter les conclusions trompeuses sur des statistiques agrégées.

Thomas SAUTIER · Publié le · Révisions de certification

Références et objectifs de certification (5)
  • Certification : F5 301A · Référence consultée le · Objectifs abordés : F5 301A 1.02.
  • Certification : F5 301B · Référence consultée le · Objectifs abordés : F5 301B 2.04, F5 301B 2.05.
  • Certification : F5CAB5 · Référence consultée le · Objectifs abordés : F5CAB5 F5CAB5.06.
  • Certification : F5CABR · Référence consultée le · Objectifs abordés : F5CABR 5.06.
  • Certification : F5CTSLTMR · Référence consultée le · Objectifs abordés : F5CTSLTMR 3.01, F5CTSLTMR 3.02, F5CTSLTMR 3.03, F5CTSLTMR 3.04, F5CTSLTMR 3.05, F5CTSLTMR 3.06, F5CTSLTMR 3.07.

Ce guide concerne BIG-IP sur TMOS. Vérifiez les noms et les options dans la documentation de votre version.

Comprendre en imageUn graphique dépend du périmètre de collecte
Un graphique dépend du périmètre de collecte Le profil Analytics détermine les données recueillies sur le Virtual Server. Les statistiques doivent être lues avec leurs unités, leur période et leur population. Une variation fait naître une hypothèse à vérifier, plutôt qu’une conclusion immédiate. analyse Passer d’une observation à une vérification Trafic du VS Population observée Profil Analytics Collecte activée Mesures Débit, requêtes, latence Validation Essai et compteurs Hypothèse Cause possible Comparaison Période et population Hausse d’erreurs sur un membre Vérification suivante: Comparer réponses HTTP,moniteur et application sur ce membre. Latence sur une seule URI Vérification suivante: Comparer méthode, taille deréponse et dépendances métier. Pic simultané sur plusieurs VS Vérification suivante: Examiner ressources BIG-IPet réseaux partagés.

Le profil Analytics détermine les données recueillies sur le Virtual Server. Les statistiques doivent être lues avec leurs unités, leur période et leur population. Une variation fait naître une hypothèse à vérifier, plutôt qu’une conclusion immédiate.

Télécharger le schéma en SVG · version claire

Un graphique dépend de ce qui a été collecté

Application Visibility and Reporting fournit des métriques applicatives et des vues par entité dans les configurations prises en charge. Pour HTTP, il faut le provisioning adapté et un profil Analytics associé au VS concerné.

Les entités collectées déterminent les dimensions disponibles : membre, URL, navigateur ou IP client selon les options. Un rapport agrégé ne prouve pas que tous les utilisateurs sont identiques ; la dimension peut ne pas avoir été collectée.

Sources : F5, Setting Up Application Statistics Collection ; F5, ltm profile analytics ; F5, sys provision.

Séparer débit, taux de requêtes et latence

TPS mesure un taux de transactions. Le débit représente un volume par unité de temps. La latence mesure une durée selon les définitions de la métrique. Un débit faible peut venir d’une faible demande, pas nécessairement d’une saturation.

Les métriques client et serveur doivent être lues selon leur périmètre F5. Ne transformez pas une « latence serveur » en temps CPU de l’application sans autre mesure. De même, le temps de chargement d’une page ne se réduit pas au temps d’une seule réponse backend.

Sources : F5, Setting Up Application Statistics Collection.

Comparer des périodes et des populations comparables

Dans cet exemple, la médiane d’une population vaut 80 ms tandis qu’un petit groupe de clients dépasse 900 ms. Une moyenne unique peut masquer ce groupe. Filtrez d’abord l’application, la période et les entités pertinentes.

Comparez les membres du même pool et les URI au même moment. Une hausse qui touche un seul membre invite à regarder ce membre ; une hausse commune nécessite d’examiner les dépendances et les chemins partagés.

Sources : F5, ltm profile analytics.

Transformer un graphique en hypothèse testable

Ces observations guident une enquête ; elles ne démontrent pas seules la cause. Corrélez avec journaux, compteurs et captures horodatées.

Passer d’une observation à une vérification
ObservationVérification suivante
Hausse d’erreurs sur un membreComparer réponses HTTP, moniteur et application sur ce membre.
Latence sur une seule URIComparer méthode, taille de réponse et dépendances métier.
Pic simultané sur plusieurs VSExaminer ressources BIG-IP et réseaux partagés.

Sources : F5, Setting Up Application Statistics Collection ; F5, sys cpu.

Relire la configuration de mesure

Les commandes montrent le provisioning, le profil Analytics et son association. Adaptez les noms. Les statistiques ne seront pas disponibles pour une dimension qui n’était pas collectée au moment du problème.

Inspecter le périmètre AnalyticsShell · commandes de lecture
tmsh list sys provision
tmsh list ltm profile analytics /Common/analytics_application all-properties
tmsh list ltm virtual /Common/vs_application all-properties

Sources : F5, ltm profile analytics ; F5, sys provision.

Définir un périmètre de collecte utile

Collecter toutes les URL et toutes les IP n’est pas toujours nécessaire au besoin. Évaluez les ressources et la granularité recherchée. Une capture applicative peut aussi contenir des données sensibles : délimitez la période et les personnes qui y accèdent.

En laboratoire, activez une dimension pertinente puis vérifiez qu’elle apparaît dans le rapport attendu. Comparez ensuite l’observation à un événement applicatif connu.

Sources : F5, ltm profile analytics.

Construire une investigation avec les filtres AVR

Fixez d’abord une période et un virtual server. Sélectionnez ensuite une dimension utile : URL, code de réponse, pool member ou source, selon les données effectivement collectées. Les filtres avancés permettent de réduire la population ; leur intérêt dépend des options du profil Analytics et de l’échantillonnage.

Pour une route lente, comparez les membres du pool dans la même fenêtre. Une latence serveur élevée sur un seul membre oriente vers ce backend ou son chemin ; un temps de chargement côté client élevé avec latence serveur stable oriente vers d’autres composantes du parcours. Les différentes métriques ne sont pas des synonymes.

Pour une suspicion d’attaque, rapprochez taux de requêtes, codes, URLs et sources, puis cherchez un événement ou une capture qui confirme le comportement. Une hausse de 4xx peut aussi venir d’une version cliente défectueuse. Si une dimension manque, vérifiez sa collecte avant de modifier le profil ; l’activer maintenant ne reconstruit pas les données anciennes.

Construire une investigation avec les filtres AVR
ObservationInterprétationContrôle suivant
Un membre plus lentDifférence backend ou cheminMême URL et même période
4xx en hausseRefus ou clients incorrectsSource, URL et événement
Dimension absenteCollecte non disponibleProfil et période de collecte

Sources : F5, Examining and exporting application statistics ; F5, Investigating server latency issues ; F5, ltm profile analytics.

Sources et portée

Les dates de consultation et les versions applicables sont précisées pour chaque référence ci-dessous. Les exemples utilisent des noms et adresses de documentation à remplacer. Les commandes de lecture affichent l’existant ; les captures et requêtes de diagnostic sont à limiter au périmètre autorisé.

Retrouver le parcours de lecture F5 LTM

Continuer la série F5

Explorer tous les guides du parcours F5 LTM

Découvrir l’expertise F5 de Samhan

Échange

Besoin d’éclaircir votre architecture F5 ?

Échangeons sur vos flux, vos contraintes de disponibilité et vos services applicatifs.