A partire dal 1° maggio 2026, Cloud Monitoring inizierà ad addebitare costi per l'utilizzo dei criteri di avviso. Per informazioni sul modello di prezzi, consulta Riepilogo dei prezzi di Cloud Monitoring.
Questo documento descrive le strategie che puoi utilizzare per ridurre i costi per gli avvisi.
Consolida le policy di avviso per operare su più risorse
A causa del costo di 0,10 $per condizione, è più conveniente utilizzare un criterio di avviso per monitorare più risorse che utilizzare un criterio di avviso per monitorare ogni risorsa. Considera i seguenti esempi:
Esempio 1
Dati
- 100 VM
- Ogni VM emette una metrica,
metric_name metric_nameha un'etichetta con 10 valori
- Una condizione di avviso
- Aggrega le condizioni a livello di VM
- Periodo di esecuzione di 30 secondi
- Costo della condizione: 1 condizione * 0,10 $ al mese = 0,10 $ al mese
- Costo delle serie temporali: 100 serie temporali restituite per periodo * 86.400 periodi al mese = 8,6 milioni di serie temporali restituite al mese * 0,35 $ per milione di serie temporali = 3,02 $ al mese
- Costo totale: 3,12$al mese
Esempio 2
Dati
- 100 VM
- Ogni VM emette una metrica,
metric_name metric_nameha un'etichetta con 10 valori
- 100 condizioni
- Ogni condizione viene filtrata e aggregata a una VM
- Periodo di esecuzione di 30 secondi
- Costo della condizione: 100 condizioni * 0,10 $ al mese = 10 $al mese
- Costo delle serie temporali: 100 condizioni * 1 serie temporale restituita per condizione per periodo * 86.400 periodi al mese = 8,6 milioni di serie temporali restituite al mese * 0,35 $ per milione di serie temporali = 3,02 $ al mese
- Costo totale: 13,02$al mese
In entrambi gli esempi, monitori lo stesso numero di risorse. Tuttavia, l'esempio 2 utilizza 100 policy di avviso, mentre l'esempio 1 ne utilizza solo una. Di conseguenza, l'esempio 1 costa quasi 10 $in meno al mese.
Aggrega solo al livello per cui devi generare avvisi
L'aggregazione a livelli di granularità più elevati comporta costi superiori rispetto all'aggregazione a livelli di granularità inferiori. Ad esempio, l'aggregazione a livello di progetto Google Cloud è più economica dell'aggregazione a livello di cluster, e l'aggregazione a livello di cluster è più economica dell'aggregazione a livello di cluster e spazio dei nomi.
Considera i seguenti esempi:
Esempio 1
Dati
- 100 VM
- Ogni VM emette una metrica,
metric_name metric_nameha un'etichetta con 10 valori
- Una condizione di avviso
- Aggrega le condizioni a livello di VM
- Periodo di esecuzione di 30 secondi
- Costo della condizione: 1 condizione * 0,10 $ al mese = 0,10 $ al mese
- Costo delle serie temporali: 100 serie temporali restituite per periodo * 86.400 periodi al mese = 8,6 milioni di serie temporali restituite al mese * 0,35 $ per milione di serie temporali = 3,02 $ al mese
- Costo totale: 3,12$al mese
Esempio 4
Dati
- 100 VM, in cui ogni VM appartiene a un servizio
- Cinque servizi in totale
- Ogni VM emette una metrica,
metric_name metric_nameha un'etichetta con 10 valori
- Una condizione
- Aggrega le condizioni al livello di servizio
- Periodo di esecuzione di 30 secondi
- Costo della condizione: 1 condizione * 0,10 $ al mese = 0,10 $ al mese
- Costo delle serie temporali: 5 serie temporali restituite per periodo * 86.400 periodi al mese = 432.000 serie temporali restituite al mese * 0,35 $ per milione di serie temporali = 0,14 $ al mese
- Costo totale: 0,24$al mese
Esempio 5
Dati
- 100 VM
- Ogni VM emette una metrica,
metric_name metric_nameha 100 etichette con 1000 valori ciascuna
- Una condizione
- Aggrega le condizioni a livello di VM
- Periodo di esecuzione di 30 secondi
- Costo della condizione: 1 condizione * 0,10 $ al mese = 0,10 $ al mese
- Costo delle serie temporali: 100 serie temporali restituite per periodo * 86.400 periodi al mese = 8,5 milioni di serie temporali restituite al mese * 0,35 $ per milione di serie temporali = 3,02 $ al mese
- Costo totale: 3,12$al mese
Confronta l'esempio 1 con l'esempio 4: entrambi gli esempi operano sugli stessi dati sottostanti e hanno un'unica norma di avviso. Tuttavia, poiché i criterio di avviso nell'esempio 4 vengono aggregati al servizio, sono meno costosi rispetto ai criterio di avviso nell'esempio 1, che vengono aggregati in modo più granulare alla VM.
Inoltre, confronta l'esempio 1 con l'esempio 5: in questo caso, la cardinalità della metrica nell'esempio 5 è 10.000 volte superiore a quella della metrica nell'esempio 1. Tuttavia, poiché la criterio di avviso nell'esempio 1 e nell'esempio 5 si aggregano alla VM e poiché il numero di VM è lo stesso in entrambi gli esempi, gli esempi sono equivalenti in termini di prezzo.
Quando configuri i criteri di avviso, scegli i livelli di aggregazione più adatti al tuo caso d'uso. Ad esempio, se ti interessa ricevere avvisi sull'utilizzo della CPU, potresti voler eseguire l'aggregazione a livello di VM e CPU. Se ti interessa ricevere avvisi sulla latenza per endpoint, potresti voler eseguire l'aggregazione a livello di endpoint.
Non inviare avvisi relativi a dati non elaborati e non aggregati
Il monitoraggio utilizza un sistema di metriche dimensionali, in cui qualsiasi metrica ha una cardinalità totale pari al numero di risorse monitorate moltiplicato per il numero di combinazioni di etichette per quella metrica. Ad esempio, se hai 100 VM che emettono una metrica e questa metrica ha 10 etichette con 10 valori ciascuna, la cardinalità totale è 100 * 10 * 10 = 10.000.
A causa del modo in cui viene scalata la cardinalità, gli avvisi sui dati non elaborati possono essere estremamente costosi. Nell'esempio precedente, vengono restituite 10.000 serie temporali per ogni periodo di esecuzione. Tuttavia, se esegui l'aggregazione nella VM, vengono restituite solo 100 serie temporali per periodo di esecuzione, indipendentemente dalla cardinalità delle etichette dei dati sottostanti.
Gli avvisi sui dati non elaborati ti espongono anche al rischio di un aumento delle serie temporali quando le tue metriche ricevono nuove etichette. Nell'esempio precedente, se un utente aggiunge una nuova etichetta alla metrica, la cardinalità totale aumenta a 100 * 11 * 10 = 11.000 serie temporali. In questo caso, il numero di serie temporali restituite aumenta di 1000 per ogni periodo di esecuzione,anche se la norma di avviso rimane invariata. Se invece esegui l'aggregazione nella VM, nonostante l'aumento della cardinalità sottostante, vengono restituite solo 100 serie temporali.
Filtrare le risposte non necessarie
Configura le condizioni per valutare solo i dati necessari per le tue esigenze di avviso. Se non interverresti per risolvere un problema, escludilo dalle tue policy di avviso. Ad esempio, probabilmente non devi generare avvisi per la VM di sviluppo di uno stagista.
Per ridurre costi e incidenti non necessari, puoi filtrare le serie temporali che non sono importanti. Puoi utilizzare le etichette dei metadati per taggare gli asset con categorie e poi filtrare le categorie di metadati non necessarie. Google Cloud
Utilizzare gli operatori di flusso principali per ridurre il numero di serie temporali restituite
Se la condizione utilizza una query PromQL, puoi utilizzare un operatore di flussi principali per selezionare un numero di serie temporali restituite con i valori più alti:
- PromQL:
topk
Ad esempio, una clausola topk(metric, 5) in una query PromQL limita
il numero di serie temporali restituite a cinque in ogni periodo di esecuzione.
Se limiti il numero di serie temporali, potresti riscontrare dati mancanti e incidenti errati, ad esempio:
- Se più di N serie temporali violano la soglia, perderai i dati al di fuori delle prime N serie temporali.
- Se una serie temporale che viola la soglia si verifica al di fuori delle prime N serie temporali, gli incidenti potrebbero chiudersi automaticamente nonostante la serie temporale esclusa continui a violare la soglia.
- Le query sulle condizioni potrebbero non mostrare un contesto importante, ad esempio le serie temporali di base che funzionano come previsto.
Per mitigare questi rischi, scegli valori elevati per N e utilizza l'operatore top-streams solo nelle norme di avviso che valutano molte serie temporali, ad esempio gli incidenti per i singoli container Kubernetes.
Aumenta la durata del periodo di esecuzione (solo PromQL)
Se la condizione utilizza una query PromQL, puoi modificare la durata
del periodo di esecuzione impostando il campo
evaluationInterval nella
condizione.
Intervalli di valutazione più lunghi comportano la restituzione di un numero inferiore di serie temporali al mese. Ad esempio, una query di condizione con un intervallo di 15 secondi viene eseguita con una frequenza doppia rispetto a una query con un intervallo di 30 secondi e una query con un intervallo di 1 minuto viene eseguita con una frequenza dimezzata rispetto a una query con un intervallo di 30 secondi.