Risolvere i 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 la sezione Richiedere 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 ne determina la frequenza:
- Logging: ogni ~10 secondi
- Metriche: ogni ~1 minuto
- Edge (API Context/visualizzazione della topologia): report incrementali ogni ~1 minuto, con report completi ogni ~10 minuti.
- Trace: determinati dalla frequenza di campionamento configurata (in genere, una ogni 100 richieste).
Le dashboard di telemetria raccolgono dati sia da Confluence sia da Google Cloud Observability per visualizzare le varie dashboard incentrate sui servizi.
Verificare che esista al massimo una configurazione dell'API di telemetria Istio
Questa sezione si applica solo al control plane di Traffic Director gestito.
Se hai già una CR dell'API di telemetria Istio esistente, per conservare le impostazioni di personalizzazione precedenti nella CR di telemetria Istio esistente, devi includerle nella nuova CR dell'API di telemetria Istio.
Per elencare le configurazioni dell'API di telemetria, esegui il comando seguente. Verifica che esista al massimo una configurazione dell'API di telemetria Istio.
kubectl -n istio-system get telemetry
Nella dashboard Servizi manca un servizio
La dashboard mostra solo i servizi HTTP(S)/gRPC. Se il tuo servizio deve essere presente nell'elenco, verifica che la telemetria di Cloud Service Mesh lo identifichi come servizio HTTP.
Se il servizio continua a mancare, verifica che esista una configurazione del servizio Kubernetes nel cluster.
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 errate per i servizi, consulta le sezioni seguenti per le possibili soluzioni.
Verificare che i proxy sidecar esistano e siano stati inseriti correttamente
Lo spazio dei nomi potrebbe non avere un'etichetta per l'inserimento automatico o 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
Verificare che esista una configurazione di telemetria
Per verificare che il filtro Google Cloud Observability sia configurato, raccogli un dump della configurazione da ogni proxy e cerca la presenza del filtro 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": "{....}"
}Verificare che Cloud Service Mesh identifichi un servizio HTTP
Le metriche non vengono visualizzate nell'interfaccia utente se la porta di servizio per il
servizio Kubernetes non è denominata http o qualsiasi nome con un prefisso http-.
Verifica che il servizio abbia i nomi corretti per le porte.
Verificare che l'API Cloud Monitoring sia abilitata per il progetto
Verifica che l'API Cloud Monitoring sia abilitata nella dashboard API e servizi in Google Cloud console, che è l'impostazione predefinita.
Verificare che non siano presenti errori nella segnalazione all'API Cloud Monitoring
Nella dashboard API e servizi della Google Cloud console, 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 indica un potenziale problema di quota. Consulta la sezione successiva per i passaggi di risoluzione dei problemi.
Verificare la quota corretta per l'API Cloud Monitoring
Nella Google Cloud console, 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 delle quote per il progetto, in cui puoi cercare
Cloud Monitoring API.
Verificare che non siano presenti log di 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
Verificare 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 segnalino le metriche e che il relativo
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 nel cluster, quindi esamina il metodo di installazione per verificare se è possibile impostarlo sul valore previsto.
Dati di telemetria mancanti o errati per i servizi
Per impostazione predefinita, Cloud Monitoring e Cloud Logging vengono abilitati nel tuo Google Cloud progetto quando installi Cloud Service Mesh. 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 Google Cloud console. 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 tracing, devi abilitare Cloud Trace. Le trace vengono segnalate in base alla frequenza di campionamento configurata (in genere, una ogni 100 richieste).
Le metriche vengono visualizzate solo per i servizi HTTP nella pagina Metriche di Cloud Service Mesh. Se non vedi alcuna metrica, verifica che tutti i pod nello spazio dei nomi per i servizi della tua applicazione abbiano i proxy sidecar inseriti:
kubectl get pod -n YOUR_NAMESPACE --all
Nell'output, osserva che 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, quindi 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).