Questa pagina è stata tradotta dall'API Cloud Translation.

Risoluzione dei problemi di Managed Service per Prometheus

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

Hai configurato Managed Service per Prometheus, ma non lo vedi qualsiasi dato delle metriche in Grafana o nell'interfaccia utente di Prometheus. A livello generale, la causa può essere:

Un problema lato query, in modo che i dati non possano essere letti. Lato query i problemi sono spesso causati da autorizzazioni errate sul l'account di servizio che legge i dati o a causa di un'errata configurazione 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 di regole.

a determinare se il problema riguarda l'importazione o la 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 autorizzazioni di lettura o impostazioni Grafana.

Per visualizzare questa pagina:

Utilizza il selettore di progetti della console Google Cloud per selezionarlo per cui non visualizzi dati.
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 Monitoraggio.
Nella barra degli strumenti della riquadro Query Builder, seleziona il pulsante con MQL o PromQL.
Verifica che PromQL sia selezionato con l'opzione Lingua. Il pulsante di attivazione/disattivazione della lingua si trova nella stessa barra degli strumenti. consente di formattare la query.
Inserisci la seguente query nell'editor, e poi fai clic su Esegui query:
```
up
```

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

Se esegui una query sulla metrica up e non vedi alcun risultato, il problema è dal punto di vista dell'importazione. Per informazioni su come risolvere questi problemi, vedi Problemi lato importazione.

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

La pagina Gestione delle metriche di Cloud Monitoring fornisce informazioni che può 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, nelle varie metriche domini 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:

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 Monitoraggio.
Seleziona la finestra temporale nella barra degli strumenti. Per impostazione predefinita, La pagina Gestione delle metriche mostra informazioni sulle metriche raccolte. nel giorno precedente.

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

Problemi lato query

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

Autorizzazioni o credenziali non corrette per gli account di servizio.
Configurazione errata di Workload Identity, se nel tuo cluster è disponibile attivata. Per ulteriori informazioni, consulta Configurare un servizio per Workload Identity.

Per prima cosa:

Controlla attentamente la configurazione in base alle istruzioni di configurazione per per le query.
Se utilizzi Workload Identity, verifica che il tuo servizio l'account disponga delle autorizzazioni corrette, procedendo nel seguente modo:
1. Nella console Google Cloud, vai alla pagina IAM:
  Vai a IAM
  
  Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo IAM e Console di amministrazione.
2. Identifica il nome dell'account di servizio nell'elenco delle entità. Verifica che l'ortografia del nome dell'account di servizio è corretta. Poi fai clic su Modifica.
3. Seleziona il campo Ruolo, quindi fai clic su Attualmente in uso cerca il ruolo Visualizzatore Monitoring. Se l'account di servizio questo ruolo, aggiungilo adesso.

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 errore di ortografia o mancanza secret:

Uno di questi è "vietato" 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 quando recupero dei nomi delle metriche: Accesso negato"
Vedere un messaggio simile al seguente nei tuoi log:
"impossibile leggere il file delle credenziali: apri /gmp/key.json: nessun file o directory di questo tipo"

Se utilizzi lo strumento di sincronizzazione dell'origine dati per l'autenticazione e configurare Grafana, prova a procedere nel seguente modo per risolvere questi errori:

Verifica di aver scelto l'endpoint API Grafana corretto, Grafana l'UID dell'origine dati e il token dell'API Grafana. Puoi esaminare le variabili nella eseguendo il comando kubectl describe cronjob datasource-syncer.
Verifica di aver impostato lo stesso ID progetto dello strumento di sincronizzazione dell'origine dati ambito delle metriche o progetto del tuo account di servizio. credenziali.
Verifica che il tuo account di servizio Grafana disponga del ruolo "Amministratore" ruolo e che le tue Il token dell'API non è scaduto.
Verifica che l'account di servizio abbia il ruolo Visualizzatore Monitoring per all'ID progetto scelto.
Verifica che non siano presenti errori nei log per l'origine dati. un job di sincronizzazione eseguendo kubectl logs job.batch/datasource-syncer-init. Questo deve essere eseguito subito dopo l'applicazione dell'istruzione datasource-syncer.yaml .
Se utilizzi Workload Identity, verifica di non aver digitato in modo errato i l'account con la chiave o le credenziali dell'account e verifica di averlo associato al lo spazio dei nomi corretto.

Se utilizzi il proxy della UI frontend legacy, prova quanto segue. risolvere questi errori:

Verifica di aver impostato l'ID progetto dell'interfaccia utente frontend sulle stesse metriche ambito o progetto di cui l'account di servizio dispone credenziali.
Verifica l'ID progetto che hai specificato per qualsiasi --query.project-id di controllo.
Verifica che l'account di servizio abbia il ruolo Visualizzatore Monitoring per all'ID progetto scelto.
Verifica di aver impostato l'ID progetto corretto quando esegui il deployment del frontend UI e non lasciarla impostata sulla stringa letterale. PROJECT_ID.
Se utilizzi Workload Identity, verifica di non aver digitato in modo errato i l'account con la chiave o le credenziali dell'account e verifica di averlo associato al lo spazio dei nomi corretto.

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

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

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

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 dell'API Grafana, significa che Grafana è configurato per inviare una richiesta POST anziché una richiesta GET:

"{"status":"error","errorType":"bad_data","error":"nessuna corrispondenza[] parametro fornito"}%"

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

Timeout per query di grandi dimensioni o a lunga esecuzione

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

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

Managed Service per Prometheus non scade finché una query supera 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 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 lavoro [job]: errore durante l'aggiornamento delle opzioni: etichette diverse da nome sono non ancora supportata".

Managed Service per Prometheus supporta l'endpoint /api/v1/$label/values solo per l'etichetta __name__. Questo limite causa query che utilizzano Variabile label_values($label) in Grafana in caso di errore.

Usa invece il modulo di label_values($metric, $label). Questa query è consigliato perché vincola i valori delle etichette restituiti per metrica, impedisce 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 API compatibilità.

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 temporale' e limita le "Query serie temporali 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 assistenza, contatta Assistenza Google Cloud. Per ulteriori informazioni quote, consulta Utilizzo delle quote.

Metriche di più progetti

Se vuoi visualizzare le metriche di più progetti Google Cloud, Non devi configurare più sincronizzatori dell'origine dati o creare più origini dati in Grafana.

Crea invece un ambito delle metriche di Cloud Monitoring in uno progetto Google Cloud, ovvero il progetto di definizione dell'ambito, che contiene ai progetti che vuoi 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 una risorsa monitorata quando si utilizza PromQL per eseguire query su un sistema Google Cloud metrica:

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

Puoi specificare un tipo di risorsa monitorata filtrando utilizzando il metodo Etichetta monitored_resource. Per ulteriori informazioni sull'identificazione e la scelta un tipo di risorsa monitorata valido, consulta Specifica di una risorsa monitorata del testo.

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

Potresti notare una differenza tra i valori nel raccoglitore locale UI di Prometheus e console Google Cloud di Google Cloud durante l'esecuzione di query su una o la somma di un contatore. Questo comportamento è previsto.

Monarch richiede i timestamp di inizio, ma Prometheus non ha i timestamp di inizio i timestamp. Managed Service per Prometheus genera timestamp di inizio di saltare il primo punto importato in una serie temporale e convertirlo 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 La console Google Cloud corrisponde al primo valore registrato nella UI del raccoglitore. previsto perché il sistema ignora quel valore iniziale.

Questo è accettabile perché non c'è bisogno di produzione per l'esecuzione di una query per valori contatore non elaborati; tutte le query utili sui contatori richiedono una funzione rate() o simili, nel qual caso la differenza rispetto a un orizzonte temporale è identica tra le due UI. I contatori aumentano solo sempre, quindi non puoi impostare un avviso per una come serie temporale raggiunge una soglia solo una volta. Tutti utili gli avvisi e i grafici esaminano la variazione o il tasso di variazione del valore.

Il raccoglitore contiene solo circa 10 minuti di dati in locale. Discrepanze nei dati non elaborati potrebbero emergere anche a causa di un ripristino dei contatori effettuato prima del orizzonte di minuti. Per escludere questa possibilità, prova a impostare solo una query di 10 minuti periodo di riferimento quando si confrontano la UI del raccoglitore con la console Google Cloud.

Le discrepanze possono essere causate anche dalla presenza di più thread worker nella tua applicazione, ciascuno con un endpoint /metrics. Se l'applicazione avvia più thread, devi inserire Prometheus in modalità multiprocesso. Per ulteriori informazioni, consulta la documentazione per l'utilizzo della modalità multi-processo in Prometheus Libreria client Python.

Dati del contatore mancanti o istogrammi non funzionanti

L'indicatore più comune di questo problema è l'assenza o la visualizzazione di dati intervalli vuoti quando si esegue 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 un rate alla query (ad esempio, rate(metric_name_foo[5m])).

Potresti anche notare che i campioni importati sono aumentati nettamente senza principale cambiamento nel volume di scrape o con la creazione di nuove metriche "sconosciuto" o "unknown:counter" suffissi in Cloud Monitoring.

Potresti anche notare che le operazioni a istogramma, come quantile() non funzionano come previsto.

Questi problemi si verificano quando una metrica viene raccolta senza un TIPO di metrica di Prometheus. Poiché Monarch è un tipo fortemente digitato, Managed Service per Prometheus prende in considerazione le metriche non digitate con il suffisso "sconosciuto" e l'importazione 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 a quale query le funzioni che utilizzi.

Questa euristica di solito funziona abbastanza bene, ma può portare a problemi quali strani risultati durante l'esecuzione di query su un valore "unknown:counter" non elaborato o una metrica di valutazione. Inoltre, come gli istogrammi sono oggetti digitati in modo specifico in Monarch, importando tre istogrammi obbligatori metriche poiché le singole metriche del contatore impediscono il funzionamento delle funzioni dell'istogramma. Come Le metriche di tipo "sconosciuto" vengono importate due volte; se non imposti un TYPE, il valore importati.

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

Configurazione accidentale di un servizio gestito per Prometheus come server di federazione. La federazione non è supportata se utilizzi Managed Service per Prometheus. Poiché la federazione rimuove intenzionalmente TYPE informazioni, l'implementazione della federazione provoca metriche di tipo "sconosciuto".
Utilizzo di Prometheus Remote Scrivi in qualsiasi punto della pipeline di importazione. Questo elimina intenzionalmente le informazioni TYPE.
Utilizzare una regola di rietichettatura che modifichi il nome della metrica. Questo fa sì che metrica rinominata per dissociarsi dalle informazioni TYPE associate a il nome originale della metrica.
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 per ridurre cardinalità e costi mediante "aggregazione" prima di inviarli al 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 la Endpoint /metrics.
Elimina tutte le regole di rietichettatura che modificano il nome di una metrica.
Elimina tutte le metriche in conflitto con il valore "sconosciuto" o "unknown:counter" suffisso 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 tuoi dati sembrano scomparire da Grafana dopo il riavvio di un pod, ma visibile in Cloud Monitoring, allora si usa Grafana per eseguire query locale di Prometheus anziché Managed Service per Prometheus.

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

Importazione delle dashboard Grafana

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

Per informazioni sui problemi relativi alla conversione dei contenuti della dashboard, vedi i campi dell'importazione README.

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 esegui 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 :

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 maggiori informazioni consulta le informazioni sullo stato del target.

Stato endpoint mancante o troppo vecchio

Se hai attivato la funzionalità relativa allo stato target ma una o più delle tue risorse PodMonitoring o ClusterPodMonitoring non include il campo o il valore Status.Endpoint Statuses, potresti presenti uno dei seguenti problemi:

Managed Service per Prometheus non è riuscito a raggiungere un raccoglitore su lo stesso nodo di uno degli endpoint.
Sono state generate una o più configurazioni PodMonitoring o ClusterPodMonitoring senza target validi.

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 con il tuo endpoint di scraping sia 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 attivato la funzionalità relativa allo stato target, ricevi informazioni sullo stato delle risorse. La Status.Endpoint Statuses.Collectors Fraction del valore di PodMonitoring Le risorse ClusterPodMonitoring rappresentano la frazione di raccoglitori, espressa raggiungibili da 0 a 1. Ad esempio, il 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, allora uno o più i raccoglitori non sono raggiungibili e le metriche in ognuno di questi nodi probabilmente è stato estratto. Assicurati che tutti i raccoglitori siano in esecuzione e raggiungibili tramite alla rete di un cluster Kubernetes. 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 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 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 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 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 non integri

Se hai attivato la funzionalità relativa allo stato target, ma una o più delle tue risorse PodMonitoring o ClusterPodMonitoring hanno campo Status.Endpoint Statuses.Unhealthy Targets con un valore diverso da 0, il raccoglitore non potrà eseguire lo scraping di uno o più obiettivi.

Visualizza il campo Sample Groups, che raggruppa i target in base a messaggi di errore e trova nel 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, utilizza il target di esempio come riferimento, controlla se gli endpoint di scrape sono in esecuzione.

Endpoint di scraping non autorizzato

Se visualizzi uno dei seguenti errori e la destinazione dello scrape richiede autorizzazione, il raccoglitore non è configurato per utilizzare tipo di autorizzazione o utilizza il payload di autorizzazione errato:

server returned HTTP status 401 Unauthorized
x509: certificate signed by unknown authority

Per risolvere il problema, consulta Configurazione di un endpoint di scrape autorizzato.

Quota superata

Se visualizzi 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 limit "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 assistenza, contatta Assistenza Google Cloud. Per ulteriori informazioni quote, consulta Utilizzo delle quote.

Autorizzazione mancante nell'account di servizio predefinito del nodo

Se visualizzi uno dei seguenti errori, significa che l'account di servizio predefinito nella al nodo potrebbero mancare 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 l'esecuzione della query sull'istanza Prometheus"

Raccolta gestita e strumento di valutazione delle regole gestite in Managed Service per Prometheus utilizza entrambi l'account di servizio predefinito sul nodo. Questo account viene creato con tutte le autorizzazioni necessarie, ma a volte i clienti rimuovono manualmente autorizzazioni aggiuntive. 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 esegui questo comando:
```
gcloud compute instances describe NODE_NAME --format="json" | jq .serviceAccounts
```
Cerca la stringa https://www.googleapis.com/auth/monitoring. Se necessaria, aggiungi Monitoring come descritto in Configurazione errata dell'account di servizio.
Vai 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 con il 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 configurato per esaminare il progetto sbagliato. Per informazioni sulla verifica stai eseguendo query l'ambito delle metriche previsto, consulta Modificare l'ambito delle metriche progetto.

Account di servizio configurato in modo errato

Se vedi uno dei seguenti messaggi di errore, significa che l'account di servizio utilizzata dal raccoglitore non dispone delle autorizzazioni corrette:

"code = PermissionNegaed desc = Permission monitoring.timeSeries.create allowed (La descrizione non è consentita?) (oppure la risorsa potrebbe non esistere)"
"google: impossibile trovare credenziali predefinite. Consulta https://developers.google.com/accounts/docs/application-default-credentials per ulteriori informazioni."

Per verificare che l'account di servizio disponga delle autorizzazioni corrette, esegui la seguenti:

Nella console Google Cloud, vai alla pagina IAM:
Vai a IAM

Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo IAM e Console di amministrazione.
Identifica il nome dell'account di servizio nell'elenco delle entità. Verifica che l'ortografia del nome dell'account di servizio è corretta. Poi fai clic su Modifica.
Seleziona il campo Ruolo, quindi fai clic su Attualmente in uso cerca il ruolo Writer metriche Monitoring o Editor Monitoring. Se l'account di servizio non ha uno di questi ruoli, concedi il ruolo account di servizio, il ruolo Autore delle metriche di Monitoring (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 sia in rules che in collection sezioni. Per saperne di più, vedi Fornire credenziali esplicitamente (per la raccolta) o Fornisci credenziali esplicitamente (per le regole).

Gli account di servizio sono spesso limitati a un singolo progetto Google Cloud. Utilizzarne uno di 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 il servizio predefinito di servizio, valuta la possibilità di configurare un account di servizio dedicato aggiungi in modo sicuro l'autorizzazione monitoring.timeSeries.create per diversi progetti. Se non puoi concedere questa autorizzazione, puoi utilizzare la rietichettatura delle metriche per riscrivere l'etichetta project_id con un altro nome. Per impostazione predefinita, l'ID progetto è il progetto Google Cloud in cui il server Prometheus o lo strumento di valutazione delle regole in esecuzione.

Configurazione scrape non valida

Se viene visualizzato l'errore seguente, il file PodMonitoring o ClusterPodMonitoring non è una forma corretta:

"Si è verificato un errore interno: chiamata al 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 la risorsa personalizzata sia formattata correttamente in base alle la specifica.

Problemi con gli intervalli di scrape e i timeout

Quando si utilizza Managed Service per Prometheus, il timeout dello scrape non può sia 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 job "PodMonitoring/gmp-system/example-app/go-metrics""

Per risolvere il problema, imposta il valore dell'intervallo di scrape uguale a o maggiore del valore del timeout dello 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 causato dalle informazioni mancanti sul tipo, controlla la /metrics dell'applicazione di esportazione. Se non è presente una riga come la seguente, le informazioni sul tipo mancano:

# TYPE {metric_name} <type>

Alcune librerie, ad esempio quelle di VictoriaMetrics precedenti alla versione 1.28.0, eliminare intenzionalmente le informazioni sul tipo. Queste librerie sono non supportato da Managed Service per Prometheus.

Collisioni di serie temporali

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

"Impossibile scrivere una o più serie temporali: sono stati scritti uno o più punti con maggiore frequenza rispetto al 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 meno recente rispetto alla più recente punto".

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

Utilizzo di coppie ad alta disponibilità. Managed Service per Prometheus per supportare la raccolta tradizionale ad alta disponibilità. Utilizzo di questa configurazione creare più raccoglitori che tentano di scrivere dati nelle stesse serie temporali causando questo errore.

Per risolvere il problema, disabilita i raccoglitori duplicati riducendo il valore numero di repliche a 1 oppure utilizza il modello supportato per l'alta disponibilità .
Utilizzo di regole di rietichettatura, in particolare quelle che operano su job o istanze. Managed Service per Prometheus identifica parzialmente una serie temporale univoca dalla combinazione di {project_id, location, cluster, namespace, job, instance}. Se usi una regola di rietichettatura per abbandonarle, in particolare le etichette job e instance, possono spesso causare collisioni. Non è consigliabile riscrivere queste etichette.

Per risolvere il problema, elimina la regola che lo causa; Questo può accadere spesso eseguita dalla regola metricRelabeling che utilizza l'azione labeldrop. Puoi identificare la regola problematica inserendo un commento su tutte le regole di rietichettatura e reintegrandoli uno alla volta, fino a quando l'errore non si ripete.

Una causa meno comune delle collisioni tra serie temporali è l'uso di un intervallo di scraping più breve. per più di 5 secondi. L'intervallo minimo di scrape supportato Managed Service per Prometheus è di 5 secondi.

Superamento del limite di numero di etichette

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

"Impossibile scrivere una o più serie temporali: Il nuovo le etichette provocherebbero la metrica prometheus.googleapis.com/METRIC_NAME per avere più di PER_PROJECT_LIMIT etichette".

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

Ci sono tre passaggi per risolvere questo problema:

Identifica il motivo per cui una determinata metrica ha troppe etichette o che cambiano di frequente.
- Puoi utilizzare il widget Explorer API nella metricDescriptors.list per chiamare il metodo. Per maggiori informazioni vedi Explorer API. Per alcuni esempi, vedi Elenca i tipi di metriche e risorse.
Risolvi l'origine del problema, che potrebbe comportare la modifica delle le regole di rietichettatura di PodMonitoring, la modifica dell'esportatore o la correzione la strumentazione di lavoro.
Elimina il descrittore della metrica per questa metrica (che comporterà una perdita di dati), in modo che possa essere ricreato con un insieme di etichette più piccolo e più stabile. Puoi utilizza il metodo metricDescriptors.delete per farlo.

Le fonti più comuni del problema sono:

Raccolta di metriche da esportatori o applicazioni che collegano etichette dinamiche sulle metriche. Ad esempio, cAdvisor di cui è stato eseguito il deployment autonomamente con etichette del contenitore e variabili di ambiente o Agente DataDog, che inserisce annotazioni dinamiche.

Per risolvere il problema, puoi usare una sezione metricRelabeling su PodMonitoring per mantenere o rilasciare le etichette. Alcune applicazioni gli esportatori consentono anche una configurazione che modifica le metriche esportate. Ad esempio: cAdvisor ha una serie di impostazioni di runtime avanzate che possono aggiungere etichette. Quando utilizzi la raccolta gestita, ti consigliamo di usare la libreria kubelet automatico.
Utilizzando 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 che lo causa.

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 sulla Creare nuove metriche e aggiungere nuove etichette a quelle esistenti:

"Richiesta limitata. Hai raggiunto il limite per progetto sulla definizione della metrica oppure modifiche alla definizione dell'etichetta al minuto."

Questo limite di frequenza viene solitamente raggiunto solo alla prima integrazione con Managed Service per Prometheus, ad esempio quando esegui la migrazione di un maturo di Prometheus per utilizzare la raccolta con deployment autonomo. Questo non è 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 di valutazione.

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

Limiti al numero di descrittori delle metriche

Se visualizzi il seguente errore, significa che hai raggiunto il limite di quota per numero di descrittori delle metriche all'interno di un 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 tu abbia raggiunto questo limite perché stai importando contenuti in formato non i nomi delle metriche nel sistema.

Prometheus ha un modello dei dati dimensionale dove informazioni come il nome del cluster o dello spazio dei nomi devono essere codificate come valore etichetta. Se dimensionale è invece incorporata nel nome della metrica stessa, il numero di descrittori delle metriche aumenta all'infinito. Inoltre, poiché in questo scenario le etichette non vengono utilizzate correttamente, diventa molto più difficile eseguire query 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 StatisticheD o Grafite. Sebbene la maggior parte degli esportatori Prometheus sia configurata correttamente da subito, alcuni come l'esportatore StatisticheD, l'esportatore Vault o il proxy Envoy fornito con Istio, deve essere configurato in modo esplicito per l'utilizzo delle etichette anziché incorporando informazioni nel nome della metrica. Esempi di nomi di metriche con formato non corretto include:

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:

Nella console Google Cloud, seleziona il progetto Google Cloud collegato l'errore.
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 Monitoraggio.
Conferma che la somma delle metriche Attive e Inattive sia superiore 25.000. Nella maggior parte dei casi, dovrebbe vedere un numero elevato di metriche Non attive.
Ordina per Volume fatturabile dei campioni in ordine crescente, sfoglia l'elenco e cerca gli schemi ripetuti.

In alternativa, puoi verificare il problema utilizzando Metrics Explorer:

Nella console Google Cloud, seleziona il progetto Google Cloud collegato l'errore.
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 Monitoraggio.
In Query Builder, fai clic su Seleziona una metrica, poi cancella lo stato "Attivo" casella di controllo.
Digita "Prometheus" nella barra di ricerca.
Cerca eventuali pattern nei nomi delle metriche.

Una volta identificati i pattern che indicano metriche non corrette, puoi mitigare il problema correggendo l'utilità di esportazione all'origine ed eliminando descrittori delle metriche offensivi.

Per evitare che il problema si ripresenti, devi prima configurare lo esportatore pertinente per non emettere più metriche con formato non corretto. I nostri suggerimenti consultare la documentazione dell'esportatore per ricevere assistenza. Puoi confermare aver risolto il problema visitando manualmente l'endpoint /metrics e e controllare i nomi delle metriche esportate.

Puoi quindi liberare la tua quota eliminando le metriche con formato non valido utilizzando projects.metricDescriptors.delete gcloud. A eseguire più facilmente l'iterazione dell'elenco di metriche in formato non corretto, forniamo un modello Golang script che puoi utilizzare. Questo script accetta una normale espressione che può identificare le metriche con formato non corretto ed elimina qualsiasi metrica 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 vedi errori, ma i dati non di Cloud Monitoring, la causa più probabile è che gli esportatori delle metriche o le configurazioni di scrape non sono configurati in modo corretto. Managed Service per Prometheus non invia dati delle serie temporali a meno che non applichi prima una configurazione di scrape valida.

Per capire se la causa è questa, prova a eseguire il deployment dell'applicazione di esempio e alla risorsa PodMonitoring di esempio. Se ora viene visualizzato up metrica (l'operazione potrebbe richiedere alcuni minuti), il problema riguarda lo scrape configurazione o esportatore.

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

PodMonitoring fa riferimento a una porta valida.
La specifica del deployment dell'esportatore ha porte denominate correttamente.
I selettori (più comunemente app) corrispondono al deployment e alle risorse di 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 si desidera eseguire lo scraping. Non installare risorse personalizzate o applicazioni nello spazio dei nomi gmp-system o gke-gmp-system.
I nomi delle metriche e delle etichette corrispondono a quelli di Prometheus con la convalida di regolari dell'oggetto. 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 e location sia 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, Stati e GaugeHistogram, ma questi tipi di metriche non sono supportati Managed Service per Prometheus e vengono eliminati automaticamente.

Mancano alcune metriche per gli obiettivi a breve termine

Il deployment di Google Cloud Managed Service per Prometheus è stato eseguito e non si verificano errori di configurazione. ma mancano alcune metriche.

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

Individua il file YAML del deployment di cron job e trova lo stato, ovvero 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"
```
Se il tempo di esecuzione è inferiore a cinque minuti, significa che il job non è in esecuzione a lungo sufficiente affinché i dati delle metriche vengano costantemente copiati.

Per risolvere la situazione, prova a procedere nel seguente modo:
- Configura il job per assicurarti che non venga chiuso almeno fino a quando sono trascorsi 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é raccogliendo dati sulle metriche. Questo approccio viene suggerito quando i dati pubblicate con una tariffa bassa. Per ulteriori informazioni, vedi Metriche basate su log.
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 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 esposti 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 il scraping dell'esportatore esaminando all'interfaccia web Prometheus esposto dal raccoglitore.
1. Identifica il raccoglitore gestito in esecuzione sullo stesso nodo su cui è in esecuzione l'esportatore. Ad esempio, se esportatore è in esecuzione sui pod nello spazio dei nomi test e questi 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 in modo da consentire le richieste POST e GET ai Servizio API Monitoring, monitoring.googleapis.com, per consentire l'importazione e query.

Errore relativo a modifiche simultanee

Il messaggio di errore "Troppe modifiche contemporanee alla configurazione del progetto" in genere è transitorio e si risolve dopo pochi minuti. Di solito è causato rimuovendo una regola di rietichettatura che interessa molte metriche diverse. La la rimozione causa la formazione di una coda di aggiornamenti ai descrittori della metrica nel tuo progetto. L'errore scompare quando la coda viene elaborata.

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