Richiedi i log proxy

Le pagine di Cloud Service Mesh forniscono link a due diversi tipi di log in Cloud Logging: log degli accessi (noti anche come log di Envoy) e log sul traffico (noti anche come log degli accessi di Google Cloud Observability).

Log degli accessi

Abilita log degli accessi

I passaggi necessari per abilitare i log degli accessi dipendono dal tipo di Cloud Service Mesh, gestito o in-cluster:

Visualizza log degli accessi

Per visualizzare i log degli accessi in Esplora log:

  1. Vai a Esplora log:

    Vai a Esplora log

  2. Seleziona ilprogettoappropriato. Google Cloud

  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

Attiva 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 nota come Citadel).

Per abilitare i log sul traffico su Google Distributed Cloud con Istio CA quando installi 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.

Visualizza log di traffico

Visualizza i log di traffico in Esplora log

Per visualizzare i log di traffico in Esplora log: :

  1. Vai a Esplora log:

    Vai a Esplora log

  2. Seleziona ilprogettoappropriato. Google Cloud

  3. Esegui la seguente query 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"
    

Visualizza i log di traffico nella pagina Anthos Service Mesh

Per visualizzare i log di traffico nella pagina Cloud Service Mesh per un servizio durante un intervallo 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 ispezionare.

  3. Vai alla pagina Metriche.

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

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

Il log di traffico è denominato server-accesslog-stackdriver ed è collegato alla risorsa monitorata corrispondente (k8s_container o gce_instance) utilizzata dal servizio. Il log di 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 il tracing è abilitato, informazioni di 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"
}

Interpreta la telemetria di Anthos 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.

Interpreta le metriche del control plane

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 il prefisso 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, consulta Visualizzare la dashboard installata.

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

Esegui la diagnostica dei ritardi di configurazione

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 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. Accedi a localhost:15014 e grep per convergence nelle metriche:

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

Interpreta i log degli accessi della suite operativa di Google Cloud

Le seguenti informazioni spiegano come utilizzare i log degli accessi di Google Cloud Observability per risolvere i problemi di connessione. I log degli accessi/del traffico di Google Cloud Observability sono abilitati per impostazione predefinita.

Cloud Service Mesh esporta i dati nei log degli accessi di Google Cloud Observability, 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 degli accessi di Google Cloud Observability sono abilitati per impostazione predefinita per le installazioni di Cloud Service Mesh su Google Kubernetes Engine. Puoi abilitare i log degli accessi di Google Cloud Observability 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 degli accessi:

  • 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 il tracing è abilitato, i log contengono informazioni di traccia, come campionamento, ID traccia e ID intervallo.

Le informazioni visualizzate nei log degli accessi di Google Cloud Observability provengono dai log degli accessi di Envoy, quando li abiliti nella configurazione di Istio. Contengono le seguenti intestazioni:

  • route_name
  • upstream_cluster
  • X-Envoy-Original-Path
  • X-Envoy-Original-Host

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

  • Esegui l'integrazione con Cloud Trace, una funzionalità facoltativa di Cloud Service Mesh.
  • Esporta i log di 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 riesce 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 del 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 del server, verifica 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, consulta i flag di risposta.

Interpreta i log degli accessi

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

I log degli accessi sono utili per diagnosticare problemi come:

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

I log degli accessi non sono abilitati per impostazione predefinita in Cloud Service Mesh e possono essere abilitati solo a livello globale nell'intero mesh.

Puoi risolvere i problemi relativi agli errori di connessione/richiesta generando attività nella tua applicazione che attiva una richiesta HTTP, quindi ispezionando 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 visualizzi 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 di 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.

Utilizza Esplora log per eseguire query sui log

Puoi utilizzare l'interfaccia di Esplora log per eseguire query su log degli accessi 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"

Imposta una policy dei log degli accessi

Per configurare la registrazione dei proxy per Cloud Service Mesh gestito, consulta Log degli accessi di Envoy.

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, consulta Installazione con funzionalità facoltative.

Visualizza 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, ispeziona 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 -c istio-proxy -- pilot-agent request GET SCOPE

Nell'esempio, SCOPE è uno dei seguenti:

  • certs - Certificati all'interno dell'istanza di 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

Visualizza 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 exec POD_NAME -c istio-proxy -- ss -anopim
  2. Visualizza un riepilogo delle statistiche dei socket:

    kubectl exec POD_NAME -c istio-proxy -- ss -s

Per ulteriori informazioni, consulta Introduzione al comando ss.

Log istio-proxy e istio-init

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

kubectl logs POD_NAME -c istio-proxy

Puoi fare lo stesso per il container init:

kubectl logs POD_NAME -c istio-init

Passaggi successivi