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 visualizzi alcun dato metrico 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 sono spesso causati da autorizzazioni errate sul l'account di servizio che legge i dati o tramite 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 di regole.

Per determinare se il problema riguarda l'importazione o le 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 selezionarlo per cui non visualizzi 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 Query Builder, seleziona il pulsante  MQL o  PromQL.

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

  5. 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 riguarda la 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, consulta Problemi relativi all'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 fatturabili senza influire sull'osservabilità. La pagina Gestione delle metriche riporta le seguenti informazioni:

  • Volumi di importazione sia per la fatturazione basata su byte che su sample, per i domini delle metriche e per le singole metriche.
  • Dati su etichette e cardinalità delle metriche.
  • Numero di letture per ogni metrica.
  • Utilizzo di metriche nei criteri di avviso e nelle dashboard personalizzate.
  • Tasso di errori di scrittura delle metriche.

Puoi anche utilizzare la pagina Gestione delle metriche per escludere le metriche non necessarie, eliminando il costo di importazione.

Per visualizzare la pagina Gestione delle metriche:

  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 l'intervallo di tempo. Per impostazione predefinita, la pagina Gestione delle metriche mostra informazioni sulle metriche raccolte nell'ultimo giorno.

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:

Per iniziare:

  • Controlla attentamente la configurazione in base alle istruzioni di configurazione per le query.

  • Se utilizzi la federazione delle identità per i carichi di lavoro per GKE, verifica che il tuo account servizio disponga delle autorizzazioni corrette 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 il nome dell'account di servizio sia scritto correttamente. Poi, fai clic su Modifica.

    3. Seleziona il campo Ruolo, poi fai clic su Attualmente in uso e cerca il ruolo Visualizzatore monitoraggio. 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 una delle seguenti situazioni, è possibile che il segreto sia mancante o digitato erroneamente:

  • Uno di questi errori "forbidden" 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 di risposta imprevisto durante il recupero dei nomi delle metriche: Forbidden"

  • 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 il sincronizzatore 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 corretto, Grafana l'UID dell'origine dati e il token dell'API Grafana. Puoi ispezionare le variabili nel CronJob eseguendo il comando kubectl describe cronjob datasource-syncer.

  2. 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.

  3. Verifica che il tuo account di servizio Grafana disponga del ruolo "Amministratore" ruolo e che le tue Il token dell'API non è scaduto.

  4. Verifica che l'account di servizio abbia il ruolo Visualizzatore Monitoring per all'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 la federazione delle identità per i carichi di lavoro per GKE, verifica di non aver digitato erroneamente la chiave o le credenziali dell'account e di averle associate allo spazio dei nomi corretto.

Se utilizzi il proxy dell'interfaccia utente frontend precedente, prova a svolgere quanto segue per risolvere questi errori:

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

  2. Verifica l'ID progetto che hai specificato per qualsiasi --query.project-id di controllo.

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

  4. Verifica di aver impostato l'ID progetto corretto durante il deployment dell'UI frontend e di non averlo lasciato impostato sulla stringa letteralePROJECT_ID.

  5. 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.

  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 segreto sia montato correttamente:

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

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

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

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

Metodo HTTP errato per Grafana

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

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

Per risolvere 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 awaiting response headers"

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__. Questa limitazione causa l'errore delle query che utilizzano la variabile label_values($label) in Grafana.

Utilizza invece il modulo label_values($metric, $label). Questa query è consigliata perché limita i valori delle etichette restituiti in base alla 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 la sezione Compatibilità dell'API.

Quota superata

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

  • "429: RESOURCE_EXHAUSTED: quota superata per la metrica di quota 'Query serie 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 per aumentare la quota di lettura per l'API Monitoring. Per assistenza, contatta 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 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.

I valori non elaborati di contatori, istogrammi e riepiloghi non corrispondono tra l'interfaccia utente del collector 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 sui dati non elaborati valore delle metriche cumulative di Prometheus, tra cui contatori, istogrammi e riassunti. Questo comportamento è previsto.

Monarch richiede timestamp di inizio, ma Prometheus non ha timestamp di inizio. 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. I punti successivi hanno il valore dell'iniziale saltata punto sottratto dal loro valore per assicurare che le tariffe siano corrette. Ciò causa un deficit persistente nel valore non elaborato di questi punti.

La differenza tra il numero nell'interfaccia utente del raccoglitore e il numero nella Nella console Google Cloud corrisponde il primo valore registrato nella UI del raccoglitore. che è previsto perché il sistema salta quel valore iniziale e lo sottrae dai punti successivi.

Questo è accettabile perché non è necessario eseguire una query per i valori non elaborati delle metriche cumulative in produzione. Tutte le query utili richiedono una funzione rate() o simili, nel qual caso la differenza in qualsiasi orizzonte temporale è identica tra le due UI. Le metriche cumulative aumentano sempre, pertanto non puoi impostare un avviso su una query non elaborata perché una serie temporale raggiunge una soglia una sola volta. Tutti gli avvisi e i grafici utili osservano la variazione o il tasso di variazione del valore.

Il collector memorizza localmente solo circa 10 minuti di dati. Le discrepanze nei valori cumulativi non elaborati potrebbero verificarsi anche a causa di un ripristino dei dati di fabbrica avvenuto prima dell'intervallo di 10 minuti. Per escludere questa possibilità, prova a impostare solo un periodo di tempo di query di 10 minuti quando confronti l'interfaccia utente del collector 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 relativa all'utilizzo della modalità multiprocesso nella libreria client Python di Prometheus.

Dati del contatore mancanti o istogrammi non funzionanti

L'indicatore più comune di questo problema è l'assenza di dati o la presenza di lacune nei dati quando esegui una query su una metrica del contatore semplice (ad esempio una query PromQL di metric_name_foo). Puoi confermare questo problema 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 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 sull'istogramma, ad esempio la funzione quantile(), non funzionano come previsto.

Questi problemi si verificano quando una metrica viene raccolta senza un tipo di metrica Prometheus. Poiché Monarch è fortemente tipizzato, Managed Service per Prometheus tiene conto delle metriche non tipizzate aggiungendo il suffisso "unknown" e importandole due volte, una come indicatore e una come contatore. Il motore di query sceglie quindi se eseguire una query sulla metrica del misuratore o del contatore sottostante in base alle funzioni di query utilizzate.

Sebbene questa euristica in genere funzioni abbastanza bene, può causare problemi come risultati insoliti quando esegui una query su una metrica non elaborata "unknown:counter". 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. Poiché le metriche di tipo "unknown" vengono importate due volte, la mancata impostazione di un valore TYPE raddoppia i campioni 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 quando si utilizza 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.
  • Utilizzo di una regola di rinominazione che modifica il nome della metrica. Di conseguenza, la metrica rinominata viene disaccoppiata 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 per ridurre cardinalità e costi mediante "aggregazione" prima di inviarli al Monarch, consulta Configurare l'aggregazione locale.
  • Interrompi l'utilizzo di Prometheus Remote Write nel percorso della raccolta.
  • Verifica che il campo # TYPE esista per ogni metrica visitando la Endpoint /metrics.
  • Elimina le regole di rinominazione che modificano il nome di una metrica.
  • Elimina le metriche in conflitto con il suffisso "unknown" o "unknown:counter" chiamando DeleteMetricDescriptor.
  • In alternativa, esegui sempre query sui contatori utilizzando una funzione rate o un'altra funzione di elaborazione dei contatori.

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 utilizza Grafana per eseguire query locale di Prometheus anziché Managed Service per Prometheus.

Per informazioni su come configurare Grafana per utilizzare il servizio gestito come origine dati, consulta Grafana.

Importazione delle dashboard Grafana

Per informazioni sull'utilizzo e sulla risoluzione dei problemi relativi all'importatore di dashboard, consulta Importare le dashboard di Grafana in Cloud Monitoring.

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

Problemi lato importazione

I problemi relativi all'importazione possono essere correlati alla raccolta o alla valutazione delle regole. Inizia esaminando 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 i seguenti comandi:

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

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

La funzionalità di stato del target può aiutarti a eseguire il debug del target di scansione. Per maggiori informazioni consulta le informazioni sullo stato del target.

Stato endpoint mancante o troppo vecchio

Se hai attivato la funzionalità di stato del target, ma in una o più risorse PodMonitoring o ClusterPodMonitoring manca il campo o il valore Status.Endpoint Statuses, potresti riscontrare 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 anche causare un valore del campo Status.Endpoint Statuses.Last Update Time precedente a pochi minuti più l'intervallo di scansione.

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

La frazione di collezionisti è inferiore a 1

Se hai attivato la funzionalità di stato del target, ricevi informazioni sullo stato delle tue risorse. Il valore Status.Endpoint Statuses.Collectors Fraction delle risorse PodMonitoring o ClusterPodMonitoring rappresenta la frazione di collector, espressa da 0 a 1, che sono raggiungibili. 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, significa che uno o più collettivi non sono raggiungibili e le metriche in uno di questi nodi potrebbero non essere sottoposte a scraping. 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 è 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 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 collector non sono in stato di salute, consulta la risoluzione dei problemi relativi ai carichi di lavoro 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à di stato del target, ma una o più delle tue 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ù dei tuoi target.

Visualizza il campo Sample Groups, che raggruppa i target in base al messaggio di errore, e individua il campo Last Error. Il campo Last Error proviene da Prometheus e indica il motivo per cui non è stato possibile eseguire lo scraping della destinazione. 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 Configurare un endpoint di scansione 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 delle serie temporali" e per il limite "Richieste di importazione delle serie temporali al minuto" del servizio "monitoring.googleapis.com" per il consumatore "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 importati al secondo.

Per risolvere il problema, invia una richiesta per aumentare la quota di importazione per l'API Monitoring. Per assistenza, contatta l'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:

  • "execute query: Error querying Prometheus: client_error: client error: 403"
  • "Test di idoneità non riuscito: test HTTP non riuscito con codice di stato: 503"
  • "Errore durante la query dell'istanza Prometheus"

Raccolta gestita e strumento di valutazione delle regole gestite 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 le autorizzazioni di monitoraggio. Questa rimozione causa il fallimento della raccolta e della valutazione delle regole.

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 necessario, aggiungi Monitoring come descritto in Account di servizio configurato in modo errato.

  • Vai alla VM di base 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 Gestione di API e identità e fai clic su Mostra dettagli.

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

È anche possibile che il sincronizzatore delle origini dati o l'interfaccia utente di Prometheus sia stato configurato per esaminare il progetto sbagliato. Per informazioni su come verificare di eseguire query sull'ambito delle metriche previsto, consulta Modificare il progetto su cui è stata eseguita la query.

Service account 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: could not find default credentials. Consulta https://developers.google.com/accounts/docs/application-default-credentials per ulteriori informazioni."

Per verificare che il tuo account di servizio disponga delle autorizzazioni corrette, svolgi i seguenti passaggi:

  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 il nome dell'account di servizio sia scritto correttamente. Poi, fai clic su Modifica.

  3. 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 all'account di servizio il ruolo Scrittore di metriche di monitoraggio (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 nelle sezioni rules sia in quelle collection. 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 visualizzi il seguente errore, significa che PodMonitoring o ClusterPodMonitoring non è formattato correttamente:

  • "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.

Il webhook di ammissione non è in grado di analizzare o la configurazione del client HTTP non è valida

Nelle versioni di Managed Service per Prometheus precedenti alla 0.12, potresti visualizzare un errore simile al seguente, relativo all'iniezione di secret nell'ambito non predefinito:

  • "Webhook di ammissione "convalida.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com" rifiutata la richiesta: definizione non valida per l'endpoint con indice 0: impossibile analisi o configurazione del client HTTP Prometheus non valida: deve utilizzare lo spazio dei nomi "my-custom-namespace", get: "default""

Per risolvere il problema, esegui l'upgrade alla versione 0.12 o successive.

Problemi con gli intervalli di scrape e i timeout

Quando utilizzi Managed Service per Prometheus, il timeout dello scraping non può essere superiore all'intervallo di scraping. Per verificare se questo problema si verifica nei log, esegui il seguente 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:

  • "Il timeout della scansione è maggiore dell'intervallo di scansione per la configurazione della scansione con il nome del 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, eliminano 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à. L'utilizzo di questa configurazione può creare più collezioni che tentano di scrivere dati nella stessa serie temporale, 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 rinominazione, 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}. L'utilizzo di una regola di rinominazione per rimuovere queste etichette, soprattutto job e instance, può 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 di collisioni delle serie temporali è l'utilizzo di un intervallo di scansione inferiore a 5 secondi. L'intervallo minimo di scrape supportato Managed Service per Prometheus è di 5 secondi.

Superamento del limite 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: le nuove etichette farebbero sì che la metrica prometheus.googleapis.com/METRIC_NAME abbia 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. Il monitoraggio cloud 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. Identificare il motivo per cui una determinata metrica ha troppe etichette o etichette che cambiano spesso.

  2. Risolvi la causa del problema, che potrebbe comportare la modifica delle regole di rinominazione di PodMonitoring, la modifica dell'esportatore o la correzione dell'instrumentazione.

  3. 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. Per farlo, puoi utilizzare il metodo metricDescriptors.delete.

Le fonti più comuni del problema sono:

  • Raccolta di metriche da esportatori o applicazioni che aggiungono etichette dinamiche alle 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 dispone di una serie di impostazioni di runtime avanzate che possono aggiungere etichette. Quando utilizzi la raccolta gestita, ti consigliamo di utilizzare la raccolta kubelet automatica integrata.

  • 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 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 sulla definizione della metrica oppure modifiche alla definizione dell'etichetta al minuto."

In genere, questo limite di frequenza viene raggiunto solo durante la prima integrazione con il servizio gestito per Prometheus, ad esempio quando esegui la migrazione di un deployment Prometheus esistente e maturo per utilizzare la raccolta con deployment automatico. 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 il numero di descrittori delle metriche all'interno di 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 tu abbia raggiunto questo limite perché stai importando contenuti in formato non corretto 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 le metriche non dimensionali, come quelle formattate per StatsD o Graphite. Sebbene la maggior parte degli esportatori Prometheus sia configurata correttamente, alcuni, come l'esportatore StatsD, l'esportatore Vault o il proxy Envoy fornito con Istio, devono essere configurati esplicitamente per utilizzare le etichette anziché incorporare le 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 confermare 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. Conferma che la somma delle metriche Attive e Inattive sia superiore 25.000. Nella maggior parte dei casi, dovresti vedere un numero elevato di metriche non attive.
  4. Seleziona "Non attivo" nel riquadro Filtri rapidi, scorri l'elenco e cerca schemi.
  5. Seleziona "Attivo". nel riquadro Filtri rapidi, ordina per Campioni fatturabili volume decrescente, scorrere l'elenco e cercare pattern.
  6. 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:

  1. Nella console Google Cloud, seleziona il progetto Google Cloud collegato l'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 cancella lo stato "Attivo" casella di controllo.
  4. Digita "Prometheus" nella barra di ricerca.
  5. 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 l'esportatore pertinente in modo che non emetta più metriche con formato non corretto. I nostri suggerimenti consultare la documentazione dell'esportatore per ricevere assistenza. Puoi verificare di aver risolto il problema visitando manualmente l'endpoint /metrics e controllando i nomi delle metriche esportate.

Puoi quindi liberare la quota eliminando le metriche con formato non corretto utilizzando il metodo projects.metricDescriptors.delete. 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 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, consigliamo vivamente di eseguire prima lo script utilizzando la modalità di prova.

Nessun errore e nessuna metrica

Se utilizzi la raccolta gestita, non visualizzi errori, ma i dati non vengono visualizzati in Cloud Monitoring, la causa più probabile è che gli esportatori di metriche o le configurazioni di scansione non siano configurati correttamente. 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 (in genere app) corrispondono alle risorse 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 si desidera 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 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 utilizzi un insieme di filtri che causano l'esclusione di tutti i dati. Fai molta 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 CronJob di Google Kubernetes Engine, determina il tempo di esecuzione tipico del job:

  1. 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"

  2. 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 regolarmente copiati.

    Per risolvere la situazione, prova quanto segue:

    • Configura il job in modo che non esista almeno fino a quando non sono trascorsi almeno cinque minuti dall'avvio.

    • 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 basata su log con valore di distribuzione anziché raccogliere i dati delle metriche. Questo approccio è consigliato quando i dati vengono pubblicati a una frequenza ridotta. 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 come segue:

    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 questo caso, il problema riguarda Grafana, non la raccolta delle metriche.

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

    1. Identifica il raccoglitore gestito in esecuzione sullo stesso nodo su cui è in esecuzione l'esportatore. Ad esempio, se il tuo esportatore è in esecuzione su 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 come uno dei target, il tuo raccoglitore gestito sta eseguendo lo scraping dell'esportatore.

Errori di esaurimento della memoria (OOM) del raccoglitore

Se utilizzi la raccolta gestita e si verificano errori di memoria insufficiente (Out Of Memory) nei raccoglitori, quindi valuta la possibilità di abilitare la scalabilità automatica pod verticale.

L'operatore presenta errori di esaurimento della memoria (OOM)

Se utilizzi la raccolta gestita e riscontri errori di OutOfMemory (OOM) sul tuo operatore, considera la possibilità di disattivare la funzionalità di stato del target. La funzionalità di stato target può causare problemi di prestazioni degli operatori nei cluster più grandi.

Firewall

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

Errore relativo alle modifiche simultanee

Il messaggio di errore "Troppe modifiche contemporanee alla configurazione del progetto" in genere è transitorio e si risolve dopo pochi minuti. In genere è causato dalla rimozione di una regola di rinominazione che influisce su molte metriche diverse. La rimozione provoca la formazione di una coda di aggiornamenti ai descrittori delle metriche nel progetto. L'errore scompare quando la coda viene elaborata.

Per ulteriori informazioni, consulta Limiti per la creazione e l'aggiornamento di metriche e etichette.

Query bloccate e annullate da Monarch

Se viene visualizzato il seguente errore, significa che hai raggiunto il limite interno per il numero di query simultanee che possono essere eseguite per un determinato progetto:

  • "internal: expanding series: generic::aborted: invalid status monarch::220: Cancelled due to the number of queries whose evaluation is blocked waiting for memory is 501, which is equal to or greater than the limit of 500."

Per garantire protezione da comportamenti illeciti, il sistema impone un limite rigido al numero di query da un progetto che possono essere eseguite contemporaneamente all'interno di Monarch. Con un utilizzo tipico di Prometheus, le query dovrebbero essere rapide e questo limite non dovrebbe mai essere raggiunto.

Potresti raggiungere questo limite se stai inviando molte query simultanee che vengono eseguite per un periodo di tempo più lungo del previsto. Le query che richiedono più di 25 ore di dati sono in genere più lente da eseguire rispetto a quelle che richiedono meno di 25 ore di dati e più lungo è il periodo di tempo preso in considerazione dalla query, più lenta dovrebbe essere la query.

In genere, questo problema si verifica se vengono eseguite molte regole con un periodo di tempo di riferimento lungo in modo inefficiente. Ad esempio, potresti avere molte regole eseguite una volta al minuto e richiedere una tariffa di 4 settimane. Se l'esecuzione di ciascuna di queste regole richiede molto tempo, potrebbe verificarsi un backup delle query in attesa di esecuzione per il progetto, che a sua volta causa la limitazione delle query da parte di Monarch.

Per risolvere il problema, devi aumentare l'intervallo di valutazione delle regole con un periodo di tempo di riferimento lungo in modo che non vengano eseguite ogni minuto. Esecuzione di una query per una tariffa di 4 settimane ogni minuto non è necessario; sono 40.320 minuti in 4 settimane, quindi ogni minuto non ti fornisce quasi nessun segnale aggiuntivo (i tuoi dati al massimo di 1/40.320°). L'utilizzo di un intervallo di valutazione di un'ora dovrebbe essere sufficiente per una query che richiede una tariffa di 4 settimane.

Una volta risolto il collo di bottiglia causato da query inefficienti di lunga durata eseguite troppo di frequente, il problema dovrebbe risolversi da solo.

Tipi di valori incompatibili

Se visualizzi il seguente errore durante l'importazione o la query, significa che nelle metriche è presente un'incompatibilità di tipo di valore:

  • "Il tipo di valore per la metrica prometheus.googleapis.com/metric_name/gauge deve essere INT64, ma è DOUBLE"
  • "Il tipo di valore per la metrica prometheus.googleapis.com/metric_name/gauge deve essere DOUBLE, ma è INT64"
  • "Non è stato possibile scrivere una o più serie temporali: il tipo di valore per la metrica prometheus.googleapis.com/target_info/gauge è in conflitto con il tipo di valore esistente (INT64)"

Potresti visualizzare questo errore al momento dell'importazione, in quanto Monarch non supporta la scrittura di dati di tipo DOUBLE nelle metriche di tipo INT64 né la scrittura di dati di tipo INT64 nelle metriche di tipo DOUBLE. Potresti visualizzare questo errore anche quando esegui query utilizzando una nell'ambito delle metriche, poiché Monarch non può unire metriche di tipo DOPPIO in una progetto con metriche di tipo INT64 in un altro progetto.

Questo errore si verifica solo quando i collezionisti OpenTelemetry generano report sui dati e ha maggiori probabilità di verificarsi se hai sia OpenTelemetry (che utilizza l'esportatore googlemanagedprometheus) sia Prometheus che generano report per la stessa metrica, come accade comunemente per la metrica target_info.

La causa è probabilmente una delle seguenti:

  • Stai raccogliendo metriche OTLP e la libreria di metriche OTLP ha cambiato il suo valore da DOUBLE a INT64, come è accaduto con le metriche Java di OpenTelemetry. La la nuova versione della libreria delle metriche non è ora compatibile con il valore della metrica tipo creato con la versione precedente della libreria di metriche.
  • Stai raccogliendo la metrica target_info utilizzando sia Prometheus che OpenTelemetry. Prometheus raccoglie questa metrica come DOPPIO, mentre OpenTelemetry raccoglie questa metrica come INT64. Ora i tuoi collector scrivono due tipi di valori nella stessa metrica nello stesso progetto e solo il collector che ha creato per primo il descrittore della metrica riesce.
  • Stai raccogliendo target_info utilizzando OpenTelemetry come INT64 in uno e stai raccogliendo target_info utilizzando Prometheus come DOUBLE in un altro progetto. Se aggiungi entrambe le metriche allo stesso ambito, l'esecuzione di query su quella metrica tramite l'ambito delle metriche causa un'unione non valida tra i tipi di valori delle metriche incompatibili.

Questo problema può essere risolto forzando tutti i tipi di valore delle metriche a DOPPIO. le seguenti:

  1. Riconfigura i raccoglitori OpenTelemetry per forzare tutte le metriche a essere DOPPIE attivando gate-gate exporter.googlemanagedprometheus.intToDouble flag.
  2. Elimina tutti i descrittori delle metriche INT64 e consenti di rielaborarli come DOUBLE. Puoi utilizzare lo strumento delete_metric_descriptors.go script per automatizzare questa operazione.

Seguendo questi passaggi verranno eliminati tutti i dati archiviati come metrica INT64. Non esiste un'alternativa all'eliminazione delle metriche INT64 che risolva completamente questo problema.