Richiedere i log proxy

Cloud Service Mesh supporta due diversi tipi di log di accesso in Cloud Logging: Log di traffico (noti anche come log di accesso di Google Cloud Observability) e log di accesso di Envoy. Questa pagina mostra come attivare, disattivare, visualizzare e interpretare questi log. Tieni presente che i log del traffico sono attivati per impostazione predefinita.

Attivazione e disattivazione dei log di accesso

Cloud Service Mesh gestito

Log di accesso di Envoy

Esegui questo comando per abilitare i log di accesso di Envoy e disabilitare i log di traffico:

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 fornitore per il log del traffico è stackdriver.

Log sul traffico

Per impostazione predefinita, i log di traffico sono abilitati e i log di accesso Envoy sono disabilitati. Se in precedenza hai attivato i log di accesso Envoy e vuoi attivare i log sul traffico e disattivare i log di accesso Envoy, esegui il seguente 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 di Envoy sia i log sul traffico, 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 disattivare sia i log di accesso di Envoy sia i log di traffico, 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
    

Gestito da istiod

Log di accesso di Envoy

Esegui i seguenti comandi per abilitare la registrazione degli accessi di Envoy:

  1. 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 o asm-managed-rapid).

  2. Esegui questo comando per visualizzare il configmap:

     kubectl get configmap istio-release-channel -n istio-system -o yaml
    
  3. Per verificare che il logging degli accessi sia abilitato, assicurati che la riga accessLogFile: /dev/stdout venga visualizzata nella sezione mesh:.

    ...
    apiVersion: v1
    data:
      mesh: |
        ....
        accessLogFile: /dev/stdout
    ...
    

Log sul traffico

I log del traffico sono abilitati per impostazione predefinita.

In-cluster

Log di accesso di Envoy

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

Per maggiori informazioni, vedi Attivare la registrazione degli accessi di Envoy.

Log sul traffico

I log del traffico sono abilitati per impostazione predefinita, a meno che Cloud Service Mesh non sia installato su Google Distributed Cloud con Istio CA (precedentemente noto come Citadel).

Per attivare i log di traffico su Google Distributed Cloud con Istio CA durante l'installazione di Cloud Service Mesh nel cluster, utilizza il flag --option stackdriver. In alternativa, puoi abilitare i log di traffico su Google Distributed Cloud con Istio CA dopo aver installato 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 degli accessi di Envoy in Esplora log:

  1. Vai a Esplora log:

    Vai a Esplora log

  2. Seleziona il Google Cloud progetto appropriato.

  3. 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 in Esplora log:

  1. Vai a Esplora log:

    Vai a Esplora log

  2. Seleziona il Google Cloud progetto appropriato.

  3. Esegui la seguente query a seconda che tu stia visualizzando i log di accesso client o 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"
    

Per visualizzare i log di traffico nella pagina Cloud Service Mesh per un servizio durante un intervallo di tempo specificato, segui questi passaggi:

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

    Vai alla pagina Cloud Service Mesh

  2. Nella sezione Servizi, seleziona il nome del servizio che vuoi esaminare.

  3. Vai alla pagina Metriche.

  4. Specifica un intervallo di tempo dal menu a discesa Intervallo di tempo o imposta un intervallo personalizzato con la cronologia.

  5. In Seleziona un'opzione di filtro, fai clic su Visualizza log del traffico.

Il log del traffico è denominato server-accesslog-stackdriver ed è collegato alla risorsa monitorata corrispondente (k8s_container o gce_instance) utilizzata dal tuo servizio. Il log del traffico contiene le seguenti informazioni:

  • Proprietà della richiesta HTTP, come ID, URL, dimensioni, latenza e intestazioni comuni.

  • Informazioni sui workload di origine e di destinazione, ad esempio nome, spazio dei nomi, identità ed etichette comuni.

  • Se la tracciabilità è attivata, le informazioni di tracciamento, come il campionamento, l'ID traccia e l'ID span.

Una voce di log di esempio è simile alla 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 Cloud Service Mesh

Le sezioni seguenti spiegano come controllare lo stato della mesh e rivedere le varie telemetrie che contengono dettagli utili per aiutarti nella risoluzione dei problemi.

Interpretare le metriche del control plane

Cloud Service Mesh gestito

Cloud Service Mesh con un control plane Cloud Service Mesh gestito non supporta le metriche del control plane.

Gestito da istiod

Cloud Service Mesh con un control plane istiod gestito non supporta l'ispezione delle metriche del control plane in questa sezione.

In-cluster

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 piano di controllo, ad esempio il numero di proxy connessi a ciascuna istanza del piano di controllo, eventi di configurazione, push e convalide.

Osserva o risolvi i problemi del control plane seguendo questi passaggi.

  1. Carica una dashboard di esempio:

    git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples/dashboards && git checkout servicemesh
  2. Installa la dashboard Cloud Service Mesh:

    gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json
  3. Cerca nell'elenco una dashboard denominata Istio Control Plane Dashboard. Per ulteriori informazioni, vedi Visualizzare la dashboard installata.

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

Eseguire la diagnostica dei ritardi di configurazione

Cloud Service Mesh gestito

Cloud Service Mesh con un control plane Cloud Service Mesh gestito non supporta la diagnosi dei ritardi di configurazione.

Gestito da istiod

Cloud Service Mesh con un control plane istiod gestito non supporta la diagnosi dei ritardi di configurazione.

In-cluster

I seguenti passaggi 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.

  1. 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
  2. Accedi a localhost:15014 e grep per convergence nelle metriche:

    curl http://localhost:15014/metrics | grep convergence

Interpretare i log di traffico

Le seguenti informazioni spiegano come utilizzare i log del traffico per risolvere i problemi di connessione. I log del traffico sono abilitati per impostazione predefinita.

Cloud Service Mesh esporta i dati nei log di traffico 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 di traffico sono abilitati per impostazione predefinita per le installazioni di Cloud Service Mesh su Google Kubernetes Engine. Puoi attivare i log sul traffico eseguendo di nuovo asmcli install. Utilizza le stesse opzioni che hai installato originariamente, ma ometti l'overlay personalizzato che ha disattivato Stackdriver.

Esistono due tipi di log del traffico:

  • I log di accesso al server forniscono una visualizzazione lato server delle richieste. Si trovano in server-accesslog-stackdriver, allegati alla risorsa k8s_container monitorata. 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 di accesso client forniscono una visualizzazione lato client delle richieste. Si trovano in client-accesslog-stackdriver, collegati 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 di accesso contengono le seguenti informazioni:

  • Proprietà della richiesta HTTP, come ID, URL, dimensioni, latenza e intestazioni comuni.
  • Informazioni sui workload di origine e di destinazione, ad esempio nome, spazio dei nomi, identità ed etichette comuni.
  • Informazioni sul servizio canonico e sulla revisione di origine e destinazione.
  • Se la tracciabilità è attivata, i log contengono informazioni di traccia, come campionamento, ID traccia e ID intervallo.

I log del 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 vari modi:

  • Esegui l'integrazione con Cloud Trace, una funzionalità facoltativa di Cloud Service Mesh.
  • Esporta i log del traffico in BigQuery, dove puoi eseguire query come la selezione di tutte le richieste che richiedono più di 5 secondi.
  • Creare metriche basate su log.
  • Risolvere i problemi relativi agli errori 404 e 503

Risolvere i problemi relativi agli errori 404 e 503

Il seguente esempio 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.

  1. 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"
    }
  2. Vai alle etichette nella voce del log di accesso. Trova 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 è stata trovata alcuna catena di filtri corrispondente per una connessione downstream. Allo stesso modo, puoi utilizzare l'etichetta response_flag per risolvere anche gli errori 503.

  3. Se visualizzi errori 503 nei log di accesso del client e del server, verifica che i nomi delle porte impostati per ogni 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 verrà negoziato automaticamente in modo corretto.

Per ulteriori informazioni, vedi flag di risposta.

Interpretare i log di accesso di Envoy

I passaggi seguenti spiegano come utilizzare i log di accesso di Envoy per mostrare il traffico tra le due estremità di una connessione a scopo di 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 di Envoy non sono abilitati per impostazione predefinita in Cloud Service Mesh e possono essere abilitati per i cluster in un mesh.

Puoi risolvere i problemi di connessione o di richiesta generando attività nella tua applicazione che attiva una richiesta HTTP, quindi esaminando la richiesta associata nei log di origine o di destinazione.

Se viene attivata 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 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 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 negoziare automaticamente il 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.

Utilizzare Esplora log per eseguire query sui log

Puoi utilizzare l'interfaccia di Logs Explorer per eseguire query su log di accesso Envoy specifici. Ad esempio, per eseguire query su tutte le richieste che hanno MULTUAL_TLS abilitato e 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 di log degli accessi

Cloud Service Mesh gestito

Per configurare i log di accesso per Cloud Service Mesh con un control plane Cloud Service Mesh gestito, consulta Abilitazione dei log di accesso.

Gestito da istiod

Per configurare i log di accesso per Cloud Service Mesh con un control plane istiod gestito, consulta Abilitazione dei log di accesso.

In-cluster

Per impostare un criterio dei log di accesso per Cloud Service Mesh con il piano di controllo in-cluster:

  1. Crea un file di overlay personalizzato IstioOperator che includa i valori AccessLogPolicyConfig applicabili al tuo scenario.

  2. Passa questo file a asmcli utilizzando l'opzione --custom_overlay per aggiornare la configurazione del control plane in-cluster. Per informazioni sull'esecuzione di asmcli install con un file di overlay personalizzato, vedi Installazione con funzionalità facoltative.

Visualizzare informazioni specifiche del servizio o del workload

Se hai un problema con un servizio o un carico di lavoro specifico anziché con l'intera mesh, esamina i singoli proxy Envoy e raccogli le informazioni pertinenti. Per raccogliere informazioni su un particolare 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 valori:

  • 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 - Visualizzare e modificare le impostazioni di logging
  • stats - Statistiche di Envoy
  • stats/prometheus - Statistiche di Envoy come record Prometheus

Visualizza gli stati dei socket proxy

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

  1. Visualizza un elenco di socket stabiliti, inclusi i socket nello stato TIME_WAIT, che possono influire negativamente sulla scalabilità se il loro numero è elevato:

    kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
  2. Visualizza un riepilogo delle statistiche dei socket:

    kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -s

Per ulteriori informazioni, consulta An Introduction to the ss Command.

Log istio-proxy e istio-init

Inoltre, recupera i log istio-proxy ed esamina i contenuti per individuare eventuali errori che potrebbero suggerire la causa del problema:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Puoi fare lo stesso per il container init:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init

Passaggi successivi