Richiedi log del proxy
Cloud Service Mesh supporta due diversi tipi di log degli accessi in Cloud Logging: Log del traffico (anche noti come log di accesso di Google Cloud Observability) e Log di accesso di Envoy. In questa pagina viene spiegato come abilitare, disabilitare, visualizzare e interpretare questi log. Tieni presente che i log del traffico sono abilitate per impostazione predefinita.
Abilitazione e disabilitazione dei log degli accessi
Mesh di servizi cloud gestito
Log di accesso di Envoy
Esegui questo comando per abilitare i log di accesso di Envoy e disabilitare il traffico log:
cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
name: enable-envoy-disable-sd
namespace: istio-system
spec:
accessLogging:
- providers:
- name: envoy
- providers:
- name: stackdriver
disabled: true
EOF
Tieni presente che il nome del provider per il log del traffico è stackdriver
.
Log sul traffico
Per impostazione predefinita, i log del traffico sono abilitati e quelli di accesso a Envoy. Se in precedenza hai abilitato i log di accesso a Envoy e vuoi abilitare i log del traffico e Disabilita i log di accesso di Envoy, esegui questo comando:
cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
name: disable-envoy-enable-sd
namespace: istio-system
spec:
accessLogging:
- providers:
- name: envoy
disabled: true
- providers:
- name: stackdriver
EOF
Entrambi
Per abilitare sia i log di accesso che i log del traffico Envoy, esegui questo comando :
cat <<EOF | kubectl apply -n istio-system -f - apiVersion: telemetry.istio.io/v1alpha1 kind: Telemetry metadata: name: enable-envoy-and-sd-access-log namespace: istio-system spec: accessLogging: - providers: - name: envoy - name: stackdriver EOF
Per disabilitare sia i log di accesso sia i log del traffico di Envoy, esegui questo comando :
cat <<EOF | kubectl apply -n istio-system -f - apiVersion: telemetry.istio.io/v1alpha1 kind: Telemetry metadata: name: disable-envoy-and-sd namespace: istio-system spec: accessLogging: - providers: - name: envoy disabled: true - providers: - name: stackdriver disabled: true EOF
istiod
gestita
Log di accesso di Envoy
Esegui questi comandi per abilitare il logging degli accessi Envoy:
Esegui questo comando per aggiungere
accessLogFile: /dev/stdout
:cat <<EOF | kubectl apply -f - apiVersion: v1 data: mesh: |- accessLogFile: /dev/stdout kind: ConfigMap metadata: name: istio-release-channel namespace: istio-system EOF
dove release-channel è il tuo canale di rilascio (
asm-managed
,asm-managed-stable
oasm-managed-rapid
).Esegui questo comando per visualizzare il file configmap:
kubectl get configmap istio-release-channel -n istio-system -o yaml
Per verificare che il logging degli accessi sia abilitato, assicurati che La riga
accessLogFile: /dev/stdout
compare nella sezionemesh:
.... apiVersion: v1 data: mesh: | .... accessLogFile: /dev/stdout ...
Log sul traffico
I log sul traffico sono abilitati per impostazione predefinita.
Nel cluster
Log di accesso di Envoy
Per ulteriori informazioni, vedi Abilita il logging degli accessi di Envoy.
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 abilitare i log del traffico su Google Distributed Cloud con Istio CA
durante l'installazione di Cloud Service Mesh nel cluster,
quindi utilizza il flag --option stackdriver
. In alternativa, puoi attivare il traffico
log su Google Distributed Cloud with Istio CA
dopo l'installazione di Cloud Service Mesh nel cluster.
Visualizzazione dei log di accesso
Log di accesso di Envoy
Riga di comando
Per visualizzare i log di accesso di Envoy nel log istio-proxy, esegui questo comando:
kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy
Esplora log
Per visualizzare i log di accesso di Envoy nel 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
Per visualizzare i log di traffico nel Esplora log:
Vai a Esplora log:
Seleziona il progetto Google Cloud appropriato.
Esegui la seguente query a seconda che tu stia visualizzando il client o log di accesso al server:
Log del server
resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/server-accesslog-stackdriver"
Log client
resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/client-accesslog-stackdriver"
Visualizzare i log del traffico nella pagina Cloud Service Mesh per un servizio durante per un periodo di tempo specificato, segui questi passaggi:
Nella console Google Cloud, vai alla pagina Cloud Service Mesh.
Nella sezione 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 oppure impostare un intervallo personalizzato con la sequenza temporale.
In filter_list Seleziona un'opzione di filtro, fai clic su Visualizza i log del traffico:
Il log del traffico è denominato server-accesslog-stackdriver ed è collegato alla risorsa monitorata corrispondente (k8s_container oppure gce_instance), il tuo servizio è che utilizzano. Il log sul traffico contiene le seguenti informazioni:
Proprietà delle richieste HTTP, come ID, URL, dimensioni, latenza e comuni headers.
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 Cloud Service Mesh
Le sezioni seguenti spiegano come controllare lo stato del mesh ed eseguire la revisione i vari dati di telemetria che contengono dettagli utili per aiutarti risoluzione dei problemi.
Interpretare le metriche del piano di controllo
Mesh di servizi cloud gestito
Cloud Service Mesh con un piano di controllo Cloud Service Mesh gestito non supporta le metriche del piano di controllo.
istiod
gestita
Cloud Service Mesh con un piano di controllo istiod
gestito non supporta
l'ispezione delle metriche del piano di controllo
in questa sezione.
Nel cluster
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 il piano di controllo o risolvi i relativi problemi seguendo questa procedura.
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.
Diagnosticare i ritardi di configurazione
Mesh di servizi cloud gestito
Cloud Service Mesh con un piano di controllo Cloud Service Mesh gestito non supporta diagnosticare i ritardi di configurazione.
istiod
gestita
Cloud Service Mesh con un piano di controllo Istio gestito non supporta diagnosticare i ritardi di configurazione.
Nel cluster
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.
Esegui un comando shell in un pod:
kubectl debug --image istio/base --target istio-proxy -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -- curl -s
Accedi a
localhost:15014
egrep
perconvergence
nelle metriche:curl http://localhost:15014/metrics | grep convergence
Interpretare i log del traffico
Le seguenti informazioni spiegano come utilizzare i log del traffico per risolvere i problemi problemi di connessione. I log sul traffico sono abilitati per impostazione predefinita.
Cloud Service Mesh esporta i dati nei log del traffico che possono aiutarti a eseguire il debug i seguenti tipi di problemi:
- Flusso di traffico ed errori
- Routing delle richieste end-to-end
I log sul traffico sono abilitati per impostazione predefinita per le installazioni di Cloud Service Mesh su
Google Kubernetes Engine. Puoi abilitare i log del traffico eseguendo di nuovo asmcli install
. Utilizza le funzionalità di
le stesse opzioni che hai installato inizialmente, ma ometti l'overlay personalizzato
ha disabilitato Stackdriver.
Esistono due tipi di log di traffico:
I log di accesso al server forniscono una vista lato server delle richieste. Si trovano in
server-accesslog-stackdriver
, collegato ak8s_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 monitoratak8s_pod
. Utilizza la seguente sintassi dell'URL per visualizzare i log dell'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 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.
I log sul traffico possono contenere le seguenti etichette:
route_name
upstream_cluster
X-Envoy-Original-Path
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 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.
- Risolvi i problemi relativi a
404
e503
Risolvi i problemi relativi a 404
e 503
L'esempio seguente spiega come utilizzare questo log per risolvere i problemi quando
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
è l'acronimo diNoRoute
, il che significa che non è stata trovata alcuna route per destinazione o non esisteva una catena di filtri corrispondente per un downstream connessione. Analogamente, puoi utilizzare l'etichettaresponse_flag
per risolvere i problemi503
errori.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 è denominatahttp2
, il protocollo non verrà negoziata automaticamente in modo corretto.
Per ulteriori informazioni, vedi dei flag di risposta.
Interpretare i log di accesso di Envoy
I passaggi seguenti spiegano come utilizzare i log di accesso di Envoy per visualizzare il traffico. tra entrambe le estremità di una connessione, per la risoluzione dei 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 di accesso a Envoy non sono abilitati per impostazione predefinita in Cloud Service Mesh e possono essere abilitato per i cluster in un mesh.
Puoi risolvere gli errori di connessione o di richiesta generando attività in alla tua applicazione che attiva una richiesta HTTP, quindi ispezionare i richiesta 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 assicurarti che
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 funziona correttamente. Se viene invece visualizzato un errore, esegui un Envoy il dump della configurazione e verificare i valori corretti per la porta di traffico impostata la configurazione del listener.
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 Esplora log.
per eseguire query su specifici log di accesso a Envoy. Ad esempio, per eseguire query su tutte le richieste
hai abilitato MULTUAL_TLS
e utilizza il protocollo grpc
, aggiungi quanto segue al
query sui log di accesso al server:
labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"
Imposta un criterio di log di accesso
Mesh di servizi cloud gestito
Per configurare i log di accesso per Cloud Service Mesh con un server sul piano di controllo Cloud Service Mesh, vedi Attivazione dei log degli accessi.
istiod
gestita
Per configurare i log di accesso per Cloud Service Mesh con un server il piano di controllo Istio, consulta Attivazione dei log degli accessi.
Nel cluster
Per impostare un criterio di log di accesso per Cloud Service Mesh con il controllo nel cluster aereo:
Crea un file di overlay personalizzato
IstioOperator
che includa l'oggettoAccessLogPolicyConfig
per il tuo scenario.Passa questo file a
asmcli
utilizzando l'opzione--custom_overlay
per aggiornare la configurazione del piano di controllo nel cluster. Per informazioni sulla corsaasmcli install
con un file di overlay personalizzato, vedi Installazione con funzionalità facoltative.
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 servizio o un carico di lavoro specifico
esaminare i singoli proxy Envoy e raccogliere le informazioni pertinenti
da questi. Per raccogliere informazioni su un determinato carico di lavoro e sui suoi proxy,
puoi usare 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 Envoyclusters
- Cluster con Envoy configuratoconfig_dump
- Esegue il dump della configurazione Envoylisteners
- Listener con Envoy configuratologging
- Visualizza e modifica le impostazioni di loggingstats
- Statistiche di Envoystats/prometheus
- Statistiche di Envoy come record di 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 debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
Visualizza un riepilogo delle statistiche socket:
kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- 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.