Richiedi i log proxy

Cloud Service Mesh supporta due tipi diversi di log degli accessi in Cloud Logging: log sul traffico (noti anche come log degli accessi di Google Cloud Observability) e log degli accessi di Envoy. Questa pagina mostra come abilitare, disabilitare, visualizzare e interpretare questi log. Tieni presente che i log sul traffico sono abilitati per impostazione predefinita.

Abilitare e disabilitare i log degli accessi

Traffic Director gestito

Nota: nel canale rapido, Cloud Service Mesh con un control plane Traffic Director gestito supporta più configurazioni dell'API Telemetria. Le API Telemetria sono supportate a livello di spazio dei nomi radice (impostazione predefinita: istio-system o come indicato in meshconfig), a livello di spazio dei nomi e a livello di selettore specifico. La priorità è massima per il selettore e minima per il livello radice. Negli altri canali è supportata una sola configurazione dell'API Telemetria a livello di cluster, in particolare una singola CR dell'API Telemetria Istio nello spazio dei nomi radice.

Se hai già una CR dell'API Telemetria Istio esistente, per conservare le impostazioni di personalizzazione precedenti nella CR Telemetria Istio esistente, devi includerle nella nuova CR dell'API Telemetria Istio.

Log degli accessi di Envoy

Esegui il comando seguente per abilitare i log degli accessi di Envoy e disabilitare i log sul 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 sul traffico è stackdriver.

Log sul traffico

Per impostazione predefinita, i log sul traffico sono abilitati e i log degli accessi di Envoy sono disabilitati. Se in precedenza hai abilitato i log degli accessi di Envoy e vuoi abilitare i log sul traffico e disabilitare i log degli accessi di Envoy, esegui il comando seguente:

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 degli accessi di Envoy sia i log sul traffico, esegui il comando seguente:

  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 disabilitare sia i log degli accessi di Envoy sia i log sul traffico, esegui il comando seguente:

  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
  

Log degli accessi specifici per il selettore

Nel canale rapido, per abilitare la registrazione degli accessi solo per un workload specifico, devi prima disabilitarla a livello di mesh applicando una configurazione di telemetria nello spazio dei nomi radice (poiché la registrazione del traffico è abilitata per impostazione predefinita). Poi, applichi una configurazione separata con un selettore per abilitarla solo per quel workload.

# 1. Disable mesh-wide access logging
cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-mesh-wide-telemetry
  namespace: istio-system
spec:
  accessLogging:
  - providers:
    - name: stackdriver
    disabled: true
EOF

# 2. Enable access logging for a specific workload
cat <<EOF | kubectl apply -n NAMESPACE -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: workload-specific-telemetry
  namespace: NAMESPACE
spec:
  selector:
    matchLabels:
      app: YOUR_APP_LABEL
  accessLogging:
  - providers:
    - name: stackdriver
EOF

istiod gestito

Log degli accessi di Envoy

Esegui i comandi seguenti per abilitare la registrazione degli accessi di Envoy:

Avviso: puoi sovrascrivere le tue modifiche. Se hai già un configmap esistente, devi includere tutte le impostazioni di personalizzazione precedenti nella sezione mesh: per conservare le modifiche. In questo modo non si verificano tempi di inattività quando abiliti le funzionalità facoltative.

1. Esegui il comando seguente 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).

2. Esegui il comando seguente per visualizzare il configmap:

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

3. Per verificare che la registrazione degli accessi sia abilitata, assicurati che la riga accessLogFile: /dev/stdout venga visualizzata nella sezione mesh:.

   ...
   apiVersion: v1
   data:
     mesh: |
       ....
       accessLogFile: /dev/stdout
   ...
   

Log sul traffico

I log sul traffico sono abilitati per impostazione predefinita.

Interno al cluster

Log degli accessi di Envoy

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

Per ulteriori informazioni, vedi Abilitare 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 con Istio CA (precedentemente noto come Citadel).

Per abilitare i log sul traffico su Google Distributed Cloud con Istio CA durante l'installazione di Cloud Service Mesh in-cluster, utilizza il flag --option stackdriver. In alternativa, puoi abilitare i log sul traffico su Google Distributed Cloud con Istio CA dopo aver installato Cloud Service Mesh in-cluster.

Visualizzare i log degli accessi

Log degli accessi di Envoy

Riga di comando

Per visualizzare i log degli accessi di Envoy nel log istio-proxy, esegui il comando seguente:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Esplora log

Per visualizzare i log degli accessi di Envoy in Esplora log:

1. Vai a Esplora log:

   Vai a Esplora log

2. Seleziona il Google Cloud progettoappropriato.

3. 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 sul traffico in Esplora log:

1. Vai a Esplora log:

   Vai a Esplora log

2. Seleziona il Google Cloud progettoappropriato.

3. Esegui la query seguente a seconda che tu stia visualizzando i log degli accessi client o server:

   Log del server

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

   Log del client

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

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

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

   Vai alla pagina Cloud Service Mesh

2. In Servizi, seleziona il nome del servizio che vuoi esaminare.

3. Vai alla pagina Metriche.

4. Specifica un periodo di tempo dal menu a discesa Periodo di tempo o imposta un periodo personalizzato con la sequenza temporale.

5. In Seleziona un'opzione di filtro, fai clic Visualizza log sul traffico.

Il log sul traffico è denominato server-accesslog-stackdriver ed è collegato alla risorsa monitorata corrispondente (k8s_container o gce_instance) utilizzata dal servizio. Il log sul traffico contiene le seguenti informazioni:

• Proprietà della richiesta HTTP, come ID, URL, dimensioni, latenza e intestazioni comuni.

• Informazioni sul workload di origine e di destinazione, come nome, spazio dei nomi, identità ed etichette comuni.

• Se la traccia è abilitata, informazioni sulla traccia, come campionamento, ID traccia e ID intervallo.

Ecco un esempio di voce di log:

{
  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 e rivedere le varie telemetrie che contengono dettagli utili per la risoluzione dei problemi.

Interpretare le metriche del control plane

Traffic Director gestito

Cloud Service Mesh con un control plane Traffic Director gestito non supporta le metriche del control plane.

istiod gestito

Cloud Service Mesh con un control plane istiod gestito non supporta l'ispezione delle metriche del control plane in questa sezione.

Interno al cluster

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

Osserva o risolvi i problemi del control plane seguendo questi passaggi.

1. Carica una dashboard di esempio:

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

2. Installa la dashboard di Cloud Service Mesh:

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

3. Cerca una dashboard denominata Istio Control Plane Dashboard nell'elenco. Per ulteriori informazioni, vedi Visualizzare la dashboard installata.

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

Diagnosticare i ritardi di configurazione

Traffic Director gestito

Cloud Service Mesh con un control plane Traffic Director gestito non supporta la diagnosi dei ritardi di configurazione.

istiod gestito

Cloud Service Mesh con un control plane istiod gestito non supporta la diagnosi dei ritardi di configurazione.

Interno al cluster

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

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

2. Accedi a localhost:15014 e grep per convergence nelle metriche:

   curl http://localhost:15014/metrics | grep convergence

Interpretare i log sul traffico

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

Cloud Service Mesh esporta i dati nei log sul traffico che possono aiutarti a eseguire il debug dei 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 abilitare i log sul traffico eseguendo di nuovo asmcli install. Utilizza le stesse opzioni che hai installato originariamente, ma ometti l'overlay personalizzato che ha disabilitato Stackdriver.

Esistono due tipi di log sul traffico:

• I log degli accessi al server forniscono una visualizzazione lato server delle richieste. Si trovano in server-accesslog-stackdriver, collegati alla risorsa monitorata k8s_container. Utilizza la seguente sintassi dell'URL per visualizzare i log degli accessi lato server:

  https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID

• I log degli accessi client forniscono una visualizzazione lato client delle richieste. Si trovano in client-accesslog-stackdriver, collegati alla risorsa monitorata k8s_pod. Utilizza la seguente sintassi dell'URL per visualizzare i log degli accessi lato client:

  https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID

I log degli accessi contengono le seguenti informazioni:

• Proprietà della richiesta HTTP, come ID, URL, dimensioni, latenza e intestazioni comuni.
• Informazioni sul workload di origine e di destinazione, come nome, spazio dei nomi, identità ed etichette comuni.
• Informazioni sul servizio canonico e sulla revisione di origine e di destinazione.
• Se la traccia è abilitata, i log contengono informazioni sulla 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 una voce di log di esempio:

{
  "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 vari modi:

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

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

1. Nel log degli accessi 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"
   }

2. Vai alle etichette nella voce di log degli accessi. Trova il campo response_flag simile al seguente:

   response_flag: "NR"

   Il valore NR è un acronimo di NoRoute, il che significa che non è stata trovata alcuna route per la destinazione o che non è stata trovata alcuna catena di filtri corrispondente per una connessione downstream. Allo stesso modo, puoi utilizzare l'etichetta response_flag anche per risolvere i problemi relativi agli errori 503.

3. Se visualizzi errori 503 sia nei log degli accessi client sia in quelli server, controlla che i nomi delle porte impostati per ogni servizio corrispondano al nome del protocollo in uso tra di essi. Ad esempio, se un client binario golang si connette a un server golang utilizzando HTTP, ma la porta è denominata http2, il protocollo non eseguirà la negoziazione automatica correttamente.

Per ulteriori informazioni, vedi Flag di risposta.

Interpretare i log degli accessi di Envoy

I passaggi seguenti spiegano come utilizzare i log degli accessi di Envoy per mostrare il traffico tra le due estremità di una connessione a scopo di risoluzione dei problemi.

I log degli accessi di Envoy sono utili per diagnosticare problemi come:

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

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

Nota: i log sul traffico (noti anche come i log di Google Cloud Observability) sono i log preferiti per la maggior parte degli scenari di risoluzione dei problemi. Tuttavia, se il problema persiste, abilita i log degli accessi di Envoy per risolvere ulteriormente il problema.

Puoi risolvere i problemi relativi agli errori di connessione o di richiesta generando attività nella tua applicazione che attiva una richiesta HTTP, quindi esaminando la richiesta associata nei log di origine o di destinazione.

Se viene visualizzata una richiesta e 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 Envoy per assicurarti che sia corretta. Se vedi la richiesta ma il log non contiene errori, controlla invece i log del proxy di destinazione.

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

Se il problema persiste dopo aver eseguito i passaggi precedenti, Envoy potrebbe non essere in grado di eseguire la negoziazione automatica del protocollo tra il sidecar e il relativo pod dell'applicazione. Assicurati che il nome della porta del servizio Kubernetes, ad esempio http-80, corrisponda al protocollo utilizzato dall'applicazione.

Utilizzare Esplora log per eseguire query sui log

Puoi utilizzare l'interfaccia di Esplora log per eseguire query su log degli accessi di Envoy specifici. Ad esempio, per eseguire query su tutte le richieste per cui è abilitato MULTUAL_TLS e che utilizzano il protocollo grpc, aggiungi quanto segue alla query dei log degli accessi al server:

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

Impostare una policy dei log degli accessi

Traffic Director gestito

Per configurare i log degli accessi per Cloud Service Mesh con un control plane Traffic Director gestito, vedi Abilitare i log degli accessi.

istiod gestito

Per configurare i log degli accessi per Cloud Service Mesh con un control plane istiod gestito, vedi Abilitare i log degli accessi.

Interno al cluster

Per impostare una policy dei log degli accessi per Cloud Service Mesh con il control plane in-cluster:

1. Crea un file di overlay personalizzato IstioOperator che includa i valori applicabili AccessLogPolicyConfig per il tuo scenario.

2. Passa questo file a asmcli utilizzando l'opzione --custom_overlay per aggiornare la configurazione del control plane in-cluster. Per informazioni sull'esecuzione asmcli install con un file di overlay personalizzato, vedi Installare con funzionalità facoltative.

   Attenzione: se hai personalizzato l'installazione precedente, devi mantenere le stesse personalizzazioni quando reinstalli il control plane per includere il file con le impostazioni AccessLogPolicyConfig. Se ometti un file di overlay, l'installazione viene eseguita correttamente. Tuttavia, il mesh di servizi avrà una configurazione diversa da quella prevista perché i valori omessi vengono reimpostati sui valori predefiniti quando viene eseguito nuovamente il deployment del control plane.

Visualizzare informazioni specifiche del servizio o del workload

Se hai un problema con un servizio o un workload specifico anziché un problema a livello di mesh, esamina i singoli proxy Envoy e raccogli le informazioni pertinenti. Per raccogliere informazioni su un determinato workload 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 di 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 Prometheus

Nota: config_dump e stats sono le opzioni che hanno maggiori probabilità di produrre informazioni utili.

Visualizzare gli stati dei socket proxy

Puoi esaminare direttamente lo stato dei socket proxy Envoy utilizzando la seguente procedura.

1. Visualizza un elenco di socket stabiliti, inclusi i socket nello stato TIME_WAIT, che possono influire negativamente sulla scalabilità se il loro conteggio è elevato:

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

2. Visualizza un riepilogo delle statistiche dei socket:

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

Per ulteriori informazioni, vedi Introduzione al comando ss.

Log istio-proxy e istio-init

Inoltre, recupera i log istio-proxy ed esamina i 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 container init:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init

Passaggi successivi

• Esegui l'integrazione con Cloud Trace. Cloud Trace è una funzionalità facoltativa di Cloud Service Mesh.

• Esporta i log sul traffico in BigQuery.

• Crea metriche basate su log.