Gestire i costi degli avvisi

Questo documento descrive le strategie che puoi utilizzare per ridurre i costi per gli avvisi. Per informazioni sul modello di prezzi, consulta Prezzi di Google Cloud Observability ed Esempi di prezzi degli avvisi.

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

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

Utilizza Esplora metriche per verificare il conteggio dei punti restituiti

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

  • Per una condizione di avviso con soglia metrica, utilizza Metrics Explorer per creare una query identica. Aggiungi una trasformazione secondaria di Conteggio serie temporali 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 criterio 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é crearne una 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 con 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.

  • Crea 100 criteri di avviso e ognuno contiene una condizione e quindi un riferimento alla 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 rispetto all'aggregazione a livello di cluster, mentre l'aggregazione a livello di cluster è più economica rispetto all'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:

  • Aggreghi 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.

  • Aggregare i dati a livello di VM. Dopo l'aggregazione, ogni esecuzione 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 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 servizio, ti consigliamo di eseguire l'aggregazione a livello di servizio.

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 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 ti espongono anche al rischio di un aumento dei punti restituiti 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 punti restituiti aumenta di 1000 per ogni periodo di esecuzione,anche se la policy 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 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 riscontrare dati mancanti e incidenti errati, ad esempio:

  • Se più di N punti violano la soglia, perderai i dati al di fuori dei primi N punti.
  • Se un punto di violazione si verifica al di fuori dei primi N punti, i tuoi incidenti 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 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 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 metriche basate sui 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 in un solo tipo di risorsa. Se la metrica basata sui log viene visualizzata in più tipi di risorse, puoi creare più policy di avviso o utilizzare più condizioni in una singola policy di avviso.