Traçage distribué

Dans le graphe de services, vous pouvez utiliser la vue de traçage distribué pour :

• Analyser les performances globales du service.

• Visualiser 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é.

• Afficher les détails des transactions entre le service sélectionné et chacun de ses services interdépendants.

Prérequis

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

• Vous assurer qu’une application maintient les en-têtes de trace suivants lors de l’envoi de trafic est-ouest :

  

• Pour les versions CIC antérieures à 1.7.23, mettez à jour le fichier YAML CPX avec NS_DISTRIBUTED_TRACING et la valeur yes.

  

• Pour les versions CIC ultérieures à 1.7.23, vous devez utiliser une ConfigMap.

  Les ConfigMaps vous permettent de séparer vos configurations de vos pods et de rendre vos charges de travail portables. En utilisant les ConfigMaps, vous pouvez facilement modifier et gérer les configurations de vos charges de travail et réduire le besoin de coder en dur les données de configuration dans les spécifications des pods.

  Avec la prise en charge des ConfigMaps, vous pouvez mettre à jour la configuration automatiquement tout en maintenant le pod NetScaler Ingress Controller en cours d’exécution. Vous n’avez pas besoin de redémarrer le pod après la mise à jour. Pour plus d’informations, consultez Prise en charge de ConfigMap pour le contrôleur d’entrée.

  À l’aide de la ConfigMap, vous pouvez activer ou désactiver le traçage distribué, les événements, les journaux d’audit, etc. Pour utiliser la ConfigMap :

  1. Créez un fichier YAML en utilisant les paramètres requis.

     L’exemple de fichier YAML suivant a le traçage distribué activé et d’autres variables telles que les journaux d’audit, les événements et les transactions désactivées :

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: cic-configmap
       namespace: default
     data:
       LOGLEVEL: 'debug'
       NS_PROTOCOL: 'http'
       NS_PORT: '80'
       NS_HTTP2_SERVER_SIDE: 'ON'
       NS_ANALYTICS_CONFIG:
         distributed_tracing:
           enable: 'true'
           samplingrate: 100
         endpoint:
           server: <Console-AgentIP> / <Console-AppserverIP>
         timeseries:
           port: 5563
           metrics:
             enable: 'true'
             mode: 'avro'
           auditlogs:
             enable: 'false'
           events:
             enable: 'false'
         transactions:
           enable: 'false'
           port: 5557
     <!--NeedCopy-->
     

     Remarque

     Vous pouvez fournir des valeurs pour Samplingrate entre 0 et 100. NetScaler Console affiche le nombre de transactions de trace mentionné.

  2. Déployez la ConfigMap en utilisant :

     kubectl create -f <configmap-yaml>.yaml

  3. Modifiez le fichier YAML CPX et utilisez envFrom ou args pour spécifier les arguments suivants :

     envFrom:
      -  configMapRef:
          name: cic-configmap
     <!--NeedCopy-->
     

     OU

     

  4. Si vous souhaitez modifier la valeur d’une variable, modifiez les valeurs dans la ConfigMap. Dans cet exemple, toutes les autres variables sont passées de false à true.

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: cic-configmap
       namespace: default
     data:
       LOGLEVEL: 'debug'
       NS_PROTOCOL: 'http'
       NS_PORT: '80'
       NS_HTTP2_SERVER_SIDE: 'ON'
       NS_ANALYTICS_CONFIG:
         distributed_tracing:
           enable: 'true'
           samplingrate: 100
         endpoint:
           server: <Console-AgentIP> / <Console-AppserverIP>
         timeseries:
           port: 5563
           metrics:
             enable: 'true'
             mode: 'avro'
           auditlogs:
             enable: 'true'
           events:
             enable: 'true'
         transactions:
           enable: 'true'
           port: 5557
       <!--NeedCopy-->
     

  5. Réappliquez la ConfigMap à l’aide de la commande suivante :

     kubectl apply -f <yaml-file>.yaml

Afficher les détails de trace du service

Dans le graphe de services, cliquez sur un service et sélectionnez Trace Info.

La page Résumé de la trace s’affiche pour le service sélectionné.

Le Résumé de la trace affiche :

• Une recherche avancée qui vous permet de rechercher des transactions avec des suggestions et des opérateurs (1). Pour plus d’informations, consultez Recherche avancée.

• La liste des durées qui vous permet de sélectionner la durée, telle que 1 heure, 12 heures, 1 jour, 1 semaine, 1 mois et une durée personnalisée (2).

• Le graphique Détails de la chronologie qui vous permet de glisser et de sélectionner pour afficher les résultats pour une durée spécifique (3).

• Le panneau Filtres qui vous permet de sélectionner des options pour chaque métrique (4).

• Les détails de la transaction pour le service sélectionné (5).

Afficher les détails de la transaction

Cliquez sur une transaction pour obtenir des informations détaillées. Vous pouvez afficher les détails de la transaction pour le service sélectionné, tels que :

• Heure de début

• Heure de fin

• Métriques SSL

• Communication avec les services interdépendants (ainsi que les erreurs et le temps de réponse avec chaque service).

L’exemple suivant indique une erreur du catalogue-store-service. Cliquez sur Voir les détails de la trace pour plus de détails.

La page Détails de la trace s’affiche.

1 – Affiche l’heure de début, le temps de réponse, le nombre total de services et le nombre total de spans pour la transaction.

2 – Affiche les détails du service sélectionné qui a communiqué avec ses services interdépendants. Vous pouvez cliquer sur chaque transaction pour afficher les détails.

3 – Affiche les détails de la transaction pour chaque service.

Selon l’image d’exemple, le catalogue-store-service a indiqué une erreur. Cliquez sur la transaction disponible pour le catalogue-store-service.

Les détails de la transaction entre product-catalogue-service et catalogue-store-service indiquent une réponse HTTP de 500. Avec ces détails, en tant qu’administrateur, vous pouvez analyser le service erroné et dépanner le product-catalogue-service comme solution.

Vous pouvez également filtrer les résultats en sélectionnant des options pour chaque métrique sous le panneau Filtres. Par exemple, si vous souhaitez afficher toutes les transactions 5xx, cliquez sur Code de réponse et sélectionnez 500.

• RTT client : Durée nécessaire à un paquet pour voyager depuis le client.

• RTT serveur : Durée nécessaire à un paquet pour voyager depuis le serveur.

• Temps de réponse de l’application : Temps de réponse moyen de l’application.

• Temps de transfert de données : Taille du transfert de données et débit auquel la transmission peut se produire depuis/vers un service.

• Emplacement : Emplacement du client.

• Navigateur : Types de navigateurs utilisés par les clients. Par exemple : Chrome, Firefox.

• Système d’exploitation client : Système d’exploitation client basé sur les détails de l’agent utilisateur du navigateur.

• Appareil : Appareils basés sur les détails de l’agent utilisateur du navigateur. Par exemple : Tablette, Mobile.

• Type de requête : Type de requête de transaction. Par exemple : GET.

• Code de réponse : Code de réponse reçu du serveur. Par exemple : 501, 404, 200.

• Type de contenu de réponse : Type de contenu de la transaction. Si la requête client est pour text/html, alors la réponse du serveur doit être text/html.

• Protocole SSL : Version du protocole SSL utilisée par les clients. Par exemple : SSLv3.

• Force du chiffrement SSL : Force du chiffrement basée sur la taille de la clé du certificat SSL, telle que élevée, moyenne et faible.

• Force de la clé SSL : La force du chiffrement SSL est calculée à partir de la taille de la clé du certificat SSL. La longueur de la clé définit la sécurité de l’algorithme SSL. Par exemple : 2048.

• Raison de l’échec du front-end SSL : Message d’erreur de la poignée de main SSL du front-end. Par exemple : SSL CLIENTAUTH FAILURE.