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 assistenza, vedi Ricevere 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 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 tuo servizio dovrebbe essere nell'elenco, verifica che la telemetria di Cloud Service Mesh lo identifichi come servizio HTTP.
Se il servizio rimane mancante, verifica che nel cluster sia presente 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 nella dashboard Servizi mancano metriche o sono errate per i servizi, consulta le seguenti sezioni 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. Verifica che i pod nello spazio dei nomi abbiano almeno due container e che uno di questi container sia 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 Google Cloud Observability sia configurato correttamente, raccogli un dump della configurazione da ogni proxy e cerca la presenza del filtro Observability di Google Cloud:
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 è simile al seguente:
"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 verranno visualizzate nell'interfaccia utente se la porta del servizio per il servizio Kubernetes non è denominata 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 nella dashboard API e servizi della console Google Cloud (impostazione predefinita).
Verifica che non ci siano segnalazioni di 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 accertamenti. In particolare, cerca un numero elevato di messaggi di errore 429
, che indicano un potenziale problema di quota. Consulta la prossima sezione
per i passaggi di 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 l'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
.
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
Apri Metrics Explorer 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 il loro
metric.mesh_uid
sia nel formato proj-<Cloud Service Mesh fleet project number>
.
Se metric.mesh_uid
presenta altri valori, la dashboard di Cloud Service Mesh non mostrerà le metriche. metric.mesh_uid
viene impostato quando Cloud Service Mesh viene
installato sul cluster, quindi analizza 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 tuo 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 il deployment dei carichi di lavoro, sono necessari circa uno o due minuti prima che i dati di telemetria vengano visualizzati nella console Google Cloud. Cloud Service Mesh mantiene automaticamente aggiornate le dashboard dei servizi:
- Per le metriche, i proxy collaterali chiamano l'API Cloud Monitoring circa ogni minuto.
- Per aggiornare il grafico della topologia, i proxy collaterali inviano report incrementali all'incirca ogni minuto e report completi ogni 10 minuti.
- Per il logging, i proxy sidecar chiamano l'API Cloud Logging ogni dieci secondi circa.
- Per il tracciamento, devi abilitare Cloud Trace. Le tracce vengono segnalate 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 delle 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 proxy sidecar:
kubectl get pod -n YOUR_NAMESPACE --all
Nell'output, nota che la colonna READY
mostra due container per ciascuno
dei 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 i dati di telemetria potrebbero non essere visualizzati se il client non è nel mesh o se è configurato per segnalare solo le metriche client (come i gateway in entrata).