Anthos Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Questa pagina è stata tradotta dall'API Cloud Translation.

Richiedi log del proxy

Le pagine 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 del traffico (anche noti come log di accesso di Google Cloud Observability).

Log degli accessi

Abilita log degli accessi

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

Gestito

Segui le istruzioni per abilitare i log degli accessi nella versione gestita di Cloud Service Mesh.

Nel cluster

Segui le istruzioni per abilita i log degli accessi in Cloud Service Mesh nel cluster.

Visualizza log di accesso

Per visualizzare i log di accesso nel Esplora log:

Vai a Esplora log:

Vai a Esplora log
Seleziona il progetto Google Cloud appropriato.

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 with Istio CA (precedentemente noto come Citadel).

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

Visualizza log di traffico

Visualizza i log del traffico in Esplora log

Per visualizzare i log di traffico nel Esplora log:

Vai a Esplora log:

Vai a Esplora log
Seleziona il progetto Google Cloud appropriato.

Esegui la seguente query a seconda che tu stia visualizzando i log di accesso del client o del server:

Log del server

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

Log dei client

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

Visualizzare i log del traffico nella pagina Anthos Service Mesh

Visualizzare i log del traffico nella pagina Cloud Service Mesh per un servizio durante un determinato questo periodo di tempo, segui questi passaggi:

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

Vai alla pagina Cloud Service Mesh
In Servizi, seleziona il nome del servizio che vuoi ispezionare.
Vai alla pagina Metriche.
Specifica un intervallo di tempo dal menu a discesa Intervallo di tempo o imposta un intervallo personalizzato con la cronologia.
Fai clic su Visualizza log di 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, ad esempio 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 monitoraggio è attivato, le informazioni sulla traccia, ad esempio il campionamento, l'ID traccia e l'ID span.

Un esempio di voce di log è il seguente:

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

Interpretare le metriche del piano di controllo

Quando installi Cloud Service Mesh con il piano di controllo interno al cluster, istiod esporta le metriche in Google Cloud Observability per il monitoraggio, per impostazione predefinita. istiod antepone queste metriche a istio.io/control e fornisce informazioni 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 i passaggi riportati di seguito.

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

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

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 passaggi riportati di seguito spiegano come utilizzare la metrica pilot_proxy_convergence_time per diagnosticare un ritardo tra una modifica alla configurazione e la convergenza di tutti i proxy.

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 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 aiutarti a 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 le installazioni di 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 visualizzazione 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, ad esempio ID, URL, dimensioni, latenza e intestazioni comuni.
Informazioni sul carico di lavoro di origine e di destinazione, ad esempio nome, spazio dei nomi, identità ed etichette comuni.
Informazioni sulla revisione e sul servizio canonico 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 selezionare tutte le richieste che richiedono più di 5 secondi.
Creare metriche basate su log.
Risolvere i problemi relativi agli errori 404 e 503

Risolvi i problemi relativi a `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.

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 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 anche per risolvere i problemi relativi agli errori 503.
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 tramite HTTP, ma la porta è denominata http2, il protocollo non verrà negoziata automaticamente in modo corretto.

Per ulteriori informazioni, vedi dei flag di risposta.

Interpreta i log degli accessi

I passaggi riportati di seguito spiegano come utilizzare i log di accesso (noti anche come log 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 quali:

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

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

Puoi risolvere gli errori di connessione/richiesta generando attività nel tuo un'applicazione che attiva una richiesta HTTP, esaminando la richiesta associata nei log di origine o di destinazione.

Se attivi una richiesta e questa 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 di 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 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 impossibile negoziare automaticamente il protocollo tra il file collaterale e la sua applicazione pod. Assicurati che il nome della porta del servizio Kubernetes, ad esempio http-80, corrisponde 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 MULTUAL_TLS abilitato e utilizza il protocollo grpc. Aggiungi seguendo al server query sui log di accesso:

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

Imposta un criterio di log di accesso

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

Per impostare un criterio per i log di accesso per Cloud Service Mesh con il piano di controllo interno al cluster:

Crea un file di overlay personalizzato IstioOperator che includa i valori AccessLogPolicyConfig applicabili per il tuo scenario.
Passa questo file a asmcli utilizzando l'opzione --custom_overlay per aggiornare la configurazione del piano di controllo in-cluster. Per informazioni sull'esecuzione di asmcli install con un file overlay personalizzato, consulta Installare 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 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

Visualizza gli stati del socket del proxy

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

Visualizza un elenco di socket stabiliti, inclusi quelli in TIME_WAIT il che può influire negativamente sulla scalabilità se il conteggio è elevato:
```
kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- ss -anopim
```

Visualizza un riepilogo delle statistiche socket:

kubectl exec POD_NAME -n NAMESPACE_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 -n NAMESPACE_NAME -c istio-proxy

Puoi fare lo stesso per il contenitore init:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init

Passaggi successivi

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