Accéder aux journaux dans Cloud Logging

Les pages Cloud 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 :

1. Accédez à la page Cloud Service Mesh de la console Google Cloud.

   Accéder à la page "Cloud Service Mesh"

2. Sous Services, sélectionnez le nom du service que vous souhaitez inspecter.

3. Accédez à la page Métriques.

4. Spécifiez une période dans le menu déroulant Période ou définissez une période personnalisée avec la chronologie.

5. 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 :

1. Dans la console Google Cloud, accédez à la page Cloud Service Mesh.

   Accéder à la page "Cloud Service Mesh"

2. Sous Services, sélectionnez le nom du service que vous souhaitez inspecter.

3. Accédez à la page Diagnostic.

4. Spécifiez une période dans le menu déroulant Période ou définissez une période personnalisée avec la chronologie.

5. 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 :

1. Dans la console Google Cloud, accédez à la page Cloud Service Mesh.

   Accéder à la page "Cloud Service Mesh"

2. Sous Services, sélectionnez le nom du service que vous souhaitez inspecter.

3. Accédez à la page Métriques.

4. Spécifiez une période dans le menu déroulant Période ou définissez une période personnalisée avec la chronologie.

5. 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 la télémétrie d'Anthos Service Mesh

Les sections suivantes expliquent comment vérifier l'état de votre réseau maillé et le vérifier les différentes télémétries qui contiennent des détails utiles pour vous aider à résoudre votre problème.

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

Lors de l'installation de Cloud Service Mesh avec le plan de contrôle au sein du cluster, istiod exporte par défaut les métriques vers Google Cloud Observability à 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.

1. Chargez un exemple de tableau de bord :

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

2. Installez le tableau de bord Cloud Service Mesh :

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

3. 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.

1. 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

2. 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 Google Cloud Observability

Les informations suivantes expliquent comment utiliser Google Cloud Observability les journaux d'accès pour résoudre les problèmes de connexion. Observabilité Google Cloud les journaux d'accès et de trafic sont activés par défaut.

Cloud Service Mesh exporte des données dans les journaux d'accès de Google Cloud Observability afin de vous aider à résoudre les types de problèmes suivants :

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

Les journaux d'accès Google Cloud Observability sont activés par défaut pour Cloud Service Mesh sur Google Kubernetes Engine. Vous pouvez activer Google Cloud Observability les journaux d'accès 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

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 de Google Cloud Observability 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 de Cloud 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.

1. 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"
   }

2. 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.

3. 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 Cloud Service Mesh et ne peuvent être activés que dans l'ensemble du maillage.

Remarque : Les journaux Google Cloud Observability sont à privilégier journaux pour la plupart des scénarios de dépannage. Toutefois, si un problème persiste, activez les journaux d'accès Envoy pour tenter de résoudre le problème.

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

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

Pour définir une règle de journal d'accès pour Cloud Service Mesh avec le plan de contrôle au sein du cluster :

1. Créez un fichier de superposition personnalisée IstioOperator qui inclut les valeurs AccessLogPolicyConfig applicables à votre scénario.

2. 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

Remarque : Les options config_dump et stats sont les plus susceptibles de produire des informations exploitables.

Afficher les états des sockets de proxy

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

1. 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

2. 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 dans Cloud Service Mesh.

• Exportez les journaux de trafic vers BigQuery.

• Créez des métriques basées sur les journaux.