Questa pagina descrive come ottimizzare e monitorare i costi di Google Cloud Observability. Per le informazioni sui prezzi, consulta la pagina Prezzi di Google Cloud Observability.
Potrebbero interessarti anche i seguenti documenti:
- Stima le fatture.
- Esempi di prezzi.
- Ottimizza i costi con Cost Explorer. Cost Explorer fornisce visualizzazioni attuali e storiche dei dati sui costi e delle metriche di utilizzo. Pertanto, i dati ti aiutano a identificare le opportunità di ottimizzazione.
Ottimizza
Questa sezione fornisce indicazioni su come ridurre o ottimizzare i costi associati a Cloud Logging, Cloud Trace e Google Cloud Managed Service per Prometheus.
Ridurre l'archiviazione dei log
Per ridurre i costi di archiviazione di Cloud Logging, configura i filtri di esclusione sui sink di log per escludere il routing di determinati log. I filtri di esclusione possono rimuovere tutte le voci di log corrispondenti al filtro oppure solo una percentuale dei log. Quando una voce di log corrisponde a un filtro di esclusione di un sink, il sink non esegue il routing della voce di log alla destinazione. Le voci dei log escluse non vengono conteggiate ai fini dell'allocazione di spazio di archiviazione. Per istruzioni sull'impostazione dei filtri di esclusione, consulta Esclusioni dei log.
Un'altra opzione per ridurre i costi di archiviazione di Cloud Logging è il routing dei log al di fuori di Cloud Logging verso una destinazione supportata. Cloud Logging non addebita costi per il routing dei log verso le destinazioni supportate. Tuttavia, potrebbero essere addebitati costi quando i log vengono ricevuti da una destinazione:
Per informazioni sul routing dei log al di fuori di Cloud Logging, consulta la pagina Instradare i log verso destinazioni supportate.
Ottimizza i costi di Managed Service per Prometheus
I prezzi di Managed Service per Prometheus sono concepiti per essere controllabili. Poiché gli addebiti avvengono per campione, puoi utilizzare i seguenti metodi per controllare i costi:
Periodo di campionamento: la modifica del periodo di scraping delle metriche da 15 a 60 secondi può comportare un risparmio sui costi del 75%, senza sacrificare la cardinalità. Puoi configurare i periodi di campionamento in base al job, al target o a livello globale.
Filtraggio: puoi utilizzare i filtri per ridurre il numero di campioni inviati al datastore globale del servizio. Per ulteriori informazioni, consulta Filtraggio delle metriche esportate. Utilizza le configurazioni di rietichettatura delle metriche nella configurazione di scraping di Prometheus per rilasciare le metriche al momento dell'importazione, in base ai matcher delle etichette.
Mantieni dati locali ad alta cardinalità e a basso valore. Puoi eseguire Prometheus standard insieme al servizio gestito, utilizzando le stesse configurazioni di scraping, e conservare in locale i dati che non vale la pena inviare al datastore globale del servizio.
I prezzi di Managed Service per Prometheus sono concepiti per essere prevedibili.
Non vengono addebitati costi se hai istogrammi sparsi. I campioni vengono conteggiati solo per il primo valore diverso da zero e, successivamente, quando il valore del bucketn è maggiore del valore del bucketn-1: Ad esempio, un istogramma con valori
10 10 13 14 14 14viene conteggiato come tre campioni per il primo, il terzo e il quarto bucket.A seconda del numero di istogrammi e del loro utilizzo, l'esclusione dai prezzi dei bucket invariati in genere potrebbe comportare un numero di campioni ridotto del 20%-40% rispetto al numero assoluto indicato dai bucket dell'istogramma ai fini della fatturazione.
Con i prezzi per campione, non vengono addebitati costi per i container a scalabilità rapida e non scalabili, prerilasciabili o temporanei, come quelli creati da HPA o GKE Autopilot.
Se Managed Service per Prometheus addebitasse in base alla metrica, pagheresti per la cardinalità di un intero mese, in una sola soluzione, ogni volta che viene avviato un nuovo container. Con i prezzi per campione, paghi solo quando il container è in esecuzione.
Query, incluse le query di avviso
Tutte le query inviate dall'utente, incluse quelle inviate durante l'esecuzione delle regole di registrazione di Prometheus, vengono addebitate tramite chiamate all'API Cloud Monitoring. Per la tariffa attuale, consulta la tabella della sezione Riepilogo dei prezzi di Google Cloud Managed Service per Prometheus o Riepilogo dei prezzi di Cloud Monitoring.
Ridurre l'utilizzo delle tracce
Per controllare il volume di importazione degli intervalli di Trace, puoi gestire la frequenza di campionamento delle tracce per bilanciare la quantità di tracce necessaria per l'analisi delle prestazioni e il livello di tolleranza dei costi.
Per i sistemi a traffico elevato, la maggior parte dei clienti può effettuare il campionamento con una frequenza di 1 traccia per 1000 transazioni o persino di 1 per 10.000 transazioni e disporre comunque di informazioni sufficienti per l'analisi delle prestazioni.
La frequenza di campionamento viene configurata con le librerie client di Cloud Trace.
Ridurre la fattura degli avvisi
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, vedi Prezzi per gli avvisi.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 totali
- 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 alla cardinalità della metrica nell'esempio 1. Tuttavia, poiché i criterio di avviso nell'esempio 1 e nell'esempio 5 vengono aggregati 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, ti consigliamo di 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 alla 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 in modo da 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 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 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 principale per ridurre il numero di serie temporali restituite
Se la condizione utilizza una query PromQL o MQL, 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 avvisi 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, i tuoi 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 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 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.
Monitoraggio
Questa sezione descrive come monitorare i costi creando policy di avviso. Un criterio di avviso può monitorare i dati delle metriche e inviarti una notifica quando questi dati superano una soglia.
Monitora i byte di log mensili importati
Per creare un criterio di avviso che si attivi quando il numero di byte di log scritti nei bucket di log supera il limite definito dall'utente per Cloud Logging, utilizza le impostazioni seguenti.
| Nuova condizione Campo |
Valore |
|---|---|
| Risorsa e metrica | Nel menu Risorse, seleziona Globale. Nel menu Categorie di metriche, seleziona Metrica basata su log. Nel menu Metriche, seleziona Byte di log mensili inseriti. |
| Filtro | Nessuno. |
| Tra le serie temporali Aggregazione serie temporali |
sum |
| Finestra temporale continua | 60 m |
| Funzione finestra temporale continua | max |
| Configura trigger di avviso Campo |
Valore |
|---|---|
| Tipo di condizione | Threshold |
| Trigger avviso | Any time series violates |
| Posizione soglia | Above threshold |
| Valore soglia | Sei tu a determinare il valore accettabile. |
| Finestra di ripetizione test | Il valore minimo accettabile è di 30 minuti. |
Monitorare le metriche totali importate
Non è possibile creare un avviso in base alle metriche importate mensilmente. Tuttavia, puoi creare un avviso per i tuoi costi di Cloud Monitoring. Per informazioni, vedi Configurare un avviso di fatturazione.
Monitorare gli intervalli di traccia mensili importati
Per creare un criterio di avviso che si attivi quando gli intervalli mensili importati di Cloud Trace superano un limite definito dall'utente, utilizza le impostazioni seguenti.
| Nuova condizione Campo |
Valore |
|---|---|
| Risorsa e metrica | Nel menu Risorse, seleziona Globale. Nel menu Categorie di metriche, seleziona Fatturazione. Nel menu Metriche, seleziona Intervalli di traccia mensili inseriti. |
| Filtro | |
| Tra le serie temporali Aggregazione serie temporali |
sum |
| Finestra temporale continua | 60 m |
| Funzione finestra temporale continua | max |
| Configura trigger di avviso Campo |
Valore |
|---|---|
| Tipo di condizione | Threshold |
| Trigger avviso | Any time series violates |
| Posizione soglia | Above threshold |
Threshold value |
Sei tu a determinare il valore accettabile. |
| Finestra di ripetizione test | Il valore minimo accettabile è di 30 minuti. |
Configurare un avviso di fatturazione
Per ricevere notifiche degli addebiti fatturabili o previsti che superano un dato budget, crea un avviso nella pagina Budget e avvisi della Google Cloud console:
-
Nella console Google Cloud , vai alla pagina Fatturazione:
Puoi trovare questa pagina anche utilizzando la barra di ricerca.
Se disponi di più account di fatturazione Cloud, esegui una di queste operazioni:
- Per gestire la fatturazione Cloud per il progetto attuale, seleziona Vai all'account di fatturazione collegato.
- Per individuare un altro account di fatturazione Cloud, seleziona Gestisci gli account di fatturazione e scegli l'account per cui vuoi impostare un budget.
- Nel menu di navigazione Fatturazione, seleziona Budget e avvisi.
- Fai clic su Crea budget.
- Compila i campi nella finestra di dialogo per il budget. In questa finestra di dialogo puoi selezionare progetti e prodotti Google Cloud e quindi creare un budget per la specifica combinazione. Per impostazione predefinita, riceverai una notifica al raggiungimento del 50%, 90% e 100% del budget. Per la documentazione completa, consulta Impostare budget e avvisi di spesa.