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

Questa sezione illustra i problemi comuni di Cloud Service Mesh e come risolverli che li rappresentano. Per ulteriore assistenza, consulta Assistenza.

Nella telemetria di Cloud Service Mesh, i proxy Envoy chiamano la classe API Google Cloud Observability per segnalare periodicamente i dati di telemetria. Il tipo di chiamata API ne determina la frequenza:

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

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

Verifica che esista al massimo una configurazione dell'API di telemetria Istio

Questa sezione si applica solo al piano di controllo di Cloud Service Mesh gestito.

Per elencare le configurazioni dell'API Telemetry, esegui questo comando. Verifica che esiste al massimo una configurazione dell'API di telemetria Istio.

kubectl -n istio-system get telemetry

Nella dashboard dei servizi manca un servizio

La dashboard mostra solo i servizi HTTP(S)/gRPC. Se il servizio deve essere dell'elenco, verifica che la telemetria di Cloud Service Mesh lo identifichi come un traffico HTTP completamente gestito di Google Cloud.

Se il servizio continua a non essere presente, verifica che nel cluster esista una configurazione del servizio Kubernetes.

  • 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 container e che uno di questi è il proxy istio-proxy container:

kubectl -n YOUR_NAMESPACE get pods

Verificare che esista la configurazione della telemetria

Per verificare che il filtro di osservabilità di Google Cloud sia configurato, raccoglie un dump di configurazione da ogni proxy e cerca la presenza del filtro di osservabilità di Google Cloud:

kubectl debug --image istio/base --target istio-proxy -it YOUR_POD_NAME -n YOUR_NAMESPACE curl localhost:15000/config_dump

Nell'output del comando precedente, cerca il filtro Observability di Google Cloud. che ha il seguente aspetto:

"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 corretti per le porte.

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

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

Verifica che non vengano segnalati 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 visualizzi messaggi di errore, potrebbe trattarsi di un problema che richiede ulteriori 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 Quote . 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 non siano presenti 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 quelli riportati di seguito, 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

Apri Esplora metriche ed esegui la seguente 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 un altro valore, la dashboard di Cloud Service Mesh non mostrerà le metriche. metric.mesh_uid viene impostato quando Cloud Service Mesh è installato sul cluster, quindi controlla il metodo di installazione per verificare se esiste 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 nel progetto Google Cloud quando installi 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 aver eseguito il deployment dei carichi di lavoro, sono necessari circa uno o due minuti per visualizzare i dati di telemetria nella console Google Cloud. Cloud Service Mesh mantiene automaticamente le dashboard dei servizi aggiornati:

  • Per le metriche, i proxy sidecar chiamano l'API Cloud Monitoring circa ogni minuto.
  • Per aggiornare il grafico della topologia, i proxy sidecar inviano report incrementali circa ogni minuto e report completi ogni dieci minuti circa.
  • Per la registrazione, i proxy sidecar chiamano l'API Cloud Logging ogni circa dieci secondi.
  • Per il tracciamento, devi abilitare Cloud Trace. Le tracce vengono registrate in base alla frequenza di campionamento che hai configurato (in genere una ogni 100 richieste).

Le metriche vengono visualizzate solo per i servizi HTTP su Cloud Service Mesh pagina Metriche. Se non vedi metriche, verifica che tutti i pod nella dello spazio dei nomi per i servizi della tua applicazione hanno proxy sidecar inseriti:

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 Servizi mostra solo le metriche del server, pertanto i dati di telemetria potrebbero non essere visualizzati se il client non è nel mesh o se è configurato per registrare solo le metriche del client (ad esempio i gateway di ingresso).