Accesso ai log in Cloud Logging

Le pagine Cloud 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 un intervallo di tempo specificato: questi passaggi:

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

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

5. Fai clic su Visualizza log applicazioni.

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

Accesso ai log degli errori

Per visualizzare i log degli errori di un servizio in un periodo di tempo specificato:

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

   Vai alla pagina di Cloud Service Mesh

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

3. Vai alla pagina Diagnostica.

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

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

Accesso ai log sul traffico

Visualizzare i log del traffico, o accedere ai log in Istio, per un servizio durante un periodo di tempo segui questa procedura:

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

   Vai alla pagina Cloud Service Mesh

2. Nella sezione 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 oppure impostare un intervallo personalizzato con la sequenza temporale.

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

Il log del traffico si chiama server-accesslog-stackdriver ed è associato alla risorsa monitorata corrispondente (k8s_container o gce_instance) utilizzata dal servizio. Il log sul 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, ad esempio nome, spazio dei nomi, identità ed etichette comuni.

• Se il tracciamento è abilitato, le informazioni di traccia, come campionamento, ID traccia e ID intervallo.

Un esempio di voce di log ha il seguente aspetto:

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

Le sezioni seguenti spiegano come controllare lo stato del mesh ed eseguire la revisione le varie telemetrie che contengono dettagli utili per la risoluzione dei problemi.

Interpreta le metriche del piano di controllo

Quando installi Cloud Service Mesh con il piano di controllo nel cluster, istiod esporta le metriche in Google Cloud Observability per il monitoraggio, per impostazione predefinita. istiod aggiunge il prefisso istio.io/control a queste metriche e fornisce approfondimenti su lo stato del piano di controllo, ad esempio il numero di proxy connessi a ciascun 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.

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 Visualizzazione della dashboard installata.

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

Diagnostica dei ritardi nella configurazione

I seguenti passaggi 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

Interpretare i log di accesso di Google Cloud Observability

Le seguenti informazioni spiegano come utilizzare Google Cloud Observability accedere ai log per risolvere i problemi di connessione. Osservabilità di Google Cloud i log di accesso/traffico sono abilitati per impostazione predefinita.

Cloud Service Mesh esporta i dati nei log di accesso di Google Cloud Observability che possono di eseguire il debug dei seguenti tipi di problemi:

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

I log di accesso di Google Cloud Observability sono abilitati per impostazione predefinita per Cloud Service Mesh su Google Kubernetes Engine. Puoi abilitare Google Cloud Observability accedi di nuovo ai log eseguendo di nuovo asmcli install. Utilizza le stesse opzioni che hai scelto installato inizialmente, ma ometti l'overlay personalizzato che ha disabilitato Stackdriver.

Esistono due tipi di log di accesso:

• I log di accesso al server forniscono una vista lato server delle richieste. Si trovano in server-accesslog-stackdriver, collegato a k8s_container monitorato risorsa. Utilizza la seguente sintassi dell'URL per visualizza 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 vista lato client delle richieste. Si trovano nella sezione client-accesslog-stackdriver, collegato 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, come 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.

Le informazioni visualizzate nei log di accesso di Google Cloud Observability provengono dai log di accesso di Envoy, se li attivi 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:

• Eseguire l'integrazione con Cloud Trace, una funzionalità facoltativa in 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.
• Risolvere i problemi relativi agli errori 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 richiesta non riuscita con un codice di risposta 404 o 503.

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

2. Vai alle etichette nella voce di log di accesso. Trova il campo response_flag con un aspetto simile al seguente:

   response_flag: "NR"

   Il valore NR è un acronimo di NoRoute, che significa che non è stato trovato alcun percorso per la destinazione o non è stata trovata una catena di filtri corrispondente per una connessione a valle. Analogamente, puoi utilizzare l'etichetta response_flag per risolvere i problemi 503 errori.

3. 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 utilizzando HTTP, ma la porta è denominata http2, il protocollo non verrà negoziato automaticamente correttamente.

Per ulteriori informazioni, consulta la sezione flag di risposta.

Interpretare i log di Envoy

I passaggi riportati di seguito spiegano come utilizzare i log di accesso del proxy 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 come:

• Flusso di traffico e 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'intera rete mesh.

Nota: 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 Log di accesso di Envoy per ulteriori procedure di risoluzione.

Puoi risolvere i problemi di connessione/richiesta generando attività nella tua applicazione che attivano una richiesta HTTP, quindi ispezionando la richiesta associata nei log di origine o di destinazione.

Se attivi una richiesta, che compare nei log del proxy di origine, questa indica che il reindirizzamento del traffico di iptables funziona correttamente e che Envoy il proxy gestisce il traffico. Se noti errori nei log, genera un file Envoy della configurazione e controlla la configurazione del cluster Envoy per verificare che sia risposta esatta. Se vedi la richiesta, ma il log non contiene errori, controlla la destinazione log del proxy.

Se la richiesta viene visualizzata nei log del proxy di destinazione, significa che il mesh stesso 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 non essere in grado di negoziare automaticamente il protocollo tra il sidecar e il relativo pod di applicazioni. 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 di accesso specifici. Ad esempio, per eseguire query su tutte le richieste per le quali è attivato MULTUAL_TLS 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 di log di accesso

Per configurare il logging proxy per Cloud Service Mesh gestito, consulta Log di accesso Envoy.

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

1. Crea un file IstioOperator overlay personalizzato che includa i valori AccessLogPolicyConfig applicabili per il 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 sulla corsa asmcli install con un file di overlay personalizzato, vedi Installazione 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. L'omissione di un file overlay consente di eseguire un'installazione corretta, ma il mesh di servizi ha una configurazione diversa da quella prevista perché i valori omessi vengono reimpostati su quelli predefiniti quando il control plane viene reimplementato.

Visualizzare le informazioni specifiche del servizio o del 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 suoi proxy, puoi usare 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 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.

Visualizza gli stati del socket del proxy

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

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

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

2. Mostra un riepilogo delle statistiche del socket:

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

Per ulteriori informazioni, consulta Introduzione al comando ss.

istio-proxy e istio-init log

Inoltre, recupera i log istio-proxy e rivedine il contenuto per qualsiasi 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

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

• Esportare i log del traffico in BigQuery.

• Creare metriche basate su log.