Vous consultez la documentation de Service Mesh 1.22.

Versions disponibles

Cloud Service Mesh
Archive 1.22
Archive 1.21
Archive 1.20
Archive 1.19
Archive 1.18

Cette page a été traduite par l'API Cloud Translation.

Demander des journaux de proxy

Cloud Service Mesh est compatible avec deux types de journaux d'accès différents dans Cloud Logging : les journaux de trafic (également appelés journaux d'accès Google Cloud Observability) et les journaux d'accès Envoy. Cette page vous explique comment activer, désactiver, afficher et interpréter ces journaux. Notez que les journaux de trafic sont activés par défaut.

Activer et désactiver les journaux d'accès

Cloud Service Mesh géré

Journaux d'accès Envoy

Exécutez la commande suivante pour activer les journaux d'accès Envoy et désactiver les journaux de trafic:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-envoy-disable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
  - providers:
      - name: stackdriver
    disabled: true
EOF

Notez que le nom du fournisseur pour le journal des flux est stackdriver.

Journaux de trafic

Par défaut, les journaux de trafic sont activés et les journaux d'accès Envoy sont désactivés. Si vous avez déjà activé les journaux d'accès Envoy et que vous souhaitez activer les journaux de trafic et désactiver les journaux d'accès Envoy, exécutez la commande suivante:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-envoy-enable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
    disabled: true
  - providers:
      - name: stackdriver
EOF

Les deux

Pour activer à la fois les journaux d'accès et les journaux de trafic Envoy, exécutez la commande suivante:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-envoy-and-sd-access-log
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
      - name: stackdriver
EOF

Pour désactiver à la fois les journaux d'accès et les journaux de trafic Envoy, exécutez la commande suivante:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-envoy-and-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
    disabled: true
  - providers:
      - name: stackdriver
    disabled: true
EOF

`istiod` géré

Journaux d'accès Envoy

Exécutez les commandes suivantes pour activer la journaux d'accès Envoy :

Exécutez la commande suivante pour ajouter accessLogFile: /dev/stdout :

cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
EOF

où release-channel est votre version disponible (asm-managed, asm-managed-stable ou asm-managed-rapid).

Exécutez la commande suivante pour afficher le ConfigMap :

 kubectl get configmap istio-release-channel -n istio-system -o yaml

Pour vérifier que les journaux d'accès sont activés, assurez-vous que la ligne accessLogFile: /dev/stdout s'affiche dans la section mesh:.
```
...
apiVersion: v1
data:
  mesh: |
    ....
    accessLogFile: /dev/stdout
...
```

Journaux de trafic

Les journaux de trafic sont activés par défaut.

Dans le cluster

Journaux d'accès Envoy

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

Pour en savoir plus, consultez la page Activer la journalisation des accès Envoy.

Journaux de trafic

Les journaux de trafic sont activés par défaut, sauf si Cloud Service Mesh est installé sur Google Distributed Cloud avec l'autorité de certification Istio (anciennement appelée Citadel).

Pour activer les journaux de trafic sur Google Distributed Cloud avec l'autorité de certification Istio lors de l'installation de Cloud Service Mesh dans le cluster, utilisez l'option --option stackdriver. Vous pouvez également activer les journaux de trafic sur Google Distributed Cloud avec l'autorité de certification Istio après avoir installé Cloud Service Mesh dans le cluster.

Afficher les journaux d'accès

Journaux d'accès Envoy

Ligne de commande

Pour afficher les journaux d'accès Envoy dans le journal istio-proxy, exécutez la commande suivante:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Explorateur de journaux

Pour afficher les journaux d'accès Envoy dans l'explorateur de journaux:

Accédez à l'explorateur de journaux :

Accéder à l'explorateur de journaux
Sélectionnez le projet Google Cloud approprié.
Exécutez la requête suivante :

resource.type="k8s_container" \
resource.labels.container_name="istio-proxy"
resource.labels.cluster_name="CLUSTER_NAME" \
resource.labels.namespace_name="NAMESPACE_NAME" \
resource.labels.pod_name="POD_NAME"

Journaux de trafic

Pour afficher les journaux de trafic dans l'explorateur de journaux:

Accédez à l'explorateur de journaux :

Accéder à l'explorateur de journaux
Sélectionnez le projet Google Cloud approprié.

Exécutez la requête suivante selon que vous consultez les journaux d'accès du client ou du serveur:

Fichiers journaux de serveur

resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/server-accesslog-stackdriver"

Journaux client

resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/client-accesslog-stackdriver"

Pour afficher les journaux de trafic sur la page Cloud Service Mesh d'un service pendant une période donnée, procédez comme suit:

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

Accéder à la page Cloud 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, 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 :

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 Cloud Service Mesh

Les sections suivantes expliquent comment vérifier l'état de votre réseau maillé et comment consulter les différentes données de télémétrie contenant des détails utiles pour le dépannage.

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

Cloud Service Mesh géré

Cloud Service Mesh avec un plan de contrôle Cloud Service Mesh géré n'est pas compatible avec les métriques du plan de contrôle.

`istiod` géré

Cloud Service Mesh avec un plan de contrôle istiod géré n'est pas compatible avec l'inspection des métriques du plan de contrôle dans cette section.

Dans le cluster

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.

Chargez un exemple de tableau de bord :

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

Installez le tableau de bord Cloud 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

Cloud Service Mesh géré

Cloud Service Mesh avec un plan de contrôle Cloud Service Mesh géré ne permet pas de diagnostiquer les retards de configuration.

`istiod` géré

Cloud Service Mesh avec un plan de contrôle istiod géré ne permet pas de diagnostiquer les retards de configuration.

Dans le cluster

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 debug --image istio/base --target istio-proxy -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -- 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 de trafic

Les informations suivantes expliquent comment utiliser les journaux de trafic pour résoudre les problèmes de connexion. Les journaux de trafic sont activés par défaut.

Cloud Service Mesh exporte des données dans les journaux de trafic 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 de trafic sont activés par défaut pour les installations Cloud Service Mesh sur Google Kubernetes Engine. Vous pouvez activer les journaux de trafic 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 de trafic:

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 journaux de trafic peuvent contenir les libellés suivants:

route_name
upstream_cluster
X-Envoy-Original-Path

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.

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 d'accès Envoy

Les étapes suivantes expliquent comment utiliser les journaux d'accès d'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

Les journaux d'accès Envoy ne sont pas activés par défaut dans Cloud Service Mesh et peuvent être activés pour les clusters d'un maillage.

Vous pouvez résoudre les échecs de connexion ou de 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 Envoy 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

Cloud Service Mesh géré

Pour configurer des journaux d'accès pour Cloud Service Mesh avec un plan de contrôle Cloud Service Mesh géré, consultez la section Activer les journaux d'accès.

`istiod` géré

Pour configurer des journaux d'accès pour Cloud Service Mesh avec un plan de contrôle istiod géré, consultez la section Activer les journaux d'accès.

Dans le cluster

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:

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 -n NAMESPACE_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 debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
```

Affichez un résumé des statistiques liées aux sockets :

kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- 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 -n NAMESPACE_NAME -c istio-proxy

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

kubectl logs POD_NAME -n NAMESPACE_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.

Demander des journaux de proxy

Activer et désactiver les journaux d'accès

Cloud Service Mesh géré

Journaux d'accès Envoy

Journaux de trafic

Les deux

istiod géré

Journaux d'accès Envoy

Journaux de trafic

Dans le cluster

Journaux d'accès Envoy

Journaux de trafic

Afficher les journaux d'accès

Journaux d'accès Envoy

Ligne de commande

Explorateur de journaux

Journaux de trafic

Fichiers journaux de serveur

Journaux client

Interpréter la télémétrie Cloud Service Mesh

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

Cloud Service Mesh géré

istiod géré

Dans le cluster

Diagnostiquer les retards de configuration

Cloud Service Mesh géré

istiod géré

Dans le cluster

Interpréter les journaux de trafic

Résoudre les erreurs 404 et 503

Interpréter les journaux d'accès Envoy

Utiliser l'explorateur de journaux pour interroger les journaux

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

Cloud Service Mesh géré

istiod géré

Dans le cluster

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

Afficher les états des sockets de proxy

Journaux istio-proxy et istio-init

Étapes suivantes

`istiod` géré

`istiod` géré

`istiod` géré

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

`istiod` géré

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