Questo documento ti aiuta a scegliere l'approccio migliore per rappresentare graficamente o monitorare un rapporto di dati metrici. Include anche link a esempi, identifica quando puoi calcolare i rapporti e descrive le anomalie che potresti riscontrare quando rappresenti graficamente un rapporto di due metriche diverse. Queste anomalie sono dovute a differenze nella frequenza di campionamento o nei parametri di allineamento.
I rapporti ti consentono di trasformare i dati metrici in una forma diversa e potenzialmente più utile. Ad esempio, considera un tipo di metrica che conta il numero di risposte HTTP in base al codice di risposta. I dati metrici riportano il numero di errori, ma non la proporzione di richieste non riuscite. Tuttavia, i requisiti di rendimento vengono spesso specificati come percentuale, ad esempio "Il tasso di errore deve essere inferiore allo 0,1%". Per determinare il tasso di errore utilizzando i dati metrici, calcola il rapporto tra le richieste non riuscite e il numero totale di richieste.
Best practice
Per monitorare o rappresentare graficamente un rapporto di dati metrici, ti consigliamo di utilizzare PromQL. Puoi utilizzare PromQL con l' API Cloud Monitoring e con la Google Cloud console. La Google Cloud console include un editor di codice che fornisce suggerimenti, rilevamento degli errori e altro supporto per la creazione di query PromQL valide.
Per creare una criterio di avviso che monitori un rapporto di metriche quando non hai familiarità con PromQL, utilizza l'API Cloud Monitoring e includi un filtro di serie temporali. Per un esempio, vedi Rapporto metrico.
Per rappresentare graficamente un rapporto di dati metrici quando non hai familiarità con PromQL, ti consigliamo di utilizzare la Google Cloud console e un'interfaccia basata su menu. Per istruzioni dettagliate, vedi, Rappresentare graficamente un rapporto di metriche e Aggiungere grafici e tabelle a una dashboard personalizzata.
Restrizioni con i rapporti
Quando configuri un rapporto, si applicano le seguenti restrizioni:
Dopo l'aggregazione, le etichette nelle serie temporali del denominatore devono essere uguali o un sottoinsieme delle etichette nelle serie temporali del numeratore.
Ti consigliamo di selezionare le opzioni di aggregazione in modo che, dopo l'aggregazione, le serie temporali del numeratore e del denominatore abbiano le stesse etichette.
Considera una configurazione in cui le serie temporali del numeratore hanno le etichette
method,quota_metriceproject_id. Le serie temporali del denominatore hanno le etichettelimit_name,quota_metriceproject_id. Le scelte valide per il raggruppamento del denominatore dipendono dalle selezioni per il numeratore:- Numeratore raggruppato in base all'etichetta
method: combina le serie temporali del denominatore in una singola serie temporale. Nessun altro raggruppamento fa sì che le etichette per le serie temporali del denominatore siano un sottoinsieme delle etichette per le serie temporali del numeratore. - Numeratore raggruppato in base all'etichetta
quota_metric: raggruppa il denominatore in base a questa etichetta o combina tutte le serie temporali nel denominatore in una singola serie temporale. - Numeratore raggruppato in base alle etichette
quota_metriceproject_id: raggruppa il denominatore in base a entrambe le etichette, a una sola etichetta o combina le serie temporali del denominatore in una singola serie temporale.
Le opzioni di aggregazione del denominatore valide eliminano sempre l'etichetta
limit_namedalle serie temporali raggruppate perché questa etichetta non è presente nelle serie temporali del numeratore.- Numeratore raggruppato in base all'etichetta
Il periodo di allineamento deve essere lo stesso per il numeratore e il denominatore quando configuri un grafico utilizzando la Google Cloud console; tuttavia, questi campi possono essere diversi quando utilizzi l'API Cloud Monitoring.
Ti consigliamo di utilizzare lo stesso periodo di allineamento per il numeratore e il denominatore, indipendentemente dallo strumento utilizzato per creare il grafico.
Il numeratore e il denominatore devono avere lo stesso tipo di valore. Ad esempio, se il numeratore è di tipo
DOUBLE, anche il denominatore deve essere di tipoDOUBLE.I rapporti richiedono che la metrica del numeratore e del denominatore abbia un tipo di valore
DOUBLEoINT64.Le serie temporali allineate per il numeratore e il denominatore devono avere lo stesso tipo di metrica. Se le due metriche hanno tipi diversi, devi utilizzare gli allineatori per convertirle nello stesso tipo.
Considera una configurazione in cui è selezionata una metrica
DELTAper il numeratore e una metricaGAUGEper il denominatore. In questa situazione, utilizza l'allineatore di frequenza,ALIGN_RATE, per convertire la metricaDELTAin una metricaGAUGE. Per un esempio, vedi Policy di avviso per il rapporto sull'utilizzo della quota di frequenza per un limite.Per i rapporti non definiti con PromQL, il tipo di risorsa monitorata deve essere lo stesso per il numeratore e il denominatore.
Ad esempio, se la risorsa per la metrica del numeratore è rappresentata dalle istanze Compute Engine, anche la risorsa per la metrica del denominatore deve essere rappresentata dalle istanze Compute Engine.
Anomalie dovute a mancata corrispondenza tra campionamento e allineamento
In generale, è preferibile calcolare i rapporti in base alle serie temporali raccolte per un singolo tipo di metrica, utilizzando i valori delle etichette. Un rapporto calcolato su due tipi di metriche diversi è soggetto ad anomalie dovute a periodi di campionamento e finestre di allineamento diversi.
Ad esempio, supponiamo di avere due tipi di metriche diversi, un conteggio totale delle RPC e un conteggio degli errori RPC, e di voler calcolare il rapporto tra le RPC con conteggio degli errori e le RPC totali. Le RPC non riuscite vengono conteggiate nelle serie temporali di entrambi i tipi di metriche. Pertanto, è possibile che, quando allinei le serie temporali, una RPC non riuscita non venga visualizzata nello stesso intervallo di allineamento per entrambe le serie temporali. Questa differenza può verificarsi per diversi motivi, tra cui:
- Poiché esistono due serie temporali diverse che registrano lo stesso evento, esistono due valori di contatore sottostanti che implementano la raccolta e non vengono aggiornati in modo atomico.
- Le frequenze di campionamento potrebbero essere diverse. Quando le serie temporali vengono allineate a un periodo comune, i conteggi per un singolo evento potrebbero essere visualizzati in intervalli di allineamento adiacenti nelle serie temporali per le diverse metriche.
La differenza nel numero di valori negli intervalli di allineamento corrispondenti può
portare a valori di rapporto error/total senza senso, come 1/0 o 2/1.
È meno probabile che i rapporti di numeri più grandi generino valori senza senso. Puoi ottenere numeri più grandi tramite l'aggregazione, utilizzando una finestra di allineamento più lunga del periodo di campionamento o raggruppando i dati per determinate etichette. Queste tecniche riducono al minimo l'effetto di piccole differenze nel numero di punti in un determinato intervallo. Ovvero, una disparità di due punti è più significativa quando il numero previsto di punti in un intervallo è 3 rispetto a quando il numero previsto è 300.
Se utilizzi tipi di metriche integrate, potresti non avere altra scelta che calcolare i rapporti tra i tipi di metriche per ottenere il valore di cui hai bisogno.
Se stai progettando metriche personalizzate che potrebbero conteggiare la stessa cosa, ad esempio le RPC che restituiscono lo stato di errore, in due metriche diverse, prendi in considerazione invece una singola metrica, che include ogni conteggio una sola volta. Ad esempio, supponiamo che tu stia conteggiando le RPC e che tu voglia monitorare il rapporto tra le RPC non riuscite e tutte le RPC. Per risolvere questo problema, crea un singolo tipo di metrica per conteggiare le RPC e utilizza un'etichetta per registrare lo stato della chiamata, incluso lo stato "OK". Quindi, ogni valore di stato, errore o "OK", viene registrato aggiornando un singolo contatore per quel caso.
Incidenti falsi dovuti ad anomalie nel calcolo del rapporto
Per evitare incidenti falsi dovuti a errori temporanei o dati mancanti, imposta la durata della query PromQL su almeno il doppio dell'intervallo di valutazione:
- Google Cloud Console: imposta la durata nel campo Durata quando configuri la condizione di avviso.
- API Cloud Monitoring o Terraform: specifica la durata utilizzando il campo
AlertPolicy.Condition.PrometheusQueryLanguageCondition.duration.
Passaggi successivi
Per informazioni sull'utilizzo di PromQL per configurare le policy di avviso, vedi Panoramica degli avvisi PromQL.
Per informazioni sulla creazione di grafici, consulta i seguenti documenti:
- Per creare grafici temporanei, vedi Esplora metriche.
- Per aggiungere grafici a una dashboard utilizzando la Google Cloud console, vedi Aggiungere grafici e tabelle a una dashboard personalizzata.
- Per gestire i grafici utilizzando l'API Cloud Monitoring, vedi Creare e gestire le dashboard tramite API.