Risoluzione dei problemi di osservabilità e telemetria in Cloud Service Mesh

Questa sezione illustra i problemi comuni di Cloud Service Mesh e come risolverli. Se hai bisogno di ulteriore aiuto, vedi Ricevere assistenza.

Nella telemetria di Cloud Service Mesh, i proxy Envoy chiamano le API Google Cloud Observability periodicamente per generare report sui dati di telemetria. Il tipo di chiamata API determina la sua frequenza:

  • Logging: ogni 10 secondi circa
  • Metriche: ogni minuto circa
  • Perimetri (visualizzazione API Context/topologia): report incrementali ogni minuto circa, con report completi ogni 10 minuti circa.
  • Tracce: determinata in base alla frequenza di campionamento configurata (in genere, una richiesta ogni 100).

Le dashboard di telemetria raccolgono i dati sia di Confluence che di Google Cloud Observability per visualizzare le varie dashboard incentrate sui servizi.

Nella dashboard dei servizi manca un servizio

La dashboard mostra solo i servizi HTTP(S)/gRPC. Se il servizio deve essere verifica che la telemetria di Cloud Service Mesh lo identifichi come servizio HTTP.

Se il servizio persiste, verifica che Configurazione del servizio Kubernetes nel tuo cluster.

Rivedi l'elenco di tutti i servizi Kubernetes:

kubectl get services --all-namespaces

Esamina l'elenco dei servizi Kubernetes in uno spazio dei nomi specifico:

kubectl get services -n YOUR_NAMESPACE

Metriche mancanti o errate per i servizi

Se mancano metriche o sono errate per i servizi nei Servizi consulta le sezioni seguenti per le potenziali risoluzioni.

Verifica che i proxy Sidecar esistano e siano stati inseriti correttamente

Lo spazio dei nomi potrebbe non avere un'etichetta per l'inserimento automatico oppure L'inserimento manuale non è riuscito. Conferma che i pod nello spazio dei nomi abbiano almeno due di questi container è il container istio-proxy:

kubectl -n YOUR_NAMESPACE get pods

Verifica che la configurazione della telemetria esista

Utilizza EnvoyFiltri nello spazio dei nomi istio-system per configurare la telemetria. Senza questa configurazione, Cloud Service Mesh non segnalerà i dati a Google Cloud Observability.

Verifica che esista la configurazione di Google Cloud Observability (e la configurazione dello scambio di metadati):

kubectl -n istio-system get envoyfilter

L'output previsto è simile al seguente:

NAME                        AGE
metadata-exchange-1.4       13d
metadata-exchange-1.5       13d
stackdriver-filter-1.4      13d
stackdriver-filter-1.5      13d
...

Per confermare ulteriormente che il filtro Observability di Google Cloud sia configurato correttamente, raccogli una il dump della configurazione da ciascun proxy e cerca la presenza di filtro:

kubectl exec YOUR_POD_NAME -n YOUR_NAMESPACE -c istio-proxy curl localhost:15000/config_dump

Nell'output del comando precedente, cerca il filtro Observability di Google Cloud, che cerca ad esempio:

"config": {
    "root_id": "stackdriver_inbound",
    "vm_config": {
        "vm_id": "stackdriver_inbound",
        "runtime": "envoy.wasm.runtime.null",
        "code": {
            "local": {
                "inline_string": "envoy.wasm.null.stackdriver"
             }
         }
     },
     "configuration": "{....}"
}

Verificare che Cloud Service Mesh identifichi un servizio HTTP

Le metriche non vengono visualizzate nell'interfaccia utente se la porta del servizio Il servizio Kubernetes non è denominato http o qualsiasi nome con prefisso http-. Verifica che il servizio abbia i nomi appropriati per le sue porte.

Verifica che l'API Cloud Monitoring sia abilitata per il progetto

Verifica che l'API Cloud Monitoring sia abilitata nelle API e nella dashboard dei servizi in console Google Cloud, che è l'impostazione predefinita.

Verifica che non ci siano segnalazioni di errori all'API Cloud Monitoring

Nell'API Google Cloud Console e nella dashboard dei servizi, apri URL grafico Traffico per codice di risposta:

https://console.cloud.google.com/apis/api/monitoring.googleapis.com/metrics?folder=&organizationId=&project=YOUR_PROJECT_ID

Se vengono visualizzati messaggi di errore, potrebbe trattarsi di un problema che richiede ulteriori le indagini. In particolare, cerca un numero elevato di messaggi di errore 429. che indica un potenziale problema di quota. Consulta la prossima sezione passaggi per la risoluzione dei problemi.

Verifica la quota corretta per l'API Cloud Monitoring

Nella console Google Cloud, apri il menu IAM & Admin e verifica che sia presente una quota . Puoi accedere direttamente a questa pagina utilizzando l'URL:

https://console.cloud.google.com/iam-admin/quotas?project=YOUR_PROJECT_ID

Questa pagina mostra l'insieme completo delle quote per il progetto, dove puoi cercare Cloud Monitoring API.

Verifica che nessun log di errore nei proxy Envoy

Esamina i log del proxy in questione, cercando le istanze dei messaggi di errore:

kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy

Tuttavia, ignora i messaggi di avviso come i seguenti, che sono normali:

[warning][filter] [src/envoy/http/authn/http_filter_factory.cc:83]
mTLS PERMISSIVE mode is used, connection can be either plaintext or TLS,
and client cert can be omitted. Please consider to upgrade to mTLS STRICT mode
for more secure configuration that only allows TLS connection with client cert.
See https://istio.io/docs/tasks/security/mtls-migration/ [warning][config]
[bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91]
gRPC config stream closed: 13

Verifica che metric.mesh_uid sia impostato correttamente

Aperto Esplora metriche ed esegui questa query MQL:

fetch istio_canonical_service
| metric 'istio.io/service/server/request_count'
| align delta(1m)
| every 1m
| group_by [metric.destination_canonical_service_namespace, metric.destination_canonical_service_name, metric.mesh_uid]

Verifica che tutti i servizi previsti stiano generando report di metriche e che i relativi metric.mesh_uid è nel formato proj-<Cloud Service Mesh fleet project number>.

Se metric.mesh_uid presenta altri valori, la dashboard di Cloud Service Mesh non mostrano le metriche. metric.mesh_uid viene impostato quando Cloud Service Mesh è sul cluster, quindi verifica il tuo metodo di installazione per verificare c'è un modo per impostarlo sul valore previsto.

Dati di telemetria mancanti o errati per i servizi

Per impostazione predefinita, Cloud Monitoring e Cloud Logging sono abilitati progetto Google Cloud al momento dell'installazione di Cloud Service Mesh. Per generare report sui dati di telemetria, ogni proxy sidecar che viene inserito nei pod di servizio chiama l'API Cloud Monitoring e l'API Cloud Logging. Dopo il deployment dei carichi di lavoro, uno o due minuti affinché i dati di telemetria vengano visualizzati nella console Google Cloud. Cloud Service Mesh mantiene automaticamente le dashboard dei servizi aggiornati:

  • Per le metriche, i proxy collaterali chiamano l'API Cloud Monitoring approssimativamente ogni minuto.
  • Per aggiornare il grafico della topologia, i proxy collaterali inviano report incrementali ogni minuto circa e report completi ogni dieci minuti circa.
  • Per il logging, i proxy sidecar chiamano l'API Cloud Logging approssimativamente ogni dieci secondi.
  • Per il tracciamento, devi abilitare Cloud Trace. Le tracce vengono segnalate in base alla frequenza di campionamento configurata (di solito, uno ogni 100 richieste).

Le metriche vengono visualizzate solo per i servizi HTTP nella pagina delle metriche di Cloud Service Mesh. Se non vedi metriche, verifica che tutti i pod nello spazio dei nomi per nei servizi dell'applicazione sono stati inseriti proxy sidecar:

kubectl get pod -n YOUR_NAMESPACE --all

Nell'output, nota che la colonna READY mostra due container per ciascuno i tuoi carichi di lavoro: il container principale e il container per il proxy sidecar.

Inoltre, la dashboard dei servizi mostra solo le metriche del server, quindi la telemetria i dati potrebbero non essere visualizzati se il client non è nella rete o se è configurato Segnala solo le metriche client (ad esempio i gateway in entrata).