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

Accéder aux journaux dans Cloud Logging

Les pages Anthos Service Mesh fournissent des liens vers trois types de journaux différents dans Cloud Logging : les journaux d'application, les journaux d'erreurs et les journaux de trafic.

Accéder aux journaux d'application

Pour afficher les journaux d'application d'un service pendant une période donnée, procédez comme suit :

Accédez à la page Anthos Service Mesh de Google Cloud Console.

Accéder à la page Anthos Service Mesh
Sous Services, sélectionnez le nom du service que vous souhaitez inspecter.
Accédez à la page Métriques.
Spécifiez une période dans le menu déroulant Période ou définissez une période personnalisée avec la chronologie.
Cliquez sur Afficher les journaux d'application.

Les journaux d'application sont les journaux générés par votre propre code d'application et sont associés à la ressource surveillée correspondante (k8s_container ou gce_instance) utilisée par votre application.

Accéder aux journaux d'erreurs

Pour afficher les journaux d'erreurs d'un service pendant une période donnée, procédez comme suit :

Dans Google Cloud Console, accédez à la page Anthos Service Mesh.

Accéder à la page Anthos Service Mesh
Sous Services, sélectionnez le nom du service que vous souhaitez inspecter.
Accédez à la page Diagnostic.
Spécifiez une période dans le menu déroulant Période ou définissez une période personnalisée avec la chronologie.
Dans l'angle supérieur droit de la fenêtre, cliquez sur Ouvrir dans Logging.

Accéder aux journaux de trafic

Pour afficher les journaux de trafic d'un service pendant une période donnée ou pour accéder aux journaux dans Istio, procédez comme suit :

Dans Google Cloud Console, accédez à la page Anthos Service Mesh.

Accéder à la page Anthos Service Mesh
Sous Services, sélectionnez le nom du service que vous souhaitez inspecter.
Accédez à la page Métriques.
Spécifiez une période dans le menu déroulant Période ou définissez une période personnalisée avec la chronologie.
Sous Sélectionner une option de filtrage, et cliquez sur Afficher les journaux du trafic.

Le journal de trafic est nommé server-accesslog-stackdriver et est associé à la ressource surveillée correspondante (k8s_container ou gce_instance) utilisée par votre service. Le journal de trafic contient 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
Si le traçage est activé, des informations de trace telles que l'échantillonnage, l'ID de trace et l'ID de période

Voici un exemple d'entrée de journal :

{
  insertId: "1awb4hug5pos2qi"
  httpRequest: {
    requestMethod: "GET"
    requestUrl: "YOUR-INGRESS/productpage"
    requestSize: "952"
    status: 200
    responseSize: "5875"
    remoteIp: "10.8.0.44:0"
    serverIp: "10.56.4.25:9080"
    latency: "1.587232023s"
    protocol: "http"
  }
  resource: {
    type: "k8s_container"
    labels: {
      location: "us-central1-a"
      project_id: "YOUR-PROJECT"
      pod_name: "productpage-v1-76589d9fdc-ptnt9"
      cluster_name: "YOUR-CLUSTER-NAME"
      container_name: "productpage"
      namespace_name: "default"
    }
  }
  timestamp: "2020-04-28T19:55:21.056759Z"
  severity: "INFO"
  labels: {
    destination_principal: "spiffe://cluster.local/ns/default/sa/bookinfo-productpage"
    response_flag: "-"
    destination_service_host: "productpage.default.svc.cluster.local"
    source_app: "istio-ingressgateway"
    service_authentication_policy: "MUTUAL_TLS"
    source_name: "istio-ingressgateway-5ff85d8dd8-mwplb"
    mesh_uid: "YOUR-MESH-UID"
    request_id: "021ce752-9001-4ac6-b6d6-3b15f5d3632"
    destination_namespace: "default"
    source_principal:  "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    destination_workload: "productpage-v1"
    destination_version: "v1"
    source_namespace: "istio-system"
    source_workload: "istio-ingressgateway"
    destination_name: "productpage-v1-76589d9fdc-ptnt9"
    destination_app: "productpage"
  }
  trace: "projects/YOUR-PROJECT/traces/d4197f59b7a43e3aeff3571bac99d536"
  receiveTimestamp: "2020-04-29T03:07:14.362416217Z"
  spanId: "43226343ca2bb2b1"
  traceSampled: true
  logName: "projects/YOUR-PROJECT/logs/server-accesslog-stackdriver"
  receiveTimestamp: "2020-04-28T19:55:32.185229100Z"
}

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 avec le plan de contrôle du cluster, 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 dans la liste un tableau de bord nommé Istio Control Plane Dashboard. Pour en savoir plus, consultez la section Afficher le tableau de bord installé.

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. Les journaux d'accès/de trafic de l'observabilité Google Cloud sont activés par défaut.

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 d'observabilité Google Cloud sont activés par défaut pour les installations Anthos Service Mesh sur Google Kubernetes Engine. Vous pouvez activer les journaux d'accès de l'observabilité Google Cloud en exécutant à nouveau asmcli install. Utilisez les options que vous avez initialement installées, mais omettez la superposition personnalisée responsable de la désactivation de Stackdriver.

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.

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 la visionneuse 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

Pour configurer la journalisation du proxy pour le service Anthos Service Mesh géré, consultez la page Journaux d'accès Envoy.

Pour définir une règle de journal d'accès pour Anthos Service Mesh avec le plan de contrôle au sein du cluster, procédez comme suit :

Créez un fichier de superposition personnalisée IstioOperator qui inclut les valeurs AccessLogPolicyConfig applicables à votre scénario.
Transmettez ce fichier à asmcli à l'aide de l'option --custom_overlay pour mettre à jour la configuration du plan de contrôle au sein du cluster. Pour en savoir plus sur l'exécution de asmcli install avec un fichier de superposition personnalisée, consultez la section Installer avec des fonctionnalités facultatives.

Attention : Si vous avez personnalisé l'installation précédente, vous devez reprendre les mêmes personnalisations lorsque vous réinstallez le plan de contrôle, afin d'inclure le fichier avec les paramètres AccessLogPolicyConfig. Le fait de ne pas spécifier de fichier de superposition ne compromet pas la réussite de l'installation. Cependant, votre maillage de services va se retrouver avec une configuration différente de celle souhaitée, car les valeurs omises sont rétablies sur les valeurs par défaut lors du redéploiement du plan de contrôle.

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

Étapes suivantes

Procédez à l'intégration avec Cloud Trace. Cloud Trace est une fonctionnalité facultative d'Anthos Service Mesh.
Exportez les journaux de trafic vers BigQuery.
Créez des métriques basées sur les journaux.