Gestire i costi degli avvisi

Puoi gestire i costi delle tue policy di avviso di Cloud Monitoring consolidando le policy e limitando il numero di punti delle serie temporali restituiti dalle query. Per ridurre i punti restituiti, puoi aggregare e filtrare le serie temporali monitorate e regolare gli intervalli di valutazione di PromQL. Puoi anche visualizzare l'aggiornamento della fattura stimata man mano che modifichi i parametri delle norme.

Per informazioni sul modello di prezzi, consulta Prezzi di Google Cloud Observability ed Esempi di prezzi di Alerting.

Visualizza la fattura stimata utilizzando il Calcolatore prezzi nell'interfaccia utente

Quando crei o modifichi un criterio di avviso, Cloud Alerting mostra il costo stimato del criterio. Puoi utilizzare questo calcolatore per vedere come cambia il costo stimato man mano che modifichi i parametri della criterio di avviso.

Utilizzare Esplora metriche per verificare il conteggio dei punti restituiti

Il numero di punti restituiti dalla query della criterio di avviso dipende principalmente dalla cardinalità dell'output della query della criterio di avviso. Per visualizzare la cardinalità stimata del criterio di avviso:

  • Per una condizione di avviso basata su una soglia della metrica, utilizza Metrics Explorer per creare una query identica. Aggiungi una trasformazione secondaria di Serie temporale di conteggio per Nessuno.
  • Per una condizione di avviso PromQL, copia la query in Metrics Explorer, quindi procedi nel seguente modo:
    • Dividi la query in clausole separate in base a ogni operatore >, <, >=, <=, ==, !=, AND, OR e UNLESS.
    • Elimina qualsiasi clausola che non contenga una metrica, ad esempio un valore soglia numerico.
    • Racchiudi ogni clausola in una funzione count().
    • Somma i risultati.

  • Per una condizione di avviso MQL, copia la query in Metrics Explorer. Rimuovi la riga | condition. Aggiungi una riga | group_by [], .count alla fine.

    MQL è ritirato e le richieste di assistenza per il debug dei problemi di fatturazione potrebbero essere rifiutate dall'assistenza clienti Google Cloud.

Consolida le policy di avviso per operare su più risorse

Gli avvisi addebitano un costo per riferimento alla metrica e ogni policy di soglia metrica ha un riferimento alla metrica per condizione. Per questo motivo, quando possibile, utilizza una criterio di avviso per monitorare più risorse anziché creare una criterio di avviso per ogni risorsa.

Ad esempio, supponiamo di avere 100 VM. Ogni VM genera un punto al minuto per il tipo di metrica my_metric. Ecco due modi diversi per monitorare i punti restituiti:

  • Crea un criterio di avviso con una condizione e quindi un riferimento alla metrica. La condizione monitora my_metric e aggrega i dati a livello di VM. Dopo l'aggregazione, viene restituito un punto per ogni VM. Pertanto, la condizione genera 100 punti restituiti per valutazione.

  • Crei 100 policy di avviso e ognuna contiene una condizione e quindi un riferimento a una metrica. Ogni condizione monitora la serie temporale my_metric per una delle VM e aggrega i dati a livello di VM. Pertanto, ogni condizione restituisce un punto per valutazione.

La seconda opzione, che crea 100 condizioni (100 riferimenti alle metriche), è più costosa della prima, che crea solo 1 condizione (1 riferimento alla metrica). Entrambe le opzioni restituiscono 100 punti per valutazione.

Aggrega solo al livello per cui devi generare avvisi

Viene restituito un punto per ogni serie temporale monitorata da un criterio di avviso. 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 progettoGoogle 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.

Ad esempio, supponiamo di avere 100 VM. Ogni VM genera un punto per il tipo di metrica my_metric. Ogni VM appartiene a uno dei cinque servizi. Decidi di creare un criterio di avviso con una condizione che monitora my_metric. Ecco due diverse opzioni di aggregazione:

  • Aggregare i dati al servizio. Dopo l'aggregazione, ogni esecuzione criterio di avviso restituisce un punto per ogni servizio. Pertanto, la condizione restituisce 5 punti per esecuzione.

  • Aggrega i dati a livello di VM. Dopo l'aggregazione, ogni esecuzione del criterio di avviso restituisce un punto per ogni VM. Pertanto, la condizione restituisce 100 punti per esecuzione.

La seconda opzione, che restituisce 100 punti per esecuzione, è più costosa della prima, che restituisce solo 5 punti per esecuzione.

Quando configuri le policy 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 servizio, ti consigliamo di eseguire l'aggregazione a livello di servizio.

Non inviare avvisi relativi a dati non elaborati e non aggregati

Monitoring utilizza un sistema di metriche dimensionali, in cui qualsiasi metrica ha una cardinalità 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 restituiti 10.000 punti per ogni periodo di esecuzione. Tuttavia, se esegui l'aggregazione nella VM, vengono restituiti solo 100 punti 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 dei punti restituiti 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 punti restituiti 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 in modo da valutare solo i dati necessari per le tue esigenze di avviso. Se non intraprenderesti azioni per risolvere un problema, escludilo dalle tue policy di avviso. Ad esempio, probabilmente non devi inviare avvisi per la VM di sviluppo di uno stagista.

Per ridurre costi e avvisi non necessari, puoi filtrare le serie temporali che non sono importanti. Puoi utilizzare Google Cloud le etichette dei metadati per taggare gli asset con categorie e poi filtrare le categorie di metadati non necessarie.

Utilizza gli operatori di flusso principali per ridurre il numero di punti restituiti

Se la condizione utilizza una query PromQL, puoi utilizzare un operatore di flussi principali per selezionare un numero di punti restituiti con i valori più alti:

Ad esempio, una clausola topk(metric, 5) in una query PromQL limita il numero di punti restituiti a cinque in ogni periodo di esecuzione.

Se limiti il numero di punti, potresti perdere dati e ricevere avvisi errati, ad esempio:

  • Se più di N punti violano la soglia, perderai i dati al di fuori dei primi N punti.
  • Se un punto che viola la soglia si verifica al di fuori dei primi N punti, gli avvisi potrebbero chiudersi automaticamente nonostante i punti esclusi continuino a violare la soglia.
  • Le query sulle condizioni potrebbero non mostrare un contesto importante, come i punti di riferimento che funzionano come previsto.

Per mitigare questi rischi, scegli valori elevati per N e utilizza l'operatore top-streams solo nelle policy 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 punti restituiti 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.

Non utilizzare "Risorsa non specificata" (solo metriche basate su log)

Le condizioni di avviso che utilizzano le metriche basate su log ti consentono di impostare "Risorsa non specificata" come tipo di risorsa monitorata. In questo caso, la condizione di avviso avvia una query separata per ogni tipo di risorsa monitorata in Cloud Monitoring. Poiché ogni query fattura un minimo di un punto restituito, se non specifichi il tipo di risorsa, la fattura per i punti restituiti sarà elevata.

Per ridurre la fattura, scegli un tipo di risorsa specifico anziché utilizzare "Risorsa non specificata". Questo funziona perché la maggior parte delle metriche basate sui log viene visualizzata solo in un tipo di risorsa. Se la metrica basata su log viene visualizzata in più tipi di risorse, puoi creare più policy di avviso o utilizzare più condizioni in una singola policy di avviso.