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 sul traffico.

Accesso ai log delle applicazioni

Per visualizzare i log dell'applicazione per un servizio durante un intervallo di tempo specificato, segui questi passaggi:

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

Vai alla pagina Anthos Service Mesh
In Services (Servizi), seleziona il nome del servizio che vuoi controllare.
Vai alla pagina Metriche.
Specifica un intervallo di tempo nel menu a discesa Intervallo di tempo o imposta un intervallo personalizzato con la sequenza temporale.
Fai clic su Visualizza i log dell'applicazione.

I log dell'applicazione sono quelli 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 durante un periodo di tempo specificato, procedi come segue:

In Google Cloud Console, vai alla pagina Anthos Service Mesh.

Vai alla pagina Anthos Service Mesh
In Services (Servizi), seleziona il nome del servizio che vuoi controllare.
Vai alla pagina Diagnostica.
Specifica un intervallo di tempo nel menu a discesa Intervallo di tempo o imposta un intervallo personalizzato con la sequenza temporale.
Nell'angolo in alto a destra della finestra, fai clic su Apri in Logging.

Accesso ai log sul traffico

Per visualizzare i log sul traffico o accedere ai log in Istio per un servizio durante un intervallo di tempo specificato, segui questi passaggi:

In Google Cloud Console, vai alla pagina Anthos Service Mesh.

Vai alla pagina Anthos Service Mesh
In Services (Servizi), seleziona il nome del servizio che vuoi controllare.
Vai alla pagina Metriche.
Specifica un intervallo di tempo nel menu a discesa Intervallo di tempo o imposta un intervallo personalizzato con la sequenza temporale.
In Seleziona un'opzione di filtro, fai clic su Visualizza log sul traffico.

Il log del traffico viene 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à delle richieste HTTP, ad esempio ID, URL, dimensioni, latenza e intestazioni comuni.
Informazioni sul carico di lavoro di origine e di destinazione, come nome, spazio dei nomi, identità ed etichette comuni.
Se il tracciamento è attivo, le informazioni di traccia, ad esempio il campionamento, l'ID traccia e l'ID intervallo,

Di seguito è riportato 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 i log di Anthos Service Mesh

Le seguenti sezioni spiegano come controllare lo stato del mesh ed esaminare i vari log contenenti dettagli utili per risolvere i 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 antepone queste metriche a istio.io/control 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.

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

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

Cerca nell'elenco la dashboard Istio Control Plane Dashboard. Per saperne di più, consulta Visualizzare la dashboard installata.

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

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

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

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

Interpretare i log di accesso alla suite operativa di Google Cloud

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

Anthos Service Mesh esporta i dati nei log di accesso alla suite operativa di Google Cloud per 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 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 disattivato Stackdriver.

Esistono due tipi di log di accesso:

I log di accesso al server offrono una visualizzazione lato server delle richieste. Si trovano in server-accesslog-stackdriver, collegato alla risorsa monitorata k8s_container. Utilizza la seguente sintassi 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, collegate alla risorsa monitorata k8s_pod. Utilizza la seguente sintassi 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 degli accessi contengono le seguenti informazioni:

Proprietà delle richieste HTTP, ad esempio ID, URL, dimensioni, latenza e intestazioni comuni.
Informazioni sul carico di lavoro di origine e di destinazione, come nome, spazio dei nomi, identità ed etichette comuni.
Informazioni relative al servizio canonico e alla revisione di origine e destinazione.
Se il tracciamento è abilitato, i log contengono informazioni sulle tracce, ad esempio campionamento, ID traccia e ID span.

Le informazioni visualizzate nei log di accesso alla suite operativa di Google Cloud provengono dai log di accesso di Envoy, quando 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 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 cinque secondi.
Creare metriche basate su log.
Risolvere gli errori 404 e 503

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

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. Individua il campo response_flag simile al seguente:
```
response_flag: "NR"
```
Il valore NR è l'acronimo di NoRoute, il che significa che non è stato trovato alcun percorso per la destinazione o non esiste una catena di filtri corrispondente per una connessione a valle. Allo stesso modo, puoi utilizzare l'etichetta response_flag per risolvere anche gli errori 503.
Se vengono visualizzati errori 503 nei log di accesso client e server, controlla che i nomi delle porte impostati per ogni servizio corrispondano al nome del protocollo in uso tra loro. Ad esempio, se un client binario golang si connette a un server golang tramite HTTP, ma la porta è denominata http2, il protocollo non esegue la negoziazione automatica corretta.

Per ulteriori informazioni, consulta i flag di risposta.

Interpretare i log Envoy

I seguenti passaggi spiegano come utilizzare i log di accesso al proxy Envoy per mostrare il traffico tra entrambe le estremità di una connessione al fine di risolvere i problemi.

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

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

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

Puoi risolvere gli errori di connessione/richiesta generando attività nella tua applicazione che attivi una richiesta HTTP, quindi esaminando la richiesta associata nei log di origine o di destinazione.

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

Se la richiesta viene visualizzata nei log del proxy di destinazione, significa che il mesh stesso funziona correttamente. Se viene visualizzato un errore, esegui un dump della configurazione 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 negoziare automaticamente il protocollo tra il sidecar e il 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 Esplora log per eseguire query su log di accesso specifici. Ad esempio, per eseguire una query su tutte le richieste in cui MULTUAL_TLS è abilitato e utilizzare 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, vedi Log di accesso di Envoy.

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

Crea un file di overlay personalizzato IstioOperator che includa i valori AccessLogPolicyConfig applicabili al tuo scenario.
Passa il 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 Installazione con funzionalità facoltative.

Attenzione: se hai personalizzato l'installazione precedente, hai bisogno delle stesse personalizzazioni quando reinstalli il piano di controllo per includere il file con le impostazioni di AccessLogPolicyConfig. L'omissione di un file overlay genera un'installazione riuscita; tuttavia, il tuo mesh di servizi ha una configurazione diversa da quella prevista perché i valori omessi vengono reimpostati sui valori predefiniti quando viene eseguito nuovamente il deployment del piano di controllo.

Visualizza le informazioni specifiche per servizio o carico di lavoro

Se hai un problema con un servizio o un carico di lavoro specifico anziché un problema a livello di mesh, esamina i singoli proxy Envoy e raccogli le informazioni pertinenti da loro. Per raccogliere informazioni su un determinato carico di lavoro 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 Envoy
clusters: cluster con Envoy configurato
config_dump - Dump della configurazione Envoy
listeners: listener con Envoy configurato
logging - Visualizza e modifica le impostazioni di logging
stats - Statistiche Envoy
stats/prometheus - Statistiche di Envoy registrate da Prometheus

Visualizza stati socket proxy

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

Mostra un elenco di socket consolidati, 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
```
Visualizza un riepilogo delle statistiche dei socket:
```
kubectl exec POD_NAME -c istio-proxy -- ss -s
```

Per ulteriori informazioni, consulta la sezione Introduzione al comando ss.

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

Inoltre, recupera i log istio-proxy ed esaminane i 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

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