Risolvere i problemi di osservabilità e telemetria in Cloud Service Mesh
Questa sezione illustra i problemi comuni di Cloud Service Mesh e come risolverli. 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 La chiamata API ne determina la frequenza:
- Logging: ogni circa 10 secondi
- Metriche: ogni circa 1 minuto
- Edge (visualizzazione API Context/Topologia): report incrementali ogni circa 1 minuto, con report completi ogni circa 10 minuti.
- Tracce: determinata in base alla frequenza di campionamento configurata (di solito, 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 riguarda solo il piano di controllo Cloud Service Mesh gestito.
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 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 persiste, verifica che Configurazione del servizio Kubernetes nel tuo 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 le metriche per i servizi nella dashboard Servizi risultano mancanti o errate, consulta le sezioni seguenti per potenziali 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 contenitori e che uno di questi sia il contenitore istio-proxy:
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 di servizio per il servizio Kubernetes non è denominata http
o non ha un nome con un 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 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 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. Per la procedura 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
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
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
ha un altro valore, la dashboard di Cloud Service Mesh non mostrerà 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 nel progetto Google Cloud quando installi Cloud Service Mesh. Per segnalare i dati di telemetria, ogni proxy sidecar 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 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 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 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 nella pagina Metriche di Cloud Service Mesh. Se non visualizzi alcuna metrica, verifica che in tutti i pod nell'espandimentime per i servizi della tua applicazione siano stati inseriti i proxy sidecar:
kubectl get pod -n YOUR_NAMESPACE --all
Nell'output, tieni presente che la colonna READY
mostra due contenitori per ciascuno dei tuoi carichi di lavoro: il contenitore principale e il contenitore 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).