Questo documento descrive alcuni problemi che potresti riscontrare durante l'utilizzo di Google Cloud Managed Service per Prometheus e fornisce informazioni sulla diagnostica e sulla risoluzione dei problemi.
Hai configurato Managed Service per Prometheus, ma non visualizzi i dati delle metriche in Grafana o nella UI di Prometheus. In generale, la causa potrebbe essere una delle seguenti:
Un problema relativo alla query, per cui i dati non possono essere letti. I problemi lato query sono spesso causati da autorizzazioni errate nell'account di servizio che leggono i dati o da errori di configurazione di Grafana.
Un problema relativo all'importazione, per cui non vengano inviati dati. I problemi sul lato importazione possono essere causati da problemi di configurazione degli account di servizio, dei raccoglitori o della valutazione delle regole.
Per determinare se il problema è sul lato importazione o sul lato 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 con le impostazioni di Grafana.
Per visualizzare questa pagina:
Utilizza il selettore di progetti della console Google Cloud per selezionare il progetto per il quale non visualizzi dati.
Nella console Google Cloud, vai a Monitoring o utilizza il seguente pulsante:
Nel riquadro di navigazione di Monitoring, fai clic su
Metrics Explorer.Seleziona la scheda PromQL.
Inserisci la query seguente:
up
Fai clic su Esegui query.
Se eseguite una query sulla metrica up e visualizzate risultati, il problema riguarda
la parte relativa alla query. Per informazioni sulla risoluzione di questi problemi, consulta
Problemi lato query.
Se eseguite una query sulla metrica up e non visualizzate risultati, il problema riguarda l'importazione. Per informazioni sulla risoluzione di questi problemi, consulta
Problemi lato importazione.
Un firewall può anche causare problemi di importazione e di query; per ulteriori informazioni, consulta la sezione Firewall.
Problemi lato query
La causa della maggior parte dei problemi lato query è una delle seguenti:
- Autorizzazioni o credenziali errate per gli account di servizio.
- Configurazione errata di Workload Identity, se questa funzionalità è abilitata nel cluster. Per ulteriori informazioni, consulta la pagina Configurare un account di servizio per Workload Identity.
Per iniziare, segui questi passaggi:
Confronta attentamente la tua configurazione con le istruzioni di configurazione per le query.
Se utilizzi Workload Identity, verifica che il tuo account di servizio disponga delle autorizzazioni corrette procedendo come segue:
Nella console Google Cloud, vai a IAM e amministrazione o utilizza il seguente pulsante:
Identifica il nome dell'account di servizio nell'elenco delle entità. Verifica che il nome dell'account di servizio sia scritto correttamente. Fai clic su edit Modifica.
Seleziona il campo Ruolo, quindi fai clic su Utilizzato attualmente e cerca il ruolo Visualizzatore Monitoring. Se l'account di servizio non ha questo ruolo, aggiungilo ora.
Se il problema persiste, valuta le seguenti possibilità:
Secret configurati in modo errato o digitato in modo errato
Se visualizzi uno dei seguenti problemi, è possibile che il secret sia mancante o digitato in modo errato:
Uno di questi errori "non consentiti" nella UI di Prometheus:
- "Avviso: stato della risposta imprevista durante il recupero dell'ora del server: vietato"
- "Avviso: errore durante il recupero dell'elenco delle metriche: stato della risposta imprevisto durante il recupero dei nomi delle metriche: vietato"
Un messaggio simile a questo nei log:
"non è in grado di leggere il file delle credenziali: apri /gmp/key.json: questo file o directory non esiste"
Per risolvere questi errori, prova quanto segue:
Verifica di aver impostato l'ID progetto dell'interfaccia utente di frontend con lo stesso ambito delle metriche o il progetto per il quale il tuo account di servizio dispone delle credenziali.
Verifica l'ID progetto che hai specificato per tutti i flag
--query.project-id.Verifica che il tuo account di servizio abbia il ruolo Visualizzatore Monitoring.
Verifica di aver impostato l'ID progetto corretto durante il deployment dell'UI di frontend e di non averlo lasciato sulla stringa letterale
PROJECT_ID.Se utilizzi Workload Identity, verifica di non aver sbagliato a digitare la chiave o le credenziali dell'account e verifica di averlo associato allo spazio dei nomi corretto.
Se installi il tuo secret, assicurati che sia presente:
kubectl get secret gmp-test-sa -o json | jq '.data | keys'
Verifica che il secret sia montato correttamente:
kubectl get deploy frontend -o json | jq .spec.template.spec.volumes kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].volumeMounts
Assicurati che il secret venga passato correttamente al container:
kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].args
Metodo HTTP non corretto per Grafana
Se viene visualizzato il seguente errore API di Grafana, Grafana è configurato per inviare una richiesta POST anziché una richiesta GET:
- "{"status":"error","errorType":"bad_data","error":"nessun parametro fornito[] fornito"}%"
Per risolvere il problema, configura Grafana in modo che utilizzi una richiesta GET seguendo le istruzioni riportate in Configurare un'origine dati.
Timeout in query di grandi dimensioni o a lunga esecuzione
Se viene visualizzato il seguente errore in Grafana, il timeout di query predefinito è troppo basso:
- "Pubblica "http://frontend.gmp-test.svc:9090/api/v1/query_range": net/http: timeout pending response intestazioni"
Per impostazione predefinita, Managed Service per Prometheus non scade finché una query non supera i 120 secondi, mentre Grafana scade dopo 30 secondi. Per risolvere il problema, aumenta i timeout in Grafana a 120 secondi seguendo le istruzioni in Configurare un'origine dati.
Errori di convalida delle etichette
Se visualizzi uno dei seguenti errori in Grafana, è possibile che tu stia utilizzando un endpoint non supportato:
- "Convalida: le etichette diverse da nome non sono ancora supportate"
- "Definizione del modello [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 fa sì che le query che utilizzano la variabile label_values($label) in Grafana non vadano a buon fine.
Utilizza invece il modulo label_values($metric, $label). Questa query è consigliata perché limita i valori delle etichette restituite dalla 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 compatibilità dell'API.
Quota superata
Se vedi 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 serie temporali" e limite "Query serie temporali al minuto" del servizio "monitoring.googleapis.com" per il consumer "project_number:...".
Per risolvere il problema, invia una richiesta per aumentare la quota di lettura per l'API Monitoring. Per supporto, contatta l'assistenza Google Cloud. Per ulteriori informazioni sulle quote, consulta Utilizzo delle quote.
Metriche di più progetti
Se vuoi visualizzare le metriche di più progetti Google Cloud, non devi configurare più istanze della UI Prometheus o creare più origini dati in Grafana.
Crea invece un ambito delle metriche di Cloud Monitoring in un progetto Cloud, il progetto di definizione dell'ambito, che contiene i progetti da monitorare. Quando configuri l'interfaccia utente di Prometheus o un'origine dati Grafana con un progetto di definizione dell'ambito, puoi accedere ai dati di tutti i progetti nell'ambito delle metriche. Per ulteriori informazioni, consulta la sezione Ambiti 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 una query su una metrica di sistema Google Cloud:
- "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 utilizzando l'etichetta monitored_resource. Per ulteriori informazioni sull'identificazione e la scelta di un tipo di risorsa monitorata valida, consulta la sezione [Specificare un tipo di risorsa monitorata][promql-mr-types].
Le somme dei contatori non corrispondono tra l'UI del raccoglitore e la console Google Cloud
Potresti notare una differenza tra i valori nell'interfaccia utente di Prometheus raccoglitore locale e nella console Google Cloud di Google Cloud quando esegui query su un contatore non elaborato o sulla somma di un contatore. Si tratta di un comportamento previsto.
Monarch richiede i timestamp di inizio, ma Prometheus non ha timestamp di inizio. Managed Service per Prometheus genera timestamp di inizio saltando il primo punto importato di qualsiasi serie temporale e convertendolo in un timestamp di inizio. Questo causa un deficit persistente nella somma di un contatore.
La differenza tra il numero nella UI del raccoglitore e quello nella console Google Cloud è uguale al primo valore registrato nell'interfaccia utente, il che è previsto perché il sistema ignora quel valore iniziale.
Questo è accettabile perché non è necessario eseguire una produzione per una query per i valori non elaborati del contatore; tutte le query utili sui contatori richiedono una funzione rate() o simile, nel qual caso la differenza nell'orizzonte temporale è identica tra le due UI. I contatori continuano ad aumentare, perciò non è possibile impostare un avviso per una query non elaborata perché una serie temporale raggiunge una soglia solo una volta. Tutti gli avvisi e i grafici utili esaminano la variazione o il tasso di variazione del valore.
Problemi sul lato dell'importazione
I problemi lato importazione possono essere correlati alla raccolta o alla valutazione delle regole. Inizia esaminando i log degli errori della raccolta gestita. Puoi eseguire questi comandi:
kubectl logs -f -ngmp-system -lapp.kubernetes.io/part-of=gmp kubectl logs -f -ngmp-system -lapp.kubernetes.io/name=collector -c prometheus
Nei cluster GKE Autopilot, puoi eseguire i seguenti comandi:
kubectl logs -f -ngke-gmp-system -lapp.kubernetes.io/part-of=gmp kubectl logs -f -ngke-gmp-system -lapp.kubernetes.io/name=collector -c prometheus
Quota superata
Se vedi 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 della serie temporale" e limite "Richieste di importazione della serie temporale 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 sarà esaurita 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 supporto, contatta l'assistenza Google Cloud. Per ulteriori informazioni sulle quote, consulta Utilizzo delle quote.
Autorizzazione mancante per l'account di servizio predefinito del nodo
Se viene visualizzato uno dei seguenti errori, è possibile che l'account di servizio predefinito nel nodo non abbia le autorizzazioni:
- "execute query: Errore durante l'esecuzione della query su Prometheus: client_error: client error: 403"
- "Errore di idoneità non riuscito: probe HTTP non riuscito con codice di stato: 503"
- "Errore durante l'esecuzione della query sull'istanza di Prometheus"
La raccolta gestita e il valutatore della regola gestita in Service Service per Prometheus utilizzano entrambi l'account di servizio predefinito sul nodo. Questo account viene creato con tutte le autorizzazioni necessarie, ma i clienti a volte li rimuovono manualmente. Questa rimozione determina l'esito negativo 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 di 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 Account di servizio configurato in modo errato.Passa alla VM sottostante nel cluster e controlla la configurazione dell'account di servizio del nodo:
Nella console Google Cloud, seleziona Kubernetes Engine oppure utilizza il seguente pulsante:
Seleziona Cluster, quindi fai clic sul nome del cluster.
Seleziona Nodi, quindi fai clic sul nome del nodo nella tabella Nodi.
Fai clic su Dettagli.
Fai clic sul link Istanza VM.
Individua il riquadro Gestione di API e identità e fai clic su Mostra dettagli.
Cerca l'API Stackdriver Monitoring con accesso completo.
È anche possibile che la UI di Prometheus sia stata configurata per esaminare il progetto sbagliato. Per informazioni sulla verifica dell'esecuzione di query sull'ambito delle metriche, consulta Modificare il progetto oggetto della query.
Account di servizio configurato in modo errato
Se viene visualizzato uno dei seguenti messaggi di errore, significa che l'account di servizio utilizzato dal raccoglitore non dispone delle autorizzazioni corrette:
- "code = PermissionDenied desc = Permission monitoring.timeSeries.create (oppure la risorsa potrebbe non esistere)"
- "google: impossibile trovare le credenziali predefinite. Per ulteriori informazioni, visita la pagina https://developers.google.com/accounts/docs/application-default-credentials."
Per verificare che l'account di servizio disponga delle autorizzazioni corrette, procedi nel seguente modo:
Nella console Google Cloud, vai a IAM e amministrazione o utilizza il seguente pulsante:
Identifica il nome dell'account di servizio nell'elenco delle entità. Verifica che il nome dell'account di servizio sia scritto correttamente. Fai clic su edit Modifica.
Seleziona il campo Ruolo, quindi fai clic su Utilizzato attualmente e cerca il ruolo Writer Monitoring o Editor di monitoraggio. Se l'account di servizio non ha uno di questi ruoli, aggiungilo ora.
Se esegui su Kubernetes non GKE, devi passare esplicitamente le credenziali sia al raccoglitore che al valutatore della regola.
Devi ripetere le credenziali sia nella sezione rules che nella sezione collection. Per scoprire di più, vedi Fornire le credenziali in modo esplicito (per la raccolta) o Fornire le credenziali in modo esplicito (per le regole).
Spesso gli account di servizio hanno come ambito un singolo progetto Google Cloud. Questo errore di autorizzazione può essere causato dall'utilizzo di un account di servizio per scrivere dati di metrica per più progetti, ad esempio quando un valutatore di regole gestite esegue query su un ambito delle metriche multiprogetto. Se utilizzi l'account di servizio predefinito, valuta la possibilità di configurare un account di servizio dedicato in modo da poter aggiungere in sicurezza l'autorizzazione monitoring.timeSeries.create per diversi progetti.
Se non puoi concedere questa autorizzazione, puoi utilizzare la rietichettatura delle metriche per riscrivere l'etichetta project_id in un altro nome. L'ID progetto è quindi predefinito sul progetto Cloud in cui è in esecuzione il server Prometheus o il valutatore della regola.
Configurazione dello scraping non valida
Se viene visualizzato il seguente errore, significa che il formato PodMonitoring o ClusterPodMonitoring è errato:
- "Si è verificato un errore interno: chiamata non riuscita a webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com": Pubblica "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.
Problemi con intervalli di timeout e timeout
Quando utilizzi Managed Service per Prometheus, il timeout di scraping non può essere maggiore dell'intervallo di scraping. Per controllare i log per individuare il problema, esegui questo comando:
kubectl -n gmp-system logs ds/collector prometheus
Nei cluster GKE Autopilot, esegui il comando seguente:
kubectl -n gke-gmp-system logs ds/collector prometheus
Cerca questo messaggio:
- "timeout scrape superiore all'intervallo scrape per config scrape con nome job "PodMonitoring/gmp-system/example-app/go-metrics""
Per risolvere il problema, imposta un valore pari o superiore all'intervallo di scraping rispetto al valore del timeout di scraping.
TYPE mancante per la metrica
Se viene visualizzato il seguente errore, nella metrica mancano le informazioni relative al tipo:
- "Nessun metadati trovato per il nome della metrica "{metric_name}"
Per verificare che il problema sia dovuto alle informazioni di tipo mancanti, controlla l'output /metrics dell'applicazione di esportazione. Se non è presente alcuna riga come la seguente,
manchino le informazioni sul tipo:
# TYPE {metric_name} <type>
Alcune librerie di VictoriaMetrics eliminano intenzionalmente le informazioni relative al tipo. Queste librerie non sono supportate da Managed Service for Prometheus.
Metriche di tipo sconosciuto o di doppia scrittura
Se viene visualizzato il seguente errore, è possibile che la metrica venga importata due volte:
- "parametro "query" non valido: query sostitutive non riuscite: selettore di vettori di conversione non riuscito: insiemi di etichette non corrispondenti tra i tipi di metriche corrispondenti prometheus.googleapis.com/metric_name_foo/gauge e prometheus.googleapis.com/metric_name_foo/unknown"
Potresti anche notare che i tuoi campioni importati sono aumentati in modo significativo senza variazioni significative del volume di scraping oppure che vengono create nuove metriche con suffissi "sconosciuti" o "sconosciuti:contatore".
Un altro possibile segnale di questo problema potrebbe essere l'assenza di dati o la presenza di lacune nei dati durante l'esecuzione di una query su una metrica del contatore semplice (ad esempio, una query PromQL di
metric_name_foo). Puoi verificare se gli errori sopra riportati vengono visualizzati dopo aver aggiunto una funzione rate alla query (ad esempio
rate(metric_name_foo[5m])).
Di solito il problema è dovuto alla configurazione accidentale del raccoglitore Managed Service per Prometheus come server di federazione. La federazione non è supportata quando si utilizza Managed Service per Prometheus. Poiché la federazione diminuisce intenzionalmente le informazioni di tipo TYPE, l'implementazione della federazione causa metriche di tipo "sconosciuto" e mentre il sistema invia tutte le metriche di tipo "sconosciuto" due volte (una volta come indicatore, una volta come contatore), la federazione raddoppia i campioni importati.
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.
- Elimina eventuali metriche in conflitto con il suffisso "unknown" o "unknown:counter" chiamando DeleteMetricDescriptor.
Collisioni di serie temporali
Se visualizzi uno dei seguenti errori, è possibile che più di un raccoglitore tenti di scrivere nella stessa serie temporale:
- "Impossibile scrivere una o più serie temporali: uno o più punti sono stati scritti più spesso del periodo di campionamento massimo configurato per la metrica".
- "Impossibile scrivere una o più serie temporali: i punti devono essere scritti in ordine. Uno o più punti specificati avevano un'ora di fine precedente rispetto a quella 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 supportato ad alta disponibilità.
Utilizzo di regole di rietichettatura, in particolare quelle che operano su job o istanze. Managed Service per Prometheus identifica parzialmente una serie temporale unica mediante la combinazione di etichette {
project,location,cluster,namespace,job,instance}. L'utilizzo di una regola di etichettatura per eliminare queste etichette, in particolarejobeinstance, può causare spesso collisioni. Ti consigliamo di non riscrivere queste etichette.Per risolvere il problema, elimina la regola che lo causa. Spesso si tratta di una configurazione di rietichettatura delle metriche che utilizza l'azione
labeldrop. Puoi identificare la regola problematica commentando tutte le regole di rietichettatura e poi ripristinandole una alla volta finché l'errore non si ripete.
Una causa meno comune di collisioni di serie temporali è l'utilizzo di un intervallo di scraping inferiore a 5 secondi. L'intervallo minimo di scraping supportato da Managed Service per Prometheus è di 5 secondi.
Nessun errore e nessuna metrica
Se utilizzi la raccolta gestita, non vedrai alcun errore, ma i dati non vengono visualizzati in Cloud Monitoring. La causa più probabile è che le esportazioni di metriche o le configurazioni di scraping non sono configurate correttamente. Managed Service per Prometheus non invia dati delle serie temporali a meno che non applichi prima una configurazione di scraping valida.
Per identificare questa causa, prova a eseguire il deployment dell'applicazione di esempio e della risorsa PodMonitoring di esempio. Se la metrica up viene visualizzata (l'operazione potrebbe richiedere alcuni minuti), il problema riguarda la configurazione dello scraper o l'esportatore.
La causa principale è un numero qualsiasi di cose. Ti consigliamo di controllare quanto segue:
Il PodMonitoring fa riferimento a una porta valida.
Le specifiche di deployment dell'esportatore hanno porte denominate correttamente.
I selettori (più comunemente
app) corrispondono alle risorse Deployment e PodMonitoring.Puoi visualizzare i dati all'endpoint e alla porta previsti visitandoli manualmente.
Hai installato la risorsa PodMonitoring nello stesso spazio dei nomi dell'applicazione di cui vuoi eseguire il scraping. Non installare risorse o applicazioni personalizzate nello spazio dei nomi
gmp-systemogke-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
_.Se non utilizzi un insieme di filtri, tutti i dati vengono filtrati. Presta particolare attenzione a non utilizzare filtri in conflitto quando utilizzi un filtro
collectionnella risorsaOperatorConfig.Se eseguito al di fuori di Google Cloud,
projectoproject-idè impostato su un progetto Google Cloud valido, mentrelocationè impostato su una regione di Google Cloud valida. Non puoi utilizzareglobalcome valore perlocation.
Problemi con la raccolta dagli esportatori
Se le metriche di un esportatore non vengono importate, verifica quanto segue:
Verifica che l'esportatore funzioni e stia esportando le metriche utilizzando il comando
kubectl port-forward.Ad esempio, per controllare che i pod con il selettore
app.kubernetes.io/name=redisnello spazio dei nomitestemettono metriche nell'endpoint/metricssulla porta 9121, puoi effettuare 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}')" 9121Accedi all'endpoint
localhost:9121/metricsusando il browser ocurlin un'altra sessione del terminale per verificare che le metriche vengano esposte dall'esportatore per lo scraping.Verifica se puoi eseguire query sulle metriche nella console Google Cloud, ma non su Grafana. In tal caso, il problema riguarda Grafana, non la raccolta delle metriche.
Verifica che il raccoglitore gestito sia in grado di recuperare l'esportatore esaminando l'interfaccia web di Prometheus.
Identifica il raccoglitore gestito in esecuzione sullo stesso nodo su cui è in esecuzione l'esportatore. Ad esempio, se l'esportatore è in esecuzione sui pod nello spazio dei nomi
teste i pod sono etichettati conapp.kubernetes.io/name=redis, il comando seguente 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}'Configura il port forwarding dalla porta 19090 del raccoglitore gestito:
kubectl port-forward POD_NAME -n gmp-system 19090
Vai all'URL
localhost:19090/targetsper accedere all'interfaccia web. Se l'esportatore è elencato tra le destinazioni, il tuo raccoglitore gestito sta eseguendo lo scraping.
Firewall
Un firewall può causare problemi di importazione e di query. Il tuo 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 "Troppi cambiamenti simultanei alla configurazione del progetto" solitamente è temporaneo e si risolve dopo qualche minuto. Di solito il problema è dovuto alla rimozione di una regola di etichettatura che interessa molte metriche diverse. La rimozione determina la formazione di una coda di aggiornamenti ai descrittori delle metriche nel tuo progetto. L'errore scompare quando la coda viene elaborata.