Questo documento descrive le strategie che puoi utilizzare per ridurre i costi degli avvisi.
Consolidare i criteri di avviso per operare su più risorse
A causa del costo di 1,50 $per condizione, è più conveniente utilizzare un criterio di avviso per monitorare più risorse rispetto a utilizzarne uno per monitorare ogni risorsa. Considera gli esempi seguenti:
Esempio 1
Dati
- 100 VM
- Ogni VM emette una metrica,
metric_name metric_nameha un'etichetta con 10 valori
- Una condizione di avviso
- Aggregazioni delle condizioni a livello di VM
- Periodo di esecuzione di 30 secondi
- Costo della condizione: 1 condizione * 1,50 $ al mese = 1,50 $ 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: 4,52$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 in una VM
- Periodo di esecuzione di 30 secondi
- Costo delle condizioni: 100 condizioni * 1,50 $ al mese = 150 $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: 153,02$al mese
In entrambi gli esempi, monitori lo stesso numero di risorse. Tuttavia, l'esempio 2 utilizza 100 criteri di avviso, mentre l'esempio 1 ne utilizza solo uno. Di conseguenza, l'esempio 1 è quasi 150 $più economico al mese.
Aggregare solo al livello per cui è necessario inviare un avviso
L'aggregazione a livelli di granularità più elevati comporta costi più elevati rispetto all'aggregazione a livelli di granularità più bassi. 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 gli esempi seguenti:
Esempio 1
Dati
- 100 VM
- Ogni VM emette una metrica,
metric_name metric_nameha un'etichetta con 10 valori
- Una condizione di avviso
- Aggregazioni delle condizioni a livello di VM
- Periodo di esecuzione di 30 secondi
- Costo della condizione: 1 condizione * 1,50 $ al mese = 1,50 $ 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: 4,52$al mese
Esempio 4
Dati
- 100 VM, in cui ogni VM appartiene a un servizio
- Cinque servizi totali
- Ogni VM emette una metrica,
metric_name metric_nameha un'etichetta con 10 valori
- Una condizione
- Aggregazioni delle condizioni a livello di servizio
- Periodo di esecuzione di 30 secondi
- Costo della condizione: 1 condizione * 1,50 $ al mese = 1,50 $ 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: 1,64$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 * 1,50 $ al mese = 1,50 $ 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: 4,52$al mese
Confronta l'esempio 1 con l'esempio 4: entrambi gli esempi operano sugli stessi dati sottostanti e hanno un unico criterio di invio di avvisi. Tuttavia, poiché il criterio di avviso nell'esempio 4 viene aggregato al servizio, è meno costoso del criterio di avviso nell'esempio 1, che viene aggregato 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 alla cardinalità della metrica nell'esempio 1. Tuttavia, poiché i criteri di avviso nell'esempio 1 e nell'esempio 5 sono entrambi aggregati alla VM e poiché il numero di VM è lo stesso in entrambi gli esempi, i prezzi sono equivalenti.
Quando configuri i criteri di avviso, scegli i livelli di aggregazione più adatti al tuo caso d'uso. Ad esempio, se ti interessano gli avvisi sull'utilizzo della CPU, ti consigliamo di aggregare i dati a livello di VM e CPU. Se ti interessano gli avvisi sulla latenza per endpoint, ti consigliamo di aggregare i dati a livello di endpoint.
Non inviare avvisi su dati non elaborati e non aggregati
Il monitoraggio utilizza un sistema di metriche dimensionali, in cui qualsiasi metrica ha un valore totale [cardinality][cardinality] 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 della scalabilità della 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à dell'etichetta dei dati sottostanti.
Gli avvisi sui dati non elaborati comportano anche il rischio di un aumento delle serie temporali quando le 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 ogni periodo di esecuzione anche se il criterio di avviso rimane invariato. 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 intervieni per correggere un problema, escludi lo dai criteri di avviso. Ad esempio, probabilmente non è necessario inviare un avviso sulla VM di sviluppo di un stagista.
Per ridurre gli avvisi e i costi non necessari, puoi escludere le serie temporali non importanti. Puoi utilizzare le Google Cloud etichette dei metadati per taggare gli asset con le categorie e poi filtrare le categorie di metadati non necessarie.
Utilizza gli operatori top-stream per ridurre il numero di serie temporali restituite
Se la condizione utilizza una query PromQL o MQL, puoi utilizzare un operatore top-streams per selezionare un numero di serie temporali restituite con i valori più elevati:
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.
Il limite a un numero massimo di serie temporali potrebbe comportare la mancanza di dati e alert 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 in violazione si verifica al di fuori delle prime N serie temporali, gli incidenti potrebbero chiudersi automaticamente nonostante la serie temporale esclusa violi ancora la soglia.
- Le query sulle condizioni potrebbero non mostrare un contesto importante, ad esempio le serie temporali di riferimento che funzionano come previsto.
Per ridurre questi rischi, scegli valori elevati per N e utilizza l'operatore top-streams solo nei criteri di avviso che valutano molte serie temporali, ad esempio gli avvisi 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 un numero inferiore di serie temporali restituite al mese. Ad esempio, una query con condizione con un intervallo di 15 secondi viene eseguita il doppio delle volte rispetto a una query con un intervallo di 30 secondi e una query con un intervallo di 1 minuto viene eseguita la metà delle volte rispetto a una query con un intervallo di 30 secondi.