Risolvere i problemi di osservabilità e telemetria in Anthos Service Mesh

Questa sezione illustra i problemi comuni di Anthos Service Mesh e come risolverli. Se hai bisogno di ulteriore assistenza, vedi Ricevere assistenza.

Nella telemetria di Anthos 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
• Edge (API di contesto/visualizzazione topologia): report incrementali ogni minuto circa, con report completi ogni 10 minuti circa.
• Tracce: determinate dalla frequenza di campionamento configurata (in genere, una su 100 richieste).

Importante: la telemetria completa potrebbe subire ritardi di 1-2 minuti all'avvio dei cluster.

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

Se il servizio rimane mancante, 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 nella dashboard Servizi mancano metriche o sono errate, consulta le sezioni seguenti per potenziali risoluzioni.

Verifica che i proxy Sidecar esistano e che siano stati inseriti correttamente

Nota: devi avere accesso al cluster per risolvere i problemi relativi a metriche mancanti/non corrette.

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

Verificare l'esistenza della configurazione di telemetria

Utilizza EnvoyFiltri nello spazio dei nomi istio-system per configurare la telemetria. Senza questa configurazione, Anthos Service Mesh non segnalerà i dati all'osservabilità di Google Cloud.

Verifica che la configurazione di Google Cloud Observability (e la configurazione dello scambio di metadati) esista:

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 di osservabilità di Google Cloud sia configurato correttamente, raccogli un dump di configurazione da ogni proxy e cerca la presenza del filtro di osservabilità 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 di osservabilità 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 Anthos Service Mesh identifichi un servizio HTTP

Le metriche non vengono visualizzate nell'interfaccia utente se la porta del servizio per il servizio Kubernetes non è denominata http o un nome con un prefisso http-. Verifica che le porte del servizio siano indicate con i nomi corretti.

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

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

Verifica che non ci siano report sugli errori per l'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, è possibile che si tratti 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 l'opzione Quote. Puoi accedere a questa pagina direttamente 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 non siano presenti log degli errori nei proxy Envoy

Esamina i log del proxy in questione e cerca le istanze dei messaggi di errore:

kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy

Tuttavia, ignora i messaggi di avviso simili ai 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 delle metriche e che il relativo metric.mesh_uid sia nel formato proj-<Anthos Service Mesh fleet project number>.

Nota: per i mesh multiprogetto, il numero di progetto deve essere il progetto del parco risorse, anziché il progetto host.

Se metric.mesh_uid ha un altro valore, la dashboard di Anthos Service Mesh non mostrerà le metriche. metric.mesh_uid viene impostato quando Anthos Service Mesh viene installato sul cluster, quindi analizza il tuo 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 Anthos 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 per visualizzare i dati di telemetria nella console Google Cloud. Anthos Service Mesh mantiene automaticamente aggiornate le dashboard dei servizi:

• Per le metriche, i proxy collaterali chiamano l'API Cloud Monitoring all'incirca ogni minuto.
• Per aggiornare il grafico della topologia, i proxy collaterali inviano report incrementali ogni minuto circa e report completi 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 segnalate in base alla frequenza di campionamento che hai configurato (in genere, una su 100 richieste).

Le metriche vengono visualizzate solo per i servizi HTTP nella pagina Metriche di Anthos 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 collaterali:

kubectl get pod -n YOUR_NAMESPACE --all

Nell'output, nota che la colonna READY mostra due container per ognuno 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, pertanto i dati di telemetria potrebbero non essere visualizzati se il client non è nel mesh o se è configurato per generare report solo sulle metriche client (come i gateway in entrata).