Citrix ADC

AppFlow

October 4, 2021

Contributeur:

L’appliance Citrix ADC est un point central de contrôle pour tout le trafic d’application dans le datacenter. Il recueille des informations de flux et de session utilisateur utiles pour la surveillance des performances des applications, l’analyse et les applications décisionnelles. Il recueille également des données sur les performances des pages Web et des informations sur les bases de données. AppFlow transmet les informations à l’aide du format IPFIX (Internet Protocol Flow Information Export), qui est un standard ouvert Internet Engineering Task Force (IETF) défini dans la RFC 5101. IPFIX (la version standardisée de NetFlow de Cisco) est largement utilisé pour surveiller les informations de flux réseau. AppFlow définit de nouveaux éléments d’information pour représenter les informations au niveau de l’application, les données de performances des pages Web et les informations de base de données.

En utilisant UDP comme protocole de transport, AppFlow transmet les données collectées, appelées enregistrements de flux, à un ou plusieurs collecteurs IPv4. Les collecteurs regroupent les enregistrements de flux et génèrent des rapports en temps réel ou historiques.

AppFlow fournit une visibilité au niveau des transactions pour les flux HTTP, SSL, TCP, SSL_TCP et HDX Insight. Vous pouvez échantillonner et filtrer les types de flux que vous souhaitez surveiller.

Remarque

Pour plus d’informations sur HDX Insight, consultez HDX Insight.

AppFlow utilise des actions et des stratégies pour envoyer des enregistrements pour un flux sélectionné à un ensemble de collecteurs spécifique. Une action AppFlow spécifie quel ensemble de collecteurs reçoivent les enregistrements AppFlow. Les stratégies basées sur des expressions avancées peuvent être configurées pour sélectionner les flux pour lesquels des enregistrements de flux sont envoyés aux collecteurs spécifiés par l’action AppFlow associée.

Pour limiter les types de flux, vous pouvez activer AppFlow pour un serveur virtuel. AppFlow peut également fournir des statistiques pour le serveur virtuel.

Vous pouvez également activer AppFlow pour un service spécifique, représentant un serveur d’applications, et surveiller le trafic vers ce serveur d’applications.

Remarque : Cette fonctionnalité est prise en charge uniquement sur les versions Citrix ADC nCore.

Fonctionnement d’AppFlow

Dans le scénario de déploiement le plus courant, le trafic entrant circule vers une adresse IP virtuelle (VIP) sur l’appliance Citrix ADC et est équilibré de charge vers un serveur. Le trafic sortant circule du serveur vers une adresse IP mappée ou de sous-réseau sur le Citrix ADC et du VIP vers le client. Un flux est une collection unidirectionnelle de paquets IP identifiés par les cinq tuples suivants : SourceIP, SourcePort, DesTip, DestPort et protocole.

La figure suivante décrit le fonctionnement de la fonctionnalité AppFlow.

Figure 1. Séquence de flux Citrix ADC

Séquence de flux

Comme le montre la figure, les identificateurs de flux réseau pour chaque étape d’une transaction dépendent de la direction du trafic.

Les différents flux qui forment un enregistrement de flux sont les suivants :

Flow1: <Client-IP, Client-Port, VIP-IP, VIP-port, Protocol>

Flow2: <NS-MIP/SNIP, NS-port, Server-IP, Server-Port, Protocol>

Flow3: <Server-IP, Server-Port, NS-MIP/SNIP, NS-Port, Protocol>

Flow4: <VIP-IP, VIP-port, Client-IP, Client-Port, Protocol>

Pour aider le collecteur à lier les quatre flux d’une transaction, AppFlow ajoute un élément transactionID personnalisé à chaque flux. Pour la commutation de contenu au niveau de l’application, telle que HTTP, il est possible qu’une connexion TCP client unique soit équilibrée sur différentes connexions TCP back-end pour chaque requête. AppFlow fournit un ensemble d’enregistrements pour chaque transaction.

Enregistrements de flux

Les enregistrements AppFlow contiennent des informations standard NetFlow ou IPFIX, telles que les horodatages pour le début et la fin d’un flux, le nombre de paquets et le nombre d’octets. Les enregistrements AppFlow contiennent également des informations au niveau de l’application (telles que les URL HTTP, les méthodes de requête HTTP et les codes d’état de réponse, le temps de réponse du serveur et la latence). Données de performances des pages Web (telles que le temps de chargement de la page, le temps de rendu de la page et le temps passé sur la page). Et les informations de base de données (telles que le protocole de base de données, l’état de réponse de la base de données et la taille de la réponse Les enregistrements de flux IPFIX sont basés sur des modèles qui doivent être envoyés avant d’envoyer des enregistrements de flux.

Modèles

AppFlow définit un ensemble de modèles, un pour chaque type de flux. Chaque modèle contient un ensemble d’éléments d’information standard (IE) et d’éléments d’information spécifiques à l’entreprise (EIE). Les modèles IPFIX définissent l’ordre et les tailles des éléments d’information (Internet Explorer) dans l’enregistrement de flux. Les modèles sont envoyés aux collecteurs à intervalles réguliers, comme décrit dans la RFC 5101.

Un modèle peut inclure les EIE suivants :

ID de transaction

Numéro 32 bits non signé identifiant une transaction au niveau de l’application. Pour HTTP, il correspond à une paire de requêtes et de réponses. Tous les enregistrements de flux qui correspondent à cette paire demande et réponse ont le même ID de transaction. Dans le cas le plus courant, quatre uniflow enregistrements correspondent à cette transaction. Si Citrix ADC génère la réponse par lui-même (servie à partir du cache intégré ou par une stratégie de sécurité), il peut y avoir seulement deux enregistrements de flux pour cette transaction.
connectionID

Numéro 32 bits non signé identifiant une connexion de couche 4 (TCP ou UDP). Les flux Citrix ADC sont bidirectionnels, avec deux enregistrements de flux distincts pour chaque direction du flux. Cet élément d’information peut être utilisé pour relier les deux flux.

Pour Citrix ADC, un ID de connexion est un identificateur de la structure de données de connexion permettant de suivre la progression d’une connexion. Dans une transaction HTTP, par exemple, un ID de connexion donné peut avoir plusieurs éléments TransactionID correspondant à plusieurs requêtes effectuées sur cette connexion.
tcpRTT

Temps de trajet aller-retour, en millisecondes, mesuré sur la connexion TCP. Il peut être utilisé comme mesure pour déterminer la latence du client ou du serveur sur le réseau.
httpRequestMethod

Numéro 8 bits indiquant la méthode HTTP utilisée dans la transaction. Un modèle d’options avec le mappage numéro-méthode est envoyé avec le modèle.
httpRequestSize

Numéro 32 bits non signé indiquant la taille de la charge utile de la requête.
httpRequestURL

URL HTTP demandée par le client.
httpUserAgent

Source des requêtes entrantes vers le serveur Web.
httpResponseStatus

Numéro 32 bits non signé indiquant le code d’état de la réponse.
httpResponseSize

Numéro 32 bits non signé indiquant la taille de la réponse.
httpResponseTimeToFirstByte

Numéro 32 bits non signé indiquant le temps nécessaire pour recevoir le premier octet de la réponse.
httpResponseTimeToLastByte

Numéro 32 bits non signé indiquant le temps nécessaire pour recevoir le dernier octet de la réponse.
flowFlags

Indicateur 64 bits non signé utilisé pour indiquer différentes conditions de flux.

EIE pour les données de performance des pages Web

clientInteractionStartTime

Heure à laquelle le navigateur reçoit le premier octet de la réponse pour charger les objets de la page tels que des images, des scripts et des feuilles de style.
clientInteractionEndTime

Heure à laquelle le navigateur a reçu le dernier octet de réponse pour charger tous les objets de la page tels que les images, les scripts et les feuilles de style.
clientRenderStartTime

Heure à laquelle le navigateur commence à rendre la page.
clientRenderEndTime

Heure à laquelle un navigateur a terminé le rendu de la page entière, y compris les objets incorporés.

EIE pour l’information sur les bases de données

dbProtocolName

Numéro 8 bits non signé indiquant le protocole de base de données. Les valeurs valides sont 1 pour MS SQL et 2 pour MySQL.
dbReqType

Numéro 8 bits non signé indiquant la méthode de requête de base de données utilisée dans la transaction. Pour MS SQL, les valeurs valides sont 1 pour QUERY, 2 pour TRANSACTION et 3 pour RPC. Pour connaître les valeurs valides pour MySQL, consultez la documentation MySQL.
dbReqString

Indique la chaîne de requête de base de données sans l’en-tête.
dbRespStatus

Numéro 64 bits non signé indiquant l’état de la réponse de la base de données reçue du serveur Web.
dbRespLength

Nombre 64 bits non signé indiquant la taille de la réponse.
dbRespStatString

Chaîne d’état de réponse reçue du serveur Web.

La version officielle de ce document est en anglais. Certains contenus de la documentation Citrix ont été traduits de façon automatique à des fins pratiques uniquement. Citrix n'exerce aucun contrôle sur le contenu traduit de façon automatique, qui peut contenir des erreurs, des imprécisions ou un langage inapproprié. Aucune garantie, explicite ou implicite, n'est fournie quant à l'exactitude, la fiabilité, la pertinence ou la justesse de toute traduction effectuée depuis l'anglais d'origine vers une autre langue, ou quant à la conformité de votre produit ou service Citrix à tout contenu traduit de façon automatique, et toute garantie fournie en vertu du contrat de licence de l'utilisateur final ou des conditions d'utilisation des services applicables, ou de tout autre accord avec Citrix, quant à la conformité du produit ou service à toute documentation ne s'applique pas dans la mesure où cette documentation a été traduite de façon automatique. Citrix ne pourra être tenu responsable de tout dommage ou problème dû à l'utilisation de contenu traduit de façon automatique.

AppFlow

October 4, 2021

Contributeur:

October 4, 2021

Contributeur:

Dans cet article

Fonctionnement d’AppFlow