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

Questa sezione descrive i problemi più comuni di Cloud Service Mesh e spiega come risolverli. Se hai bisogno di ulteriore assistenza, consulta Richiedi assistenza.

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

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

Le dashboard di telemetria raccolgono i dati sia da Confluence sia da 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 tuo servizio dovrebbe essere nell'elenco, verifica che la telemetria di Cloud Service Mesh lo identifichi come servizio HTTP.

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

  • Esamina 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 nella dashboard Servizi mancano metriche o sono presenti metriche errate per i servizi, consulta le sezioni seguenti per le possibili soluzioni.

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. Verifica che i pod nello spazio dei nomi abbiano almeno due container e che uno di questi sia il container istio-proxy:

kubectl -n YOUR_NAMESPACE get pods

Verifica che la configurazione della telemetria esista

Per verificare che il filtro di Google Cloud Observability sia configurato, raccogli un dump della configurazione da ogni proxy e cerca la presenza del filtro di Google Cloud Observability:

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 Google Cloud Observability, 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": "{....}"
}

Verifica che Cloud Service Mesh identifichi un servizio HTTP

Le metriche non verranno visualizzate nell'interfaccia utente se la porta di servizio per il servizio Kubernetes non è denominata http o con un nome con prefisso http-. Verifica che il servizio abbia i nomi corretti per le sue 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 consoleGoogle Cloud , che è l'impostazione predefinita.

Verifica che non vengano segnalati errori all'API Cloud Monitoring

Nella dashboard API e servizi della console Google Cloud , apri l'URL del 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 indicano un potenziale problema di quota. Per i passaggi di risoluzione dei problemi, consulta la sezione successiva.

Verifica la quota corretta per l'API Cloud Monitoring

Nella console Google Cloud , apri il menu IAM & Admin e verifica che sia presente un'opzione 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 di quote per il progetto, dove puoi cercare Cloud Monitoring API.

Verifica che non siano presenti log degli errori 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

Apri 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 segnalando le metriche e che il loro metric.mesh_uid sia nel formato proj-<Cloud Service Mesh fleet project number>.

Se metric.mesh_uid ha un altro valore, la dashboard di Cloud Service Mesh non visualizzerà le metriche. metric.mesh_uid viene impostato quando Cloud Service Mesh viene installato sul cluster, quindi esamina 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, quando installi Cloud Service Mesh, Cloud Monitoring e Cloud Logging vengono abilitati nel progettoGoogle Cloud . Per segnalare i dati di telemetria, ogni proxy sidecar inserito nei pod del servizio chiama l'API Cloud Monitoring e l'API Cloud Logging. Dopo il deployment dei workload, sono necessari circa uno o due minuti prima che i dati di telemetria vengano visualizzati nella consoleGoogle Cloud . Cloud Service Mesh mantiene automaticamente aggiornate le dashboard dei servizi:

  • 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 circa ogni dieci minuti.
  • Per il logging, i proxy sidecar chiamano l'API Cloud Logging circa ogni dieci secondi.
  • Per il tracciamento, devi abilitare Cloud Trace. Le tracce vengono registrate in base alla frequenza di campionamento configurata (in genere, una richiesta su 100).

Le metriche vengono visualizzate solo per i servizi HTTP nella pagina Metriche di Cloud Service Mesh. Se non vedi alcuna metrica, verifica che in tutti i pod nello spazio dei nomi per i servizi della tua applicazione siano stati inseriti i proxy sidecar:

kubectl get pod -n YOUR_NAMESPACE --all

Nell'output, osserva come la colonna READY mostra due container per ciascuno dei tuoi workload: 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 si trova nel mesh o se è configurato per segnalare solo le metriche del client (ad esempio i gateway in entrata).