Richiedi i log proxy
Le pagine di 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 sul traffico (noti anche come log degli accessi di Google Cloud Observability).
Log degli accessi
Abilita log degli accessi
I passaggi necessari per abilitare i log degli accessi dipendono dal tipo di Cloud Service Mesh, gestito o in-cluster:
Gestito
Segui le istruzioni per abilitare i log degli accessi in Cloud Service Mesh gestito.
Interno al cluster
Segui le istruzioni per abilitare i log degli accessi in Cloud Service Mesh in-cluster.
Visualizza log degli accessi
Per visualizzare i log degli accessi in Esplora log:
Vai a Esplora log:
Seleziona ilprogettoappropriato. Google Cloud
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 con Istio CA (precedentemente nota come Citadel).
Per abilitare i log sul traffico su Google Distributed Cloud con Istio CA
quando installi Cloud Service Mesh in-cluster,
utilizza il flag --option stackdriver. In alternativa, puoi abilitare i log sul traffico su Google Distributed Cloud con Istio CA
dopo aver installato Cloud Service Mesh in-cluster.
Visualizza log di traffico
Visualizza i log di traffico in Esplora log
Per visualizzare i log di traffico in Esplora log: :
Vai a Esplora log:
Seleziona ilprogettoappropriato. Google Cloud
Esegui la seguente query a seconda che tu stia visualizzando i log degli accessi client o server:
Log del server
resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/server-accesslog-stackdriver"Log del client
resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/client-accesslog-stackdriver"
Visualizza i log di traffico nella pagina Anthos Service Mesh
Per visualizzare i log di traffico nella pagina Cloud Service Mesh per un servizio durante un intervallo di tempo specificato, segui questi passaggi:
Nella Google Cloud console, 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 sequenza temporale.
In filter_list Seleziona un'opzione di filtro, fai clic su Visualizza log di traffico.
Il log di traffico è denominato server-accesslog-stackdriver ed è collegato alla risorsa monitorata corrispondente (k8s_container o gce_instance) utilizzata dal servizio. Il log di traffico contiene le seguenti informazioni:
Proprietà della richiesta HTTP, come ID, URL, dimensioni, latenza e intestazioni comuni.
Informazioni sul workload di origine e di destinazione, come nome, spazio dei nomi, identità ed etichette comuni.
Se il tracing è abilitato, informazioni di traccia, come campionamento, ID traccia e ID intervallo.
Ecco 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"
}Interpreta la telemetria di Anthos Service Mesh
Le sezioni seguenti spiegano come controllare lo stato del mesh e rivedere le varie telemetrie che contengono dettagli utili per la risoluzione dei problemi.
Interpreta le metriche del control plane
Quando installi Cloud Service Mesh con il control plane in-cluster, istiod esporta le metriche in Google Cloud Observability per il monitoraggio, per impostazione predefinita.
istiod antepone a queste metriche il prefisso istio.io/control e fornisce informazioni sullo stato del control plane, come il numero di proxy connessi a ogni istanza del control plane, gli eventi di configurazione, i push e le convalide.
Osserva o risolvi i problemi del control plane 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 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 Dashboardnell'elenco. Per ulteriori informazioni, consulta Visualizzare la dashboard installata.
Per l'elenco completo delle metriche disponibili, consulta Metriche esportate.
Esegui 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 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 -sAccedi a
localhost:15014egrepperconvergencenelle metriche:curl http://localhost:15014/metrics | grep convergence
Interpreta i log degli accessi della suite operativa di Google Cloud
Le seguenti informazioni spiegano come utilizzare i log degli accessi di Google Cloud Observability per risolvere i problemi di connessione. I log degli accessi/del traffico di Google Cloud Observability sono abilitati per impostazione predefinita.
Cloud Service Mesh esporta i dati nei log degli accessi di Google Cloud Observability, che possono 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 di Google Cloud Observability sono abilitati per impostazione predefinita per le installazioni di Cloud Service Mesh su Google Kubernetes Engine. Puoi abilitare i log degli accessi di Google Cloud Observability eseguendo di nuovo asmcli install. Utilizza le stesse opzioni che hai installato originariamente, 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, collegati alla risorsa monitoratak8s_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 forniscono una visualizzazione lato client delle richieste. Si trovano in
client-accesslog-stackdriver, collegati alla risorsa monitoratak8s_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à della richiesta HTTP, come ID, URL, dimensioni, latenza e intestazioni comuni.
- Informazioni sul workload di origine e di destinazione, come nome, spazio dei nomi, identità ed etichette comuni.
- Informazioni sul servizio canonico e sulla revisione di origine e di destinazione.
- Se il tracing è abilitato, i log contengono informazioni di traccia, come campionamento, ID traccia e ID intervallo.
Le informazioni visualizzate nei log degli accessi di Google Cloud Observability provengono dai log degli accessi di Envoy, quando li abiliti nella configurazione di Istio. Contengono le seguenti intestazioni:
route_nameupstream_clusterX-Envoy-Original-PathX-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:
- Esegui l'integrazione con Cloud Trace, una funzionalità facoltativa di Cloud Service Mesh.
- Esporta i log di traffico in BigQuery, dove puoi eseguire query come la selezione di tutte le richieste che richiedono più di 5 secondi.
- Crea metriche basate su log.
- Risolvi i problemi relativi agli errori
404e503
Risolvi i problemi relativi agli errori 404 e 503
L'esempio seguente spiega come utilizzare questo log per risolvere i problemi quando una richiesta non riesce con un codice di risposta 404 o 503.
Nel log degli accessi 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 degli accessi. Trova il campo
response_flagsimile al seguente:response_flag: "NR"
Il valore
NRè un acronimo diNoRoute, 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. Allo stesso modo, puoi utilizzare l'etichettaresponse_flaganche per risolvere i problemi relativi agli errori503.Se visualizzi errori
503sia nei log degli accessi client sia in quelli del server, verifica che i nomi delle porte impostati per ogni servizio corrispondano al nome del protocollo in uso tra di essi. Ad esempio, se un client binario golang si connette a un server golang utilizzando HTTP, ma la porta è denominatahttp2, il protocollo non eseguirà la negoziazione automatica correttamente.
Per ulteriori informazioni, consulta i flag di risposta.
Interpreta i log degli accessi
I passaggi seguenti spiegano come utilizzare i log degli accessi (noti anche come log del 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 come:
- Flusso di traffico ed 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'intero mesh.
Puoi risolvere i problemi relativi agli 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 viene visualizzata una richiesta e 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 Envoy per assicurarti che sia corretta. Se visualizzi la richiesta, ma il log non contiene errori, controlla invece 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 visualizzi un errore, esegui un dump della configurazione di Envoy e verifica i valori corretti per la porta di traffico impostata nella configurazione del listener.
Se il problema persiste dopo aver eseguito i passaggi precedenti, Envoy potrebbe non essere in grado di eseguire la negoziazione automatica del 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 query su tutte le richieste per cui è abilitato MULTUAL_TLS e che utilizzano il protocollo grpc, aggiungi quanto segue alla query dei log degli accessi al server:
labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"
Imposta una policy dei log degli accessi
Per configurare la registrazione dei proxy per Cloud Service Mesh gestito, consulta Log degli accessi di Envoy.
Per impostare una policy dei log degli accessi per Cloud Service Mesh con il control plane in-cluster:
Crea un file di overlay personalizzato
IstioOperatorche includa i valori applicabiliAccessLogPolicyConfigper il tuo scenario.Passa questo file a
asmcliutilizzando l'opzione--custom_overlayper aggiornare la configurazione del control plane in-cluster. Per informazioni sull'esecuzioneasmcli installcon un file di overlay personalizzato, consulta Installazione con funzionalità facoltative.
Visualizza informazioni specifiche del servizio o del workload
Se hai un problema con un servizio o un workload specifico anziché un problema a livello di mesh, ispeziona i singoli proxy Envoy e raccogli le informazioni pertinenti. Per raccogliere informazioni su un determinato workload 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 di Envoyclusters- Cluster con Envoy configuratoconfig_dump- Esegue il dump della configurazione di Envoylisteners- Listener con Envoy configuratologging- Visualizza e modifica le impostazioni di loggingstats- Statistiche di Envoystats/prometheus- Statistiche di Envoy come record Prometheus
Visualizza gli stati dei socket proxy
Puoi esaminare direttamente lo stato dei socket proxy Envoy utilizzando la seguente procedura.
Visualizza un elenco di socket stabiliti, 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 Introduzione al comando ss.
Log istio-proxy e istio-init
Inoltre, recupera i log istio-proxy e rivedine i contenuti per verificare la presenza di eventuali errori che potrebbero suggerire la causa del problema:
kubectl logs POD_NAME -c istio-proxy
Puoi fare lo stesso per il container init:
kubectl logs POD_NAME -c istio-init
Passaggi successivi
Esegui l'integrazione con Cloud Trace. Cloud Trace è una funzionalità facoltativa di Cloud Service Mesh.