Dépannage du suivi d'.NET s sur Kubernetes

Symptômes : l'application affiche des métriques mais pas de traces; certains services génèrent des rapports tandis que d'autres n'en génèrent pas; ou encore, le traçage s'arrête après un déploiement ou une mise à jour.

Procédure de résolution des incidents :

1. Vérifiez que la version de l'application disponible sur .NET est prise en charge :

   • .NET Core Environnement d'exécution : 5.0 ou version ultérieure

2. Si le webhook AutoTrace est utilisé :

   • Vérifiez qu'il n'y a pas de variables d'environnement qui entrent en conflit.
   • trueVérifiez si l'option d'adhésion est activée.
   • trueSi l'option « opt-in » est activée, vérifiez les étiquettes à tous les niveaux (conteneurs, pod et déploiement). Ils doivent porter le instana-autotrace: "true" label pour pouvoir être équipés de capteurs.

   • Vérifiez que le traçage d'.NET Core s est activé pendant l'installation et qu'aucun autre traceur n'est désactivé, car cela pourrait affecter le fonctionnement du traçage d'.NET Core s

     --set autotrace.instrumentation.manual.netcore=true

3. Si le webhook AutoTrace n'est pas utilisé :

   • Vérifiez que les variables d'environnement sont correctement définies, conformément au suivi manuel.
   • Vérifiez que les paquets Instana.Tracing.Core NuGet et Instana.Tracing.Core.Rewriter.Linux ont bien été ajoutés.

4. Collectez les journaux de trace à l'aide des méthodes de collecte de journaux.

5. Consultez les journaux de traçage de l' Instana :

   • Si les journaux sont vides ou si aucune trace n'apparaît, cela signifie que l'application ne génère pas de segments.
   • Si des traces apparaissent dans les journaux mais que certaines informations (par exemple, l'hôte) manquent, le problème provient de la couche de traçage d'.NET.
   • Si des traces apparaissent dans les journaux et contiennent des informations qui ne figurent pas dans l'interface utilisateur, le problème s'est produit soit au niveau du backend d' Instana, soit au niveau de l'agent.

Symptôme : les pods d'application plantent après l'ajout de l'agent « Instana », mais fonctionnent à nouveau une fois cet agent supprimé.

Procédure de résolution des incidents :

1. Vérifiez que la version de l'application disponible sur .NET est prise en charge :

   • .NET Core Environnement d'exécution : 5.0 ou version ultérieure

2. Collectez les journaux à l'aide d' un volume persistant.

3. Récupérez les fichiers de vidage des pods qui ont planté.

4. Vérifiez s'il existe des exceptions indiquant que le service « Instana » pourrait être à l'origine d'un problème.

Symptôme : Tracer ne se connecte pas au processus, aucun journal n'est disponible et les traces ne s'affichent pas dans l'interface utilisateur.

Procédure de résolution des incidents :

1. Vérifiez que la version de l'application disponible sur .NET est prise en charge :

   • .NET Core Environnement d'exécution : 5.0 ou version ultérieure

2. Recueillez les informations relatives à l'environnement d' Kubernetes, aux applications, ainsi que les journaux des applications et des pods.

3. Si le webhook AutoTrace est utilisé :

   • Vérifiez qu'il n'y a pas de variables d'environnement qui entrent en conflit.
   • trueVérifiez si l'option d'adhésion est activée. Si opt_in est défini sur true, vérifiez les étiquettes à tous les niveaux (conteneurs, pod et déploiement). Ils doivent être munis instana-autotrace: "true" d'une étiquette pour pouvoir être équipés de capteurs.

   • Vérifiez que le traçage de l'.NET Core est activé lors de l'installation et qu'aucun autre outil de traçage n'est désactivé, car cela pourrait affecter le fonctionnement du traçage de.NET Core.

     --set autotrace.instrumentation.manual.netcore=true

4. Si le webhook AutoTrace n'est pas utilisé :

   • Vérifiez que les variables d'environnement sont correctement définies et que les chemins d'accès sont valides, accessibles par le processus ou l'application, et corrects.

5. 0Vérifiez que les variables d'environnement DOTNET_EnableDiagnostics ou COMPlus_EnableDiagnostics ne sont pas définies. Si c'est le cas, réglez-les sur 1 ou supprimez-les complètement.

Symptôme : Tracing plante et affiche OnEnter() method not found une erreur.

Cause : cette erreur se produit si vous ajoutez manuellement les bibliothèques de traçage Instana .NET au projet ou des variables d'environnement au processus ou au déploiement, ce qui induit l'application en erreur quant à l'emplacement à partir duquel charger ces bibliothèques. Le webhook « AutoTrace » ajoute automatiquement les bibliothèques de traçage d'.NET. Vous ne devez pas le faire manuellement.

Résolution :

1. Consultez la section consacrée aux variables d'environnement dans le fichier Dockerfile.

2. Si l'une des variables d'environnement suivantes est présente, supprimez-la et réinstallez :

   • DOTNET_STARTUP_HOOKS
   • CORECLR_ENABLE_PROFILING
   • CORECLR_PROFILER
   • CORECLR_PROFILER_PATH

3. Redéployez votre application.

Lors du dépannage de problèmes liés au webhook AutoTrace ou au traçage .NET sur Kubernetes, recueillez les informations de diagnostic suivantes :

• Spécifications de déploiement de l'application cible avant (si disponibles) et après la mutation :

  kubectl get deployment <target-application-deployment> -o yaml -n <target-application-namespace>

• Webhook déploiement (spécifications et configuration personnalisée) :

  kubectl get deployment instana-autotrace-webhook -n instana-autotrace-webhook -o yaml

• Webhook fichiers journaux du podcast :

  kubectl logs <instana-autotrace-webhook-pod> -n instana-autotrace-webhook

• initContainer journaux :

  kubectl logs <target-application-pod> -n <target-application-namespace> -c instana-instrumentation-init

• Journaux de déploiement de l'application cible :

  kubectl logs -l app.kubernetes.io/name=<target-application-label> -n <target-application-namespace>

Étant donné que la fonctionnalité Log Collector n'est pas disponible pour l' Kubernetes, vous devez collecter les journaux manuellement.

1. Activez les journaux de débogage :

   1. Ajoutez manuellement les variables d'environnement suivantes au niveau de l'application ou intégrez-les au déploiement :

      INSTANA_DEBUG_TRACER=1
      INSTANA_NET_LOG_PATH=/tmp
      INSTANA_NET_LOG_LEVEL=DEBUG
      INSTANA_LOG_SPANS=1
      INSTANA_CLRLOG_PATH=/var/tmp/clr_
      INSTANA_TRACER_ENTEREXIT_LOGGING=true
      COREHOST_TRACE=1 #Controls diagnostics tracing from the hosting components, such as `dotnet.exe`, `hostfxr`, and `hostpolicy`
      COREHOST_TRACEFILE=/tmp/core_host_trace.txt
      DOTNET_CLI_CONTEXT_VERBOSE=true #To enable verbose logging in order to troubleshoot issue(s)

      Remarque : assurez-vous que les chemins d'accès sont valides, accessibles par le processus ou l'application, et corrects.

   2. Redéployez votre application.

2. Collecter les journaux de trace d' Instana :

   1. Connectez-vous à l'un des pods d'agents :

      kubectl exec -it <instana-agent-pod> -n instana-agent -- /bin/bash

   2. Accédez au répertoire de configuration :

      cd /opt/instana/agent/etc/instana/

   3. Editez le fichier de configuration :

      sed -i 's/prefix=/prefix=instanaTraces/g' com.instana.agent.main.sender.File.cfg

      Vous pouvez également vérifier que ces variables sont définies dans le fichier :

      prefix=instanaTraces
      type=traces

      Cette configuration génère un fichier journal contenant toutes les traces dont [agent-dir]/data/log le nom commence par instanaTraces.

   4. Redémarrez l'application.

   5. Laissez le produit agir pendant environ 15 minutes.

   6. Récupérez les fichiers journaux dans les chemins d'accès suivants :

      • Chemin indiqué par la variable INSTANA_NET_LOG_PATH
      • instana-agent-installation-folder/data/log

3. Afficher les journaux de traçage directement dans les pods :

   1. Se connecter au pod de l'agent :

      kubectl exec -it <instana-agent-pod> -n instana-agent -- /bin/bash

   2. Accédez au répertoire des journaux :

      cd /opt/instana/agent/data/log

   3. Liste des fichiers journaux disponibles :

      ls -la

   4. Afficher un fichier journal spécifique :

      cat agent.log or less agent.log

   5. Pour les journaux en temps réel :

      tail -f agent.log

4. Afficher les journaux de traçage sans accéder aux pods :

   1. Afficher la liste des fichiers journaux dans le répertoire :

      kubectl exec <instana-agent-pod> -n instana-agent -- ls -la /opt/instana/agent/data/log

   2. Afficher un fichier journal spécifique :

      kubectl exec <instana-agent-pod> -n instana-agent -- cat /opt/instana/agent/data/log/agent.log

   3. Afficher les 100 dernières lignes d'un fichier journal :

      kubectl exec <instana-agent-pod> -n instana-agent -- tail -n 100 /opt/instana/agent/data/log/agent.log

5. Utilisation strace de pour le débogage : vous pouvez utiliser strace, un utilitaire de diagnostic et de débogage pour Linux, afin de surveiller les interactions entre les processus et le noyau d' Linux :

   strace -f -e trace=open,openat,read,write,close,stat,statx,access dotnet myapp.dll

Les fichiers journaux sont perdus lorsque les pods d'application plantent. Il est donc nécessaire de collecter les journaux à l'aide d'un volume persistant.

Pour activer la journalisation des variables d'environnement INSTANA_CLRLOG_PATH (pour les journaux de débogage CLR) et INSTANA_NET_LOG_PATH (pour les journaux d'.NET ) sur un volume persistant (PV) dans Kubernetes ou OpenShift,, vous devez :

• Créer un volume de stockage ( PersistentVolume, PV) avec une affinité de nœud vers un nœud de travail.
• Créer une demande de stockage ( PersistentVolumeClaim, PVC) auprès du fournisseur de puissance (PV).
• Mettez à jour l' YAML de déploiement pour monter le PVC et enregistrer les journaux.

1. Créer une page de profil ( PersistentVolume, PV) :

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: logs-pv
   spec:
     capacity:
       storage: 1Gi
     accessModes:
       - ReadWriteOnce
     persistentVolumeReclaimPolicy: Retain
     storageClassName: local-storage
     local:
       path: /mnt/data/logs
     nodeAffinity:
       required:
         nodeSelectorTerms:
           - matchExpressions:
               - key: kubernetes.io/hostname
                 operator: In
                 values:
                   - worker0.<cluster-name>.fyre.xyz.com

2. Créer un profilé en PVC ( PersistentVolumeClaim ) :

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: logs-pvc
     namespace: dotnet-apps
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 1Gi
     storageClassName: local-storage

3. Mise à jour de l' YAML de déploiement des applications :

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-dotnet-app
     namespace: dotnet-apps
     labels:
       app: my-dotnet-app
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: my-dotnet-app
     template:
       metadata:
         labels:
           app: my-dotnet-app
           instana-autotrace: 'true'
       spec:
         containers:
         - name: my-dotnet-app
           image: 'docker.io/myrepo/my-dotnet-app:latest'
           ports:
           - containerPort: 8080
             protocol: TCP
           env:
           - name: INSTANA_CLRLOG_PATH
             value: /var/tmp/clr_
           - name: INSTANA_NET_LOG_PATH
             value: /var/tmp/
           - name: INSTANA_LOG_LEVEL
             value: debug
           volumeMounts:
           - name: app-log-volume
             mountPath: /var/tmp
         volumes:
           - name: app-log-volume
             persistentVolumeClaim:
               claimName: logs-pvc

4. Créez le répertoire sur le nœud :

   Assurez-vous que /mnt/data/logs le répertoire existe sur le nœud et qu'il est accessible par le kubelet.

   #Start a debug session on the node:
   oc debug node/worker0.<cluster-name>.fyre.xyz.com
   
   #Switch to the host's root filesystem:
   chroot /host
   
   #Create the required directory:
   mkdir -p /mnt/data/logs
   
   #Exit the debug pod:
   exit

5. Recherchez les fichiers journaux :

   #Start a debug session on the node:
   oc debug node/worker0.<cluster-name>.fyre.xyz.com
   
   #Switch to the host's root filesystem:
   chroot /host
   
   #Locate the folder
   cd /mnt/data/logs
   
   # List the files
   ls
   
   # Read the file
   cat clr_1.log
   
   #Exit the debug pod:
   exit