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 vedi alcun dato delle metriche in Grafana o nella UI di Prometheus. A livello generale, la causa potrebbe essere una delle seguenti:

  • Un problema lato query, in modo che i dati non possano essere letti. I problemi lato query sono spesso causati da autorizzazioni errate nell'account di servizio che leggono i dati o da una configurazione errata di Grafana.

  • Un problema sul lato importazione, in modo che non vengano inviati 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 verifica sul lato dell'importazione o della query, prova a eseguire query sui dati utilizzando la scheda PromQL di Metrics Explorer nella console Google Cloud. È garantito che questa pagina non presenti problemi con le autorizzazioni di lettura o le impostazioni di Grafana.

Per visualizzare questa pagina:

  1. Utilizza il selettore di progetti della console Google Cloud per selezionare il progetto per il quale non vedi dati.

  2. Nella console Google Cloud, vai alla pagina  Esplora metriche:

    Vai a Esplora metriche

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

  3. Nella barra degli strumenti del riquadro di creazione di query, seleziona il pulsante con il nome  MQL o  PromQL.

  4. Verifica che l'opzione PromQL sia selezionata nell'opzione di attivazione/disattivazione Lingua. L'opzione di attivazione/disattivazione della lingua si trova nella stessa barra degli strumenti che ti consente di formattare la query.

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

    up

Se esegui una query sulla metrica up e visualizzi i risultati, il problema riguarda la query. Per informazioni sulla risoluzione di questi problemi, consulta Problemi lato query.

Se esegui una query sulla metrica up e non vedi alcun risultato, il problema riguarda l'importazione. Per informazioni sulla risoluzione di questi problemi, consulta Problemi lato importazione.

Un firewall può anche causare problemi di importazione e 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 sia su byte che su campioni, nei domini delle metriche e per singole metriche.
  • Dati su etichette e cardinalità delle metriche.
  • Utilizzo di metriche nei criteri di avviso e nelle dashboard personalizzate.
  • Percentuale di errori di scrittura delle metriche.

Per visualizzare la pagina Gestione delle metriche, segui questi passaggi:

  1. Nella console Google Cloud, vai alla pagina  Gestione delle metriche:

    Vai a Gestione delle metriche

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

  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:

Per prima cosa:

  • Confronta attentamente la configurazione con le istruzioni di configurazione per l'esecuzione di query.

  • Se utilizzi Workload Identity, verifica che l'account di servizio disponga delle autorizzazioni corrette procedendo nel seguente modo:

    1. Nella console Google Cloud, vai alla pagina IAM:

      Vai a IAM

      Se usi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo IAM e amministrazione.

    2. Identifica il nome dell'account di servizio nell'elenco delle entità. Verifica che il nome dell'account di servizio sia scritto correttamente. Fai clic su Modifica.

    3. Seleziona il campo Ruolo, quindi fai clic su Attualmente in uso 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 configurati o non digitati correttamente

Se visualizzi uno dei seguenti messaggi, è possibile che ci sia un secret mancante o digitato in modo errato:

  • Uno di questi errori "non consentiti" in Grafana o nell'interfaccia utente di Prometheus:

    • "Avviso. Stato di risposta imprevisto durante il recupero del tempo del server: accesso negato"
    • "Avviso: errore durante il recupero dell'elenco delle metriche. Stato della risposta imprevisto durante il recupero dei nomi delle metriche: Vietato"

  • Viene visualizzato un messaggio come questo nei tuoi log:
    "impossibile leggere il file delle credenziali: open /gmp/key.json: file o directory non presenti"

Se utilizzi lo strumento di sincronizzazione delle origini 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 controllare le variabili nel CronJob eseguendo il comando kubectl describe cronjob datasource-syncer.

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

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

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

  5. Verifica che non siano presenti errori nei log per il 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 le credenziali o la chiave dell'account, quindi verifica di averle associate allo spazio dei nomi corretto.

Se utilizzi il proxy UI frontend legacy, prova a procedere nel seguente modo per risolvere questi errori:

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

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

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

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

  5. Se utilizzi Workload Identity, verifica di non aver digitato in modo errato le credenziali o la chiave dell'account, quindi 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 non corretto per Grafana

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

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

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

Timeout per query di grandi dimensioni o a lunga esecuzione

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

  • "Post "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: timeout pending response intestazioni"

Managed Service per Prometheus non scade finché una query non supera i 120 secondi, mentre Grafana scade dopo 30 secondi per impostazione predefinita. 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: etichette diverse da nome non sono ancora supportate"
  • "Modelli di modello [job]: errore durante l'aggiornamento delle opzioni: etichette diverse da nome 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.

Usa invece il modulo di 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 quota 'Query serie temporale ' e limite 'Query serie temporale al minuto' del servizio 'monitoring.googleapis.com' per il consumer 'project_number:...'."

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

Metriche di più progetti

Se vuoi visualizzare le metriche di più progetti Google Cloud, non devi configurare più sincronizzatori delle origini dati o creare più origini dati in Grafana.

Crea invece un ambito delle metriche di Cloud Monitoring in un progetto Google Cloud (il progetto di definizione dell'ambito) che contiene 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 la pagina 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 in base all'etichetta monitored_resource. Per ulteriori informazioni sull'identificazione e la scelta di un tipo di risorsa monitorata valido, consulta Specifica di un tipo di risorsa monitorata.

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

Potresti notare una differenza tra i valori nell'interfaccia utente di Prometheus del raccoglitore locale e nella console Google Cloud di Google Cloud quando esegui una query su un contatore non elaborato o la somma di un contatore. Questo 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'interfaccia utente del raccoglitore e il numero nella console Google Cloud è uguale al primo valore registrato nell'interfaccia utente del raccoglitore, che è previsto perché il sistema ignora questo valore iniziale.

Ciò è accettabile perché non è necessaria una query in produzione per i valori contatore non elaborati; tutte le query utili sui contatori richiedono una funzione rate() o simile, nel qual caso la differenza rispetto all'orizzonte temporale è identica tra le due UI. I contatori aumentano solo sempre, quindi non puoi impostare un avviso per una query non elaborata poiché una serie temporale raggiunge una soglia solo una volta. Tutti gli avvisi e i grafici utili esaminano la variazione o la frequenza di variazione del valore.

Il raccoglitore contiene solo circa 10 minuti di dati in locale. Potrebbero verificarsi discrepanze nei conteggi non elaborati dei contatori anche a causa di un ripristino dei contatori effettuato prima dell'orizzonte dei 10 minuti. Per escludere questa possibilità, prova a impostare solo un periodo di ricerca delle query di 10 minuti quando confronti la UI del raccoglitore con la console Google Cloud.

Le discrepanze possono anche essere causate dalla presenza di più thread worker nell'applicazione, ciascuno con un endpoint /metrics. Se l'applicazione avvia più thread, devi impostare la libreria client Prometheus in modalità multiprocesso. Per ulteriori informazioni, consulta la documentazione sull'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 visualizzazione di lacune nei dati quando si esegue una query su una metrica del contatore semplice (ad esempio, una query PromQL di metric_name_foo). Puoi verificarlo 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 drasticamente senza variazioni significative del volume di scrape o che vengono create nuove metriche con i suffissi "sconosciuto" o "unknown:counter" in Cloud Monitoring.

Potresti anche notare che le operazioni dell'istogramma, ad esempio la funzione quantile(), non funzionano come previsto.

Questi problemi si verificano quando viene raccolta una metrica senza una metrica di Prometheus TYPE. Poiché Monarch è un tipo fortemente digitato, Managed Service per Prometheus tiene conto delle metriche non digitate aggiungendo il suffisso "sconosciuto" come suffisso e importandole due volte, una come misuratore e una volta come contatore. Il motore di query sceglie quindi se eseguire query sul misuratore o sulla metrica contatore sottostante in base alle funzioni di query che utilizzi.

Sebbene questa euristica di solito funzioni abbastanza bene, può portare a problemi quali risultati strani quando si esegue una query su una metrica non elaborata "unknown:counter". Inoltre, poiché gli istogrammi sono oggetti digitati in modo specifico in Monarch, l'importazione delle tre metriche di istogramma obbligatorie, poiché le singole metriche dei contatori, impediscono il funzionamento delle funzioni degli istogrammi. Poiché le metriche di tipo "sconosciuto" vengono importate due volte, se non imposti un TYPE, i campioni importati raddoppiano.

Di seguito sono riportati alcuni motivi comuni per cui potrebbe non essere impostato TYPE:

  • Configurazione accidentale di un servizio gestito per il raccoglitore Prometheus come server di federazione. La federazione non è supportata quando si utilizza Managed Service per Prometheus. Poiché la federazione elimina intenzionalmente le informazioni TYPE, l'implementazione della federazione provoca metriche di tipo "sconosciuto".
  • Utilizzo di Prometheus Remote Scrivi in qualsiasi punto della pipeline di importazione. Inoltre, questo protocollo elimina intenzionalmente le informazioni TYPE.
  • Utilizzare una regola di rietichettatura che modifichi il nome della metrica. Questo fa sì che la metrica rinominata venga dissociata dalle informazioni TYPE associate al nome della metrica originale.
  • L'esportatore non emette un TYPE per ogni metrica.
  • Un problema temporaneo per cui TYPE viene eliminato al primo avvio del raccoglitore.

Per risolvere il problema:

  • Interrompi l'utilizzo della federazione con Managed Service per 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 Scrivi 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 "unknown" o "unknown:counter" chiamando DeleteMetricDescriptor.
  • In alternativa, esegui sempre query sui contatori utilizzando un rate o un'altra funzione di contro-elaborazione.

Dati Grafana non persistenti dopo il riavvio del pod

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

Per informazioni su come configurare Grafana per l'utilizzo del servizio gestito come origine dati, consulta Grafana.

Importazione delle dashboard Grafana

Per informazioni sull'utilizzo e sulla risoluzione dei problemi dello strumento di importazione delle dashboard, vedi Importare le dashboard di Grafana in Cloud Monitoring.

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

Problemi lato importazione

I problemi lato importazione possono essere correlati alla raccolta o alla valutazione delle regole. Per prima cosa, osserva 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

Nei cluster GKE Autopilot, puoi eseguire questi 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 funzionalità dello stato del target può aiutarti a eseguire il debug della destinazione dello scrape. Per scoprire di più, consulta le informazioni sullo stato del target.

Stato endpoint mancante o troppo vecchio

Se hai abilitato la funzionalità di stato target, ma in una o più risorse PodMonitoring o ClusterPodMonitoring manca il campo o il valore Status.Endpoint Statuses, è possibile che si verifichi uno dei seguenti problemi:

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

Problemi simili possono causare anche la presenza nel campo Status.Endpoint Statuses.Last Update Time di un valore antecedente ad alcuni minuti oltre all'intervallo di scrape.

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

La frazione dei collettori è inferiore a 1

Se hai abilitato la funzionalità relativa allo stato target, vedrai informazioni sullo stato delle tue risorse. Il valore Status.Endpoint Statuses.Collectors Fraction delle risorse PodMonitoring o ClusterPodMonitoring rappresenta la frazione di raccoglitori, espressa da 0 a 1, raggiungibili. Ad esempio, un valore 0.5 indica che il 50% dei raccoglitori è raggiungibile, mentre un valore 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 questi nodi non vengano eseguite tramite scraping. Assicurati che tutti i raccoglitori siano in esecuzione e raggiungibili sulla rete 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"

Nei 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 dei carichi di lavoro di GKE.

Se i raccoglitori sono integri, controlla i registri dell'operatore. Per controllare i log dell'operatore, esegui prima questo comando 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 degli operatori (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 non integri

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

Visualizza il campo Sample Groups, che raggruppa i target in base a messaggi di errore, e trova il campo Last Error. Il campo Last Error proviene da Prometheus e indica perché non è stato possibile eseguire lo scraping del target. Per risolvere il problema, utilizzando le destinazioni di esempio come riferimento, controlla se gli endpoint di scrape 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 '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 quando si attiva per la prima volta il servizio gestito. La quota predefinita verrà esaurita a 100.000 campioni al secondo importati.

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

Autorizzazione mancante nell'account di servizio predefinito del nodo

Se viene visualizzato uno dei seguenti errori, l'account di servizio predefinito sul nodo potrebbe non disporre delle 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 l'esecuzione della query sull'istanza Prometheus"

La raccolta gestita e lo strumento di valutazione 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 vanno a buon fine.

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

  • Identifica il nome del nodo Compute Engine sottostante, quindi 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.

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

    1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes:

      Vai a Cluster Kubernetes

      Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato il cui sottotitolo è Kubernetes Engine.

    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 API e gestione delle identità e fai clic su Mostra dettagli.

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

È anche possibile che lo strumento di sincronizzazione dell'origine dati o l'interfaccia utente di Prometheus siano stati configurati in modo da visualizzare il progetto sbagliato. Per informazioni sulla verifica dell'esecuzione di query sull'ambito delle metriche previsto, consulta Modificare il progetto su 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 allowed (oppure la risorsa potrebbe non esistere)"
  • "google: impossibile trovare 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, segui questi passaggi:

  1. Nella console Google Cloud, vai alla pagina IAM:

    Vai a IAM

    Se usi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo IAM e amministrazione.

  2. Identifica il nome dell'account di servizio nell'elenco delle entità. Verifica che il nome dell'account di servizio sia scritto correttamente. Fai clic su Modifica.

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

Se utilizzi 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, vedi Fornire le credenziali in modo esplicito (per la raccolta) o Fornire le credenziali in modo esplicito (per le regole).

Gli account di servizio sono spesso limitati a un singolo progetto Google Cloud. L'utilizzo di un account di servizio per scrivere dati di metriche per più progetti, ad esempio quando un valutatore delle 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 utilizzando un altro nome. Per impostazione predefinita, l'ID progetto corrisponde al progetto Google Cloud in cui è in esecuzione il server Prometheus o il valutatore delle regole.

Configurazione scrape non valida

Se viene visualizzato il seguente errore, significa che il formato di PodMonitoring o ClusterPodMonitoring non è corretto:

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

Per risolvere il problema, assicurati che il formato della risorsa personalizzata sia corretto in base alle specifiche.

Problemi con gli intervalli di scrape e i timeout

Quando si utilizza 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 configurazione di scrape con nome del job "PodMonitoring/gmp-system/example-app/go-metrics""

Per risolvere il problema, imposta il valore dell'intervallo di scrape uguale o maggiore del valore del timeout di scrape.

TYPE mancante nella metrica

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

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

Per verificare che il problema sia dovuto a informazioni sul tipo mancanti, controlla l'output /metrics dell'applicazione di esportazione. Se non è presente una riga come la seguente, le informazioni sul tipo non sono disponibili:

# 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 di serie temporali

Se viene visualizzato uno degli errori seguenti, è possibile che più di un raccoglitore stia tentando di scrivere nella stessa serie temporale:

  • "Impossibile scrivere una o più serie temporali: uno o più punti sono stati scritti più frequentemente del periodo di campionamento massimo configurato per la metrica."
  • "Impossibile scrivere una o più serie temporali: i punti devono essere scritti in ordine. Per uno o più punti specificati l'ora di fine era precedente a quella del punto più recente."

Le cause e le soluzioni più comuni sono le seguenti:

  • Utilizzo di coppie ad alta disponibilità. Managed Service per Prometheus non supporta la raccolta tradizionale ad alta disponibilità. 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 di 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 rimuovere queste etichette, in particolare le etichette job e instance, può spesso causare collisioni. Non è consigliabile riscrivere queste etichette.

    Per risolvere il problema, elimina la regola che lo causa. Questa operazione può essere spesso eseguita da una regola metricRelabeling che utilizza l'azione labeldrop. Puoi identificare la regola problematica inserendo un commento su tutte le regole di rietichettatura e ripristinandole una alla volta finché l'errore non si ripete.

Una causa meno comune delle collisioni tra serie temporali è l'utilizzo di un intervallo di scraping inferiore a 5 secondi. L'intervallo minimo di scraping supportato da Managed Service per Prometheus è di 5 secondi.

Superamento del limite di numero di etichette

Se visualizzi il seguente errore, è possibile che tu abbia definito troppe etichette per una delle metriche:

  • "Impossibile scrivere una o più serie temporali: le nuove etichette faranno sì che la metrica prometheus.googleapis.com/METRIC_NAME avrebbe più di PER_PROJECT_LIMIT etichette."

Questo errore di solito si verifica quando modifichi rapidamente la definizione della metrica in modo che il nome di una metrica abbia effettivamente più set 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.

Ci sono tre passaggi per risolvere questo problema:

  1. Identifica il motivo per cui una determinata metrica ha troppe etichette o che cambiano di frequente.

  2. Risolvi l'origine del problema, che potrebbe comportare la modifica delle regole di rietichettatura di PodMonitoring, la modifica dell'esportatore 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 fonti più comuni del problema sono:

  • Raccolta di metriche da esportatori o applicazioni che collegano etichette dinamiche alle metriche. Ad esempio, cAdvisor di cui è stato eseguito il deployment autonomo con etichette per container e variabili di ambiente aggiuntive o l'agente DataDog, che inserisce annotazioni dinamiche.

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

  • Utilizzo di regole di rietichettatura, in particolare quelle che associano i nomi delle etichette dinamicamente, che possono causare un numero imprevisto di etichette.

    Per risolvere il problema, elimina la voce della regola che lo causa.

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

Se visualizzi 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 alle metriche esistenti:

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

In genere questo limite di frequenza viene raggiunto solo alla prima integrazione con Managed Service per Prometheus, ad esempio quando esegui la migrazione di un deployment Prometheus maturo esistente per utilizzare la raccolta di cui è stato eseguito il deployment autonomo. Non si tratta di un limite di frequenza per l'importazione di punti dati. Questo limite di frequenza si applica solo quando si creano metriche mai viste prima o quando si aggiungono nuove etichette a metriche esistenti.

Questa quota è fissa, ma eventuali problemi dovrebbero risolversi automaticamente man mano che vengono create nuove metriche ed etichette delle metriche fino al limite per minuto.

Limiti al numero di descrittori delle metriche

Se viene visualizzato il seguente errore, significa che hai raggiunto il limite di quota per il numero di descrittori delle metriche in un singolo progetto Google Cloud:

  • "La quota di descrittore della metrica è stata esaurita."

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

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

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

  • 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. Nella console Google Cloud, vai alla pagina  Gestione delle metriche:

    Vai a Gestione delle metriche

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

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

In alternativa, puoi verificare il problema utilizzando Metrics Explorer:

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

  2. Nella console Google Cloud, vai alla pagina  Esplora metriche:

    Vai a Esplora metriche

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

  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 metriche in formato non corretto, puoi mitigare il problema correggendo l'esportatore all'origine ed eliminando i descrittori delle metriche con problemi.

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

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

Nessun errore e nessuna metrica

Se utilizzi la raccolta gestita, non vengono visualizzati errori, ma i dati non vengono visualizzati in Cloud Monitoring, la causa più probabile è che gli esportatori delle metriche o le configurazioni dello scrape non siano configurati correttamente. Managed Service per Prometheus non invia dati di 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 (l'operazione potrebbe richiedere alcuni minuti), significa che il problema riguarda la configurazione o l'esportazione di scrape.

La causa principale potrebbe essere una serie di fattori. Ti consigliamo di controllare quanto segue:

  • PodMonitoring fa riferimento a una porta valida.

  • La specifica del deployment dell'esportatore ha porte denominate correttamente.

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

  • Puoi visualizzare i dati sulla porta e sull'endpoint previsti visitando manualmente l'endpoint.

  • 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 alla convalida dell'espressione regolare 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 impediscono l'esclusione di tutti i dati. Fai attenzione a non avere filtri in conflitto quando utilizzi un filtro collection nella risorsa OperatorConfig.

  • Se viene eseguito all'esterno 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 tua metrica è uno dei quattro tipi di metriche 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.

Mancano alcune metriche per gli obiettivi a breve termine

Viene eseguito il deployment di Google Cloud Managed Service per Prometheus e non si verificano errori di configurazione, ma mancano alcune metriche.

Determina il deployment che genera le metriche parzialmente mancanti. Se il deployment è un CronJob di Google Kubernetes Engine, determina per quanto tempo viene eseguito generalmente il job:

  1. Individua il file YAML del deployment di cron job e individua lo stato, che è elencato alla fine del file. Lo stato in questo esempio mostra che il job è stato eseguito per un minuto:

      status:
    lastScheduleTime: "2024-04-03T16:20:00Z"
    lastSuccessfulTime: "2024-04-03T16:21:07Z"

  2. Se il tempo di esecuzione è inferiore a cinque minuti, il job non è in esecuzione a sufficienza per consentire lo scraping costante dei dati della metrica.

    Per risolvere la situazione, prova a procedere nel seguente modo:

    • Configura il job per assicurarti che non venga chiuso prima che siano trascorsi almeno cinque minuti dall'avvio del job.

    • Configura il job per rilevare se è stato eseguito uno scraping delle metriche prima di uscire. Questa funzionalità richiede il supporto delle librerie.

    • Valuta la possibilità di creare una metrica con valore di distribuzione basata su log anziché raccogliere i dati delle metriche. Questo approccio è consigliato quando i dati vengono pubblicati con una frequenza bassa. Per ulteriori informazioni, consulta Metriche basate su log.

  3. Se il tempo di esecuzione è superiore a cinque minuti o se non è coerente, consulta la sezione Target non integri di questo documento.

Problemi con la raccolta da parte degli esportatori

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

  • Verifica che l'esportatore funzioni ed esporti 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 stiano emettendo 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 siano esposte dall'esportatore per lo scraping.

  • Verifica se puoi eseguire query sulle metriche nella console Google Cloud, ma non su Grafana. In tal caso, il problema riguarda Grafana, non la raccolta delle tue metriche.

  • Verifica che il raccoglitore gestito sia in grado di eseguire lo scraping dell'esportatore ispezionando 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 l'utilità di esportazione è in esecuzione sui pod nello spazio dei nomi test e i pod sono etichettati con app.kubernetes.io/name=redis, il seguente comando 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 è elencato tra le destinazioni, significa che il raccoglitore gestito sta eseguendo correttamente lo scraping dell'esportatore.

Firewall

Un firewall può causare problemi sia di importazione sia di query. Il firewall deve essere configurato per consentire 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" è in genere temporaneo e viene risolto dopo pochi minuti. In genere è causato dalla rimozione di una regola di rietichettatura che interessa molte metriche diverse. La rimozione causa la formazione di una coda di aggiornamenti per i descrittori della metrica 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.