Accesso ai log in Cloud Logging

Le pagine di Anthos Service Mesh forniscono link a tre diversi tipi di log in Cloud Logging: log delle applicazioni, log degli errori e log del traffico.

Accesso ai log delle applicazioni

Per visualizzare i log delle applicazioni per un servizio durante l'intervallo di tempo specificato, segui questi passaggi:

  1. Vai alla pagina Anthos Service Mesh nella console Google Cloud.

    Vai alla pagina Anthos Service Mesh

  2. Nella sezione Servizi, seleziona il nome del Servizio che vuoi controllare.

  3. Vai alla pagina Metriche.

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

  5. Fai clic su Visualizza i log delle applicazioni.

I log dell'applicazione sono i log generati dal tuo codice dell'applicazione e sono allegati alla risorsa monitorata corrispondente (k8s_container o gce_instance) utilizzata dall'applicazione.

Accesso ai log degli errori

Per visualizzare i log degli errori per un servizio durante l'intervallo di tempo specificato, segui questi passaggi:

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

    Vai alla pagina Anthos Service Mesh

  2. Nella sezione Servizi, seleziona il nome del Servizio che vuoi controllare.

  3. Vai alla pagina Diagnostica.

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

  5. Nell'angolo in alto a destra della finestra, fai clic su Apri nel logging.

Accesso ai log di traffico

Per visualizzare i log del traffico o di accesso in Istio, per un servizio durante l'intervallo di tempo specificato, segui questi passaggi:

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

    Vai alla pagina Anthos Service Mesh

  2. Nella sezione Servizi, seleziona il nome del Servizio che vuoi controllare.

  3. Vai alla pagina Metriche.

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

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

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

  • Proprietà delle richieste HTTP, come ID, URL, dimensioni, latenza e intestazioni comuni.

  • Informazioni sui carichi di lavoro di origine e di destinazione, come nome, spazio dei nomi, identità ed etichette comuni.

  • Se il tracciamento è abilitato, informazioni sulla traccia, ad esempio campionamento, ID traccia e ID intervallo.

Di seguito è riportata una voce di log di esempio:

{
  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 i log di Anthos Service Mesh

Le seguenti sezioni spiegano come controllare lo stato del mesh e come esaminare i vari log che contengono dettagli utili per la risoluzione dei problemi.

Interpretare le metriche del piano di controllo

Quando installi Anthos Service Mesh con il piano di controllo nel cluster, istiod esporta le metriche nella suite operativa di Google Cloud per il monitoraggio per impostazione predefinita. istiod aggiunge il prefisso istio.io/control a queste metriche e fornisce insight 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 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 Anthos 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.

Diagnostica i 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 tutti i proxy convergenti.

  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

Interpretare i log degli accessi alla suite operativa di Google Cloud

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

Anthos Service Mesh esporta i dati nei log degli accessi alla suite operativa di Google Cloud, utili per eseguire il debug dei seguenti tipi di problemi:

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

I log degli accessi alla suite operativa di Google Cloud sono abilitati per impostazione predefinita per le installazioni di Anthos Service Mesh su Google Kubernetes Engine. Puoi abilitare i log di accesso alla suite operativa di Google Cloud eseguendo di nuovo asmcli install. Utilizza le stesse opzioni che hai installato in origine, 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, collegato 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 offrono una visualizzazione lato client delle richieste. Si trovano in client-accesslog-stackdriver, collegato 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à delle richieste HTTP, come ID, URL, dimensioni, latenza e intestazioni comuni.
  • Informazioni sui carichi di lavoro di origine e di destinazione, come nome, spazio dei nomi, identità ed etichette comuni.
  • Informazioni sulla revisione e sul servizio canonico di origine e destinazione.
  • Se il tracciamento è abilitato, i log contengono informazioni sulla traccia, ad esempio campionamento, ID traccia e ID intervallo.

Le informazioni visualizzate nei log degli accessi alla suite operativa di Google Cloud provengono dai log di accesso di Envoy, quando li abiliti nella configurazione 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 diversi modi:

  • Eseguire l'integrazione con Cloud Trace, una funzionalità facoltativa di Anthos Service Mesh.
  • Esporta i log del traffico in BigQuery, dove puoi eseguire query, come la selezione di tutte le richieste, in più di 5 secondi.
  • Creare metriche basate su log.
  • Risolvi gli errori 404 e 503

Risolvi gli errori 404 e 503

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

  1. Nel log degli accessi del 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 che ha il seguente aspetto:

    response_flag: "NR"

    Il valore NR è l'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. Analogamente, puoi utilizzare l'etichetta response_flag per risolvere gli errori 503.

  3. Se riscontri errori 503 nei log di accesso client e server, verifica che i nomi delle porte impostati per ogni servizio corrispondano al nome del protocollo in uso. Ad esempio, se un client binario golang si connette a un server golang tramite HTTP, ma la porta è denominata http2, il protocollo non negozierà automaticamente in modo corretto.

Per ulteriori informazioni, consulta la sezione Flag di risposta.

Interpretare i log di Envoy

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

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

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

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

Puoi risolvere gli 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 attivi una richiesta che viene visualizzata e questa viene visualizzata nei log del proxy di origine, significa che il reindirizzamento del traffico iptables funziona correttamente e che il proxy Envoy sta gestendo il traffico. Se vedi errori nei log, genera un dump di configurazione Envoy e controlla la configurazione del cluster 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 per il traffico impostata nella configurazione del listener.

Se il problema persiste dopo aver eseguito i passaggi precedenti, Envoy potrebbe non essere in grado di negoziare automaticamente il 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 una query su tutte le richieste in cui MULTUAL_TLS è abilitato e che utilizzano il protocollo grpc, aggiungi quanto segue alla query dei log di accesso al server:

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

Imposta un criterio del log di accesso

Per configurare il logging del proxy per Anthos Service Mesh gestito, consulta Log degli accessi a Envoy.

Per impostare un criterio del log degli accessi per Anthos Service Mesh con il piano di controllo nel cluster:

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

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

Visualizza informazioni specifiche sul servizio o sul carico di lavoro

Se hai un problema con un servizio o un carico di lavoro specifico anziché con un problema che interessa tutto il mesh, controlla i singoli proxy Envoy e raccogli da loro le informazioni pertinenti. Per raccogliere informazioni su un determinato carico di lavoro e i suoi 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 Envoy
  • clusters - Cluster in cui è stato configurato Envoy
  • config_dump: esegue il dump della configurazione Envoy
  • listeners - Listener con Envoy configurati
  • logging - Visualizza e modifica le impostazioni di logging
  • stats - Statistiche Envoy
  • stats/prometheus - Statistiche di Envoy come registri di Prometheus

Visualizza gli stati dei socket proxy

Puoi esaminare direttamente lo stato dei socket proxy Envoy utilizzando il seguente processo.

  1. Visualizza un elenco dei socket stabiliti, inclusi quelli nello stato TIME_WAIT, che possono influire negativamente sulla scalabilità se il numero è elevato:

    kubectl exec POD_NAME -c istio-proxy -- ss -anopim
  2. Visualizza un riepilogo delle statistiche socket:

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

Per ulteriori informazioni, vedi Introduzione al comando ss.

Log di istio-proxy e istio-init

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

kubectl logs POD_NAME -c istio-proxy

Puoi fare lo stesso per il contenitore init:

kubectl logs POD_NAME -c istio-init

Passaggi successivi