AppFlow

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 la base 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, reportez-vous à la section 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 recevra les enregistrements AppFlow. Les stratégies basées sur des expressions avancées peuvent être configurées pour sélectionner les flux pour lesquels les enregistrements de flux seront 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 :

Flux 1 :<Client-IP, Client-Port, VIP-IP, VIP-port, Protocol>

Débit2 :<NS-MIP/SNIP, NS-port, Server-IP, Server-Port, Protocol>

Débit3 :<Server-IP, Server-Port, NS-MIP/SNIP, NS-Port, Protocol>

Flux4 :<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 par rapport à différentes connexions TCP backend 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), des données de performances de page 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 des informations de base de données (telles que le protocole de base de donnée, état de réponse de base de données et taille de réponse de base de données). 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 la taille des éléments d’information (IE) 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, cela correspond à une paire de requête et de réponse. 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, il y a quatre enregistrements uniflow qui correspondent à cette transaction. Si Citrix ADC génère la réponse par lui-même (à partir du cache intégré ou d’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 généralement 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, connectionID est un identifiant permettant à la structure de données de connexion de suivre la progression d’une connexion. Dans une transaction HTTP, par exemple, un connectionID 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. Cela 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 les images, les scripts et les 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 le navigateur a fini de rendre toute la page, 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.

AppFlow