Stai visualizzando la documentazione di Service Mesh 1.21.

Versioni disponibili

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

Questa pagina è stata tradotta dall'API Cloud Translation.

Richiedi log del proxy

Cloud Service Mesh supporta due diversi tipi di log degli accessi in Cloud Logging: Log del traffico (anche noti come log di accesso di Google Cloud Observability) e Log di accesso di Envoy. Questa pagina spiega come attivare, disattivare, visualizzare e interpretare questi log. Tieni presente che i log del traffico sono attivati per impostazione predefinita.

Attivazione e disattivazione dei log di accesso

Cloud Service Mesh gestito

Log di accesso di Envoy

Esegui il seguente comando per abilitare i log di accesso di Envoy e disattivare i log di traffico:

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

Tieni presente che il nome del provider per il log del traffico è stackdriver.

Log sul traffico

Per impostazione predefinita, i log del traffico sono abilitati e i log di accesso di Envoy sono disabilitati. Se in precedenza hai attivato i log di accesso di Envoy e vuoi attivare i log sul traffico e disattivare i log di accesso di Envoy, esegui il seguente comando:

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

Entrambi

Per abilitare sia i log di accesso che i log del traffico Envoy, esegui questo comando :

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

Per disattivare sia i log di accesso di Envoy sia i log di traffico, esegui il seguente comando:

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` gestita

Log di accesso di Envoy

Esegui questi comandi per abilitare il logging degli accessi a Envoy:

Esegui il seguente comando per aggiungere 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

dove release-channel è il tuo canale di rilascio (asm-managed, asm-managed-stable o asm-managed-rapid).

Esegui questo comando per visualizzare il file configmap:

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

Per verificare che il logging degli accessi sia abilitato, assicurati che la riga accessLogFile: /dev/stdout sia visualizzata nella sezione mesh:.
```
...
apiVersion: v1
data:
  mesh: |
    ....
    accessLogFile: /dev/stdout
...
```

Log sul traffico

I log del traffico sono abilitati per impostazione predefinita.

All'interno del cluster

Log di accesso di Envoy

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

Per ulteriori informazioni, consulta Attivare la registrazione degli accessi di Envoy.

Log sul traffico

I log sul traffico sono abilitati per impostazione predefinita a meno che Cloud Service Mesh non sia installato su Google Distributed Cloud with Istio CA (precedentemente noto come Citadel).

Per attivare i log del traffico su Google Distributed Cloud con la CA Istio durante l'installazione di Cloud Service Mesh nel cluster, utilizza il flag --option stackdriver. In alternativa, puoi attivare il traffico log su Google Distributed Cloud with Istio CA dopo l'installazione di Cloud Service Mesh nel cluster.

Visualizzazione dei log di accesso

Log di accesso di Envoy

Riga di comando

Per visualizzare i log di accesso di Envoy nel log istio-proxy, esegui questo comando:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Esplora log

Per visualizzare i log di accesso di Envoy nel Esplora log:

Vai a Esplora log:

Vai a Esplora log
Seleziona il progetto Google Cloud appropriato.
Esegui questa query:

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"

Log sul traffico

Per visualizzare i log di traffico nel Esplora log:

Vai a Esplora log:

Vai a Esplora log
Seleziona il progetto Google Cloud appropriato.

Esegui la seguente query a seconda che tu stia visualizzando il client o log di accesso al server:

Log del server

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

Log client

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

Visualizzare i log del traffico nella pagina Cloud Service Mesh per un servizio durante per un periodo di tempo specificato, segui questi passaggi:

Nella console Google Cloud, vai alla pagina Cloud Service Mesh.

Vai alla pagina di Cloud Service Mesh
In Servizi, seleziona il nome del servizio che vuoi ispezionare.
Vai alla pagina Metriche.
Specifica un intervallo di tempo dal menu a discesa Intervallo di tempo oppure impostare un intervallo personalizzato con la sequenza temporale.
In Seleziona un'opzione di filtro, fai clic su Visualizza i log del traffico:

Il log del traffico è denominato server-accesslog-stackdriver ed è collegato alla risorsa monitorata corrispondente (k8s_container oppure gce_instance), il tuo servizio è che utilizzano. Il log sul traffico contiene le seguenti informazioni:

Proprietà delle richieste HTTP, ad esempio ID, URL, dimensioni, latenza e intestazioni comuni.
Informazioni sui carichi di lavoro di origine e di destinazione, ad esempio nome, spazio dei nomi identità ed etichette comuni.
Se il monitoraggio è attivato, le informazioni sulla traccia, ad esempio il campionamento, l'ID traccia e l'ID span.

Un esempio di voce di log è il seguente:

{
  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"
}

Interpretare la telemetria di Cloud Service Mesh

Le sezioni seguenti spiegano come controllare lo stato del mesh ed eseguire la revisione i vari dati di telemetria che contengono dettagli utili per aiutarti risoluzione dei problemi.

Interpreta le metriche del piano di controllo

Cloud Service Mesh gestito

Cloud Service Mesh con un piano di controllo Cloud Service Mesh gestito non supporta le metriche del piano di controllo.

`istiod` gestita

Cloud Service Mesh con un piano di controllo istiod gestito non supporta l'ispezione delle metriche del piano di controllo in questa sezione.

Nel cluster

Quando installi Cloud Service Mesh con il piano di controllo interno al cluster, istiod esporta le metriche in Google Cloud Observability per il monitoraggio, per impostazione predefinita. istiod antepone queste metriche a istio.io/control e fornisce informazioni sullo stato del piano di controllo, ad esempio il numero di proxy connessi a ogni istanza del piano di controllo, eventi di configurazione, push e convalide.

Osserva o risolvi i problemi del piano di controllo seguendo i passaggi riportati di seguito.

Carica una dashboard di esempio:

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

Installa la dashboard di Cloud Service Mesh:

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

Cerca una dashboard denominata Istio Control Plane Dashboard nell'elenco. Per ulteriori informazioni, vedi Visualizzazione della dashboard installata.

Per l'elenco completo delle metriche disponibili, consulta: Metriche esportate.

Diagnosticare i ritardi di configurazione

Cloud Service Mesh gestito

Cloud Service Mesh con un piano di controllo Cloud Service Mesh gestito non supporta diagnosticare i ritardi di configurazione.

Gestito `istiod`

Cloud Service Mesh con un piano di controllo Istio gestito non supporta diagnosticare i ritardi di configurazione.

All'interno del cluster

I passaggi riportati di seguito spiegano come utilizzare la metrica pilot_proxy_convergence_time per diagnosticare un ritardo tra una modifica alla configurazione e la convergenza di tutti i proxy.

Esegui un comando shell in 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

Accedi a localhost:15014 e grep per convergence nelle metriche:
```
curl http://localhost:15014/metrics | grep convergence
```

Interpretare i log del traffico

Le seguenti informazioni spiegano come utilizzare i log del traffico per risolvere i problemi di connessione. I log del traffico sono abilitati per impostazione predefinita.

Cloud Service Mesh esporta i dati nei log del traffico che possono aiutarti a eseguire il debug i seguenti tipi di problemi:

Flusso di traffico ed errori
Routing delle richieste end-to-end

I log sul traffico sono abilitati per impostazione predefinita per le installazioni di Cloud Service Mesh su Google Kubernetes Engine. Puoi attivare i log sul traffico eseguendo di nuovo asmcli install. Utilizza le funzionalità di le stesse opzioni che hai installato inizialmente, ma ometti l'overlay personalizzato ha disabilitato Stackdriver.

Esistono due tipi di log relativi al traffico:

I log di accesso al server forniscono una vista lato server delle richieste. Si trovano in server-accesslog-stackdriver, collegate alla risorsa monitoratak8s_container. Utilizza la seguente sintassi dell'URL per visualizzare i log di accesso lato server:
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID
```
I log di accesso client forniscono una visualizzazione lato client delle richieste. Si trovano in client-accesslog-stackdriver, associate alla risorsa monitorata k8s_pod. Utilizza la seguente sintassi dell'URL per visualizzare i log di accesso lato client:
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID
```

I log di accesso contengono le seguenti informazioni:

Proprietà delle richieste HTTP, ad esempio ID, URL, dimensioni, latenza e intestazioni comuni.
Informazioni sui carichi di lavoro di origine e di destinazione, ad esempio nome, spazio dei nomi, identità ed etichette comuni.
Informazioni sulle revisioni e sui servizi canonici di origine e di destinazione.
Se il tracciamento è abilitato, i log contengono informazioni di traccia, come campionamento, ID traccia e ID intervallo.

I log sul traffico possono contenere le seguenti etichette:

route_name
upstream_cluster
X-Envoy-Original-Path

Ecco un esempio di voce di log:

{
  "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
}

Puoi utilizzare questo log in diversi modi:

Esegui l'integrazione con Cloud Trace, una funzionalità facoltativa di Cloud Service Mesh.
Esporta i log del traffico in BigQuery, dove puoi eseguire query come la selezione di tutte le richieste richiede più di 5 secondi.
Crea metriche basate su log.
Risolvi i problemi relativi a 404 e 503

Risolvere i problemi relativi agli errori `404` e `503`

L'esempio seguente spiega come utilizzare questo log per risolvere i problemi quando una richiesta non va a buon fine con un codice di risposta 404 o 503.

Nel log di accesso client, cerca una voce simile alla seguente:

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

Vai alle etichette nella voce del log di accesso. Trova il campo response_flag con un aspetto simile al seguente:
```
response_flag: "NR"
```
Il valore NR è l'acronimo di NoRoute, il che significa che non è stata trovata alcuna route per destinazione o non esisteva una catena di filtri corrispondente per un downstream connessione. Analogamente, puoi utilizzare l'etichetta response_flag per risolvere i problemi 503 errori.
Se visualizzi errori 503 nei log di accesso client e server, verifica che i nomi delle porte impostati per ogni servizio corrispondono al nome del protocollo in uso tra di loro. Ad esempio, se un client binario golang si connette a un server golang tramite HTTP, ma la porta è denominata http2, il protocollo non verrà negoziata automaticamente in modo corretto.

Per ulteriori informazioni, vedi dei flag di risposta.

Interpreta i log di accesso di Envoy

I passaggi riportati di seguito spiegano come utilizzare i log di accesso di Envoy per mostrare il traffico tra entrambe le estremità di una connessione a fini di risoluzione dei problemi.

I log di accesso di Envoy sono utili per diagnosticare problemi quali:

Flusso di traffico e errori
Routing delle richieste end-to-end

I log di accesso di Envoy non sono abilitati per impostazione predefinita in Cloud Service Mesh e possono essere attivati per i cluster in un mesh.

Puoi risolvere gli errori di connessione o di richiesta generando attività in alla tua applicazione che attiva una richiesta HTTP, quindi ispezionare i richiesta nei log di origine o di destinazione.

Se attivi una richiesta e questa viene visualizzata nei log del proxy di origine, significa che il reindirizzamento del traffico iptables funziona correttamente e che il proxy Envoy gestisce il traffico. Se visualizzi errori nei log, genera un dump della configurazione di Envoy e controlla la configurazione del cluster di Envoy per assicurarti che sia corretta. Se vedi la richiesta, ma il log non contiene errori, controlla i log del proxy di destinazione.

Se la richiesta viene visualizzata nei log del proxy di destinazione, significa che il mesh funziona correttamente. Se invece viene visualizzato un errore, esegui un dump della configurazione di Envoy e verifica i valori corretti per la porta di traffico impostata nella configurazione dell'ascoltatore.

Se il problema persiste dopo aver eseguito i passaggi precedenti, Envoy potrebbe impossibile negoziare automaticamente il protocollo tra il file collaterale e la sua applicazione pod. Assicurati che il nome della porta del servizio Kubernetes, ad esempio http-80, corrisponde al protocollo utilizzato dall'applicazione.

Utilizzare Esplora log per eseguire query sui log

Puoi utilizzare l'interfaccia Esplora log. per eseguire query su specifici log di accesso a Envoy. Ad esempio, per eseguire query su tutte le richieste hai abilitato MULTUAL_TLS e utilizza il protocollo grpc, aggiungi quanto segue al query sui log di accesso al server:

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

Imposta un criterio per i log di accesso

Cloud Service Mesh gestito

Per configurare i log di accesso per Cloud Service Mesh con un server sul piano di controllo Cloud Service Mesh, vedi Attivazione dei log degli accessi.

`istiod` gestita

Per configurare i log di accesso per Cloud Service Mesh con un control plane Istio gestito, consulta Abilitazione dei log di accesso.

Nel cluster

Per impostare un criterio di log di accesso per Cloud Service Mesh con il controllo nel cluster aereo:

Crea un file di overlay personalizzato IstioOperator che includa i campi applicabili AccessLogPolicyConfig per il tuo scenario.
Passa questo file a asmcli utilizzando l'opzione --custom_overlay per aggiornare la configurazione del piano di controllo nel cluster. Per informazioni sull'esecuzione di asmcli install con un file overlay personalizzato, consulta Installare con funzionalità facoltative.

Attenzione: se hai personalizzato l'installazione precedente, è necessario lo stesso personalizzazioni quando reinstalli il piano di controllo per includere il file con le impostazioni di AccessLogPolicyConfig. Omissione dei risultati di un file di overlay in un'installazione corretta; tuttavia, il tuo mesh di servizi ha del previsto perché i valori omessi vengono reimpostati su i valori predefiniti quando viene eseguito nuovamente il deployment del piano di controllo.

Visualizzare informazioni specifiche per il servizio o il carico di lavoro

Se hai un problema con un servizio o un carico di lavoro specifico anziché con un problema su larga scala, controlla i singoli proxy Envoy e raccogli le informazioni pertinenti. Per raccogliere informazioni su un determinato carico di lavoro e sui relativi proxy, puoi utilizzare pilot-agent:

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

Nell'esempio, SCOPE è uno dei seguenti:

certs - Certificati all'interno dell'istanza Envoy
clusters - Cluster con Envoy configurato
config_dump - Esegue il dump della configurazione Envoy
listeners - Listener con Envoy configurato
logging - Visualizza e modifica le impostazioni di logging
stats - Statistiche di Envoy
stats/prometheus - Statistiche di Envoy come record di Prometheus

Visualizza gli stati delle socket proxy

Puoi esaminare direttamente lo stato delle socket proxy di Envoy utilizzando la procedura riportata di seguito.

Visualizza un elenco di socket stabiliti, inclusi quelli in TIME_WAIT il che può influire negativamente sulla scalabilità se il conteggio è elevato:
```
kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
```

Mostra un riepilogo delle statistiche del socket:

kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -s

Per ulteriori informazioni, consulta Introduzione al comando ss.

Log di `istio-proxy` e `istio-init`

Inoltre, recupera i log di istio-proxy ed esamina i relativi contenuti per verificare la presenza di eventuali errori che potrebbero suggerire la causa del problema:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Puoi fare lo stesso per il contenitore init:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init

Passaggi successivi

Esegui l'integrazione con Cloud Trace. Cloud Trace è una funzionalità facoltativa in Cloud Service Mesh.
Esportare i log del traffico in BigQuery.
Crea metriche basate su log.

Richiedi log del proxy

Attivazione e disattivazione dei log di accesso

Cloud Service Mesh gestito

Log di accesso di Envoy

Log sul traffico

Entrambi

istiod gestita

Log di accesso di Envoy

Log sul traffico

All'interno del cluster

Log di accesso di Envoy

Log sul traffico

Visualizzazione dei log di accesso

Log di accesso di Envoy

Riga di comando

Esplora log

Log sul traffico

Log del server

Log client

Interpretare la telemetria di Cloud Service Mesh

Interpreta le metriche del piano di controllo

Cloud Service Mesh gestito

istiod gestita

Nel cluster

Diagnosticare i ritardi di configurazione

Cloud Service Mesh gestito

Gestito istiod

All'interno del cluster

Interpretare i log del traffico

Risolvere i problemi relativi agli errori 404 e 503

Interpreta i log di accesso di Envoy

Utilizzare Esplora log per eseguire query sui log

Imposta un criterio per i log di accesso

Cloud Service Mesh gestito

istiod gestita

Nel cluster

Visualizzare informazioni specifiche per il servizio o il carico di lavoro

Visualizza gli stati delle socket proxy

Log di istio-proxy e istio-init

Passaggi successivi

`istiod` gestita

`istiod` gestita

Gestito `istiod`

Risolvere i problemi relativi agli errori `404` e `503`

`istiod` gestita

Log di `istio-proxy` e `istio-init`