Anthos Service Mesh 1.6 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

1.20 (la plus récente)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Interpréter les journaux Anthos Service Mesh

Dans les sections suivantes, nous expliquons comment vérifier l'état de votre maillage et comment consulter les différents journaux contenant des détails utiles pour le dépannage.

Interpréter les métriques du plan de contrôle

Lors de l'installation d'Anthos Service Mesh à l'aide du profil asm-gcp, Istiod exporte par défaut les métriques vers l'observabilité Google Cloud à des fins de surveillance. Istiod applique à ces métriques le préfixe istio.io/control et donne des informations sur l'état du plan de contrôle, comme par exemple le nombre de proxys connectés à chaque instance de celui-ci, les événements de configuration, les requêtes push et les validations.

Pour observer ou dépanner le plan de contrôle, suivez les étapes ci-après.

Chargez un exemple de tableau de bord :

git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples && git checkout asm

Installez le tableau de bord Anthos Service Mesh :

gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json

Recherchez un tableau de bord nommé Istio Control Plane Dashboard dans la liste. Pour en savoir plus, consultez la section Afficher le tableau de bord installé.

Si vous n'utilisez pas le profil asm-gcp, vous pouvez toujours activer les métriques du plan de contrôle en ajoutant les variables d'environnement au déploiement Istiod :
```
- name: ENABLE_STACKDRIVER_MONITORING
value: "true"
```
En outre, vous pouvez ajouter cette variable d'environnement à l'aide de l'option d'installation components.pilot.k8s.env.

Pour obtenir la liste complète des métriques disponibles, consultez la page Métriques exportées.

Diagnostiquer les retards de configuration

Les étapes suivantes expliquent comment utiliser la métrique pilot_proxy_convergence_time pour diagnostiquer un délai entre une modification de configuration et la convergence de tous les proxys.

Exécutez une commande shell dans un pod :

kubectl exec -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -c istio-proxy -- curl -s

Accédez à localhost:15014 et grep pour convergence dans les métriques :
```
curl http://localhost:15014/metrics | grep convergence
```

Interpréter les journaux d'accès à l'observabilité Google Cloud

Les informations suivantes expliquent comment résoudre les problèmes de connexion à l'aide des journaux d'accès à l'observabilité de Google Cloud.

Anthos Service Mesh exporte des données dans les journaux d'accès d'observabilité Google Cloud qui peuvent vous aider à déboguer les types de problèmes suivants:

Échecs et flux de trafic
Routage des requêtes de bout en bout

Les journaux d'accès/de trafic Google Cloud sont activés par défaut dans le profil asm-gcp sur l'ensemble du maillage. Toutefois, s'ils ne sont pas encore activés, vous pouvez utiliser la commande suivante :

istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION \
    --set values.telemetry.v2.stackdriver.enabled=true \
    --set values.telemetry.v2.stackdriver.logging=true

Il existe deux types de journaux d'accès :

Les journaux d'accès au serveur offrent un aperçu des requêtes côté serveur. Les journaux d'accès côté serveur sont situés sous server-accesslog-stackdriver et sont associés à la ressource k8s_container. Utilisez la syntaxe d'URL suivante pour afficher les journaux d'accès côté serveur :
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID
```
Les journaux d'accès client offrent une vue des requêtes côté client. Ils sont situés sous client-accesslog-stackdriver et sont associés à la ressource k8s_pod. Utilisez la syntaxe d'URL suivante pour afficher les journaux d'accès côté client :
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID
```
.

Seuls les journaux d'erreurs client sont activés par défaut afin de réduire les coûts de journalisation. Toutefois, vous pouvez activer tous les journaux client (réussites et erreurs) à l'aide de la commande suivante :

istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION 

    --set values.telemetry.v2.stackdriver.enabled=true 

    --set values.telemetry.v2.stackdriver.outboundAccessLogging=FULL

Les journaux d'accès contiennent les informations suivantes :

Les propriétés des requêtes HTTP, telles que l'ID, l'URL, la taille, la latence et les en-têtes courants
Des informations sur les charges de travail source et de destination, telles que le nom, l'espace de noms, l'identité et les libellés courants
Des informations sur les révisions et les services canoniques source et de destination
Si le traçage est activé, les journaux contiennent des informations de trace, telles que l'échantillonnage, l'ID de trace et l'ID de période.

Les informations affichées dans les journaux d'accès d'observabilité Google Cloud proviennent des journaux d'accès Envoy, lorsque vous les activez dans la configuration Istio. Ces informations contiennent les en-têtes suivants :

route_name
upstream_cluster
X-Envoy-Original-Path
X-Envoy-Original-Host

Voici un exemple d'entrée de journal :

{
  "insertId": "1j84zg8g68vb62z",
  "httpRequest": {
    "requestMethod": "GET",
    "requestUrl": "http://35.235.89.201:80/productpage",
    "requestSize": "795",
    "status": 200,
    "responseSize": "7005",
    "remoteIp": "10.168.0.26:0",
    "serverIp": "10.36.3.153:9080",
    "latency": "0.229384205s",
    "protocol": "http"
  },
  "resource": {
    "type": "k8s_container",
    "labels": {
      "cluster_name": "istio-e2e22",
      "namespace_name": "istio-bookinfo-1-68819",
      "container_name": "productpage",
      "project_id": "***",
      "location": "us-west2-a",
      "pod_name": "productpage-v1-64794f5db4-8xbtf"
    }
  },
  "timestamp": "2020-08-13T21:37:42.963881Z",
  "severity": "INFO",
  "labels": {
    "protocol": "http",
    "upstream_host": "127.0.0.1:9080",
    "source_canonical_service": "istio-ingressgateway",
    "source_namespace": "istio-system",
    "x-envoy-original-path": "",
    "source_canonical_revision": "latest",
    "connection_id": "32",
    "upstream_cluster": "inbound|9080|http|productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "requested_server_name": "outbound_.9080_._.productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_version": "v1",
    "destination_workload": "productpage-v1",
    "source_workload": "istio-ingressgateway",
    "destination_canonical_revision": "v1",
    "mesh_uid": "cluster.local",
    "source_principal": "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account",
    "x-envoy-original-dst-host": "",
    "service_authentication_policy": "MUTUAL_TLS",
    "destination_principal": "spiffe://cluster.local/ns/istio-bookinfo-1-68819/sa/bookinfo-productpage",
    "response_flag": "-",
    "log_sampled": "false",
    "destination_service_host": "productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_name": "productpage-v1-64794f5db4-8xbtf",
    "destination_canonical_service": "productpage",
    "destination_namespace": "istio-bookinfo-1-68819",
    "source_name": "istio-ingressgateway-6845f6d664-lnfvp",
    "source_app": "istio-ingressgateway",
    "destination_app": "productpage",
    "request_id": "39013650-4e62-9be2-9d25-78682dd27ea4",
    "route_name": "default"
  },
  "logName": "projects/***/logs/server-accesslog-stackdriver",
  "trace": "projects/***t/traces/466d77d15753cb4d7749ba5413b5f70f",
  "receiveTimestamp": "2020-08-13T21:37:48.758673203Z",
  "spanId": "633831cb1fda4fd5",
  "traceSampled": true
}

Vous pouvez utiliser ce journal de différentes manières :

Intégrez-le à Cloud Trace, une fonctionnalité facultative d'Anthos Service Mesh.
Exportez les journaux de trafic vers BigQuery, où vous pouvez exécuter des requêtes telles que la sélection de toutes les requêtes qui prennent plus de cinq secondes.
Créez des métriques basées sur les journaux.
Résoudre les erreurs 404 et 503

Résoudre les erreurs `404` et `503`

L'exemple suivant explique comment utiliser ce journal pour résoudre les problèmes lorsqu'une requête échoue avec un code de réponse 404 ou 503.

Dans le journal d'accès client, recherchez une entrée de ce type :

httpRequest: {
requestMethod: "GET"
requestUrl: "://IP_ADDRESS/src/Util/PHP/eval-stdin.php"
requestSize: "2088"
status: 404
responseSize: "75"
remoteIp: "10.168.0.26:34165"
serverIp: "10.36.3.149:8080"
latency: "0.000371440s"
protocol: "http"
}

Accédez aux libellés de l'entrée du journal d'accès. Recherchez le champ response_flag qui se présente comme suit :
```
response_flag: "NR"
```
La valeur NR est l'acronyme de NoRoute, qui signifie qu'aucune route n'a été trouvée pour la destination ou qu'il n'y a pas de chaîne de filtre correspondante pour une connexion en aval. De même, vous pouvez utiliser le libellé response_flag pour résoudre les erreurs 503.
Si vous rencontrez des erreurs 503 dans les journaux d'accès client et serveur, vérifiez que les noms de port définis pour chaque service correspondent au nom du protocole utilisé entre eux. Par exemple, si un client binaire golang se connecte à un serveur golang à l'aide du protocole HTTP alors que le port est nommé http2, le protocole ne se négocie pas automatiquement de façon correcte.

Pour en savoir plus, consultez la section Options de réponse.

Interpréter les journaux Envoy

Les étapes suivantes expliquent comment utiliser les journaux d'accès du proxy Envoy pour afficher le trafic entre les deux extrémités d'une connexion à des fins de dépannage.

Les journaux d'accès Envoy sont utiles pour diagnostiquer des problèmes tels que les suivants :

Échecs et flux de trafic
Routage des requêtes de bout en bout

Par défaut, les journaux d'accès ne sont pas activés dans Anthos Service Mesh et ne peuvent être activés que dans l'ensemble du maillage.

Vous pouvez résoudre les échecs de connexion/requête en générant dans votre application une activité qui déclenche une requête HTTP, puis en inspectant la requête associée dans les journaux sources ou de destination.

Si vous déclenchez une requête qui apparaît dans les journaux du proxy source, cela indique que la redirection du trafic iptables fonctionne correctement et que le proxy Envoy gère le trafic. Si vous constatez des erreurs dans les journaux, générez un fichier de vidage de configuration Envoy et vérifiez la configuration du cluster Envoy. Si vous voyez la requête, mais que le journal ne comporte aucune erreur, vérifiez les journaux du proxy de destination.

Si la requête apparaît dans les journaux du proxy de destination, cela signifie que le maillage fonctionne correctement. Si une erreur s'affiche à la place, exécutez un vidage de la configuration Envoy et vérifiez les valeurs appropriées pour le port de trafic défini dans la configuration de l'écouteur.

Si le problème persiste après avoir suivi les étapes précédentes, il se peut qu'Envoy soit pas en mesure de négocier automatiquement le protocole entre le side-car et son pod d'application. Assurez-vous que le nom du port du service Kubernetes, par exemple http-80, correspond au protocole utilisé par l'application.

Utiliser l'explorateur de journaux pour interroger les journaux

Vous pouvez interroger des journaux d'accès spécifiques à l'aide de l'interface de l'explorateur de journaux. Par exemple, pour interroger toutes les requêtes pour lesquelles MULTUAL_TLS est activé et qui utilisent le protocole grpc, ajoutez ce qui suit à la requête de journaux d'accès au serveur :

labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"

Définir une règle de journal d'accès

Vous pouvez définir une règle de journalisation proxy qui détermine le type d'informations que vous collectez. Cela permet de contrôler le champ d'application de vos journaux afin de résoudre les problèmes. Par exemple, la journalisation enregistre automatiquement les erreurs, mais vous pouvez définir logWindowDuration pour également capturer les événements réussis pour une durée spécifique ou définir la durée sur zéro pour consigner tous les accès. La règle est définie au niveau du maillage ou du cluster.

Pour activer une règle de journal d'accès, utilisez la commande suivante :

istioctl install --set profile=PROFILE_NAME \
    --set values.telemetry.v2.stackdriver.enabled=true \
    --set values.telemetry.v2.stackdriver.logging=true \
    --set values.telemetry.accessLogPolicy.enabled=true

Pour en savoir plus sur les options de configuration de journal d'accès, telles que logWindowDuration, consultez la page Configuration de ConfigLogPolicy.

Afficher des informations spécifiques à un service ou une charge de travail

Si vous rencontrez un problème avec un service ou une charge de travail spécifique plutôt qu'un problème à l'échelle du maillage, inspectez les proxys Envoy individuels et récupérez les informations pertinentes à partir de ceux-ci. Pour collecter des informations sur une charge de travail spécifique et ses proxys, vous pouvez utiliser pilot-agent :

kubectl exec POD_NAME -c istio-proxy -- pilot-agent request GET SCOPE

Dans l'exemple, SCOPE correspond à l'une des options suivantes :

certs : certificats dans l'instance Envoy
clusters : clusters où Envoy est configuré
config_dump : vide la configuration Envoy
listeners : écouteurs où Envoy est configuré
logging : permet d'afficher et de modifier les paramètres de journalisation
stats : statistiques Envoy
stats/prometheus : statistiques Envoy en tant qu'enregistrements Prometheus

Afficher les états des sockets de proxy

Vous pouvez examiner directement l'état des sockets du proxy Envoy à l'aide du processus suivant.

Affichez la liste des sockets établis, y compris ceux dont l'état est TIME_WAIT, ce qui peut nuire à l'évolutivité si leur nombre est élevé :
```
kubectl exec POD_NAME -c istio-proxy -- ss -anopim
```
Affichez un résumé des statistiques liées aux sockets :
```
kubectl exec POD_NAME -c istio-proxy -- ss -s
```

Pour plus d'informations, consultez la section Présentation de la commande ss.

Journaux `istio-proxy` et `istio-init`

En outre, récupérez les journaux istio-proxy et examinez leur contenu pour identifier les erreurs pouvant être à l'origine du problème :

kubectl logs POD_NAME -c istio-proxy

Vous pouvez faire de même pour le conteneur init :

kubectl logs POD_NAME -c istio-init