Documentation Produit
ADC
14.1 - Current Release 13.1 13.0 12.1
Voir PDF

Utilisez Citrix ADM pour dépanner la mise en réseau native Citrix Cloud

March 17, 2024
Contributeur: 
C

Vue d’ensemble

Ce document fournit des informations sur la façon dont vous pouvez utiliser Citrix ADM pour mettre à disposition et surveiller des applications de microservices Kubernetes. Vous découvrirez également l’utilisation de l’interface de ligne de commande, des graphiques de service et du suivi pour permettre à la plateforme et aux équipes SRE de résoudre les problèmes.

Présentation des performances et de la latence

Cryptage TLS

Le protocole TLS est un protocole de cryptage conçu pour sécuriser les communications Internet. Une prise de contact TLS est le processus qui démarre une session de communication utilisant le cryptage TLS. Lors d’une poignée de main TLS, les deux parties communicantes échangent des messages pour s’accuser réception, se vérifier mutuellement, établir les algorithmes de chiffrement qu’ils utilisent et se mettre d’accord sur les clés de session. Les poignées de main TLS sont un élément fondamental du fonctionnement du protocole HTTPS.

Poignée de main TLS vs SSL

SSL (Secure Sockets Layer) était le protocole de cryptage original développé pour HTTP. TLS (Transport Layer Security) a remplacé SSL il y a quelque temps. Les poignées de main SSL sont maintenant appelées poignées de main TLS, bien que le nom « SSL » soit encore largement utilisé.

Quand se produit une prise de contact TLS ?

Une poignée de main TLS a lieu chaque fois qu’un utilisateur accède à un site Web via HTTPS et que le navigateur commence d’abord à interroger le serveur d’origine du site Web. Une prise de contact TLS se produit également chaque fois que d’autres communications utilisent HTTPS, y compris les appels d’API et les requêtes DNS sur HTTPS.

Les prises de contact TLS se produisent après l’ouverture d’une connexion TCP via une poignée de main TCP.

Que se passe-t-il lors d’une prise de contact TLS ?

  • Lors d’une prise de contact TLS, le client et le serveur effectuent ensemble les opérations suivantes :
    • Spécifiez la version de TLS (TLS 1.0, 1.2, 1.3, etc.) qu’ils utilisent.
    • Déterminez les suites de chiffrement (voir la section suivante) qu’ils utilisent.
    • Authentifiez l’identité du serveur via la clé publique du serveur et la signature numérique de l’autorité de certification SSL.
    • Générez des clés de session pour utiliser le chiffrement symétrique une fois la prise de contact terminée.

Quelles sont les étapes d’une prise de contact TLS ?

  • Les poignées de main TLS sont une série de datagrammes, ou messages, échangés par un client et un serveur. Une prise de contact TLS comporte plusieurs étapes, car le client et le serveur échangent les informations nécessaires pour terminer la prise de contact et permettre la poursuite de la conversation.

Les étapes exactes d’une négociation TLS varient en fonction du type d’algorithme d’échange de clés utilisé et des suites de chiffrement prises en charge par les deux parties. L’algorithme d’échange de clés RSA est le plus souvent utilisé. Il se déroule comme suit :

  1. Le message client hello : Le client lance la prise de contact en envoyant un message « Bonjour » au serveur. Le message indique la version TLS prise en charge par le client, les suites de chiffrement prises en charge et une chaîne d’octets aléatoires appelée « client aléatoire ».
  2. Le message server hello : En réponse au message Hello du client, le serveur envoie un message contenant le certificat SSL du serveur, la suite de chiffrement choisie par le serveur et le « serveur aléatoire », une autre chaîne aléatoire d’octets générée par le serveur.
  3. Authentification : Le client vérifie le certificat SSL du serveur auprès de l’autorité de certification qui l’a émis. Cela confirme que le serveur est bien celui qu’il prétend être et que le client interagit avec le véritable propriétaire du domaine.
  4. Le secret prémaître: Le client envoie une autre chaîne aléatoire d’octets, le « secret prémaître ». Le secret prémaître est chiffré avec la clé publique et ne peut être déchiffré qu’avec la clé privée par le serveur. (Le client obtient la clé publique du certificat SSL du serveur.)
  5. Clé privée utilisée : Le serveur déchiffre le secret du prémaster.
  6. Clés de session créées : le client et le serveur génèrent des clés de session à partir du client aléatoire, du serveur aléatoire et du secret prémaître. Ils devraient parvenir aux mêmes résultats.
  7. Le client est prêt : le client envoie un message « terminé » chiffré avec une clé de session.
  8. Le serveur est prêt : le serveur envoie un message « terminé » chiffré avec une clé de session.
  9. Chiffrement symétrique sécurisé obtenu : la prise de contact est terminée et la communication se poursuit à l’aide des clés de session.

Toutes les prises de contact TLS utilisent un cryptage asymétrique (clé publique et privée), mais toutes n’utilisent pas la clé privée dans le processus de génération des clés de session. Par exemple, une poignée de main éphémère Diffie-Hellman se déroule comme suit :

  1. Client Hello : le client envoie un message Hello client avec la version du protocole, le caractère aléatoire du client et une liste de suites de chiffrement.
  2. Bonjour du serveur : Le serveur répond avec son certificat SSL, sa suite de chiffrement sélectionnée et le serveur aléatoire. Contrairement à l’établissement de liaison RSA décrit dans la section précédente, le serveur inclut également dans ce message les informations suivantes (étape 3).
  3. Signature numérique du serveur : Le serveur utilise sa clé privée pour chiffrer le client au hasard, le serveur aléatoire et son paramètre DH*. Ces données cryptées fonctionnent comme la signature numérique du serveur, établissant que le serveur possède la clé privée qui correspond à la clé publique du certificat SSL.
  4. Signature numérique confirmée : le client déchiffre la signature numérique du serveur avec la clé publique, en vérifiant que le serveur contrôle la clé privée et qu’il est bien celui qu’il prétend être. Paramètre DH du client : Le client envoie son paramètre DH au serveur.
  5. Le client et le serveur calculent le secret prémaître : au lieu que le client génère le secret prémaître et l’envoie au serveur, comme dans une poignée de main RSA, le client et le serveur utilisent les paramètres DH qu’ils ont échangés pour calculer séparément un secret prémaître correspondant.
  6. Clés de session créées : Maintenant, le client et le serveur calculent les clés de session à partir du secret prémaître, du hasard du client et du serveur, comme dans une poignée de main RSA.
    • Le client est prêt : même chose qu’une poignée de main RSA
    • Le serveur est prêt
    • Cryptage symétrique sécurisé obtenu

    *Paramètre DH : DH signifie Diffie-Hellman. L’algorithme Diffie-Hellman utilise des calculs exponentiels pour arriver au même secret prémaster. Le serveur et le client fournissent chacun un paramètre pour le calcul et, lorsqu’ils sont combinés, ils aboutissent à un calcul différent de chaque côté, avec des résultats égaux.

Pour en savoir plus sur le contraste entre les poignées de main éphémères Diffie-Hellman et d’autres types de poignées de main, et sur la manière dont elles permettent d’atteindre le secret de transmission, consultez cette documentation sur le protocole TLS.

Qu’est-ce qu’une suite de chiffrement ?

  • Une suite de chiffrement est un ensemble d’algorithmes de chiffrement utilisés pour établir une connexion de communication sécurisée. (Un algorithme de chiffrement est un ensemble d’opérations mathématiques effectuées sur des données pour les rendre aléatoires.) Il existe différentes suites de chiffrement largement utilisées, et une partie essentielle de la prise de contact TLS consiste à déterminer quelle suite de chiffrement est utilisée pour cette poignée de main.

Pour commencer, reportez-vous à la section Référence : Documentation du protocole TLS.

Tableau de bord SSL Citrix Application Delivery Management

Citrix Application Delivery Management (ADM) rationalise désormais tous les aspects de la gestion des certificats pour vous. Grâce à une console unique, vous pouvez établir des stratégies automatisées pour garantir l’émetteur, la force de clé et les algorithmes corrects, tout en gardant un œil étroit sur les certificats inutilisés ou bientôt expirés. Pour commencer à utiliser le tableau de bord SSL de Citrix ADM et ses fonctionnalités, vous devez comprendre ce qu’est un certificat SSL et comment vous pouvez utiliser Citrix ADM pour suivre vos certificats SSL.

Un certificat SSL (Secure Socket Layer), qui fait partie de toute transaction SSL, est un formulaire de données numérique (X509) qui identifie une société (domaine) ou un individu. Le certificat possède un composant de clé publique visible par tout client qui souhaite lancer une transaction sécurisée avec le serveur. La clé privée correspondante, qui réside en toute sécurité sur l’appliance Citrix Application Delivery Controller (ADC), est utilisée pour effectuer le chiffrement et le déchiffrement des clés asymétriques (ou des clés publiques).

Vous pouvez obtenir un certificat SSL et une clé de l’une des manières suivantes :

  • De la part d’une autorité de certification (CA) autorisée
  • En générant un nouveau certificat SSL et une nouvelle clé sur l’appliance Citrix ADC

Citrix ADM fournit une vue centralisée des certificats SSL installés sur toutes les instances Citrix ADC gérées. Sur le tableau de bord SSL, vous pouvez afficher des graphiques qui vous aident à suivre les émetteurs de certificats, les forces clés, les algorithmes de signature, les certificats expirés ou non utilisés, etc. Vous pouvez également voir la distribution des protocoles SSL qui s’exécutent sur vos serveurs virtuels et les clés qui y sont activées.

Vous pouvez également configurer des notifications pour vous informer lorsque les certificats sont sur le point d’expirer et inclure des informations sur les instances Citrix ADC qui utilisent ces certificats.

Vous pouvez lier les certificats d’une instance Citrix ADC à un certificat d’autorité de certification. Cependant, assurez-vous que les certificats que vous liez au même certificat d’autorité de certification ont la même source et le même émetteur. Après avoir lié les certificats à un certificat d’autorité de certification, vous pouvez les dissocier.

Le tableau de bord SSL

Pour commencer, consultez la documentation du tableau de bord SSL.

Intégrations tierces

La latence de l’application est mesurée en millisecondes et peut indiquer l’un des deux éléments suivants en fonction de la mesure utilisée. La méthode la plus courante de mesure de la latence est appelée « temps aller-retour » (ou RTT). RTT calcule le temps nécessaire à un paquet de données pour se déplacer d’un point à un autre sur le réseau et pour qu’une réponse soit renvoyée à la source. L’autre mesure est appelée « temps jusqu’au premier octet » (ou TTFB), qui enregistre le temps qu’il faut entre le moment où un paquet quitte un point du réseau et le moment où il arrive à destination. Le RTT est plus couramment utilisé pour mesurer la latence car il peut être exécuté à partir d’un point unique du réseau et ne nécessite pas l’installation d’un logiciel de collecte de données sur le point de destination (comme le fait TTFB).

En surveillant l’utilisation et les performances de la bande passante de votre application en temps réel, le service ADM facilite l’identification des problèmes et la résolution préventive des problèmes potentiels avant qu’ils ne se manifestent et n’affectent les utilisateurs de votre réseau. Cette solution basée sur les flux suit l’utilisation par interface, application et conversation, vous fournissant des informations détaillées sur l’activité de votre réseau.

Utiliser les outils Splunk

Les performances de l’infrastructure et des applications sont interdépendantes. Pour avoir une vue d’ensemble, SignalFX fournit une corrélation transparente entre l’infrastructure cloud et les microservices qui s’exécutent dessus. Si votre application échoue en raison d’une fuite de mémoire, d’un conteneur voisin bruyant ou de tout autre problème lié à l’infrastructure, SignalFX vous en informe. Pour compléter le tableau, l’accès en contexte aux journaux et aux événements Splunk permet un dépannage plus approfondi et une analyse des causes profondes.

Splunk

Pour plus d’informations sur l’APM des microservices SignalFX et le dépannage avec Splunk, consultez les informations relatives à Splunk pour DevOps .

Prise en charge MongoDB

MongoDB stocke les données dans des documents flexibles de type JSON. Les champs de signification peuvent varier d’un document à l’autre et la structure des données peut être modifiée au fil du temps.

Le modèle de document correspond aux objets de votre code d’application, ce qui facilite l’utilisation des données.

Les requêtes à la demande, l’indexation et l’agrégation en temps réel fournissent de puissants moyens d’accéder à vos données et de les analyser.

MongoDB est une base de données distribuée, de sorte que la haute disponibilité, la mise à l’échelle horizontale et la distribution géographique sont intégrées et faciles à utiliser.

MongoDB est conçu pour répondre aux exigences des applications modernes grâce à une base technologique qui vous permet de :

  • Le modèle de données du document, qui vous présente la meilleure façon de travailler avec les données.
  • Une conception de systèmes distribués qui vous permet de placer intelligemment les données où vous le souhaitez.
  • Une expérience unifiée qui vous donne la liberté d’exécuter n’importe où, ce qui vous permet de pérenniser votre travail et d’éliminer la dépendance vis-à-vis des fournisseurs.

Avec ces fonctionnalités, vous pouvez créer une plate-forme de données opérationnelles intelligente, soutenue par MongoDB. Pour plus d’informations, consultez la documentation MongoDB.

Comment équilibrer la charge du trafic entrant vers une application basée sur TCP ou UDP

Dans un environnement Kubernetes, une entrée est un objet qui permet d’accéder aux services Kubernetes depuis l’extérieur du cluster Kubernetes. Les ressources Kubernetes Ingress standard supposent que tout le trafic est basé sur HTTP et ne répond pas aux protocoles non HTTP tels que TCP, TCP-SSL et UDP. Par conséquent, les applications critiques basées sur les protocoles L7 tels que DNS, FTP, LDAP, ne peuvent pas être exposées à l’aide de Kubernetes Ingress standard.

La solution standard de Kubernetes consiste à créer un service de type LoadBalancer. Consultez la section Équilibrage de charge du type de service dans Citrix ADC pour plus d’informations.

La deuxième option consiste à annoter l’objet d’entrée. Le Citrix ingress controller vous permet d’équilibrer la charge du trafic entrant basé sur TCP ou UDP. Il fournit les annotations suivantes que vous pouvez utiliser dans votre définition de ressource Kubernetes Ingress pour équilibrer la charge du trafic entrant basé sur TCP ou UDP :

  • ingress.citrix.com/insecure-service-type : l’annotation active l’équilibrage de charge L4 avec TCP, UDP ou ANY en tant que protocole pour Citrix ADC.
  • ingress.citrix.com/insecure-port : l’annotation configure le port TCP. L’annotation est utile lorsque l’accès au microservice est requis sur un port non standard. Par défaut, le port 80 est configuré.

Pour plus d’informations, consultez Comment équilibrer la charge du trafic entrant vers une application basée sur TCP ou UDP.

Surveillez et améliorez les performances de vos applications basées sur TCP ou UDP

Les développeurs d’applications peuvent surveiller de près la santé des applications basées sur TCP ou UDP grâce à des moniteurs riches (tels que TCP-ECV, UDP-ECV) dans Citrix ADC. L’ECV (Extended Content Validation) surveille l’aide pour vérifier si l’application renvoie le contenu attendu ou non.

En outre, les performances de l’application peuvent être améliorées en utilisant des méthodes de persistance telles que l’adresse IP source. Vous pouvez utiliser ces fonctionnalités Citrix ADC via Smart Annotations dans Kubernetes. Voici un exemple de ce type :

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
    name: mongodb
    annotations:
        ingress.citrix.com/insecure-port: “80”
        ingress.citrix.com/frontend-ip: “192.168.1.1”
        ingress.citrix.com/csvserver: ‘{“l2conn”:”on”}’
        ingress.citrix.com/lbvserver: ‘{“mongodb-svc”:{“lbmethod”:”SRCIPDESTIPHASH”}}’
        ingress.citrix.com/monitor: ‘{“mongodbsvc”:{“type”:”tcp-ecv”}}’
Spec:
    rules:
    - host: mongodb.beverages.com
      http:
        paths:
        - path: /
          backend:
            serviceName: mongodb-svc
            servicePort: 80
<!--NeedCopy-->

Service de gestion de la livraison d’applications (ADM) Citrix

Le service Citrix ADM offre les avantages suivants :

  • Agile — Facile à utiliser, à mettre à jour et à consommer. Le modèle de service de Citrix ADM Service est disponible sur le cloud, ce qui facilite l’utilisation, la mise à jour et l’utilisation des fonctionnalités fournies. La fréquence des mises à jour, combinée à la fonctionnalité de mise à jour automatisée, améliore rapidement votre déploiement Citrix ADC.
  • Délai de rentabilisation plus rapide — Réalisation plus rapide des objectifs commerciaux. Contrairement au déploiement sur site traditionnel, vous pouvez utiliser votre service Citrix ADM en quelques clics. Vous économisez non seulement du temps d’installation et de configuration, mais vous évitez également de perdre du temps et des ressources en cas d’erreurs potentielles.
  • Gestion multisite : volet unique de verre pour les instances dans les datacenters multi-sites. Avec le service Citrix ADM, vous pouvez gérer et surveiller les Citrix ADC qui se trouvent dans différents types de déploiements. Vous disposez d’une gestion unique pour les Citrix ADC déployés sur site et dans le cloud.
  • Efficacité opérationnelle — Une façon optimisée et automatisée d’atteindre une productivité opérationnelle plus élevée. Avec le service Citrix ADM, vos coûts opérationnels sont réduits en économisant du temps, de l’argent et des ressources sur la maintenance et la mise à niveau des déploiements matériels traditionnels.

Graphique de service pour les applications Kubernetes

À l’aide du graphique de service de la fonctionnalité d’application native cloud de Citrix ADM, vous pouvez :

  • Garantir les performances globales des applications de bout en bout
  • Identifiez les goulots d’étranglement créés par l’interdépendance des différents composants de vos applications
  • Recueillez des informations sur les dépendances des différents composants de vos applications
  • Surveiller les services au sein du cluster Kubernetes
  • Surveiller quel service rencontre des problèmes
  • Vérifiez les facteurs qui contribuent aux problèmes de performance
  • Afficher la visibilité détaillée des transactions HTTP de service
  • Analyser les mesures HTTP, TCP et SSL

En visualisant ces mesures dans Citrix ADM, vous pouvez analyser la cause première des problèmes et prendre les mesures de dépannage nécessaires plus rapidement. Le graphique de service affiche vos applications dans divers services de composants. Ces services s’exécutant à l’intérieur du cluster Kubernetes peuvent communiquer avec divers composants à l’intérieur et à l’extérieur de l’application.

Pour commencer, reportez-vous à la section Configuration du graphique de service.

Graphique de service pour les applications Web à 3 niveaux

À l’aide de la fonction de graphe de service du tableau de bord de l’application, vous pouvez afficher :

  • Détails sur la configuration de l’application (avec un serveur virtuel de commutation de contenu et un serveur virtuel d’équilibrage de charge)
    • Pour les applications GSLB, vous pouvez afficher le centre de données, l’instance ADC, les serveurs virtuels CS et LB
  • Transactions de bout en bout du client au service
  • Emplacement à partir duquel le client accède à l’application
  • Le nom du centre de données où les demandes client sont traitées et les mesures Citrix ADC du centre de données associées (uniquement pour les applications GSLB)
  • Détails des mesures pour les serveurs clients, les services et les serveurs virtuels
  • Si les erreurs proviennent du client ou du service
  • L’état du service, tel que Critique, RévisionetBon. Citrix ADM affiche l’état du service en fonction du temps de réponse du service et du nombre d’erreurs.
    • Critique (rouge) - Indique si le temps de réponse moyen du service est supérieur à 200 ms ET le nombre d’erreurs > 0
    • Avis (orange) - Indique si le temps de réponse moyen du service est supérieur à 200 ms OU le nombre d’erreurs > 0
    • Bon (vert) - Indique l’absence d’erreur et le temps de réponse moyen du service est inférieur à 200 ms
  • L’état du client, tel que Critique, RévisionetBon. Citrix ADM affiche l’état du client en fonction de la latence du réseau client et du nombre d’erreurs.
    • Critique (rouge)- Indique si la latence moyenne du réseau client est > 200 ms ET le nombre d’erreurs > 0
    • Avis (orange) - Indique lorsque la latence moyenne du réseau client est > 200 ms OU le nombre d’erreurs > 0
    • Bon (vert) - Indique l’absence d’erreur et la latence moyenne du réseau client est inférieure à 200 ms
  • L’état du serveur virtuel, tel que Critique, RévisionetBon. Citrix ADM affiche l’état du serveur virtuel en fonction du score de l’application.
    • Critique (rouge) - Indique lorsque le score de l’application est inférieur à 40
    • Avis (orange) - Indique quand le score de l’application se situe entre 40 et 75
    • Bon (vert) - Indique lorsque le score de l’application est > 75

Points à noter :

  • Seuls les serveurs virtuels d’équilibrage de charge, de commutation de contenu et GSLB sont affichés dans le graphique de service.
  • Si aucun serveur virtuel n’est lié à une application personnalisée, les détails ne sont pas visibles dans le graphique de service de l’application.
  • Vous pouvez afficher les mesures des clients et des services dans le graphique des services uniquement si des transactions actives ont lieu entre des serveurs virtuels et une application Web.
  • Si aucune transaction active n’est disponible entre les serveurs virtuels et l’application Web, vous pouvez uniquement afficher les détails dans le graphique de service en fonction des données de configuration telles que l’équilibrage de charge, la commutation de contenu, les serveurs virtuels GSLB et les services.
  • Les mises à jour de la configuration de l’application peuvent prendre 10 minutes pour apparaître dans le graphique de service.

Pour plus d’informations, consultez la section Graphique de service pour les applications.

Organigramme de service

Pour commencer, consultez la documentation Service Graph.

Dépannage pour les équipes Citrix ADC

Examinons certains des attributs les plus courants pour le dépannage de la plate-forme Citrix ADC et comment ces techniques de dépannage s’appliquent aux déploiements de niveau 1 pour les topologies de microservices.

Citrix ADC possède une interface de ligne de commande (CLI) qui affiche les commandes en temps réel et est utile pour déterminer les configurations d’exécution, la statique et la configuration des stratégies. Cela est facilité par la commande « SHOW » .

SHOW - effectuer des opérations CLI ADC :

>Show running config (-summary -fullValues)

 Ability to search (grep command)
>“sh running config | -i grep vserver”

Check the version.
>Show license
  “sh license"
<!--NeedCopy-->

Afficher les statistiques SSL

>Sh ssl
        System
        Frontend
        Backend
        Encryption
<!--NeedCopy-->

Afficher les statistiques SSL

Citrix ADC possède une commande permettant d’énumérer les statistiques pour tous les objets en fonction d’un intervalle de sept (7) secondes. Cela est facilité par la commande « STAT » .

Télémétrie L3-L7 hautement granulaire par Citrix ADC

  • Niveau système : utilisation du processeur et de la mémoire de l’ADC.
  • Protocole HTTP : #Requests /Responses, split GET/POST, erreurs HTTP pour N-S et E-W (pour le service mesh lite uniquement, sidecar bientôt).
  • SSL : #Sessions et #Handshakes pour le trafic N-S et E-W pour le service mesh lite uniquement.
  • Protocole IP : #Packets reçu/envoyé, #Bytes reçu/envoyé, paquets #Truncated et recherche d’adresse #IP.
  • Sessions #Active de Citrix ADC AAA
  • Interface : paquets multidiffusion #Total, #Total octets transférés et paquets #Jumbo reçus/envoyés.
  • Serveur virtuel d’équilibrage de charge et serveur virtuel de commutation de contenu : #Packets, #Hits et #Bytes reçus/envoyés.

STAT - effectuer des opérations CLI ADC :

>Statistics
“stat ssl”
<!--NeedCopy-->

Démarrez SSL

Citrix ADC possède une structure d’archive de journaux qui permet la recherche de statistiques et de compteurs lors du dépannage d’erreurs spécifiques via la commande « NSCONMSG » .

NSCONMSG - fichier journal principal (format de données ns) 

    Cd /var/nslog

    “Mac Moves”
    nsconmsg -d current -g nic_err
<!--NeedCopy-->

Flux de commandes

Nstcpdump

Vous pouvez utiliser nstcpdump pour le dépannage de bas niveau. nstcpdump recueille des informations moins détaillées que nstrace. Ouvrez l’interface de ligne de commande ADC et tapez shell. Vous pouvez utiliser des filtres avec nstcpdump mais ne pouvez pas utiliser de filtres spécifiques aux ressources ADC. La sortie de vidage peut être visualisée directement dans l’écran CLI.

CTRL + C — Appuyez simultanément sur ces touches pour arrêter un nstcpdump.

nstcpdump.sh dst host x.x.x.x : affiche le trafic envoyé à l’hôte de destination.

nstcpdump.sh -n src host x.x.x.x — Affiche le trafic provenant de l’hôte spécifié et ne convertit pas les adresses IP en noms (-n).

nstcpdump.sh host x.x.x.x — Affiche le trafic vers et depuis l’adresse IP de l’hôte spécifiée.

Exemple `nstcpdump`

NSTRACE - fichier de suivi des paquets

NSTRACE est un outil de débogage de paquets de bas niveau destiné au dépannage des réseaux. Il vous permet de stocker des fichiers de capture que vous pouvez analyser davantage à l’aide des outils d’analyse. Les deux outils courants sont Network Analyzer et Wireshark.

La `nstrace` sortie

La sortie de trace de paquets

Une fois le fichier de capture NSTRACE créé dans /var/nstrace sur l’ADC, vous pouvez importer le fichier de capture dans Wireshark pour la capture de paquets et l’analyse du réseau.

SYSCTL - Informations détaillées sur l’ADC : description, modèle, plate-forme, processeurs, etc 

    sysctl -a grep hw.physmem

    hw.physmem: 862306304
    netscaler.hw_physmem_mb: 822
<!--NeedCopy-->

aaad.debug - Canal ouvert pour les informations de débogage d’authentification

aaad.debug

Pour plus d’informations sur la façon de résoudre les problèmes d’authentification via ADC ou ADC Gateway avec le module aaad.debug, consultez l’article de support aaad.debug.

Il est également possible d’obtenir des statistiques de performances et des journaux d’événements directement pour l’ADC. Pour plus d’informations à ce sujet, consultez le document de support ADC.

Dépannage pour les équipes SRE et plateformes

Flux de trafic Kubernetes

Nord/Sud :

  • Le trafic Nord/Sud est le trafic circulant de l’utilisateur vers le cluster, via l’entrée.

Est/Ouest :

  • Le trafic est/ouest est le trafic circulant autour du cluster Kubernetes : service à service ou service à magasin de données.

Comment Citrix ADC CPX équilibre la charge du trafic est-ouest dans un environnement Kubernetes

Après avoir déployé le cluster Kubernetes, vous devez intégrer le cluster à ADM en fournissant les détails de l’environnement Kubernetes dans ADM. ADM surveille les modifications apportées aux ressources Kubernetes, telles que les services, les points de terminaison et les règles d’entrée.

Lorsque vous déployez une instance ADC CPX dans le cluster Kubernetes, elle s’enregistre automatiquement auprès d’ADM. Dans le cadre du processus d’enregistrement, ADM prend connaissance de l’adresse IP de l’instance CPX et du port sur lequel il peut atteindre l’instance pour la configurer à l’aide des API REST NITRO.

La figure suivante montre comment la charge ADC CPX équilibre le flux de trafic est-ouest dans un cluster Kubernetes.

Équilibrage de charge Kubernetes

Dans cet exemple,

Le nœud 1 et le nœud 2 des clusters Kubernetes contiennent des instances d’un service frontal et d’un service principal. Lorsque les instances ADC CPX sont déployées dans les nœuds 1 et 2, les instances ADC CPX sont automatiquement enregistrées auprès d’ADM. Vous devez intégrer manuellement le cluster Kubernetes à ADM en configurant les détails du cluster Kubernetes dans ADM.

Lorsqu’un client demande le service frontal, la charge de ressource d’entrée équilibre la demande entre les instances du service frontal sur les deux nœuds. Lorsqu’une instance du service frontal a besoin d’informations provenant des services principaux du cluster, elle dirige les demandes vers l’instance CPX ADC de son nœud. Cette instance CPX ADC équilibre la charge des demandes entre les services dorsaux du cluster, fournissant ainsi un flux de trafic est-ouest.

Graphique de service ADM pour les applications

La fonctionnalité de graphique de service dans Citrix ADM vous permet de surveiller tous les services dans une représentation graphique. Cette fonctionnalité fournit également une analyse détaillée et des mesures utiles. Vous pouvez consulter les graphiques de service pour :

Pour commencer, consultez les détails dans le graphique de service.

Afficher les compteurs d’applications de microservices

Le graphique de service affiche également toutes les applications de microservice appartenant aux clusters Kubernetes. Toutefois, le pointeur de la souris sur un service permet d’afficher les détails des mesures.

Vous pouvez consulter les éléments suivants :

  • Le nom du service
  • Le protocole utilisé par le service tel que SSL, HTTP, TCP, SSL sur HTTP
  • Hits — Nombre total d’accès reçus par le service
  • Temps de réponse du service — Temps de réponse moyen pris par le service. (Temps de réponse = RTT client + demande le dernier octet — demande le premier octet)
  • Erreurs — Les erreurs totales telles que 4xx, 5xx, et ainsi de suite
  • Volume de données — Volume total de données traitées par le service
  • Espace de noms — Espace de noms du service
  • Nom du cluster — Nom du cluster où le service est hébergé
  • Erreurs SSL Server  : nombre total d’erreurs SSL provenant du service

Application lente

Ces compteurs et journaux de transactions spécifiques peuvent être extraits via Citrix Observability Exporter (COE) à l’aide d’une gamme de points de terminaison pris en charge. Pour plus d’informations sur COE, consultez les sections suivantes.

Statistiques de l’exportateur pour Citrix ADC

Il s’agit d’un serveur simple qui récupère les statistiques Citrix ADC et les exporte via HTTP vers Prometheus. Prometheus peut ensuite être ajouté en tant que source de données à Grafana pour afficher les statistiques Citrix ADC sous forme graphique.

Pour surveiller les statistiques et les compteurs des instances Citrix ADC, citrix-adc-metric-exporter peut être exécuté en tant que conteneur ou script. L’exportateur collecte les statistiques Citrix ADC, telles que le nombre total d’accès à un serveur virtuel, le taux de requêtes HTTP, le taux de cryptage-décryptage SSL, etc., à partir des instances Citrix ADC et les conserve jusqu’à ce que le serveur Prometheus extrait les statistiques et les stocke avec un horodatage. Grafana peut ensuite être dirigé vers le serveur Prometheus pour récupérer les statistiques, les tracer, définir des alarmes, créer des cartes thermiques, générer des tables, etc. selon les besoins pour analyser les statistiques Citrix ADC.

Les sections suivantes fournissent des détails sur la configuration de l’exportateur pour qu’il fonctionne dans un environnement tel qu’indiqué dans la figure. Une note sur les entités/métriques Citrix ADC que l’exportateur supprime par défaut et sur la façon de les modifier est également expliquée.

Pour plus d’informations sur Exporter pour Citrix ADC, consultez l’ exportateur de métriques GitHub.

Suivi distribué du service ADM

Dans le graphique de service, vous pouvez utiliser la vue de suivi distribué pour :

  • Analysez les performances globales du service.
  • Visualisez le flux de communication entre le service sélectionné et ses services interdépendants.
  • Identifier le service qui indique des erreurs et dépanner le service erroné
  • Affichez les détails des transactions entre le service sélectionné et chaque service interdépendant.

Prérequis pour le suivi distribué ADM

Pour afficher les informations de suivi du service, vous devez :

  • Assurez-vous qu’une application conserve les en-têtes de trace suivants, tout en envoyant tout trafic est-ouest :

en-têtes de trace

  • Mettez à jour le fichier YAML CPX avec NS_DISTRIBUTED_TRACING et la valeur sur YES. Pour commencer, consultez la section Suivi distribué.

Analyse de l’exportateur d’observabilité (COE) Citrix ADC

Citrix Observability Exporter est un conteneur qui collecte les mesures et les transactions des Citrix ADC et les transforme en formats appropriés (tels que JSON, AVRO) pour les points de terminaison pris en charge. Vous pouvez exporter les données collectées par l’exportateur d’observabilité Citrix vers le point de terminaison souhaité. En analysant les données exportées vers le point de terminaison, vous pouvez obtenir des informations précieuses au niveau des microservices pour les applications traitées par proxy par Citrix ADC.

Pour plus d’informations sur COE, consultez COE GitHub.

COE avec Elasticsearch comme point de terminaison de transaction

COE

Lorsque Elasticsearch est spécifié comme point de terminaison de transaction, Citrix Observability Exporter convertit les données au format JSON. Sur le serveur Elasticsearch, Citrix Observability Exporter crée des index Elasticsearch pour chaque ADC sur une base horaire. Ces index sont basés sur les données, l’heure, l’UUID de l’ADC et le type de données HTTP (http_event ou http_error). Ensuite, l’exportateur d’observabilité Citrix télécharge les données au format JSON sous les index de recherche Elastic pour chaque ADC. Toutes les transactions régulières sont placées dans l’index http_event et toutes les anomalies sont placées dans l’index http_error.

COE JSON

Prise en charge du suivi distribué avec Zipkin

Dans une architecture de microservices, une seule demande d’utilisateur final peut s’étendre à plusieurs microservices, ce qui rend difficile le suivi d’une transaction et la résolution des sources d’erreurs. Dans de tels cas, les méthodes traditionnelles de surveillance des performances ne permettent pas de déterminer avec précision où les défaillances se produisent et quelle est la raison de ces mauvaises performances. Vous avez besoin d’un moyen de capturer des points de données spécifiques à chaque microservice traitant une demande et de les analyser pour obtenir des informations pertinentes.

Le suivi distribué répond à ce défi en fournissant un moyen de suivre une transaction de bout en bout et de comprendre comment elle est gérée sur plusieurs microservices.

OpenTracing est une spécification et un ensemble standard d’API pour la conception et la mise en œuvre du suivi distribué. Les traceurs distribués vous permettent de visualiser le flux de données entre vos microservices et d’identifier les goulots d’étranglement dans votre architecture de microservices.

L’exportateur d’observabilité Citrix ADC implémente le suivi distribué pour Citrix ADC et prend actuellement en charge Zipkin en tant que traceur distribué.

Actuellement, vous pouvez surveiller les performances au niveau de l’application à l’aide de Citrix ADC. À l’aide de Citrix Observability Exporter avec Citrix ADC, vous pouvez obtenir des données de suivi pour les microservices de chaque application mandatée par votre Citrix ADC CPX, MPX ou VPX.

Pour commencer, consultez l’ exportateur d’observabilité GitHub.

COE ADC

Zipkin pour le débogage des applications

Zipkin est un système de traçage distribué open source basé sur l’article de Dapper de Google. Dapper est le système de Google pour son système de traçage distribué en production. Google explique cela dans son article : « Nous avons conçu Dapper pour fournir aux développeurs de Google plus d’informations sur le comportement des systèmes distribués complexes ». L’observation du système sous différents angles est essentielle lors du dépannage, en particulier lorsqu’un système est complexe et distribué.

Les données de trace Zipkin suivantes identifient un total de 5 spans et 5 services liés à l’exemple d’application Watches. Les données de suivi montrent les données de portée spécifiques sur les 5 microservices.

Pour commencer, consultez Zipkin.

Traces Zipkin

Envergure Amazon

Exemple de plage Zipkin montrant la latence de l’application pour la demande initiale de chargement de

Exemple de service Zipkin

Kibana pour l’affichage des données

Kibana est une interface utilisateur ouverte qui vous permet de visualiser vos données Elasticsearch et de naviguer dans Elastic Stack. Faites n’importe quoi, du suivi du chargement des requêtes à la compréhension de la façon dont les demandes circulent dans vos applications

Que vous soyez analyste ou administrateur, Kibana rend vos données exploitables en fournissant les trois fonctions clés suivantes :

  • Une plateforme d’analyse et de visualisation open source. Utilisez Kibana pour explorer vos données Elasticsearch, puis créez de superbes visualisations et tableaux de bord.
  • Une interface utilisateur pour gérer la pile Elastic. Gérez vos paramètres de sécurité, attribuez des rôles d’utilisateur, prenez des instantanés, regroupez vos données et bien plus encore, le tout depuis le confort d’une interface utilisateur Kibana.
  • Un hub centralisé pour les solutions Elastic. De l’analyse des journaux à la découverte de documents en passant par le SIEM, Kibana est le portail d’accès à ces fonctionnalités et à d’autres.

Kibana est conçu pour utiliser Elasticsearch comme source de données. Considérez Elasticsearch comme le moteur qui stocke et traite les données, avec Kibana en tête.

Sur la page d’accueil, Kibana propose les options suivantes pour ajouter des données :

Kibana utilise un modèle d’index pour indiquer les indices Elasticsearch à explorer. Si vous téléchargez un fichier, exécutez un didacticiel intégré ou ajoutez des exemples de données, vous obtenez un modèle d’index gratuitement et vous pouvez commencer à explorer. Si vous chargez vos propres données, vous pouvez créer un modèle d’index dans Stack Management.

Étape 1 : Configurer le modèle d’index pour Logstash

Étape 2 : Sélectionnez l’index et générez le trafic à remplir.

Étape 3 : générer une application à partir des données non structurées issues des flux de journaux.

Étape 4 : Kibana met en forme l’entrée Logstash pour créer des rapports et des tableaux de bord.

  • Plage de temps
  • Vue tabulaire
  • Nombre de visites en fonction de l’application.
    • IP de temps, agent, machine.OS, code de réponse (200), URL
    • Filtre sur les valeurs

Étape 5 : Visualisez les données dans un rapport d’agrégations.

  • Agrégation des résultats dans un rapport graphique (secteur, graphique, etc.)

Tableau de bord Kib

Kibana

Utilisez Citrix ADM pour dépanner la mise en réseau native Citrix Cloud
March 17, 2024
Contributeur: 
C
March 17, 2024
Contributeur: 
C

Dans cet article

Commentaires sur le site | Your privacy choices footer linkVos préférences de confidentialité | Confidentialité et conditions légales | Préférences de cookies | Paramètres de consentement | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.