Anthos Service Mesh 1.6 ha raggiunto la fine del ciclo di vita e non è più supportato. Vedi Upgrade da versioni precedenti.

Visualizza la documentazione più recente o seleziona un'altra versione disponibile:

Versioni disponibili

1.20 (ultima versione)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Interpretazione dei log di Anthos Service Mesh

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

Interpretare le metriche del piano di controllo

Durante l'installazione di Anthos Service Mesh utilizzando il profilo asm-gcp, Istiod esporta le metriche nell'osservabilità di Google Cloud per il monitoraggio, per impostazione predefinita. Istiod prefissa queste metriche con istio.io/control e fornisce insight sullo stato del piano di controllo, come il numero di proxy connessi a ogni istanza del piano di controllo, gli eventi di configurazione, i push e le 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 && git checkout asm

Installa la dashboard di Anthos 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 maggiori informazioni, consulta la pagina relativa alla visualizzazione della dashboard installata.

Se non utilizzi il profilo asm-gcp, puoi comunque abilitare le metriche del piano di controllo aggiungendo le variabili di ambiente al deployment Istiod:
```
- name: ENABLE_STACKDRIVER_MONITORING
value: "true"
```
Inoltre, puoi aggiungere questa variabile di ambiente utilizzando l'opzione di installazione components.pilot.k8s.env.

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

Eseguire 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 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
```

Interpreta i log degli accessi all'osservabilità di Google Cloud

Le seguenti informazioni spiegano come utilizzare i log di accesso di osservabilità di Google Cloud per risolvere i problemi di connessione.

Anthos Service Mesh esporta i dati nei log degli accessi all'osservabilità di Google Cloud 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/traffico per l'osservabilità di Google Cloud sono abilitati per impostazione predefinita nel profilo asm-gcp nell'intero mesh. Tuttavia, se non sono già abilitati, puoi utilizzare il seguente comando:

istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION \
    --set values.telemetry.v2.stackdriver.enabled=true \
    --set values.telemetry.v2.stackdriver.logging=true

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, collegati alla risorsa monitorata k8s_container. Utilizza la seguente sintassi dell'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 degli accessi client forniscono 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 di accesso lato client:
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID
```
.

Solo i log degli errori del client sono abilitati per impostazione predefinita per ridurre i costi di logging. Tuttavia, puoi abilitare tutti i log del client (operazione riuscita ed errori) utilizzando il seguente comando:

istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION 

    --set values.telemetry.v2.stackdriver.enabled=true 

    --set values.telemetry.v2.stackdriver.outboundAccessLogging=FULL

I log degli accessi contengono le seguenti informazioni:

Proprietà delle richieste HTTP, come ID, URL, dimensione, 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 di osservabilità di Google Cloud provengono dai log di accesso 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 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 in caso di errore di una richiesta 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 degli accessi. Trova il campo response_flag con 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 non è stata trovata una catena di filtri corrispondente per una connessione downstream. Analogamente, puoi utilizzare l'etichetta response_flag per risolvere gli errori 503.
Se noti errori 503 nei log di accesso client e server, verifica che i nomi delle porte impostati per ciascun servizio corrispondano al nome del protocollo in uso tra i due. Ad esempio, se un client binario golang si connette a un server golang utilizzando HTTP, ma la porta è denominata http2, il protocollo non negozierà automaticamente in modo corretto.

Per ulteriori informazioni, consulta Flag di risposta.

Interpretare i log di Envoy

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

I log di accesso 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 nell'intero mesh.

Puoi risolvere gli errori 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 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 noti errori nei log, genera un dump della configurazione Envoy e controlla la configurazione del cluster Envoy per verificare che sia corretta. Se visualizzi 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, indica che il mesh stesso funziona correttamente. Se invece visualizzi 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 file collaterale e il relativo pod di 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 Esplora log per eseguire query su log di accesso specifici. Ad esempio, per eseguire 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

Puoi impostare un criterio di logging del proxy che determina il tipo di informazioni che raccogli. Questo è utile per controllare l'ambito dei log e risolvere i problemi. Ad esempio, il logging acquisisce automaticamente gli errori, ma puoi impostare logWindowDuration in modo da acquisire anche gli eventi riusciti per un periodo di tempo specifico o impostare la durata della finestra su zero per registrare tutti gli accessi. Il criterio viene impostato a livello di mesh o cluster.

Per abilitare un criterio del log di accesso, utilizza il comando seguente:

istioctl install --set profile=PROFILE_NAME \
    --set values.telemetry.v2.stackdriver.enabled=true \
    --set values.telemetry.v2.stackdriver.logging=true \
    --set values.telemetry.accessLogPolicy.enabled=true

Per ulteriori informazioni sulle opzioni di configurazione dei log degli accessi, ad esempio logWindowDuration, consulta Configurazione di AccessLogPolicy.

Visualizzare 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 a livello di 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 con Envoy configurato
config_dump - Esegui il dump della configurazione Envoy
listeners - Listener con Envoy configurato
logging - Visualizza e modifica le impostazioni di logging
stats - Statistiche Envoy
stats/prometheus - Statistiche Envoy come registri Prometheus

Visualizza gli stati dei socket proxy

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

Visualizza un elenco di 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
```
Visualizza un riepilogo delle statistiche 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 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