Risoluzione dei problemi di Managed Service per Prometheus

Questo documento descrive alcuni problemi che potresti riscontrare durante l'utilizzo di Google Cloud Managed Service per Prometheus e fornisce informazioni su come diagnosticare e risolvere i problemi.

Hai configurato Managed Service per Prometheus, ma non visualizzi dati delle metriche in Grafana o nella UI di Prometheus. A livello generale, la causa potrebbe essere una delle seguenti:

  • Un problema lato query, che impedisce la lettura dei dati. I problemi lato query sono spesso causati da autorizzazioni errate per la lettura dei dati dell'account di servizio o da configurazione errata di Grafana.

  • Un problema sul lato importazione, che impedisce l'invio di dati. I problemi lato importazione possono essere causati da problemi di configurazione con account di servizio, raccoglitori o valutazione delle regole.

Per determinare se il problema si trova sul lato importazione o sul lato query, prova a eseguire query sui dati utilizzando la scheda PromQL di Metrics Explorer nella console Google Cloud. Si garantisce che questa pagina non presenti alcun problema con le autorizzazioni di lettura o le impostazioni di Grafana.

Per visualizzare questa pagina, procedi nel seguente modo:

  1. Usa il selettore progetti della console Google Cloud per selezionare il progetto per cui non visualizzi i dati.

  2. Nel pannello di navigazione della console Google Cloud, seleziona Monitoring e poi  Metrics Explorer:

    Vai a Metrics Explorer

  3. Nella barra degli strumenti del riquadro del generatore di query, seleziona il pulsante il cui nome è  MQL o  PromQL.

  4. Verifica che sia selezionato PromQL nel pulsante di attivazione/disattivazione Lingua. Il pulsante di attivazione/disattivazione della lingua si trova nella stessa barra degli strumenti che consente di formattare la query.

  5. Inserisci la seguente query nell'editor e fai clic su Esegui query:

    up

Se esegui una query sulla metrica up e vedi i risultati, il problema riguarda il lato query. Per informazioni su come risolvere questi problemi, consulta Problemi lato query.

Se esegui una query sulla metrica up e non vedi alcun risultato, il problema riguarda il lato importazione. Per informazioni su come risolvere questi problemi, consulta Problemi lato importazione.

Un firewall può anche causare problemi di importazione ed query; per ulteriori informazioni, consulta la pagina Firewall.

La pagina Gestione delle metriche di Cloud Monitoring fornisce informazioni che possono aiutarti a controllare l'importo speso per le metriche addebitabili senza influire sull'osservabilità. La pagina Gestione delle metriche riporta le seguenti informazioni:

  • Volumi di importazione per la fatturazione basata su byte e campioni, nei domini delle metriche e per le singole metriche.
  • Dati su etichette e cardinalità delle metriche.
  • Utilizzo delle metriche nei criteri di avviso e nelle dashboard personalizzate.
  • Percentuale di errori di scrittura delle metriche.

Per visualizzare la pagina Gestione delle metriche:

  1. Nel pannello di navigazione della console Google Cloud, seleziona Monitoring, quindi  Gestione delle metriche:

    Vai a Gestione delle metriche

  2. Nella barra degli strumenti, seleziona la finestra temporale. Per impostazione predefinita, la pagina Gestione delle metriche mostra informazioni sulle metriche raccolte il giorno precedente.

Per saperne di più sulla pagina Gestione delle metriche, consulta Visualizzare e gestire l'utilizzo delle metriche.

Problemi lato query

La causa della maggior parte dei problemi lato query è una delle seguenti:

Inizia procedendo nel seguente modo:

  • Controlla attentamente la configurazione in base alle istruzioni di configurazione per l'esecuzione di query.

  • Se utilizzi Workload Identity, verifica che l'account di servizio disponga delle autorizzazioni corrette seguendo questi passaggi:

    1. Nel pannello di navigazione della console Google Cloud, seleziona IAM:

      Vai a IAM

    2. Identifica il nome dell'account di servizio nell'elenco delle entità. Verifica che il nome dell'account di servizio sia stato digitato correttamente. Poi fai clic su Modifica.

    3. Seleziona il campo Ruolo, quindi fai clic su Attualmente utilizzato e cerca il ruolo Visualizzatore Monitoring. Se l'account di servizio non ha questo ruolo, aggiungilo ora.

Se il problema persiste, considera le seguenti possibilità:

Secret non configurati correttamente o digitati in modo errato

Se vedi quanto segue, è possibile che il secret non sia presente o sia digitato in modo errato:

  • Uno di questi errori "non consentiti" in Grafana o nella UI di Prometheus:

    • "Avviso: stato della risposta imprevisto durante il recupero dell'ora del server: accesso vietato"
    • "Avviso: errore durante il recupero dell'elenco di metriche: stato della risposta imprevisto durante il recupero dei nomi delle metriche: vietato"

  • Un messaggio simile al seguente nei tuoi log:
    "Impossibile leggere il file delle credenziali: apri /gmp/key.json: nessun file o directory simile"

Se utilizzi il sincronizzatore dell'origine dati per autenticare e configurare Grafana, prova a procedere nel seguente modo per risolvere questi errori:

  1. Verifica di aver scelto l'endpoint API Grafana, l'UID dell'origine dati Grafana e il token dell'API Grafana corretti. Puoi esaminare le variabili nel CronJob eseguendo il comando kubectl describe cronjob datasource-syncer.

  2. Verifica di aver impostato l'ID progetto del sincronizzazione dell'origine dati sullo stesso ambito delle metriche o sullo stesso progetto per cui il tuo account di servizio dispone delle credenziali.

  3. Verifica che il tuo account di servizio Grafana disponga del ruolo "Amministratore" e che il token API non sia scaduto.

  4. Verifica che l'account di servizio disponga del ruolo Visualizzatore Monitoring per l'ID progetto scelto.

  5. Verifica che non siano presenti errori nei log del job di sincronizzazione dell'origine dati eseguendo kubectl logs job.batch/datasource-syncer-init. Questo comando deve essere eseguito immediatamente dopo l'applicazione del file datasource-syncer.yaml.

  6. Se utilizzi Workload Identity, verifica di non aver digitato in modo errato la chiave o le credenziali dell'account e verifica di averle associate allo spazio dei nomi corretto.

Se utilizzi il proxy UI frontend legacy, prova a risolvere questi errori:

  1. Verifica di aver impostato l'ID progetto dell'interfaccia utente frontend sullo stesso ambito delle metriche o sullo stesso progetto per cui il tuo account di servizio dispone delle credenziali.

  2. Verifica l'ID progetto che hai specificato per eventuali flag --query.project-id.

  3. Verifica che l'account di servizio disponga del ruolo Visualizzatore Monitoring per l'ID progetto scelto.

  4. Verifica di aver impostato l'ID progetto corretto durante il deployment dell'interfaccia utente frontend e di non averlo lasciato impostato sulla stringa letterale PROJECT_ID.

  5. Se utilizzi Workload Identity, verifica di non aver digitato in modo errato la chiave o le credenziali dell'account e verifica di averle associate allo spazio dei nomi corretto.

  6. Se stai montando il tuo secret, assicurati che sia presente:

    kubectl get secret gmp-test-sa -o json | jq '.data | keys'

  7. Verifica che il secret sia montato correttamente:

    kubectl get deploy frontend -o json | jq .spec.template.spec.volumes

kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].volumeMounts

  8. Assicurati che il secret venga passato correttamente al container: 

    kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].args

Metodo HTTP errato per Grafana

Se visualizzi il seguente errore API da Grafana, significa che Grafana è configurato per inviare una richiesta POST anziché una richiesta GET:

  • "{"status":"error","errorType":"bad_data","error":"no match[] parameter provided"}%"

Per risolvere questo problema, configura Grafana in modo che utilizzi una richiesta GET seguendo le istruzioni riportate in Configurare un'origine dati.

Timeout su query di grandi dimensioni o a lunga esecuzione

Se in Grafana viene visualizzato il seguente errore, il timeout delle query predefinito è troppo basso:

  • "Pubblica "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: timeout in attesa di intestazioni di risposta"

Per impostazione predefinita, Managed Service per Prometheus non scade fino a quando una query non supera i 120 secondi, mentre il timeout di Grafana dopo 30 secondi. Per risolvere il problema, aumenta i timeout in Grafana a 120 secondi seguendo le istruzioni riportate in Configurare un'origine dati.

Errori di convalida delle etichette

Se visualizzi uno dei seguenti errori in Grafana, è possibile che tu stia utilizzando un endpoint non supportato:

  • "Convalida: le etichette diverse da name non sono ancora supportate"
  • "Modelli [job]: Errore durante l'aggiornamento delle opzioni: le etichette diverse da name non sono ancora supportate."

Managed Service per Prometheus supporta l'endpoint /api/v1/$label/values solo per l'etichetta __name__. Questo limite determina l'esito negativo delle query che utilizzano la variabile label_values($label) in Grafana.

Utilizza invece il modulo label_values($metric, $label). Questa query è consigliata perché vincola i valori delle etichette restituiti per metrica, impedendo il recupero di valori non correlati ai contenuti della dashboard. Questa query chiama un endpoint supportato per Prometheus.

Per ulteriori informazioni sugli endpoint supportati, consulta Compatibilità delle API.

Quota superata

Se viene visualizzato il seguente errore, significa che hai superato la quota di lettura per l'API Cloud Monitoring:

  • "429: RESOURCE_EXHAUSTED: Quota superata per la metrica di quota "Query serie temporali" e limita le "Query serie temporali al minuto" del servizio "monitoring.googleapis.com" per il consumer "numero_progetto:..."."

Per risolvere il problema, invia una richiesta per aumentare la quota di lettura per l'API Monitoring. Per ricevere aiuto, contatta l'assistenza Google Cloud. Per ulteriori informazioni sulle quote, consulta Utilizzo delle quote.

Metriche di più progetti

Per visualizzare le metriche di più progetti Google Cloud, non è necessario configurare più sincronizzatori di origini dati o creare più origini dati in Grafana.

Puoi invece creare un ambito delle metriche di Cloud Monitoring in un progetto Google Cloud (il progetto di definizione dell'ambito) contenente i progetti da monitorare. Quando configuri l'origine dati Grafana con un progetto di definizione dell'ambito, puoi accedere ai dati di tutti i progetti nell'ambito delle metriche. Per ulteriori informazioni, consulta Ambiti di query e metriche.

Nessun tipo di risorsa monitorata specificato

Se viene visualizzato il seguente errore, devi specificare un tipo di risorsa monitorata quando utilizzi PromQL per eseguire query su una metrica di sistema Google Cloud:

  • "La metrica è configurata per essere utilizzata con più di un tipo di risorsa monitorata; il selettore di serie deve specificare un matcher etichetta sul nome della risorsa monitorata"

Puoi specificare un tipo di risorsa monitorata filtrando con l'etichetta monitored_resource. Per saperne di più su come identificare e scegliere un tipo di risorsa monitorata valida, consulta Specifica di un tipo di risorsa monitorata.

Somma dei contatori non corrispondente tra l'UI del raccoglitore e la console Google Cloud

Quando esegui una query su un contatore non elaborato o sulla somma di un contatore, potresti notare una differenza tra i valori nell'interfaccia utente di Prometheus del raccoglitore locale e nella console Google Cloud di Google Cloud. Si tratta di un comportamento previsto.

Monarch richiede i timestamp di inizio, ma Prometheus non ha timestamp di inizio. Managed Service per Prometheus genera i timestamp di inizio saltando il primo punto importato in qualsiasi serie temporale e convertendolo in un timestamp di inizio. Questo causa un deficit persistente nella somma di un contatore.

La differenza tra il numero nell'UI del raccoglitore e il numero nella console Google Cloud è uguale al primo valore registrato nell'UI del raccoglitore, il che è previsto perché il sistema ignora questo valore iniziale.

Questo è accettabile perché non è necessario eseguire una query per i valori dei contatori non elaborati in produzione; tutte le query utili sui contatori richiedono una funzione rate() o simili, nel qual caso la differenza nell'orizzonte temporale è identica tra le due UI. I contatori possono aumentare solo una volta, pertanto non puoi impostare un avviso per una query non elaborata poiché una serie temporale raggiunge una soglia soltanto una volta. Tutti gli avvisi e i grafici utili controllano la variazione del valore o il tasso di variazione.

Il raccoglitore contiene solo 10 minuti di dati circa in locale. Potrebbero verificarsi discrepanze nelle somme non elaborate dei contatori a causa di un ripristino del contatore che avviene prima dell'orizzonte di 10 minuti. Per escludere questa possibilità, prova a impostare un periodo di ricerca delle query di soli 10 minuti quando confronti l'interfaccia utente del raccoglitore con la console Google Cloud.

Le discrepanze possono anche essere causate dalla presenza di più thread di worker nell'applicazione, ciascuno con un endpoint /metrics. Se l'applicazione avvia più thread, devi impostare la libreria client di Prometheus in modalità multiprocesso. Per maggiori informazioni, consulta la documentazione per l'utilizzo della modalità multiprocesso nella libreria client Python di Prometheus.

Dati del contatore mancanti o istogrammi non funzionanti

L'indicatore più comune di questo problema è l'assenza di dati o la presenza di intervalli di dati durante l'esecuzione di una query su una metrica del contatore semplice (ad esempio, una query PromQL di metric_name_foo). Puoi verificare se i dati vengono visualizzati dopo aver aggiunto una funzione rate alla query (ad esempio, rate(metric_name_foo[5m])).

Potresti anche notare che i campioni importati sono aumentati notevolmente senza alcuna modifica significativa nel volume di scraping o che vengono create nuove metriche con suffissi "sconosciuto" o "unknown:counter" in Cloud Monitoring.

Potresti anche notare che le operazioni sugli istogrammi, come la funzione quantile(), non funzionano come previsto.

Questi problemi si verificano quando una metrica viene raccolta senza una metrica di Prometheus TYPE. Poiché Monarch è di tipo forte, Managed Service per Prometheus prende in considerazione le metriche non digitate, assegnandole come suffisso "sconosciuto" e importandole due volte, una come indicatore e una volta come contatore. Il motore di query sceglie quindi se eseguire query sul misuratore o sulla metrica del contatore sottostante in base alle funzioni di query utilizzate.

Sebbene questa euristica di solito funzioni abbastanza bene, può portare a problemi come risultati strani quando si esegue una query su una metrica "unknown:counter" non elaborata. Inoltre, poiché gli istogrammi sono oggetti digitati in modo specifico in Monarch, l'importazione delle tre metriche degli istogrammi richiesti come singole metriche dei contatori fa sì che le funzioni degli istogrammi non funzionino. Poiché le metriche di tipo "sconosciuto" vengono importate due volte, senza l'impostazione di un TYPE, gli esempi importati vengono raddoppiati.

Ecco alcuni motivi comuni per cui TYPE potrebbe non essere impostato:

  • Configurazione accidentale di un raccoglitore Managed Service per Prometheus come server di federazione. La federazione non è supportata quando si utilizza Managed Service per Prometheus. Poiché la federazione ignora intenzionalmente le informazioni TYPE, l'implementazione della federazione causa metriche di tipo "sconosciuto".
  • Utilizzo di Prometheus Remote Write in qualsiasi punto della pipeline di importazione. Anche questo protocollo ignora intenzionalmente le informazioni TYPE.
  • Utilizzare una regola di rietichettatura che modifichi il nome della metrica. Di conseguenza, la metrica rinominata non sarà più associata alle informazioni di TYPE associate al nome della metrica originale.
  • L'esportatore non ha emesso il valore TYPE per ogni metrica.
  • Un problema temporaneo in cui TYPE viene eliminato al primo avvio del raccoglitore.

Per risolvere il problema:

  • Interrompi l'utilizzo della federazione con Managed Service for Prometheus. Se vuoi ridurre cardinalità e costi "raggruppando" i dati prima di inviarli a Monarch, consulta Configurare l'aggregazione locale.
  • Interrompi l'utilizzo di Prometheus Remote Write nel percorso della raccolta.
  • Verifica che il campo # TYPE esista per ogni metrica visitando l'endpoint /metrics.
  • Elimina tutte le regole di rietichettatura che modificano il nome di una metrica.
  • Elimina tutte le metriche in conflitto con il suffisso "sconosciuto" o "unknown:counter" chiamando DeleteMetricDescriptor.
  • In alternativa, esegui sempre una query sui contatori utilizzando un rate o un'altra funzione di elaborazione del contatore.

I dati di Grafana non sono resi persistenti dopo il riavvio del pod

Se i dati sembrano scomparire da Grafana dopo il riavvio di un pod, ma sono visibili in Cloud Monitoring, significa che stai utilizzando Grafana per eseguire query sull'istanza di Prometheus locale anziché su Managed Service per Prometheus.

Per informazioni sulla configurazione di Grafana per l'utilizzo del servizio gestito come origine dati, consulta Grafana.

Importazione delle dashboard di Grafana

Per informazioni sull'utilizzo e sulla risoluzione dei problemi dell'importatore della dashboard, vedi Importare le dashboard Grafana in Cloud Monitoring.

Per informazioni sui problemi relativi alla conversione dei contenuti della dashboard, consulta il file README dell'importatore.

Problemi lato importazione

I problemi lato importazione possono essere correlati alla valutazione di raccolte o di regole. Per prima cosa, consulta i log degli errori per la raccolta gestita. Puoi eseguire questi comandi:

kubectl logs -f -n gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gmp-system -lapp.kubernetes.io/name=collector -c prometheus

Sui cluster GKE Autopilot, puoi eseguire i seguenti comandi:

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/name=collector -c prometheus

La funzione stato target può aiutarti a eseguire il debug della destinazione dello scrape. Per scoprire di più, consulta le informazioni sullo stato del target.

Stato dell'endpoint mancante o troppo vecchio

Se hai abilitato la funzionalità Stato target, ma in una o più risorse PodMonitoring o ClusterPodMonitoring manca il campo o il valore Status.Endpoint Statuses, potrebbe essersi verificato uno dei seguenti problemi:

  • Managed Service per Prometheus non è riuscito a raggiungere un raccoglitore sullo stesso nodo di uno dei tuoi endpoint.
  • Una o più configurazioni di PodMonitoring o ClusterPodMonitoring non hanno generato destinazioni valide.

Problemi simili possono anche far sì che il campo Status.Endpoint Statuses.Last Update Time abbia un valore più vecchio di qualche minuto più l'intervallo di scraping.

Per risolvere questo problema, inizia controllando che i pod Kubernetes associati all'endpoint di scrape siano in esecuzione. Se i tuoi pod Kubernetes sono in esecuzione, i selettori delle etichette corrispondono e puoi accedere manualmente agli endpoint di scraping (in genere visitando l'endpoint /metrics), quindi controlla se i raccoglitori di Managed Service per Prometheus sono in esecuzione.

La frazione dei raccoglitori è inferiore a 1

Se hai abilitato la funzionalità Stato target, riceverai informazioni sullo stato delle risorse. Il valore Status.Endpoint Statuses.Collectors Fraction delle risorse PodMonitoring o ClusterPodMonitoring rappresenta la frazione di raccoglitori raggiungibili, espressa da 0 a 1. Ad esempio, un valore pari a 0.5 indica che il 50% dei raccoglitori è raggiungibile, mentre un valore pari a 1 indica che il 100% dei raccoglitori è raggiungibile.

Se il campo Collectors Fraction ha un valore diverso da 1, uno o più raccoglitori non sono raggiungibili ed è possibile che le metriche in uno di questi nodi non siano state sottoposte a scraping. Assicurati che tutti i raccoglitori siano in esecuzione e raggiungibili sulla rete del cluster. Puoi visualizzare lo stato dei pod del raccoglitore con il seguente comando:

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=collector"

Sui cluster GKE Autopilot, questo comando è leggermente diverso:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=collector"

Puoi esaminare i singoli pod del raccoglitore (ad esempio un pod del raccoglitore denominato collector-12345) con il seguente comando:

kubectl -n gmp-system describe pods/collector-12345

Nei cluster GKE Autopilot, esegui questo comando:

kubectl -n gke-gmp-system describe pods/collector-12345

Se i raccoglitori non sono integri, consulta Risoluzione dei problemi relativi ai carichi di lavoro di GKE.

Se i raccoglitori sono integri, controlla i log dell'operatore. Per controllare i log dell'operatore, esegui prima il comando seguente per trovare il nome del pod dell'operatore:

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

Nei cluster GKE Autopilot, esegui questo comando:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

Quindi, controlla i log dell'operatore (ad esempio, un pod dell'operatore denominato gmp-operator-12345) con il seguente comando:

kubectl -n gmp-system logs pods/gmp-operator-12345

Nei cluster GKE Autopilot, esegui questo comando:

kubectl -n gke-gmp-system logs pods/gmp-operator-12345

Target in stato non integro

Se hai abilitato la funzionalità Stato target, ma una o più risorse PodMonitoring o ClusterPodMonitoring presentano il campo Status.Endpoint Statuses.Unhealthy Targets con un valore diverso da 0, il raccoglitore non può eseguire lo scraping di una o più destinazioni.

Visualizza il campo Sample Groups, che raggruppa i target in base al messaggio di errore e trova il campo Last Error. Il campo Last Error proviene da Prometheus e indica perché non è stato possibile estrarre il target. Per risolvere il problema, utilizzando i target di esempio come riferimento, controlla se gli endpoint di scraping sono in esecuzione.

Quota superata

Se viene visualizzato il seguente errore, significa che hai superato la quota di importazione per l'API Cloud Monitoring:

  • "429: Quota superata per la metrica di quota 'Richieste di importazione di serie temporali' e limite delle "Richieste di importazione di serie temporali al minuto" del servizio "monitoring.googleapis.com" per il consumer 'project_number:PROJECT_NUMBER'., rateLimitExceeded"

Questo errore si verifica solitamente la prima volta che viene attivato il servizio gestito. La quota predefinita verrà esaurita a 100.000 campioni al secondo importati.

Per risolvere il problema, invia una richiesta per aumentare la quota di importazione per l'API Monitoring. Per ricevere aiuto, contatta l'assistenza Google Cloud. Per ulteriori informazioni sulle quote, consulta Utilizzo delle quote.

Autorizzazione mancante sull'account di servizio predefinito del nodo

Se visualizzi uno dei seguenti errori, l'account di servizio predefinito sul nodo potrebbe non avere le autorizzazioni:

  • "esegui query: errore durante la query su Prometheus: client_error: errore client: 403"
  • "Probe di idoneità non riuscito. probe HTTP non riuscito con codice di stato: 503"
  • "Errore durante la query sull'istanza Prometheus"

La raccolta gestita e il valutatore delle regole gestite in Managed Service per Prometheus utilizzano entrambi l'account di servizio predefinito sul nodo. Questo account viene creato con tutte le autorizzazioni necessarie, ma a volte i clienti rimuovono manualmente le autorizzazioni di Monitoring. Con questa rimozione, la raccolta e la valutazione delle regole non andranno a buon fine.

Per verificare le autorizzazioni dell'account di servizio, esegui una delle seguenti operazioni:

  • Identifica il nome del nodo Compute Engine sottostante ed esegui questo comando:

    gcloud compute instances describe NODE_NAME --format="json" | jq .serviceAccounts

    Cerca la stringa https://www.googleapis.com/auth/monitoring. Se necessario, aggiungi Monitoring come descritto in Account di servizio configurato in modo errato.

  • Vai alla VM sottostante nel cluster e controlla la configurazione dell'account di servizio del nodo:

    1. Nel pannello di navigazione della console Google Cloud, seleziona Kubernetes Engine e poi Cluster:

      Vai a Cluster Kubernetes

    2. Seleziona Nodi, quindi fai clic sul nome del nodo nella tabella Nodi.

    3. Fai clic su Dettagli.

    4. Fai clic sul link Istanza VM.

    5. Individua il riquadro Gestione di API e identità e fai clic su Mostra dettagli.

    6. Cerca l'API Stackdriver Monitoring con accesso completo.

È anche possibile che il sincronizzatore dell'origine dati o l'UI di Prometheus siano stati configurati in modo da esaminare il progetto sbagliato. Per informazioni sulla verifica dell'esecuzione di query sull'ambito delle metriche previsto, consulta Modificare il progetto per cui è stata eseguita la query.

Account di servizio configurato in modo errato

Se viene visualizzato uno dei seguenti messaggi di errore, l'account di servizio utilizzato dal raccoglitore non dispone delle autorizzazioni corrette:

  • "code = PermissionDenied desc = Permission monitoring.timeSeries.create negata (o la risorsa potrebbe non esistere)"
  • "google: impossibile trovare le credenziali predefinite. Per ulteriori informazioni, visita la pagina https://developers.google.com/accounts/docs/application-default-credentials."

Per verificare che il tuo account di servizio disponga delle autorizzazioni corrette:

  1. Nel pannello di navigazione della console Google Cloud, seleziona IAM:

    Vai a IAM

  2. Identifica il nome dell'account di servizio nell'elenco delle entità. Verifica che il nome dell'account di servizio sia stato digitato correttamente. Poi fai clic su Modifica.

  3. Seleziona il campo Ruolo, quindi fai clic su Attualmente utilizzato e cerca il ruolo Writer metriche di monitoraggio o Editor Monitoring. Se l'account di servizio non dispone di uno di questi ruoli, concedi all'account di servizio il ruolo Writer metriche Monitoring (roles/monitoring.metricWriter).

Se l'esecuzione avviene su Kubernetes non GKE, devi passare esplicitamente le credenziali sia al raccoglitore sia al valutatore delle regole. Devi ripetere le credenziali in entrambe le sezioni rules e collection. Per maggiori informazioni, consulta Fornire le credenziali in modo esplicito (per la raccolta) o Fornire le credenziali in modo esplicito (per le regole).

Gli account di servizio hanno spesso come ambito un singolo progetto Google Cloud. L'utilizzo di un solo account di servizio per scrivere dati delle metriche per più progetti, ad esempio quando un valutatore di regole gestite esegue query su un ambito delle metriche multiprogetto, può causare questo errore di autorizzazione. Se utilizzi l'account di servizio predefinito, valuta la possibilità di configurare un account di servizio dedicato in modo da poter aggiungere in sicurezza l'autorizzazione monitoring.timeSeries.create per più progetti. Se non puoi concedere questa autorizzazione, puoi utilizzare la rietichettatura delle metriche per riscrivere l'etichetta project_id con un altro nome. L'ID progetto viene quindi impostato in modo predefinito sul progetto Google Cloud in cui è in esecuzione il server Prometheus o il responsabile della valutazione delle regole.

Configurazione dello scrape non valida

Se viene visualizzato il seguente errore, la formattazione di PodMonitoring o ClusterPodMonitoring non è corretta:

  • "Si è verificato un errore interno: chiamata al webhook non riuscita "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com": Pubblica "https://gmp-operator.gmp-system.svc:443/validate/monitoring.googleapis.com/v1/podmonitorings?timeout=10s": EOF""

Per risolvere questo problema, assicurati che la risorsa personalizzata sia formattata correttamente in base alla specifica.

Problemi con timeout e intervalli di scraping

Quando utilizzi Managed Service per Prometheus, il timeout dello scrape non può essere maggiore dell'intervallo di scrape. Per verificare la presenza di questo problema nei log, esegui questo comando:

kubectl -n gmp-system logs ds/collector prometheus

Nei cluster GKE Autopilot, esegui questo comando:

kubectl -n gke-gmp-system logs ds/collector prometheus

Cerca questo messaggio:

  • "timeout di scrape maggiore dell'intervallo di scrape per la configurazione di scrape con nome del job "PodMonitoring/gmp-system/example-app/go-metrics""

Per risolvere questo problema, imposta il valore dell'intervallo di scraping uguale o superiore al valore del timeout di scrape.

TYPE mancante nella metrica

Se viene visualizzato il seguente errore, significa che nella metrica mancano informazioni sul tipo:

  • "nessun metadati trovato per il nome della metrica "{metric_name}""

Per verificare che il problema sia causato dalle informazioni mancanti sul tipo, controlla l'output /metrics dell'applicazione di esportazione. Se non c'è una riga come la seguente, significa che mancano le informazioni sul tipo:

# TYPE {metric_name} <type>

Alcune librerie, come quelle di VictoriaMetrics precedenti alla versione 1.28.0, eliminano intenzionalmente le informazioni sul tipo. Queste librerie non sono supportate da Managed Service per Prometheus.

Collisioni in serie temporali

Se visualizzi uno dei seguenti errori, potresti avere più di un raccoglitore che tenta di scrivere nella stessa serie temporale:

  • "Impossibile scrivere una o più serie temporali: uno o più punti sono stati scritti più spesso del periodo di campionamento massimo configurato per la metrica."
  • "Impossibile scrivere una o più serie temporali: i punti devono essere scritti in ordine. Uno o più punti specificati avevano un'ora di fine precedente rispetto al punto più recente."

Di seguito sono riportate le cause e le soluzioni più comuni:

  • L'utilizzo di coppie ad alta disponibilità. Managed Service per Prometheus non supporta la raccolta tradizionale ad alta disponibilità. L'utilizzo di questa configurazione può creare più raccoglitori che tentano di scrivere dati nella stessa serie temporale, causando questo errore.

    Per risolvere il problema, disabilita i raccoglitori duplicati riducendo il numero delle repliche a 1 oppure utilizza il metodo ad alta disponibilità supportato.

  • Utilizzo di regole di rietichettatura, in particolare quelle che operano su job o istanze. Managed Service per Prometheus identifica parzialmente una serie temporale univoca mediante la combinazione di etichette {project_id, location, cluster, namespace, job,instance}. L'utilizzo di una regola di rietichettatura per eliminare queste etichette, in particolare le etichette job e instance, può spesso causare conflitti. Non è consigliabile riscrivere queste etichette.

    Per risolvere il problema, elimina la regola che la sta causando; spesso questa operazione può essere eseguita da una regola metricRelabeling che utilizza l'azione labeldrop. Puoi identificare la regola problematica commentando tutte le regole di rietichettatura e poi reintegrandole, una alla volta, finché l'errore non si ripresenta.

Una causa meno comune di conflitti delle serie temporali è l'uso di un intervallo di scrape inferiore a 5 secondi. L'intervallo di scrape minimo supportato da Managed Service per Prometheus è di 5 secondi.

Superamento del limite relativo al numero di etichette

Se viene visualizzato il seguente errore, è possibile che siano state definite troppe etichette per una delle metriche:

  • "Impossibile scrivere una o più serie temporali: a causa delle nuove etichette, la metrica prometheus.googleapis.com/METRIC_NAME potrebbe avere più di PER_PROJECT_LIMIT etichette".

In genere questo errore si verifica quando modifichi rapidamente la definizione della metrica in modo che un nome di metrica abbia di fatto più insiemi indipendenti di chiavi di etichetta per l'intera durata della metrica. Cloud Monitoring impone un limite al numero di etichette per ogni metrica; per ulteriori informazioni, consulta i limiti per le metriche definite dall'utente.

Per risolvere il problema sono necessari tre passaggi:

  1. Identificare perché una determinata metrica ha troppe etichette o che cambiano spesso.

  2. Risolvi l'origine del problema, che potrebbe comportare la modifica delle regole di rietichettatura di PodMonitoring, la modifica dell'utilità di esportazione o la correzione della strumentazione.

  3. Elimina il descrittore della metrica per questa metrica (che comporterà una perdita di dati), in modo che possa essere ricreata con un insieme di etichette più piccolo e più stabile. Per farlo, puoi utilizzare il metodo metricDescriptors.delete.

Le cause più comuni del problema sono:

  • Raccolta di metriche da esportatori o applicazioni che collegano etichette dinamiche sulle metriche. Ad esempio, cAdvisor con deployment autonomo con altre etichette container e variabili di ambiente o l'agente DataDog, che inserisce annotazioni dinamiche.

    Per risolvere il problema, puoi utilizzare una sezione metricRelabeling in PodMonitoring per mantenere o eliminare le etichette. Alcune applicazioni ed esportatori consentono anche la configurazione che modifica le metriche esportate. Ad esempio, cAdvisor ha una serie di impostazioni di runtime avanzate che possono aggiungere etichette in modo dinamico. Quando utilizzi la raccolta gestita, ti consigliamo di utilizzare la raccolta kubelet automatica integrata.

  • Utilizzo di regole di rietichettatura, in particolare quelle che associano i nomi delle etichette in modo dinamico, il che può causare un numero imprevisto di etichette.

    Per risolvere il problema, elimina la voce della regola all'origine.

Limiti di frequenza per la creazione e l'aggiornamento di metriche ed etichette

Se viene visualizzato il seguente errore, significa che hai raggiunto il limite di frequenza al minuto per la creazione di nuove metriche e l'aggiunta di nuove etichette di metrica a quelle esistenti:

  • "Richiesta limitata. Hai raggiunto il limite per progetto di modifiche alla definizione di metrica o di definizione di etichette al minuto."

Questo limite di frequenza viene generalmente raggiunto solo durante l'integrazione iniziale con Managed Service per Prometheus, ad esempio quando esegui la migrazione di un deployment Prometheus esistente e matura per utilizzare una raccolta con deployment autonomo. Questo non è un limite di frequenza per l'importazione di punti dati. Questo limite di frequenza si applica solo durante la creazione di metriche mai viste prima o quando si aggiungono nuove etichette a metriche esistenti.

Questa quota è corretta, ma gli eventuali problemi dovrebbero risolversi automaticamente man mano che vengono create nuove metriche ed etichette delle metriche entro il limite al minuto.

Limiti al numero di descrittori delle metriche

Se visualizzi il seguente errore, significa che hai raggiunto il limite di quota per il numero di descrittori della metrica all'interno di un singolo progetto Google Cloud:

  • "La quota del descrittore della metrica è esaurita."

Per impostazione predefinita, questo limite è impostato su 25.000. Sebbene questa quota possa essere aumentata su richiesta se le metriche sono strutturate correttamente, è molto più probabile che tu abbia raggiunto questo limite perché stai importando nomi delle metriche non corretti nel sistema.

Prometheus dispone di un modello di dati dimensionale in cui informazioni come il nome del cluster o dello spazio dei nomi devono essere codificate come valore etichetta. Quando le informazioni sulle dimensioni vengono invece incorporate nel nome della metrica stesso, il numero di descrittori delle metriche aumenta all'infinito. Inoltre, poiché in questo scenario le etichette non vengono utilizzate correttamente, diventa molto più difficile interrogare e aggregare i dati in cluster, spazi dei nomi o servizi.

Né Cloud Monitoring né Managed Service per Prometheus supportano metriche non dimensionali, come quelle formattate per StatsD o Graphite. Sebbene la maggior parte degli esportatori di Prometheus sia configurata correttamente prima dell'uso, alcuni, come l'esportatore StatsD, l'esportatore Vault o il proxy Envoy fornito con Istio, devono essere configurati esplicitamente in modo da utilizzare le etichette anziché incorporare le informazioni nel nome della metrica. Ecco alcuni esempi di nomi delle metriche non corretti:

  • request_path_____path_to_a_resource____istio_request_duration_milliseconds
  • envoy_cluster_grpc_method_name_failure
  • envoy_cluster_clustername_upstream_cx_connect_ms_bucket
  • vault_rollback_attempt_path_name_1700683024
  • service__________________________________________latency_bucket

Per verificare il problema:

  1. Nella console Google Cloud, seleziona il progetto Google Cloud collegato all'errore.

  2. Nel pannello di navigazione della console Google Cloud, seleziona Monitoring, quindi  Gestione delle metriche:

    Vai a Gestione delle metriche

  3. Verifica che la somma delle metriche attive e non attive sia superiore a 25.000. Nella maggior parte dei casi, dovresti vedere un numero elevato di metriche Non attive.
  4. Ordina per Volume fatturabile di campioni in ordine crescente, scorri l'elenco e cerca pattern.

In alternativa, puoi verificare il problema utilizzando Metrics Explorer:

  1. Nella console Google Cloud, seleziona il progetto Google Cloud collegato all'errore.

  2. Nel pannello di navigazione della console Google Cloud, seleziona Monitoring e poi  Metrics Explorer:

    Vai a Metrics Explorer

  3. In Query Builder, fai clic su Seleziona una metrica, poi deseleziona la casella di controllo "Attivo".
  4. Digita "prometheus" nella barra di ricerca.
  5. Cerca eventuali pattern nei nomi delle metriche.

Una volta identificati i pattern che indicano le metriche non corrette, puoi attenuare il problema correggendo l'esportatore all'origine ed eliminando i descrittori delle metriche in questione.

Per evitare che il problema si ripresenti, devi prima configurare l'esportatore pertinente in modo che non invii più metriche in formato non corretto. Ti consigliamo di consultare la documentazione del tuo esportatore per ricevere assistenza. Puoi confermare di aver risolto il problema visitando manualmente l'endpoint /metrics e controllando i nomi delle metriche esportate.

Puoi quindi liberare la quota eliminando le metriche con formato non corretto utilizzando il metodo projects.metricDescriptors.delete. Per eseguire l'iterazione più facilmente nell'elenco delle metriche non corrette, forniamo uno script Golang che puoi utilizzare. Questo script accetta un'espressione regolare in grado di identificare le metriche non corrette ed elimina tutti i descrittori della metrica che corrispondono al pattern. Poiché l'eliminazione delle metriche è irreversibile, ti consigliamo vivamente di eseguire prima lo script utilizzando la modalità di prova.

Nessun errore e nessuna metrica

Se utilizzi la raccolta gestita, non vedi errori, ma i dati non vengono visualizzati in Cloud Monitoring. La causa più probabile è che gli esportatori delle metriche o le configurazioni di scraping non sono configurati correttamente. Managed Service per Prometheus non invia dati delle serie temporali, a meno che non applichi prima una configurazione di scrape valida.

Per identificare se questa è la causa, prova a eseguire il deployment dell'applicazione di esempio e della risorsa PodMonitoring di esempio. Se ora vedi la metrica up (potrebbero volerci alcuni minuti), significa che il problema riguarda la configurazione dello scrape o l'utilità di esportazione.

La causa principale può essere qualsiasi cosa. Ti consigliamo di controllare quanto segue:

  • PodMonitoring fa riferimento a una porta valida.

  • Le specifiche del deployment dell'esportatore hanno porte denominate correttamente.

  • I selettori (più comunemente app) corrispondono alle risorse Deployment e PodMonitoring.

  • Puoi visualizzare i dati relativi all'endpoint e alla porta previsti visitando manualmente i dati.

  • Hai installato la risorsa PodMonitoring nello stesso spazio dei nomi dell'applicazione di cui vuoi eseguire lo scraping. Non installare risorse o applicazioni personalizzate nello spazio dei nomi gmp-system o gke-gmp-system.

  • I nomi delle metriche e delle etichette corrispondono all'espressione regolare di convalida di Prometheus. Managed Service per Prometheus non supporta i nomi delle etichette che iniziano con il carattere _.

  • Non stai utilizzando un insieme di filtri che fa sì che tutti i dati vengano esclusi. Presta particolare attenzione a non avere filtri in conflitto quando utilizzi un filtro collection nella risorsa OperatorConfig.

  • Se in esecuzione al di fuori di Google Cloud, project o project-id è impostato su un progetto Google Cloud valido, mentre location è impostato su una regione Google Cloud valida. Non puoi utilizzare global come valore per location.

  • La metrica è uno dei quattro tipi di metriche di Prometheus. Alcune librerie come Kube State Metrics espongono tipi di metriche OpenMetrics come Info, Stateset e GaugeHistogram, ma questi tipi di metriche non sono supportati da Managed Service per Prometheus e vengono eliminati automaticamente.

Problemi relativi alla raccolta da parte degli esportatori

Se le metriche di un esportatore non vengono importate, verifica quanto segue:

  • Verifica che l'utilità di esportazione funzioni ed esporta le metriche utilizzando il comando kubectl port-forward.

    Ad esempio, per verificare che i pod con il selettore app.kubernetes.io/name=redis nello spazio dei nomi test emettono metriche all'endpoint /metrics sulla porta 9121, puoi eseguire il port forwarding nel seguente modo:

    kubectl port-forward "$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].metadata.name}')" 9121

    Accedi all'endpoint localhost:9121/metrics utilizzando il browser o curl in un'altra sessione del terminale per verificare che le metriche vengano esposte dall'esportatore per lo scraping.

  • Verifica se puoi eseguire query sulle metriche nella console Google Cloud, ma non in Grafana. Se è così, il problema riguarda Grafana e non la raccolta delle metriche.

  • Verifica che il raccoglitore gestito sia in grado di eseguire lo scraping dell'esportatore esaminando l'interfaccia web di Prometheus esposta dal raccoglitore.

    1. Identifica il raccoglitore gestito in esecuzione sullo stesso nodo su cui è in esecuzione l'esportatore. Ad esempio, se il tuo esportatore è in esecuzione sui pod nello spazio dei nomi test e i pod sono etichettati con app.kubernetes.io/name=redis, il comando seguente identifica il raccoglitore gestito in esecuzione sullo stesso nodo:

      kubectl get pods -l app=managed-prometheus-collector --field-selector="spec.nodeName=$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].spec.nodeName}')" -n gmp-system -o jsonpath='{.items[0].metadata.name}'

    2. Configura il port forwarding dalla porta 19090 del raccoglitore gestito:

      kubectl port-forward POD_NAME -n gmp-system 19090

    3. Vai all'URL localhost:19090/targets per accedere all'interfaccia web. Se l'esportatore è indicato come una delle destinazioni, significa che il raccoglitore gestito sta eseguendo correttamente lo scraping dell'esportatore.

Firewall

Un firewall può causare problemi di importazione e di query. Il firewall deve essere configurato in modo da consentire le richieste POST e GET al servizio API Monitoring, monitoring.googleapis.com, per consentire l'importazione e le query.

Errore relativo a modifiche simultanee

Il messaggio di errore "Troppe modifiche simultanee alla configurazione del progetto" di solito è temporaneo e si risolve dopo pochi minuti. Di solito è causato dalla rimozione di una regola di rietichettatura che interessa molte metriche diverse. La rimozione determina la formazione di una coda di aggiornamenti ai descrittori delle metriche nel progetto. L'errore scompare quando la coda viene elaborata.

Per ulteriori informazioni, consulta Limiti relativi alla creazione e all'aggiornamento di metriche ed etichette.