Risoluzione dei problemi di Managed Service per Prometheus

Questo documento descrive alcuni problemi che potresti riscontrare quando utilizzi Google Cloud Managed Service per Prometheus e fornisce informazioni sulla diagnosi e risoluzione dei problemi.

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

• Un problema lato query, in modo che i dati non possano essere letti. I problemi lato query sono spesso causati da autorizzazioni errate per ilaccount di serviziont che legge i dati o da una configurazione errata di Grafana.

• Un problema lato importazione, in modo che non vengano inviati dati. I problemi lato importazione possono essere causati da problemi di configurazione con account di servizio, raccoglitori o valutazione delle regole.

Per determinare se il problema riguarda l'inserimento o la query, prova a eseguire query sui dati utilizzando la scheda PromQL di Metrics Explorer nella console Google Cloud . È garantito che questa pagina non presenti problemi con 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 cui 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 del generatore di query, seleziona il pulsante il cui nome è  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 ti consente di formattare la query.

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

   up
   

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

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

Un firewall può anche causare problemi di importazione e query. Per saperne di più, consulta Firewall.

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

• Volumi di importazione per la fatturazione basata su byte e campioni, in tutti 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 nelle policy di avviso e nelle dashboard personalizzate.
• Tasso di errori di scrittura delle metriche.

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

Per visualizzare la pagina Gestione metriche:

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

   Vai a Gestione metriche

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

2. Nella barra degli strumenti, seleziona la finestra temporale. Per impostazione predefinita, nella pagina Gestione metriche vengono visualizzate le informazioni sulle metriche raccolte nel giorno precedente.

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

Problemi lato query

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

• Autorizzazioni o credenziali errate per i service account.
• Configurazione errata di Workload Identity Federation for GKE, se il cluster ha questa funzionalità abilitata. Per ulteriori informazioni, consulta Configurare un service account per Workload Identity Federation for GKE.

Inizia svolgendo i seguenti passaggi:

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

• Se utilizzi Workload Identity Federation for GKE, verifica che il tuo service account disponga delle autorizzazioni corrette procedendo nel seguente modo:

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

     Vai a IAM

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

  2. Identifica il nome del account di servizio nell'elenco delle entità. Verifica che il nome delaccount di serviziot sia scritto correttamente. Poi fai clic su Modifica.

  3. Seleziona il campo Ruolo, quindi fai clic su Attualmente utilizzato e cerca il ruolo Visualizzatore Monitoring. Se il account di servizio non dispone di 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 in modo errato:

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

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

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

Se utilizzi lo strumento di sincronizzazione delle origini dati per autenticare e configurare Grafana, prova a risolvere questi errori nel seguente modo:

1. Verifica di aver scelto l'endpoint API Grafana corretto, l'UID dell'origine dati Grafana e il token API Grafana. Puoi esaminare le variabili in 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 account di servizio dispone delle credenziali.

3. Verifica che il 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 Monitoring per l'ID progetto scelto.

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

6. Se utilizzi la federazione delle identità per i carichi di lavoro per GKE, verifica di non aver digitato in modo errato la chiave o le credenziali dell'account e di averle associate allo spazio dei nomi corretto.

Se utilizzi il proxy dell'interfaccia utente frontend legacy, prova a svolgere i seguenti passaggi per risolvere questi errori:

1. Verifica di aver impostato l'ID progetto della UI frontend sullo stesso ambito delle metriche o progetto per cui l'account di servizio dispone delle credenziali.

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

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

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

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

6. Se monti un secret personalizzato, assicurati che sia presente:

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

7. Verifica che il secret sia montato correttamente:

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

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

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

Metodo HTTP errato per Grafana

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

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

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

Timeout 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"

Managed Service per Prometheus non va in timeout finché una query non supera 120 secondi, mentre Grafana va in timeout 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 in Grafana visualizzi uno dei seguenti errori, potresti utilizzare un endpoint non supportato:

• "Validation: labels other than name are not supported yet" (Convalida: al momento non sono supportate etichette diverse da name)
• "Modelli [job]: errore durante l'aggiornamento delle opzioni: le etichette diverse da name non sono ancora supportate."

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

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

Per maggiori informazioni sugli endpoint supportati, consulta la pagina relativa alla compatibilità dell'API.

Quota superata

Se visualizzi il seguente errore, 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 consumer "project_number:..."."

Per risolvere il problema, invia una richiesta per aumentare la quota di lettura per l'API Monitoring. Per assistenza, contatta l'Google Cloud assistenza. Per saperne di più sulle quote, consulta la documentazione di Cloud Quotas.

Metriche di più progetti

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

Crea invece un ambito delle metriche di Cloud Monitoring in un progettoGoogle Cloud , il progetto di definizione dell'ambito, che contiene i progetti che vuoi monitorare. Quando configuri l'origine dati Grafana con un progetto di definizione dell'ambito, ottieni l'accesso ai dati di tutti i progetti nell'ambito delle metriche. Per maggiori informazioni, consulta Ambiti di query e metriche.

Nessun tipo di risorsa monitorata specificato

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

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

Puoi specificare un tipo di risorsa monitorata filtrando in base all'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.

Valori non elaborati di contatore, istogramma e riepilogo non corrispondenti tra l'interfaccia utente del raccoglitore e la console Google Cloud

Potresti notare una differenza tra i valori nell'interfaccia utente Prometheus del raccoglitore locale e nella console Google Cloud 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 li ha. Managed Service per Prometheus genera i timestamp di inizio saltando il primo punto importato in qualsiasi serie temporale e convertendolo in un timestamp di inizio. I punti successivi hanno il valore del punto iniziale saltato sottratto dal loro valore per garantire che le tariffe siano corrette. Ciò causa un deficit persistente nel valore grezzo di questi punti.

La differenza tra il numero nell'interfaccia utente del raccoglitore e quello nella consoleGoogle Cloud è uguale al primo valore registrato nell'interfaccia utente del raccoglitore, il che è previsto perché il sistema salta il valore iniziale e lo sottrae dai punti successivi.

Questo è accettabile perché non è necessario eseguire una query per i valori non elaborati delle metriche cumulative; 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 per una query non elaborata, in quanto una serie temporale raggiunge una soglia una sola volta. Tutti gli avvisi e i grafici utili esaminano la variazione o il tasso di variazione del valore.

Il raccoglitore contiene solo circa 10 minuti di dati a livello locale. Le discrepanze nei valori cumulativi grezzi potrebbero verificarsi anche a causa di un ripristino prima dell'orizzonte di 10 minuti. Per escludere questa possibilità, prova a impostare un periodo di ricerca di 10 minuti quando confronti l'interfaccia utente del raccoglitore con la console Google Cloud .

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

Dati del contatore mancanti o istogrammi danneggiati

Il segnale più comune di questo problema è la mancata visualizzazione di dati o la presenza di lacune nei dati quando si esegue una query su una metrica di conteggio semplice (ad esempio, una query PromQL di metric_name_foo). Puoi confermarlo 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 inseriti sono aumentati notevolmente senza alcuna variazione significativa del volume di scraping o che in Cloud Monitoring vengono create nuove metriche con suffissi "unknown" o "unknown:counter".

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

Questi problemi si verificano quando una metrica viene raccolta senza 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 volta come indicatore e una volta come contatore. Il motore di query sceglie quindi se eseguire query sulla metrica del contatore o del misuratore sottostante in base alle funzioni di query che utilizzi.

Sebbene questa euristica funzioni in genere piuttosto bene, può portare a problemi come risultati strani quando si esegue una query su una metrica "unknown:counter" non elaborata. Inoltre, poiché gli istogrammi sono oggetti digitati in modo specifico in Monarch, l'importazione delle tre metriche dell'istogramma richieste come singole metriche del contatore impedisce il funzionamento delle funzioni dell'istogramma. Poiché le metriche di tipo "sconosciuto" vengono importate due volte, se non imposti un TIPO, i campioni importati raddoppiano.

Alcuni motivi comuni per cui TYPE potrebbe non essere impostato sono:

• Configurazione accidentale di un raccoglitore Managed Service per Prometheus come server federato. Il federazione non è supportato quando utilizzi Managed Service per Prometheus. Poiché la federazione elimina intenzionalmente le informazioni TYPE, l'implementazione della federazione causa metriche di tipo "sconosciuto".
• Utilizzo di Prometheus Remote Write in qualsiasi punto della pipeline di importazione. Questo protocollo elimina intenzionalmente anche le informazioni TYPE.
• Utilizzo di una regola di rietichettatura che modifica il nome della metrica. In questo modo, la metrica rinominata viene dissociata dalle informazioni TYPE associate al nome della metrica originale.
• L'esportatore non emette un TYPE per ogni metrica.
• Un problema temporaneo in cui TYPE viene eliminato al primo avvio del raccoglitore.

Per risolvere il problema, segui questi passaggi:

• 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 di raccolta.
• Verifica che il campo # TYPE esista per ogni metrica visitando l'endpoint /metrics.
• Elimina le regole di rietichettatura che modificano il nome di una metrica.
• Elimina eventuali metriche in conflitto con il suffisso "unknown" o "unknown:counter" chiamando DeleteMetricDescriptor.
• Oppure esegui sempre query sui contatori utilizzando rate o un'altra funzione di elaborazione dei contatori.

Puoi anche creare una regola di esclusione delle metriche in Gestione metriche per impedire l'importazione di metriche con il suffisso "sconosciuto" utilizzando l'espressione regolare prometheus.googleapis.com/.+/unknown.*. Se non risolvi il problema sottostante prima di installare questa regola, potresti impedire l'importazione dei dati delle metriche che ti interessano.

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

Se i tuoi 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 sulla configurazione di Grafana per l'utilizzo del servizio gestito come origine dati, consulta Grafana.

Risultati incoerenti di query o regole di avviso che si correggono automaticamente

Potresti notare un pattern in cui le query eseguite in finestre recenti, ad esempio le query eseguite dalle regole di registrazione o di avviso, restituiscono picchi inspiegabili nei dati. Quando esamini il picco eseguendo la query in Grafana o inMetrics Explorere, potresti notare che il picco è scomparso e che i dati appaiono di nuovo normali.

Questo comportamento potrebbe verificarsi più spesso se si verifica una delle seguenti condizioni:

• Esegui costantemente molte query molto simili in parallelo, magari utilizzando regole. Queste query potrebbero differire tra loro solo per un singolo attributo. Ad esempio, potresti eseguire 50 regole di registrazione che differiscono solo per il VALUE per il filtro {foo="VALUE"}, o che differiscono solo per avere valori [duration] diversi per la funzione rate.
• Stai eseguendo query in corrispondenza di time=now senza buffer.
• Stai eseguendo query istantanee come avvisi o regole di registrazione. Se utilizzi una regola di registrazione, potresti notare che l'output salvato presenta il picco, ma il picco non può essere trovato quando esegui una query sui dati non elaborati.
• Stai eseguendo una query su due metriche per creare un rapporto. I picchi sono più pronunciati quando il conteggio delle serie temporali è basso nella query del numeratore o del denominatore.
• I dati delle metriche si trovano in regioni Google Cloud più grandi, come us-central1 o us-east4.

Esistono alcune possibili cause di picchi temporanei in questi tipi di query:

• (Causa più comune) Tutte le query simili e parallele richiedono dati dallo stesso insieme di nodi Monarch, consumando una grande quantità di memoria su ogni nodo nel complesso. Quando Monarch dispone di risorse disponibili sufficienti in una regione cloud, le tue query funzionano. Quando Monarch è sotto pressione delle risorse in una regione cloud, ogni nodo limita le query, dando la precedenza agli utenti che consumano più memoria su ogni nodo. Quando Monarch avrà nuovamente risorse sufficienti, le tue query funzioneranno di nuovo. Queste query potrebbero essere indicatori di livello del servizio generati automaticamente da strumenti come Sloth.
• Hai dati in ritardo e le tue query non lo tollerano. Sono necessari circa 3-7 secondi prima che i dati appena scritti possano essere interrogati, escludendo la latenza di rete e qualsiasi ritardo causato dalla pressione delle risorse all'interno del tuo ambiente. Se la query non prevede un ritardo o un offset per tenere conto dei dati in ritardo, potresti eseguire una query inconsapevolmente su un periodo in cui disponi solo di dati parziali. Una volta arrivati i dati, i risultati della query sembrano normali.
• Monarch potrebbe presentare una leggera incoerenza durante il salvataggio dei dati in repliche diverse. Il motore di query tenta di scegliere la replica di "migliore qualità", ma se query diverse scelgono repliche diverse con set di dati leggermente diversi, è possibile che i risultati varino leggermente tra le query. Si tratta di un comportamento previsto del sistema e gli avvisi devono essere tolleranti a queste lievi discrepanze.
• Un'intera regione Monarch potrebbe non essere temporaneamente disponibile. Se una regione non è raggiungibile, il motore di query la considera come se non fosse mai esistita. Una volta che la regione diventa disponibile, i risultati della query continuano a restituire i dati della regione.

Per tenere conto di queste possibili cause principali, devi assicurarti che le query, le regole e gli avvisi seguano queste best practice:

• Consolida regole e avvisi simili in un'unica regola che aggrega in base alle etichette anziché avere regole separate per ogni permutazione dei valori delle etichette. Se si tratta di regole di avviso, puoi utilizzare le notifiche basate sulle etichette per indirizzare gli avvisi dalla regola aggregata anziché configurare regole di routing individuali per ogni avviso.

  Ad esempio, se hai un'etichetta foo con i valori bar, baz e qux, invece di avere una regola separata per ogni valore dell'etichetta (una con la query sum(metric{foo="bar"}), una con la query sum(metric{foo="baz"}) e una con la query sum(metric{foo="qux"})), crea una singola regola che aggrega i dati di quell'etichetta e, se vuoi, filtra in base ai valori dell'etichetta che ti interessano (ad esempio sum by (foo) metric{foo=~"bar|baz|qux"}).

  Se la tua metrica ha due etichette e ogni etichetta ha 50 valori e hai una regola separata per ogni combinazione di valori delle etichette e le query delle regole sono un rapporto, ogni periodo avvii 50 x 50 x 2 = 5000 query Monarch parallele che colpiscono lo stesso insieme di nodi Monarch. Nel complesso, queste 5000 query parallele consumano una grande quantità di memoria su ogni nodo Monarch, il che aumenta il rischio di limitazione quando una regione Monarch è sotto pressione delle risorse.

  Se invece utilizzi le aggregazioni per consolidare queste regole in un'unica regola che è un rapporto, ogni periodo avvii solo due query Monarch parallele. Queste due query parallele consumano molta meno memoria nel complesso rispetto alle 5000 query parallele e il rischio di limitazione è molto inferiore.

• Se la regola esamina un periodo superiore a un giorno, eseguila meno frequentemente di una volta al minuto. Le query che accedono a dati più vecchi di 25 ore vengono inviate al repository di dati su disco Monarch. Queste query del repository sono più lente e consumano più memoria rispetto alle query sui dati più recenti, il che aggrava eventuali problemi di consumo di memoria derivanti dalle regole di registrazione parallela.

  Valuta la possibilità di eseguire questi tipi di query una volta all'ora anziché una volta al minuto. L'esecuzione di una query di un giorno ogni minuto comporta una variazione di solo 1/1440 = 0,07% nel risultato di ogni periodo, una variazione trascurabile. L'esecuzione di una query di un giorno ogni ora comporta una variazione del 4% del risultato in ogni periodo, che è una dimensione del segnale più pertinente. Se vuoi ricevere un avviso in caso di modifiche recenti ai dati, puoi eseguire una regola diversa con un periodo di analisi più breve (ad esempio 5 minuti) una volta al minuto.

• Utilizza il campo for: nelle regole per tollerare risultati anomali temporanei. Il campo for: impedisce l'attivazione dell'avviso a meno che la condizione di avviso non sia stata soddisfatta per almeno la durata configurata. Imposta questo campo in modo che sia il doppio della durata dell'intervallo di valutazione delle regole o più lungo.

  L'utilizzo del campo for: è utile perché i problemi temporanei spesso si risolvono da soli, il che significa che non si verificano in cicli di avvisi consecutivi. Se noti un picco e questo picco persiste in più timestamp e in più cicli di avviso, puoi essere più sicuro che si tratti di un picco reale e non di un problema temporaneo.

• Utilizza il modificatore offset in PromQL per ritardare la valutazione della query in modo che non operi sul periodo di dati più recente. Esamina l'intervallo di campionamento e l'intervallo di valutazione delle regole e identifica quello più lungo. Idealmente, l'offset della query è almeno il doppio della lunghezza dell'intervallo più lungo. Ad esempio, se invii dati ogni 15 secondi ed esegui regole ogni 30 secondi, esegui l'offset delle query di almeno 1 minuto. Un offset di 1 minuto fa sì che le regole utilizzino un timestamp finale di almeno 60 secondi, il che crea un buffer per l'arrivo dei dati in ritardo prima dell'esecuzione della regola.

  Si tratta di una best practice di Cloud Monitoring (tutti gli avvisi PromQL gestiti hanno almeno un offset di 1 minuto) e di una best practice di Prometheus.

• Raggruppa i risultati in base all'etichetta location per isolare i potenziali problemi relativi alle regioni non disponibili. L'etichetta con la regione Google Cloud potrebbe essere chiamata zone o region in alcune metriche di sistema.

  Se non raggruppi per regione e una regione non è più disponibile, i risultati sembrano diminuire improvvisamente e potresti notare un calo anche nei risultati storici. Se raggruppi per regione e una regione non è più disponibile, non ricevi risultati da quella regione, ma i risultati delle altre regioni non vengono interessati.

• Se il rapporto è una percentuale di successo (ad esempio, risposte 2xx sul totale delle risposte), valuta la possibilità di trasformarlo in una percentuale di errore (ad esempio, risposte 4xx+5xx sul totale delle risposte). I rapporti di errore sono più tolleranti ai dati incoerenti, in quanto un calo temporaneo dei dati rende il risultato della query inferiore alla soglia e pertanto non attiva l'avviso.

• Se possibile, suddividi una query del rapporto o una regola di registrazione in query separate per numeratore e denominatore. Si tratta di una best practice di Prometheus. L'utilizzo dei rapporti è valido, ma poiché la query nel numeratore viene eseguita indipendentemente dalla query nel denominatore, l'utilizzo dei rapporti può amplificare l'impatto di problemi temporanei:

  • Se Monarch limita la query del numeratore, ma non quella del denominatore, potresti visualizzare risultati inaspettatamente bassi. Se Monarch limita la query del denominatore, ma non quella del numeratore, potresti visualizzare risultati inaspettatamente elevati.
  • Se esegui query su periodi di tempo recenti e disponi di dati in ritardo, è possibile che una query nel rapporto venga eseguita prima dell'arrivo dei dati e l'altra query nel rapporto venga eseguita dopo l'arrivo dei dati.
  • Se uno dei due lati del rapporto è composto da un numero relativamente ridotto di serie temporali, gli errori vengono amplificati. Se il numeratore e il denominatore hanno ciascuno 100 serie temporali e Monarch non restituisce una serie temporale nella query del numeratore, è probabile che noterai la differenza dell'1%. Se il numeratore e il denominatore hanno ciascuno 1.000.000 di serie temporali e Monarch non restituisce una serie temporale nella query del numeratore, è improbabile che tu noti la differenza dello 0,0001%.

• Se i dati sono sparsi, utilizza una durata del tasso più lunga nella query. Se i tuoi dati arrivano ogni 10 minuti e la tua query utilizza rate(metric[1m]), la query esamina i dati solo per 1 minuto e a volte ottieni risultati vuoti. Come regola generale, imposta [duration] in modo che sia almeno quattro volte l'intervallo di scraping.

  Per impostazione predefinita, le query del misuratore esaminano i dati degli ultimi 5 minuti. Per farli tornare più indietro, utilizza una funzione x_over_time valida, ad esempio last_over_time.

Questi consigli sono pertinenti soprattutto se visualizzi risultati delle query incoerenti quando esegui query sui dati recenti. Se riscontri questo problema quando interroghi dati più vecchi di 25 ore, potrebbe esserci un problema tecnico con Monarch. In questo caso, contatta l'assistenza clienti Google Cloud per indagare sul problema.

Importare dashboard Grafana

Per informazioni sull'utilizzo e la risoluzione dei problemi dell'importatore di dashboard, consulta Importare dashboard Grafana in Cloud Monitoring.

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

Problemi lato importazione

I problemi lato importazione possono essere correlati alla 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

Sui cluster GKE Autopilot, puoi eseguire i seguenti comandi:

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

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

La funzionalità di stato target può aiutarti a eseguire il debug del target di scraping. Per ulteriori informazioni, consulta Informazioni sullo stato della destinazione.

Lo stato dell'endpoint è mancante o troppo vecchio

Se hai attivato la funzionalità di stato 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 PodMonitoring o ClusterPodMonitoring non hanno generato target validi.

Problemi simili possono anche causare l'assegnazione al campo Status.Endpoint Statuses.Last Update Time di un valore più vecchio di qualche minuto più l'intervallo di scraping.

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

La frazione di raccoglitori è inferiore a 1

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

Se il campo Collectors Fraction ha un valore diverso da 1, uno o più collettori non sono raggiungibili e le metriche in uno qualsiasi di questi nodi potrebbero non essere sottoposte a scraping. Assicurati che tutti i raccoglitori 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 ha un aspetto leggermente diverso:

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

Puoi esaminare i singoli pod di raccolta (ad esempio, un pod di raccolta denominato collector-12345) con il seguente comando:

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

Sui cluster GKE Autopilot, esegui questo comando:

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

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

Se i raccoglitori 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"

Sui 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 operatore denominato gmp-operator-12345) con il seguente comando:

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

Sui 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 di destinazione, 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 una o più delle tue destinazioni.

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

Endpoint di scraping non autorizzato

Se visualizzi uno dei seguenti errori e il tuo target di scraping richiede l'autorizzazione, il tuo raccoglitore 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 Configurazione di un endpoint di scraping autorizzato.

Quota superata

Se visualizzi il seguente errore, hai superato la quota di importazione per l'API Cloud Monitoring:

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

Questo errore si verifica più comunemente quando viene visualizzato per la prima volta il servizio gestito. La quota predefinita si esaurisce a 100.000 campioni al secondo importati.

Per risolvere il problema, invia una richiesta per aumentare la quota di importazione per l'API Monitoring. Per assistenza, contatta l'Google Cloud assistenza. Per saperne di più sulle quote, consulta la documentazione di Cloud Quotas.

Autorizzazione mancante sull'account di servizio predefinito del nodo

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

• "execute query: Error querying Prometheus: client_error: client error: 403"
• "Readiness probe failed: HTTP probe failed with statuscode: 503" (Controllo di preparazione non riuscito: controllo HTTP non riuscito con codice di stato: 503)
• "Error querying Prometheus instance" (Errore durante l'interrogazione dell'istanza Prometheus)

La raccolta gestita e lo strumento di valutazione delle regole gestito in Managed Service per Prometheus utilizzano entrambi ilaccount di serviziot 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 l'errore della raccolta e della valutazione delle regole.

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

• Identifica il nome del nodo Compute Engine sottostante, quindi esegui il comando seguente:

  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 Service account configurato in modo errato.

• Vai alla VM sottostante nel cluster e controlla la configurazione delaccount di serviziot 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, poi 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 API Stackdriver Monitoring con accesso completo.

È anche possibile che il sincronizzatore dell'origine dati o la UI 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 viene eseguita la query.

Account di servizio configurato in modo errato

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

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

Per verificare che il account di servizio disponga delle autorizzazioni corrette, procedi 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 del account di servizio nell'elenco delle entità. Verifica che il nome delaccount di serviziot sia scritto correttamente. Poi fai clic su Modifica.

3. Seleziona il campo Ruolo, poi fai clic su Attualmente utilizzato e cerca il ruolo Scrittore metriche di monitoraggio o Editor Monitoring. Se il account di servizio non dispone di uno di questi ruoli, concedigli il ruolo Scrittore metriche Monitoring (roles/monitoring.metricWriter).

Se esegui Kubernetes non GKE, devi trasmettere esplicitamente le credenziali sia al raccoglitore che al valutatore di regole. Devi ripetere le credenziali nelle sezioni rules e collection. Per maggiori informazioni, vedi Fornire le credenziali in modo esplicito (per la raccolta) o Fornire le credenziali in modo esplicito (per le regole).

Gli account di servizio sono spesso limitati a un singolo progetto. Google Cloud L'utilizzo di un account di serviziot per scrivere dati delle metriche per più progetti, ad esempio, quando un valutatore di regole gestito esegue query su un ambito delle metriche multi-progetto, può causare questo errore di autorizzazione. Se utilizzi il service account predefinito, valuta la possibilità di configurare un account di servizio dedicato in modo da poter aggiungere in sicurezza l'autorizzazione monitoring.timeSeries.create per più progetti. Se non puoi concedere questa autorizzazione, puoi utilizzare l'assegnazione di nuove etichette alle metriche per riscrivere 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 il valutatore di regole.

Configurazione dello scraping non valida

Se visualizzi il seguente errore, significa che PodMonitoring o ClusterPodMonitoring non è formato correttamente:

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

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

Webhook di controllo dell'ammissione impossibile da analizzare o configurazione client HTTP non valida

Nelle versioni di Managed Service per Prometheus precedenti alla 0.12, potresti visualizzare un errore simile al seguente, correlato all'inserimento di secret nello spazio dei nomi non predefinito:

• "admission webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com" denied the request: invalid definition for endpoint with index 0: unable to parse or invalid Prometheus HTTP client config: must use namespace "my-custom-namespace", got: "default""

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

Problemi con intervalli di scraping e timeout

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

kubectl -n gmp-system logs ds/collector prometheus

Sui cluster GKE Autopilot, esegui questo comando:

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

Cerca questo messaggio:

• "scrape timeout greater than scrape interval for scrape config with job name "PodMonitoring/gmp-system/example-app/go-metrics""

Per risolvere il problema, imposta il valore dell'intervallo di scraping in modo che sia uguale o superiore al valore del timeout di scraping.

Manca TYPE nella metrica

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

• "no metadata found for metric name "{metric_name}"" (nessun metadato trovato per il nome della metrica "{metric_name}")

Per verificare che il problema sia dovuto alla mancanza di informazioni sul tipo, controlla l'output dell'applicazione di esportazione./metrics 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 visualizzi uno dei seguenti errori, potresti avere più di un raccoglitore che tenta di scrivere nella stessa serie temporale:

• "Impossibile scrivere una o più serie temporali: uno o più punti sono stati scritti con una frequenza superiore 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ù punti specificati avevano un orario di fine precedente a quello del 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ù raccoglitori che tentano di scrivere dati nella stessa serie temporale, causando questo errore.

  Per risolvere il problema, disattiva i raccoglitori duplicati riducendo il numero di repliche a 1 o utilizza il metodo di alta affidabilità supportato.

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

  Per risolvere il problema, elimina la regola che lo causa. Spesso puoi farlo eliminando la regola metricRelabeling che utilizza l'azione labeldrop. Puoi identificare la regola problematica commentando tutte le regole di riassegnazione e poi ripristinandole una alla volta finché non si ripresenta l'errore.

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

Superamento del limite al numero di etichette

Se visualizzi il seguente errore, potresti aver definito 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 di metrica abbia più set indipendenti di chiavi di etichetta per l'intero ciclo di vita della metrica. Cloud Monitoring impone un limite al numero di etichette per ogni metrica. Per ulteriori informazioni, consulta i limiti per le metriche definite dall'utente.

Nota: il numero di etichette (chiamate anche nomi etichette, chiavi etichette o dimensioni) è diverso dalla cardinalità. Cardinalità si riferisce al numero di combinazioni di valori di etichetta unici in tutte le etichette.

Per risolvere il problema, segui questi tre passaggi:

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

   • Puoi utilizzare il widget Explorer API nella pagina metricDescriptors.list per chiamare il metodo. Per ulteriori informazioni, consulta Explorer API. Per esempi, consulta Elenca tipi di metriche e risorse.

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

3. Elimina il descrittore della metrica per questa metrica (il che comporta la perdita di dati), in modo che possa essere ricreato con un insieme di etichette più piccolo e stabile. A tale scopo, puoi utilizzare il metodo metricDescriptors.delete.

Le cause più comuni del problema sono:

• Raccolta di metriche da esportatori o applicazioni che collegano etichette dinamiche alle metriche. Ad esempio, cAdvisor autogestito con etichette dei container e variabili di ambiente aggiuntive o l'agente DataDog, che inserisce annotazioni dinamiche.

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

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

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

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

Se visualizzi il seguente errore, 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."

Questo limite di frequenza viene in genere raggiunto solo durante l'integrazione iniziale con Managed Service 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 dei punti dati. Questo limite di frequenza si applica solo quando vengono create metriche mai viste prima o quando vengono aggiunte nuove etichette a metriche esistenti.

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

Limiti al numero di descrittori delle metriche

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

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

Per impostazione predefinita, questo limite è impostato su 25.000. Anche se questa quota può essere aumentata su richiesta se le tue metriche sono ben formate, è molto più probabile che tu raggiunga questo limite perché stai inserendo nomi di metriche malformati nel sistema.

Prometheus ha un modello di dati dimensionale in cui informazioni come il nome del cluster o dello spazio dei nomi devono essere codificate come valore dell'etichetta. Quando le informazioni dimensionali sono invece incorporate nel nome della metrica, 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 e aggregare i dati in cluster, spazi dei nomi o servizi.

Né Cloud Monitoring né Managed Service per Prometheus supportano metriche non dimensionali, come quelle formattate per StatsD o Graphite. Sebbene la maggior parte degli esportatori Prometheus sia configurata correttamente fin da subito, alcuni esportatori, come l'esportatore StatsD, l'esportatore Vault o Envoy Proxy fornito con Istio, devono essere configurati esplicitamente per utilizzare le etichette anziché incorporare le informazioni nel nome della metrica. Esempi di nomi di metriche non validi includono:

• 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 metriche:

   Vai a Gestione 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 visualizzare un numero elevato di metriche non attive.
4. Seleziona "Non attivi" nel pannello Filtri rapidi, scorri l'elenco e cerca pattern.
5. Seleziona "Attivo" nel riquadro Filtri rapidi, ordina per Volume fatturabile di campioni in ordine decrescente, scorri l'elenco e cerca pattern.
6. Ordina per Volume fatturabile dei campioni in ordine crescente, scorri l'elenco e cerca pattern.

In alternativa, puoi confermare questo problema utilizzando Metrics Explorer:

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

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

   Vai a Esplora metriche

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

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

Una volta identificati i pattern che indicano metriche non valide, puoi mitigare il problema correggendo l'esportatore all'origine ed eliminando i descrittori delle metriche problematiche.

Per evitare che questo problema si ripresenti, devi prima configurare l'esportatore pertinente in modo che non emetta più metriche non valide. 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 ispezionando i nomi delle metriche esportate.

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

Per le campagne di breve durata mancano alcune metriche

Google Cloud Managed Service per Prometheus è stato implementato e non sono presenti 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 la durata tipica del job:

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

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

2. Se la durata di esecuzione è inferiore a cinque minuti, il job non viene eseguito abbastanza a lungo per consentire lo scraping coerente dei dati delle metriche.

   Per risolvere il problema, prova quanto segue:

   • Configura il job in modo che non venga chiuso fino a quando non siano trascorsi almeno cinque minuti dall'inizio.

   • 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 valori di distribuzione anziché raccogliere dati delle metriche. Questo approccio è suggerito quando i dati vengono pubblicati a una velocità ridotta. Per ulteriori informazioni, consulta Metriche basate su log.

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

Problemi con il ritiro 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 emettano metriche all'endpoint /metrics sulla porta 9121, puoi eseguire il port forwarding nel seguente modo:

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

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

• Controlla se puoi 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 raccoglitore gestito sia in grado di eseguire lo scraping dell'esportatore esaminando l'interfaccia web di Prometheus esposta dal raccoglitore.

  1. Identifica il raccoglitore gestito in esecuzione sullo stesso nodo in cui è in esecuzione l'esportatore. Ad esempio, se l'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 raccoglitore gestito in esecuzione sullo stesso nodo:

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

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

     kubectl port-forward POD_NAME -n gmp-system 19090
     

  3. Vai all'URL localhost:19090/targets per accedere all'interfaccia web. Se l'esportatore è elencato tra i target, il raccoglitore gestito esegue lo scraping dell'esportatore.

Errori di esaurimento della memoria (OOM) del raccoglitore

Se utilizzi la raccolta gestita e riscontri errori di memoria insufficiente (OOM) sui tuoi raccoglitori, valuta la possibilità di attivare la scalabilità automatica pod verticale.

Errori di memoria insufficiente (OOM) dell'operatore

Se utilizzi la raccolta gestita e riscontri errori di memoria insufficiente (OOM) sull'operatore, valuta la possibilità di disattivare la funzionalità di stato della destinazione. La funzionalità di stato della destinazione può causare problemi di rendimento dell'operatore nei cluster più grandi.

Troppe serie temporali o aumento delle risposte 503 e degli errori di scadenza del contesto, soprattutto durante il picco di carico

Potresti riscontrare questo problema anche se visualizzi il seguente messaggio di errore:

• "La risorsa monitorata (abcdefg) ha troppe serie temporali (metriche Prometheus)"

"Context deadline exceeded" è un errore 503 generico restituito da Monarch per qualsiasi problema lato importazione che non abbia una causa specifica. È previsto un numero molto ridotto di errori "context deadline exceeded" con il normale utilizzo del sistema.

Tuttavia, potresti notare un pattern in cui gli errori "context deadline exceeded" aumentano e influiscono in modo significativo sull'importazione dei dati. Una potenziale causa principale è che potresti impostare in modo errato le etichette target. Ciò è più probabile se sono vere le seguenti condizioni:

• Gli errori "Scadenza contesto superata" hanno un andamento ciclico, in cui aumentano durante i periodi di carico elevato per te o per la regione Google Cloud specificata dall'etichetta location.
• Man mano che aggiungi più volume di metriche al servizio, visualizzi più errori.
• Stai utilizzando statsd_exporter per Prometheus, Envoy per Istio, l'esportatore SNMP, Prometheus Pushgateway, kube-state-metrics o hai un altro esportatore simile che intermedia e segnala le metriche per conto di altre risorse in esecuzione nel tuo ambiente. Il problema si verifica solo per le metriche emesse da questo tipo di esportatore.
• Noti che le metriche interessate tendono ad avere la stringa localhost nel valore dell'etichetta instance oppure che ci sono pochissimi valori per l'etichetta instance.
• Se hai accesso all'interfaccia utente di query del raccoglitore Prometheus nel cluster, puoi vedere che le metriche vengono raccolte correttamente.

Se questi punti sono veri, è probabile che l'esportatore abbia configurato in modo errato le etichette delle risorse in modo da entrare in conflitto con i requisiti di Monarch.

Monarch si adatta memorizzando i dati correlati insieme in un target. Una destinazione per Managed Service per Prometheus è definita dal tipo di risorsa prometheus_target e dalle etichette project_id, location, cluster, namespace, job e instance. Per saperne di più su queste etichette e sul comportamento predefinito, consulta Etichette riservate nella raccolta gestita o Etichette riservate nella raccolta autogestita.

Di queste etichette, instance è il campo di destinazione di livello più basso ed è quindi il più importante da compilare correttamente. L'archiviazione e l'interrogazione efficienti delle metriche in Monarch richiedono target relativamente piccoli e diversi, idealmente delle dimensioni di una VM o di un container tipici. Quando esegui Managed Service per Prometheus in scenari tipici, il comportamento predefinito open source integrato nel raccoglitore di solito sceglie valori appropriati per le etichette job e instance, motivo per cui questo argomento non è trattato altrove nella documentazione.

Tuttavia, la logica predefinita potrebbe non funzionare quando esegui un esportatore che segnala metriche per conto di altre risorse nel cluster, ad esempio statsd_exporter. Anziché impostare il valore di instance sull'IP:porta della risorsa che emette la metrica, il valore di instance viene impostato su IP:porta di statsd_exporter stesso. Il problema può essere aggravato dall'etichetta job, in quanto, oltre a non essere correlata al pacchetto di metriche o al servizio, manca anche di diversità perché è impostata su statsd-exporter.

In questo caso, tutte le metriche provenienti da questo esportatore all'interno di un determinato cluster e spazio dei nomi vengono scritte nello stesso target Monarch. Man mano che questo target aumenta, le scritture iniziano a non riuscire e vengono visualizzati un numero maggiore di errori 503 "Scadenza del contesto superata".

Puoi verificare che questo stia accadendo contattando l&#39assistenza clienti Google Cloudd e chiedendo di controllare i "log di ricovero di Monarch Quarantiner". Includi eventuali valori noti per le sei etichette riservate nel tuo ticket. Assicurati di segnalare il progetto Google Cloud che invia i dati, non il progetto Google Cloud dell'ambito delle metriche.

Per risolvere il problema, devi modificare la pipeline di raccolta in modo che utilizzi etichette target più diverse. Alcune potenziali strategie, elencate in ordine di efficacia, includono:

• Anziché eseguire un esportatore centrale che segnala le metriche per conto di tutte le VM o i nodi, esegui un esportatore separato per ogni VM come agente del nodo o eseguendo il deployment dell'esportatore come DaemonSet di Kubernetes. Per evitare di impostare l'etichetta instance su localhost, non eseguire l'esportatore sullo stesso nodo del raccoglitore.
  • Se, dopo lo sharding dell'esportatore, hai ancora bisogno di una maggiore diversità dei target, esegui più esportatori su ogni VM e assegna logicamente diversi set di metriche a ogni esportatore. Poi, invece di rilevare il job utilizzando il nome statico statsd-exporter, utilizza un nome del job diverso per ogni insieme logico di metriche. Le istanze con valori diversi per job vengono assegnate a target diversi in Monarch.
  • Se utilizzi kube-state-metrics, utilizza lo sharding orizzontale integrato per creare una maggiore diversità dei target. Altri esportatori potrebbero avere funzionalità simili.
• Se utilizzi OpenTelemetry o la raccolta autogestita, utilizza una regola di rietichettatura per modificare il valore di instance dall'IP:porta o dal nome dell'esportatore all'IP:porta o al nome univoco della risorsa che genera le metriche. È molto probabile che tu stia già acquisendo l'IP:Port o il nome della risorsa di origine come etichetta delle metriche. Devi anche impostare il campo honor_labels su true nella configurazione di Prometheus o OpenTelemetry.
• Se utilizzi OpenTelemetry o la raccolta autogestita, utilizza una regola di rietichettatura con una funzione hashmod per eseguire più job di scraping sullo stesso esportatore e assicurati che venga scelta un'etichetta di istanza diversa per ogni configurazione di scraping.

Nessun errore e nessuna metrica

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

Per verificare 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 volerci qualche minuto), il problema riguarda la configurazione o l'esportatore dello scraping.

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

• PodMonitoring fa riferimento a una porta valida.

• La specifica di deployment dell'esportatore contiene porte denominate correttamente.

• I selettori (più comunemente 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 di cui vuoi eseguire lo scraping. Non installare risorse o applicazioni personalizzate nello spazio dei nomi gmp-system o gke-gmp-system.

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

• Non stai utilizzando un insieme di filtri che causa la rimozione di tutti i dati. Fai molta attenzione a non avere filtri in conflitto quando utilizzi un filtro collection nella risorsa OperatorConfig.

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

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

Firewall

Un firewall può causare problemi sia di importazione che di query. Il firewall deve essere configurato per consentire le richieste POST e 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 temporaneo e si risolve dopo qualche minuto. Di solito è causato dalla rimozione di una regola di riassegnazione dell'etichetta che interessa molte metriche diverse. La rimozione causa la formazione di una coda di aggiornamenti ai descrittori delle metriche nel tuo progetto. L'errore scompare quando la coda viene elaborata.

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

Query bloccate e annullate da Monarch

Se visualizzi il seguente errore, 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 impone un limite rigido al numero di query di un progetto che possono essere eseguite contemporaneamente in Monarch. Con l'utilizzo tipico di Prometheus, le query devono essere rapide e questo limite non deve mai essere raggiunto.

Potresti raggiungere questo limite se esegui 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 in genere vengono eseguite più lentamente rispetto a quelle che richiedono meno di 25 ore di dati e più lungo è il periodo di ricerca della query, più lenta sarà l'esecuzione della query.

In genere questo problema si verifica quando vengono eseguite molte regole di ricerca a lungo termine in modo inefficiente. Ad esempio, potresti avere molte regole che vengono eseguite una volta al minuto e richiedono una tariffa di 4 settimane. Se l'esecuzione di ciascuna di queste regole richiede molto tempo, alla fine potrebbe causare un backup delle query in attesa di esecuzione per il tuo progetto, il che a sua volta fa sì che Monarch limiti le query.

Per risolvere il problema, devi aumentare l'intervallo di valutazione delle regole di analisi a lungo termine in modo che non vengano eseguite ogni minuto. Eseguire una query per una tariffa di 4 settimane ogni minuto è inutile: in 4 settimane ci sono 40.320 minuti, quindi ogni minuto non ti fornisce quasi nessun segnale aggiuntivo (i tuoi dati cambiano al massimo di 1/40.320). L'utilizzo di un intervallo di valutazione di 1 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 a esecuzione prolungata eseguite troppo spesso, il problema dovrebbe risolversi da solo.

Tipi di valori incompatibili

Se visualizzi il seguente errore durante l'importazione o la query, significa che le metriche presentano un'incompatibilità del 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"
• "Impossibile 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 durante l'importazione, in quanto Monarch non supporta la scrittura di dati di tipo DOUBLE in metriche di tipo INT64 né la scrittura di dati di tipo INT64 in metriche di tipo DOUBLE. Potresti visualizzare questo errore anche quando esegui query utilizzando un ambito delle metriche multiprogetto, 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 raccoglitori OpenTelemetry segnalano dati ed è più probabile che si verifichi se OpenTelemetry (utilizzando l'esportatore googlemanagedprometheus) e Prometheus segnalano dati 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 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 versione precedente della libreria delle metriche.
• Stai raccogliendo la metrica target_info utilizzando sia Prometheus che OpenTelemetry. Prometheus raccoglie questa metrica come DOUBLE, mentre OpenTelemetry la raccoglie come INT64. Ora i tuoi raccoglitori scrivono due tipi di valori nella stessa metrica dello stesso progetto e solo il raccoglitore che ha creato per primo il descrittore della metrica ha esito positivo.
• Stai raccogliendo target_info utilizzando OpenTelemetry come INT64 in un progetto e stai raccogliendo target_info utilizzando Prometheus come DOUBLE in un altro progetto. L'aggiunta di entrambe le metriche allo stesso ambito delle metriche e l'esecuzione di query su questa metrica tramite l'ambito delle metriche causano un'unione non valida tra tipi di valori delle metriche incompatibili.

Questo problema può essere risolto forzando tutti i tipi di valori delle metriche su DOUBLE nel seguente modo:

1. Riconfigura i raccoglitori OpenTelemetry per forzare tutte le metriche a essere DOUBLE attivando il flag feature-gate exporter.googlemanagedprometheus.intToDouble.
2. Elimina tutti i descrittori di metriche INT64 e lascia che vengano ricreati come DOUBLE. Puoi utilizzare lo delete_metric_descriptors.go script 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.