Configuration du webhook d' AutoTrace

Vous pouvez désactiver les traceurs suivants :

• .NET Core (netcore)
• Python (Python)
• Node.js (Node.js)
• Ruby (ruby)

Si le traçage .NET Core est activé, ne désactivez pas les autres traçages ( Python, Node.js et Ruby ). La désactivation de ces traceurs pourrait avoir une incidence sur la fonctionnalité de traçage d'.NET Core.

Pour désactiver individuellement le traçage des technologies, ajoutez la ligne --set autotrace.<technology>.enabled=false à la commande d'installation du webhook AutoTrace, comme indiqué dans l'exemple suivant. Remplacez <technology> par la technologie pour laquelle vous souhaitez désactiver le traçage.

helm install --create-namespace --namespace instana-autotrace-webhook instana-autotrace-webhook \
  --repo https://agents.instana.io/helm instana-autotrace-webhook \
  --set webhook.imagePullCredentials.password=<download_key> \
  --set autotrace.ruby.enabled=false \
 

Pour déployer le webhook AutoTrace dans un protégé par un ClusterRole ServiceAccount et correspondant à ClusterRoleBinding, définissez le rbac.enabled=true drapeau lorsque vous déployez le graphique Helm.

En plus du contrôle d'accès basé sur les rôles, si vous utilisez des politiques de sécurité des pods, ajoutez rbac.psp.enabled=true aux arguments de l' Helm.

Vous pouvez également appliquer les normes de sécurité des pods grâce au contrôleur d'admission de sécurité des pods intégré. Pour plus d'informations sur Pod Security Admission, consultez la documentation d' Kubernetes.

Si vous définissez les indicateurs rbac.enabled=false et webhook.pod.hostNetwork=false dans l'installation d' Helm, vous pouvez exécuter le webhook AutoTrace avec la norme de sécurité Pod restrictive en exécutant la commande suivante :

kubectl label --overwrite ns instana-autotrace-webhook pod-security.kubernetes.io/enforce=restricted
 

Vous devez héberger le pod du webhook AutoTrace sur le réseau hôte et le configurer correctement afin de vous assurer qu'il est accessible depuis le serveur Kubernetes API (apiserver).

Par défaut, le conteneur est lié au port 42650.

Si le port 42650 est déjà utilisé, le webhook AutoTrace plante. Pour éviter ce problème, vous pouvez modifier le port à l'aide de la webhook.pod.port propriété.

Le webhook AutoTrace instrument toutes les conteneurs dans tous les pods.

Cependant, vous pouvez mieux contrôler les ressources qui sont instrumentées. Pour spécifier que seules les ressources sélectionnées sont instrumentées, ajoutez d'abord autotrace.opt_in=true l'argument lors du déploiement de l' Helm.

Ensuite, spécifiez les ressources qui doivent être instrumentées en ajoutant le instana-autotrace: "true" label aux pods, répliques, ensembles étatiques, ensembles de démons et déploiements requis. AutoTrace webhook utilise cette étiquette pour identifier les ressources requises et les modifier. De plus, vous pouvez définir l'étiquette au niveau d'un espace de noms, où toutes les ressources de cet espace de noms sont instrumentées.

Le instana-autotrace: "false" label est respecté dans les métadonnées des déploiements DaemonSets,, DeploymentConfigs,, ReplicaSets,, StatefulSets, et des espaces de noms, comme dans les modèles de pods imbriqués et dans les pods autonomes.

Vous pouvez exclure des espaces de noms entiers de l'instrumentation automatique à l'aide de la autotrace.exclude.namespaces configuration.

Le instana-autotrace label est respecté dans les métadonnées des déploiements DaemonSets,, DeploymentConfigs,, ReplicaSets, et StatefulSets,, ainsi que dans les modèles de pods imbriqués et dans les pods autonomes.

Vous pouvez exclure des ressources individuelles de l'instrumentation automatique en ajoutant le instana-autotrace: "false" label. AutoTrace webhook ignore les ressources portant cette étiquette, quels que soient les autres paramètres.

Le instana-autotrace label est respecté dans les métadonnées des déploiements DaemonSets,, DeploymentConfigs,, ReplicaSets, et StatefulSets,, ainsi que dans les modèles de pods imbriqués et dans les pods autonomes.

À partir de la version 1.304.6, le webhook InstanaAutoTrace ne modifie que les pods et les ConfigMaps par défaut. Cela facilite les mises à jour et la désinstallation. Lorsqu'un nouveau pod webhook s'exécute, les ressources de niveau supérieur peuvent être redémarrées, ce qui invoquerait de nouveaux pods qui seraient modifiés avec la nouvelle image d'instrumentation.

Si vous avez besoin du comportement précédent consistant à modifier directement les ressources de niveau supérieur (déploiements, daemonsets, replicasets, statefulsets et deploymentconfigs), vous pouvez l'activer à l'aide du autotrace.enableHigherLevelResourceMutation=true drapeau :

helm install --create-namespace --namespace instana-autotrace-webhook instana-autotrace-webhook \
  --repo https://agents.instana.io/helm instana-autotrace-webhook \
  --set webhook.imagePullCredentials.password=<download_key> \
  --set autotrace.enableHigherLevelResourceMutation=true
 

Pour activer l'auto-instrumentation d' NGINX et d'ingress-nginx, vous devez vous inscrire en définissant le label autotrace.ingress_nginx.enabled=true.

Avant de continuer, consultez la section Dépannage du webhook AutoTrace et assurez-vous que les objets concernés sont mis à jour ou recréés.

Le webhook AutoTrace prend en charge le contrôleur d'entrée ingress-nginx Kubernetes 0.34.1 ou version ultérieure avec une politique de support de 45 jours, et est compatible avec le graphique Helm 2.11.2 ou version ultérieure.

Pour configurer un webhook Instana AutoTrace avec NGINX, exécutez la commande suivante :

helm install --create-namespace --namespace instana-autotrace-webhook \
  --repo https://agents.instana.io/helm instana-autotrace-webhook instana-autotrace-webhook \
  --set webhook.imagePullCredentials.password=<download-key> \
  --set autotrace.ingress_nginx.enabled=true

Vous devez ajouter manuellement nginx_status l'emplacement pour les versions standard ou autonomes d' NGINX. Cependant, pour ingress-nginx, la nginx_status directive `location` est automatiquement ajoutée par le webhook « AutoTrace ».

Les mutations de déploiement et d' ConfigMap ation sont nécessaires pour l'instrumentation de l' NGINX Ingress. Par conséquent, installez le webhook Instana AutoTrace avant d'installer l'Ingress NGINX. Si l' NGINX ation d'Ingress est déjà installée, procédez comme suit :

1. Pour supprimer le déploiement existant et en créer un nouveau sans affecter le service, exécutez les commandes suivantes :

   kubectl get deploy ingress-nginx-deployment -o yaml > your_deployment_backup.yaml # Back up your deployment config

   kubectl delete deploy your_deployment_name --cascade=orphan # Delete the existing deployment, cascade option ensures that pods are not deleted.

   kubectl apply -f your_deployment_backup.yaml # Re-apply the deployment config

2. Pour remplacer l' ConfigMap,, exécutez la commande suivante :

   kubectl get cm ingress-nginx-configmap -o yaml > your_configmap_backup.yaml # Back-up your configmap

   kubectl replace --force -f your_configmap_backup.yaml # replace the configmap to trigger mutation webhook API

Pour activer l'instrumentation automatique d' IBM MQ s et d'ACE, vous devez vous inscrire en définissant les étiquettes autotrace.ibmmq.enable=true et autotrace.ace.enable=true. Le webhook AutoTrace prend uniquement en charge les objets IBM MQ et ACE qui s'exécutent dans IBM Cloud Pak for Integration.

Étant donné que IBM Cloud Pak for Integration fonctionne sur le cluster Red Hat OpenShift, vous devez également définir openshift.enabled=true lors du déploiement de l' Helm.

Pour configurer un webhook Instana AutoTrace avec l' IBM MQ et l'instrumentation automatique ACE activées, entrez la commande suivante :

helm install --create-namespace --namespace instana-autotrace-webhook instana-autotrace-webhook \
  --repo https://agents.instana.io/helm instana-autotrace-webhook \
  --set webhook.imagePullCredentials.password=<download_key> \
  --set openshift.enabled=true \
  --set autotrace.ibmmq.enabled=true \
  --set autotrace.ace.enabled=true
 

Si votre application utilise des modules ECMAScript, utilisez le autotrace.nodejs.application_type paramètre. Pour vous assurer que vous utilisez bien la dernière version du webhook « AutoTrace », consultez la section Mise à jour du webhook « AutoTrace ».

• Réglez autotrace.nodejs.application_type sur module_v2 (version Node.js18.19 et ultérieure) :

    helm install --create-namespace --namespace instana-autotrace-webhook instana-autotrace-webhook \
      --repo https://agents.instana.io/helm instana-autotrace-webhook \
      --set webhook.imagePullCredentials.password=<download_key> \
      --set autotrace.nodejs.application_type=module_v2

  Remarque :

  • Cette module_v1 option est obsolète.
  • Définir autotrace.nodejs.application_type uniquement module_v1 lorsque les conditions suivantes sont remplies :
    • Votre application fonctionne sur une version d' Node.js antérieure à 18.19.0.
    • Vous utilisez le webhook AutoTrace ou une version antérieure.
  • Cette module_v1 option n'est plus prise en charge dans les versions actuelles et sera supprimée lors de la prochaine mise à jour. Pour plus de détails, consultez la section Modifications importantes.

• Pour revenir au comportement par défaut ou supprimer complètement l'option de configuration, définissez autotrace.nodejs.application_type sur commonjs:

  helm install --create-namespace --namespace instana-autotrace-webhook instana-autotrace-webhook \
    --repo https://agents.instana.io/helm instana-autotrace-webhook \
    --set webhook.imagePullCredentials.password=<download_key> \
     --set autotrace.nodejs.application_type=commonjs

Le webhook modifie le déploiement et ajoute l' initContainer (Déploiement de l'application). L' initContainer e récupère l'image contenant les fichiers d'instrumentation pour toutes les technologies prises en charge ( Node.js, .NET Core, Ruby, Python et NGINX ) et copie ces fichiers sur le volume. Les fichiers sont stockés dans le volume « emptyDirinstana-instrumentation-volume » sous le montage de volume path /opt/instana/instrumentation/. Les volumes d' emptyDir s sont stockés sur le système de fichiers local du nœud; par conséquent, les fichiers d' augmentent l'utilisation du stockage éphémère du pod. La taille totale des fichiers d'instrumentation est d'environ 300 Mo. Consultez le tableau suivant pour connaître les exigences de stockage de chaque technologie :

Dans certains cas, votre cluster peut n'utiliser que certaines technologies. Pour optimiser, vous pouvez limiter les fichiers copiés pendant l'installation, ce qui réduit le stockage éphémère et améliore le temps d'exécution de l' initContainer. Suivez les étapes suivantes pour limiter les fichiers aux seules technologies dont vous avez besoin :

1. Déterminez les technologies utilisées dans votre cluster. Dans cet exemple, Node.js et .NET Core sont sélectionnés.

2. Configurez l'installation du webhook en activant explicitement les technologies requises qui utilisent les indicateurs de graphique d' Helm. La syntaxe est la suivante :

   --set autotrace.instrumentation.manual.<technology>=true
    

   Remplacer <techonology> par l'un des éléments suivants :

   • nodejs
   • NetCore
   • python
   • ruby
   • nginx

   Par exemple, pour activer à la fois Node.js et .NET Core, utilisez les indicateurs :

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

3. Une fois l'installation du schéma « helm » terminée, veillez à recréer votre déploiement afin que la nouvelle configuration s'applique aux charges de travail du cluster.

Pour plus d'informations sur les variables d'environnement ou les indicateurs du tableau d' Helm, consultez les valeurs Helm.