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.

Consolida le policy di avviso per operare su più risorse

Gli avvisi addebitano un costo per condizione. Per questo motivo, quando possibile, utilizza un criterio di avviso per monitorare più risorse anziché crearne uno per ogni risorsa.

Ad esempio, supponiamo di avere 100 VM. Ogni VM genera una serie temporale per il tipo di metrica my_metric. Ecco due modi diversi per monitorare le serie temporali:

  • Crea un criterio di avviso con una condizione. La condizione monitora my_metric e aggrega i dati a livello di VM. Dopo l'aggregazione, c'è una serie temporale per ogni VM. Pertanto, la condizione monitora 100 serie temporali.

  • Crea 100 criteri di avviso e ognuno contiene una condizione. Ogni condizione monitora la serie temporale my_metric per una delle VM e aggrega i dati a livello di VM. Pertanto, ogni condizione monitora una serie temporale.

La seconda opzione, che crea 100 condizioni, è più costosa della prima, che ne crea solo una. Entrambe le opzioni monitorano 100 serie temporali.

Aggrega solo al livello per cui devi generare avvisi

È previsto un costo per ogni serie temporale monitorata da una 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 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.

Ad esempio, supponiamo di avere 100 VM. Ogni VM genera una serie temporale 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, è presente una serie temporale per ogni servizio. Pertanto, la condizione monitora 5 serie temporali.

  • Aggrega i dati a livello di VM. Dopo l'aggregazione, esiste una serie temporale per ogni VM. Pertanto, la condizione monitora 100 serie temporali.

La seconda opzione, che monitora 100 serie temporali, è più costosa della prima, che ne monitora solo cinque.

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 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:

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.