Anthos Service Mesh 1.11 est arrivé en fin de vie et n'est plus pris en charge. Consultez la section Mettre à niveau à partir de versions antérieures.

Accédez à la documentation la plus récente ou sélectionnez une autre version disponible :

Versions disponibles

Collecter les journaux Anthos Service Mesh

Les sections suivantes expliquent comment collecter les différents journaux d'Anthos Service Mesh pour résoudre les problèmes ou pour contacter l'assistance Google.

Collecter des journaux à l'aide de l'outil de signalement de bug

Anthos Service Mesh fournit un outil de signalement de bug automatisé qui collecte les journaux de diagnostic pertinents et vous permet de les associer à une demande d'assistance Google.

Avant de commencer, assurez-vous que votre contexte kubeconfig est défini sur le cluster cible.

Vérifiez votre contexte à l'aide de la commande suivante :
```
kubectl config current-context
```
La procédure de téléchargement et d'utilisation de l'outil de signalement de bug dépend de la version d'Anthos Service Mesh que vous utilisez. Consultez le tableau suivant pour déterminer si votre version actuelle de istioctl est suffisante ou si vous devez télécharger une version autonome de l'outil.

Version d'Anthos Service Mesh/Istio	Outil de signalement de bug
Anthos Service Mesh 1.7* et versions ultérieures	`istioctl bug-report`
Anthos Service Mesh 1.6*	SKU spécifique
Anthos Service Mesh 1.5*	SKU spécifique
Istio 1.7*	SKU spécifique
Istio 1.6*	SKU spécifique
Istio 1.5*	SKU spécifique

Pour télécharger la version autonome de l'outil de signalement de bug, procédez comme suit :

Choisissez une distribution dans la liste correspondant à votre environnement de système d'exploitation :
- https://storage.googleapis.com/gke-release/asm/bug-report_darwin_amd64-v2
- https://storage.googleapis.com/gke-release/asm/bug-report_linux_386-v2
- https://storage.googleapis.com/gke-release/asm/bug-report_linux_amd64-v2
- https://storage.googleapis.com/gke-release/asm/bug-report_linux_arm-v2

Utilisez curl pour télécharger la distribution choisie, par exemple :

curl -LO https://storage.googleapis.com/gke-release/asm/bug-report_darwin_amd64-v1

Définissez les autorisations sur le binaire de l'outil de signalement de bug pour qu'il puisse s'exécuter, par exemple :
```
chmod +x bug-report_darwin_amd64-v1
```

Démarrer la collecte des journaux

Pour démarrer la collecte des journaux, exécutez l'outil de signalement de bug et transmettez le fichier de configuration en tant que paramètre. Des options d'exécution supplémentaires sont disponibles pour écraser la configuration si nécessaire. Vous pouvez afficher ces options en utilisant l'argument --help.

Si l'outil de signalement de bug de votre version d'Anthos Service Mesh est déjà contenu dans istioctl, utilisez la commande suivante :

istioctl bug-report

Si vous avez besoin de l'outil autonome de signalement de bug, renommez l'outil et exécutez-le en prenant comme modèle les commandes ci-dessous qui utilisent la distribution Darwin :

mv ./bug-report_darwin_amd64-v1 ./bug-report

./bug-report

Importer votre archive de débogage

Placez votre archive de journaux de débogage dans le répertoire de travail de l'outil de signalement de bug. Vous pouvez décompresser le fichier de l'archive et utiliser les guides de dépannage pour tenter de résoudre le problème vous-même. Toutefois, si vous disposez d'une formule d'assistance, vous pouvez contacter l'assistance Google Cloud qui vous indiquera les étapes supplémentaires à suivre pour importer votre archive de journaux de manière sécurisée.

Collecter manuellement les journaux Anthos Service Mesh

Cette section explique comment collecter manuellement tous les journaux pertinents plutôt que d'utiliser l'outil de signalement de bug d'Anthos Service Mesh.

Journaux d'accès Envoy

Les journaux d'accès du proxy Envoy contiennent des informations détaillées utiles pour le dépannage. Cependant, vous devez les activer et définir le niveau de détail approprié.

Pour plus d'informations sur l'interprétation du contenu des journaux, consultez la page Interpréter les journaux Envoy.

Activer ou désactiver les journaux Envoy

Pour activer les journaux d'accès du proxy Envoy, configurez un fichier superposé pour ASM dans le cluster ou un ConfigMap pour ASM géré.

Augmenter les détails de journalisation

Pour augmenter temporairement le niveau de détail des journaux, utilisez la commande suivante. Ce paramètre est annulé lors de la recréation du pod.

kubectl -n NAMESPACE exec POD_NAME -c istio-proxy -- curl -X POST http://localhost:15000/logging?level=info

Écrire les journaux Envoy dans un dossier

Pour collecter les journaux d'accès du proxy Envoy et les stocker dans un dossier, exécutez la commande suivante :

kubectl logs -l app=APPLICATION_NAME -c istio-proxy > /FILE_PATH

Pour plus d'informations, reportez-vous à la section Obtenir les journaux d'accès Envoy.

Journaux Kubernetes

Kubernetes génère plusieurs journaux contenant des informations sur le comportement des composants Istio, tels que istiod, la passerelle d'entrée et les proxys. Vous pouvez consulter ces journaux pour rechercher des erreurs, ce qui peut restreindre la portée des causes possibles d'un problème.

Enregistrez les journaux istiod à l'aide de la commande suivante :

kubectl -n istio-system logs $(kubectl -n istio-system get pods -lapp=istiod -oname) > ./LOGS_FOLDER/istiod.log

Enregistrez les journaux de la passerelle d'entrée Istio à l'aide de la commande suivante :

kubectl -n istio-system logs $(kubectl -n istio-system get pods -lapp=istio-ingressgateway -oname) > /FILE_PATH

Enregistrez les journaux du proxy Istio à l'aide de la commande suivante :

kubectl -n WORKLOAD_NAMESPACE logs POD_NAME -c istio-proxy > ./LOGS_FOLDER/proxy.log

Fichier de vidage de configuration Kubernetes

Ces informations permettent aux utilisateurs ne disposant pas d'un accès direct au cluster d'afficher l'état de diverses ressources et d'identifier les éventuels problèmes de configuration. La commande suivante écrit la configuration Kubernetes dans un fichier YAML :

for namespace in "istio-system" "ns1" "ns2"; do kubectl get -oyaml deploy,statefulset,job,ingress,endpoints,configmap,event,secret,service,istio-io > ./LOGS_FOLDER/kubernetes.log; done

Vidage de mémoire Envoy

Les vidages de mémoire Envoy ne sont généralement pas utiles pour les utilisateurs finaux. Toutefois, l'assistance Google peut vous demander de récupérer ces fichiers en suivant les étapes ci-dessous dans le cadre du processus de dépannage.

Activez les vidages de mémoire pour tous les proxys de votre maillage en ajoutant ce qui suit à la configuration IstioOperator :
```
spec:
values:
global:
  proxy:
    enableCoreDumps: true
```
Effectuez la réinstallation à l'aide de la commande suivante :
```
istioctl install -f myOperatorFile.yaml
```
Supprimez votre pod cible afin qu'il soit recréé avec les vidages de mémoire du proxy activés.
Laissez le processus s'exécuter et, lorsque le problème se produit, déclenchez le vidage de mémoire en exécutant la commande suivante dans le conteneur istio-proxy :
```
kubectl exec -it POD_NAME -c istio-proxy
```
Recherchez le PID du conteneur Envoy :
```
ps aux | grep -i envoy
```
Utilisez le PID pour arrêter le processus Envoy qui génère un vidage de mémoire :
```
kill -3 PID
```
Attendez que le conteneur redémarre (ou utilisez la commande kill).
Exécutez la commande suivante pour extraire le fichier de vidage de mémoire dans votre répertoire actuel :
```
kubectl cp PID:/var/lib/istio/data/core.proxy -c istio-proxy ./core.proxy
```

Configuration du proxy Envoy

La configuration détaillée du proxy Envoy contient des détails supplémentaires qui peuvent être utiles à des fins de dépannage. Vous pouvez collecter ces informations à l'aide de la commande suivante. Dans cet exemple, ENDPOINT est l'un des éléments suivants (affichés par ordre d'importance) : * /certs * /clusters * /listeners * /config_dump * /memory * /server_info * /stats/prometheus * /runtime

kubectl exec -i POD_NAME -c istio-proxy curl 127.0.0.1:15000/ENDPOINT > out.log