Risoluzione dei problemi di Managed Service per Prometheus

Questo documento descrive alcuni problemi che potresti riscontrare durante l'utilizzo di Google Cloud Managed Service per Prometheus e fornisce informazioni sulla diagnosi e sulla risoluzione dei problemi.

Hai configurato Managed Service per Prometheus, ma non visualizzi alcun dato metrico in Grafana o nell'interfaccia utente di Prometheus. In linea generale, la causa potrebbe essere una delle seguenti:

  • Un problema relativo alla query, che impedisce la lettura dei dati. I problemi relativi alle query sono spesso causati da autorizzazioni errate sul account di servizio che legge i dati o da una configurazione errata di Grafana.

  • Un problema relativo all'importazione, per cui non vengono inviati dati. I problemi relativi all'importazione possono essere causati da problemi di configurazione con account di servizio, collector o valutazione delle 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 selezionare il progetto per il quale non visualizzi i 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 che 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, consulta Problemi lato query.

Se esegui una query sulla metrica up e non visualizzi risultati, il problema riguarda l'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 possono aiutarti a controllare la spesa 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 delle 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 ulteriori informazioni sulla pagina Gestione delle metriche, consulta Visualizzare e gestire l'utilizzo delle metriche.

Problemi lato query

La causa della maggior parte dei problemi relativi alle 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 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 con configurazione errata o digitati in modo errato

Se visualizzi uno dei seguenti messaggi, è 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 dell'ora del server: Forbidden"
    • "Avviso: errore durante il recupero dell'elenco delle metriche: stato di risposta imprevisto durante il recupero dei nomi delle metriche: Forbidden"

  • Un messaggio simile nei log:
    "cannot read credentials file: open /gmp/key.json: no such file or directory"

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

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

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

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

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

  6. Se utilizzi 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 scopo di misurazione o progetto per cui il tuo account di servizio ha le credenziali.

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

  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'interfaccia utente frontend e di non averlo lasciato impostato sulla stringa letteralePROJECT_ID.

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

  6. Se carichi 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 trasmesso correttamente al contenitore: 

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

Metodo HTTP errato per Grafana

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

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

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

Timeout per query di grandi dimensioni o a lunga esecuzione

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

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

Il servizio gestito per Prometheus non scade finché una query non supera i 120 secondi, mentre Grafana scade dopo 30 secondi per impostazione predefinita. Per risolvere il problema, aumenta i timeout in Grafana a 120 secondi seguendo le istruzioni riportate in Configurare un'origine dati.

Errori di convalida delle etichette

Se in Grafana visualizzi uno dei seguenti errori, potresti utilizzare un endpoint non supportato:

  • "Convalida: le etichette diverse da name non sono ancora supportate"
  • "Templating [job]: Error updating options: labels other than name are not supported yet."

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 visualizzi 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 sulle serie temporali" e per il limite "Query sulle serie temporali al minuto" del servizio 'monitoring.googleapis.com' per il consumatore 'project_number:...'."

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

Metriche di più progetti

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

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

Nessun tipo di risorsa monitorata specificato

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

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

Puoi specificare un tipo di risorsa monitorata filtrando i dati utilizzando l'etichetta monitored_resource. Per saperne di più su come identificare e scegliere un tipo di risorsa monitorata valido, consulta Specificare un tipo di risorsa monitorata.

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 nell'interfaccia utente Prometheus del collector locale e nella console Google Cloud quando esegui query sul valore non elaborato delle metriche cumulative di Prometheus, inclusi contatori, istogrammi e riepiloghi. Si tratta di un comportamento normale.

Monarch richiede timestamp di inizio, ma Prometheus non ha timestamp di inizio. Managed Service per Prometheus genera i timestamp di inizio omettendo il primo punto importato in qualsiasi serie temporale e convertendolo in un timestamp di inizio. Ai punti successivi viene sottratto il valore del punto iniziale saltato per garantire la correttezza delle tariffe. Ciò causa un deficit persistente nel valore non elaborato di questi punti.

La differenza tra il numero nell'interfaccia utente del collector e il numero nella console Google Cloud è uguale al primo valore registrato nell'interfaccia utente del collector, il che è normale perché il sistema ignora questo 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, quindi 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 esaminano la variazione o la velocità 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 di lavoro nella tua applicazione, ciascuno con un endpoint /metrics. Se la tua applicazione avvia più thread, devi impostare la libreria client 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 notevolmente senza alcuna variazione significativa nel volume di scansione o che vengono create nuove metriche con i suffissi "unknown" o "unknown:counter" 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, poiché gli istogrammi sono oggetti con tipi specifici in Monarch, l'importazione delle tre metriche di istogramma obbligatorie come metriche dei singoli contatori impedisce il funzionamento delle funzioni di istogramma. Poiché le metriche con tipo "unknown" vengono importate due volte, la mancata impostazione di un valore TYPE raddoppia i campioni importati.

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

  • Configurazione accidentale di un gatherer Managed Service per Prometheus come server di federazione. La federazione non è supportata quando si utilizza Managed Service per Prometheus. Poiché la federazione elimina intenzionalmente le informazioni sul TYPE, l'implementazione della federazione genera metriche di tipo "sconosciuto".
  • Utilizzo di Prometheus Remote Write in qualsiasi punto della pipeline di importazione. Questo protocollo elimina intenzionalmente anche 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 transitorio in cui TYPE viene eliminato al primo avvio del collector.

Per risolvere il problema:

  • Interrompi l'utilizzo della federazione con Managed Service per Prometheus. Se vuoi ridurre la cardinalità e i costi "aggregando" i dati prima di inviarli a Monarch, consulta Configurare l'aggregazione locale.
  • Interrompi l'utilizzo di Prometheus Remote Write nel percorso della raccolta.
  • Verifica che il campo # TYPE esista per ogni metrica visitando l'endpoint/metrics.
  • Elimina 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.

I dati di Grafana non vengono mantenuti dopo il riavvio del pod

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

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

Importazione delle dashboard di 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 dei contenuti della dashboard, consulta il file README dell'importatore.

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 eseguire i seguenti 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 ulteriori informazioni, consulta le informazioni sullo stato del target.

Lo stato dell'endpoint non è presente 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 sullo stesso nodo di uno dei tuoi endpoint.
  • Una o più configurazioni di PodMonitoring o ClusterPodMonitoring non hanno prodotto 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, un valore 0.5 indica che il 50% dei tuoi collezionisti è raggiungibile, mentre un valore 1 indica che il 100% dei tuoi collezionisti è 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 collector siano in esecuzione e raggiungibili tramite la rete del cluster. Puoi visualizzare lo stato dei pod del raccoglitore con il seguente comando:

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

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 di collector (ad esempio, un pod di collector chiamato collector-12345) con il seguente comando:

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

Nei cluster GKE Autopilot, esegui il seguente 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 collector sono integri, controlla i log dell'operatore. Per controllare i log dell'operatore, esegui prima il seguente 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 il seguente 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 il seguente 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, utilizzando i target di esempio come riferimento, controlla se gli endpoint di scansione sono in esecuzione.

Endpoint di scraping non autorizzato

Se visualizzi uno dei seguenti errori e il target di scansione richiede l'autorizzazione, il tuo collector non è configurato per utilizzare il tipo di autorizzazione corretto 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 più comunemente al primo avvio del servizio gestito. La quota predefinita verrà esaurita con l'importazione di 100.000 campioni 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 sulle quote, consulta Utilizzo delle quote.

Autorizzazione mancante nell'account di servizio predefinito del nodo

Se viene visualizzato uno dei seguenti errori, è possibile che al account di servizio predefinito sul node manchino 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"

La raccolta gestita e lo valutatore delle regole gestite in Managed Service per Prometheus utilizzano entrambi l'account di servizio predefinito sul nodo. Questo account viene creato con tutte le autorizzazioni necessarie, ma a volte i clienti rimuovono manualmente le autorizzazioni di 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, quindi esegui il seguente 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 Istanze 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.

Account di servizio configurato in modo errato

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

  • "code = PermissionDenied desc = Denied permission monitoring.timeSeries.create (or the resource may not exist)"
  • "google: could not find default credentials. Per saperne di più, consulta https://developers.google.com/accounts/docs/application-default-credentials ".

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 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 Editor monitoraggio o Scrittore di metriche di monitoraggio. 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 esegui Kubernetes non GKE, devi trasmettere esplicitamente le credenziali sia al raccoglitore che al valutatore delle regole. Devi ripetere le credenziali sia nelle sezioni rules sia in quelle collection. Per ulteriori informazioni, vedi Fornire le credenziali esplicitamente (per la raccolta) o Fornire le credenziali esplicitamente (per le regole).

Gli account di servizio sono spesso limitati a un singolo progetto Google Cloud. L'utilizzo di un account di servizio per scrivere dati sulle metriche per più progetti, ad esempio quando un valutatore delle regole gestite esegue una query su un ambito delle metriche multi-project, può causare questo errore di autorizzazione. Se utilizzi l'account di servizio predefinito, ti consigliamo di configurare un account di servizio dedicato in modo da poter aggiungere in sicurezza l'autorizzazione monitoring.timeSeries.create per diversi progetti. Se non puoi concedere questa autorizzazione, puoi utilizzare la ridenominazione delle metriche per rielaborare l'etichetta project_id con un altro nome. L'ID progetto viene impostato per impostazione predefinita sul progetto Google Cloud in cui è in esecuzione il server Prometheus o lo valutatore delle regole.

Configurazione di scansione 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 alla specifica.

Il webhook di ammissione non è stato in grado di analizzare la configurazione del client HTTP o la configurazione 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 nel namespace non predefinito:

  • "webhook di ammissione "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com" ha negato la richiesta: definizione non valida per l'endpoint con indice 0: impossibile interpretare o configurazione del client HTTP Prometheus non valida: deve essere utilizzato lo spazio dei nomi "my-custom-namespace", ricevuto: "default""

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

Problemi con intervalli di scansione e timeout

Quando utilizzi Managed Service per Prometheus, il timeout dello scraping non può essere superiore all'intervallo di scraping. Per controllare i log per questo problema, esegui il seguente comando:

kubectl -n gmp-system logs ds/collector prometheus

Nei cluster GKE Autopilot, esegui il seguente 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 scansione su un valore uguale o superiore al valore del timeout di scansione.

TYPE mancante nella metrica

Se visualizzi il seguente errore, significa che mancano le informazioni sul tipo della metrica:

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

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

# 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 non sono supportate da Managed Service per Prometheus.

Collisioni delle serie temporali

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

  • "Non è stato possibile scrivere una o più serie temporali: uno o più punti sono stati scritti più di frequente rispetto al periodo di campionamento massimo configurato per la metrica."
  • "Non è stato possibile scrivere una o più serie temporali: i punti devono essere scritti in ordine. Uno o più dei punti specificati avevano una data e ora di fine precedente rispetto al punto più recente."

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

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

    Per risolvere il problema, disattiva i collezionisti duplicati riducendo il numero di repliche a 1 o utilizza il metodo 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 tramite la combinazione di etichette {project_id, location, cluster, namespace, job, instance}. L'utilizzo di una regola di rinominazione per rimuovere queste etichette, in particolare le etichette job e instance, può spesso causare collisioni. Non è consigliabile riscrivere queste etichette.

    Per risolvere il problema, elimina la regola che lo causa. Spesso questo può essere fatto con la regola metricRelabeling che utilizza l'azione labeldrop. Puoi identificare la regola problematica mettendo in commento tutte le regole di rinominazione e poi reintegrandole una alla volta finché l'errore non si ripresenta.

Una causa meno comune di collisioni delle serie temporali è l'utilizzo di un intervallo di scansione inferiore a 5 secondi. L'intervallo di scansione minimo supportato da 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: le nuove etichette farebbero sì che la metrica prometheus.googleapis.com/METRIC_NAME abbia più di PER_PROJECT_LIMIT etichette".

Questo errore si verifica in genere quando modifichi rapidamente la definizione della metrica in modo che un nome della metrica abbia effettivamente più insiemi indipendenti di chiavi di etichetta durante l'intero ciclo di vita 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.

Per risolvere il problema, devi seguire tre passaggi:

  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 (con conseguente perdita di dati), in modo che possa essere ricreata con un insieme di etichette più piccolo e stabile. Puoi utilizzare il metodo metricDescriptors.delete per farlo.

Le cause 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 autonomo con etichette dei contenitori e variabili di ambiente aggiuntive o l'agente DataDog, che inietta annotazioni dinamiche.

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

  • L'utilizzo di regole di rinominazione, in particolare quelle che assegnano i nomi delle etichette in modo dinamico, che può causare un numero inaspettato 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 per le modifiche alla definizione delle metriche o delle etichette 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. Non si tratta di un limite di frequenza per l'importazione dei punti dati. Questo limite di frequenza si applica solo quando crei metriche mai viste prima o quando aggiungi nuove etichette alle metriche esistenti.

Questa quota è fissa, ma eventuali problemi dovrebbero risolversi automaticamente con la creazione di nuove metriche ed etichette fino al limite per minuto.

Limiti al numero di descrittori delle metriche

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

  • "La quota dei 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 ben formattate, è molto più probabile che tu raggiunga questo limite perché importi nel sistema nomi di metriche non formattati correttamente.

Prometheus ha un modello di dati dimensionali in cui informazioni come il nome del cluster o del nome spazio dei nomi devono essere codificate come valore dell'etichetta. Quando invece le informazioni dimensionali sono incorporate nel nome della metrica stessa, il numero di descrittori della metrica aumenta indefinitamente. Inoltre, poiché in questo scenario le etichette non vengono utilizzate correttamente, diventa molto più difficile eseguire query e 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. Ecco alcuni esempi di nomi di metriche con formato non corretto:

  • request_path_____path_to_a_resource____istio_request_duration_milliseconds
  • envoy_cluster_grpc_method_name_failure
  • envoy_cluster_clustername_upstream_cx_connect_ms_bucket
  • vault_rollback_attempt_path_name_1700683024
  • service__________________________________________latency_bucket

Per 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. Verifica che la somma delle metriche Attive e Non attive sia superiore a 25.000. Nella maggior parte dei casi, dovresti vedere un numero elevato di metriche non attive.
  4. Seleziona "Non attivo" nel riquadro Filtri rapidi, scorri l'elenco e cerca schemi.
  5. Seleziona "Attivo" nel riquadro Filtri rapidi, ordina in ordine decrescente per Volume di campioni fatturabili, scorri l'elenco e cerca schemi.
  6. Ordina per Volume fatturabile dei campioni in ordine crescente, scorri l'elenco e cerca schemi.

In alternativa, puoi verificare il problema utilizzando Metrics Explorer:

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

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

    Vai a Esplora metriche

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

  3. In Query Builder, seleziona una metrica, quindi deseleziona la casella di controllo "Attivo".
  4. Digita "prometheus" nella barra di ricerca.
  5. Cerca eventuali schemi nei nomi delle metriche.

Una volta identificati i pattern che indicano metriche con formato non corretto, puoi attenuare il problema correggendo l'esportatore all'origine ed eliminando i descrittori delle metriche in violazione.

Per evitare che il problema si ripresenti, devi prima configurare l'esportatore pertinente in modo che non emetta più metriche con formato non corretto. Ti consigliamo di consultare la documentazione del tuo 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. Per eseguire più facilmente l'iterazione dell'elenco delle metriche con formato non corretto, puoi utilizzare uno script Golang. Questo script accetta un'espressione regolare che può identificare le metriche con formato non corretto ed elimina tutti i descrittori delle metriche che corrispondono al pattern. Poiché l'eliminazione delle metriche è irreversibile, 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 scansione valida.

Per identificare se questa è la causa, prova a eseguire il deployment dell'applicazione di esempio e della risorsa PodMonitoring di esempio. Se ora vedi la metrica up (potrebbe essere necessario qualche minuto), il problema riguarda la configurazione o l'esportatore dello scraping.

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

  • PodMonitoring fa riferimento a una porta valida.

  • Le porte della specifica di deployment dell'esportatore sono denominate correttamente.

  • I selettori (in genere app) corrispondono alle risorse Deployment e PodMonitoring.

  • Puoi visualizzare i dati nell'endpoint e nella porta previsti visitandoli manualmente.

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

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

  • Non 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 al di fuori di Google Cloud, project o project-id è impostato su un progetto Google Cloud valido e location è impostato su una regione Google Cloud valida. Non puoi utilizzare global come valore per location.

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

Alcune metriche non sono disponibili per i target con breve tempo di esecuzione

Google Cloud Managed Service per Prometheus è stato disegnato e non ci sono errori di configurazione. Tuttavia, alcune metriche mancano.

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 di deployment del cron job e trova lo stato, elencato alla fine del file. Lo stato in questo esempio mostra che il job è stato eseguito per un minuto:

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

  2. Se il tempo di esecuzione è inferiore a cinque minuti, il job non viene eseguito per un tempo sufficiente per eseguire lo scraping dei dati delle metriche in modo coerente.

    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 in modo da rilevare se le metriche sono state sottoposte a scraping prima di uscire. Questa funzionalità richiede il supporto della libreria.

    • 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 validi 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 siano esposte dall'esportatore per lo scraping.

  • Verifica se riesci a eseguire query sulle metriche nella console Google Cloud, ma non in 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 Prometheus esposta dal collector.

    1. Identifica il collector gestito in esecuzione sullo stesso nodo su cui è in esecuzione l'esportatore. Ad esempio, se il tuo esportatore è in esecuzione sui pod nello spazio dei nomi test e i pod sono etichettati con app.kubernetes.io/name=redis, il seguente comando identifica il collector 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 riscontri errori di OOM (Out Of Memory) nei tuoi collector, valuta la possibilità di attivare la scalabilità automatica dei pod verticali.

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 del target può causare problemi di rendimento dell'operatore in cluster più grandi.

Firewall

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

Errore relativo alle modifiche simultanee

Il messaggio di errore "Troppe modifiche simultanee alla configurazione del progetto" è in genere transitorio e si risolve dopo alcuni minuti. In genere è causato dalla rimozione di una regola di rinominazione che interessa 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 proteggerti da comportamenti illeciti, il sistema applica un limite rigido al numero di query di un progetto che possono essere eseguite contemporaneamente in 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 esegui molte query simultanee che vengono eseguite per un 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 che vengono eseguite una volta ogni minuto e richiedono 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. Non è necessario eseguire una query per una frequenza di 4 settimane ogni minuto. In 4 settimane ci sono 40.320 minuti, quindi ogni minuto non fornisce quasi alcun indicatore aggiuntivo (i dati cambieranno 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 anche visualizzare questo errore quando esegui query utilizzando un ambito delle metriche di più progetti, poiché Monarch non può unire le metriche di tipo DOUBLE in un progetto con le 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 delle metriche OTLP ha modificato il tipo di valore da DOUBLE a INT64, come è successo con le metriche Java di OpenTelemetry. La nuova versione della libreria delle metriche non è più compatibile con il tipo di valore della metrica creato dalla vecchia versione della libreria delle metriche.
  • Stai raccogliendo la metrica target_info utilizzando sia Prometheus sia OpenTelemetry. Prometheus raccoglie questa metrica come DOUBLE, mentre OpenTelemetry la raccoglie 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.
  • Raccogli target_info utilizzando OpenTelemetry come INT64 in un progetto e target_info utilizzando Prometheus come DOUBLE in un altro progetto. L'aggiunta di entrambe le metriche allo stesso ambito delle metriche e la successiva query sulla metrica tramite l'ambito delle metriche causa un'unione non valida tra tipi di valori delle metriche incompatibili.

Questo problema può essere risolto impostando tutti i tipi di valori delle metriche su DOUBLE come segue:

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

Se segui questi passaggi, vengono eliminati tutti i dati memorizzati come metrica INT64. Non esiste un'alternativa all'eliminazione delle metriche INT64 che risolva completamente questo problema.