Prezzi di Google Cloud Observability

I prezzi di Google Cloud Observability ti consentono di controllare l'utilizzo e la spesa. I prezzi dei prodotti Google Cloud Observability sono calcolati in base al volume di dati o all'utilizzo. Puoi utilizzare le allocazioni di utilizzo gratuito dei dati per iniziare senza incorrere in costi anticipati e senza impegni preliminari.

Le seguenti tabelle riepilogano le informazioni sui prezzi per Cloud Logging, Cloud Monitoring e Cloud Trace.

Riepilogo dei prezzi di Cloud Logging

Funzionalità Prezzo1 Allocazione gratuita mensile Data di validità
Spazio di archiviazione Logging*
tranne i log di rete venduti.		 0, 50 $/GiB;
Addebito una tantum per lo streaming dei log nello spazio di archiviazione del bucket di log per l'indicizzazione, l'esecuzione di query e l'analisi; include fino a 30 giorni di archiviazione nei bucket di log. Nessun costo aggiuntivo per l'esecuzione di query e l'analisi dei dati di log.
 Primi 50 GiB per progetto/mese 1° luglio 2018
Archiviazione dei log di rete venduti† 0,25 $/GiB;
Addebito una tantum per lo streaming dei log di telemetria di rete nello spazio di archiviazione del bucket di log per l'indicizzazione, l'esecuzione di query e l'analisi; include fino a 30 giorni di archiviazione nei bucket di log. Nessun costo aggiuntivo per l'esecuzione di query e l'analisi dei dati di log. 		Non applicabile 1° ottobre 2024:
Fidelizzazione Logging‡ 0,01 $ per GiB al mese per i log conservati per più di 30 giorni; fatturazione mensile in base alla conservazione. I log conservati per il periodo di conservazione predefinito non sono soggetti a costi di conservazione. 1 Gennaio 2022
Router dei log♣ Nessun costo aggiuntivo Non applicabile Non applicabile
Analisi dei log♥ Nessun costo aggiuntivo Non applicabile Non applicabile
*  Il volume di archiviazione conteggia la dimensione effettiva delle voci di log prima dell'indicizzazione. Non sono previsti costi di archiviazione per i log archiviati nel bucket di log _Required.
 †  I log di distribuzione dei log sono log di networking di Google Cloud generati dai servizi Google Cloud quando è abilitata la generazione di questi log. I log Vended includono log di flusso VPC, logging delle regole firewall e log di Cloud NAT. Questi log sono inoltre soggetti ai prezzi della telemetria di rete. Per maggiori informazioni, consulta Log di deployment.
 ‡  Non sono previsti costi di conservazione per i log archiviati nel bucket di log _Required, che ha un periodo di conservazione fisso di 400 giorni.
 ♣  Il routing dei log è definito come i log di forwarding ricevuti tramite l'API Cloud Logging verso una destinazione supportata. Potrebbero essere addebitati costi alle destinazioni per i log con routing.
 ♥  Non è previsto alcun costo per eseguire l'upgrade di un bucket di log per utilizzare Analisi dei log o per inviare query SQL dalla pagina Analisi dei log.
 Nota: la lingua dei prezzi per Cloud Logging è cambiata il 19 luglio 2023; tuttavia, le allocazioni gratuite e le tariffe sono rimaste invariate. La fattura potrebbe fare riferimento alla lingua dei prezzi precedente.

Riepilogo dei prezzi di Cloud Monitoring

Funzionalità Prezzo Allocazione gratuita mensile Data di validità
Tutti i dati di Monitoring
ad eccezione di quelli importati tramite Managed Service for Prometheus		 0,2580 $/MiB:1 primi 150-100.000 MiB
0,1510 $/MiB: successivi 100.000-250.000 MiB
0,0610 $/MiB: >250.000 MiB		 Tutte le metriche di Google Cloud non addebitabili
Primi 150 MiB per account di fatturazione per le metriche addebitate dai byte importati		 1° luglio 2018
Metriche importate utilizzando Google Cloud Managed Service per Prometheus, incluse le metriche del piano di controllo GKE 0,06 $/milione di campioni†: primi 0-50 miliardi di campioni importati#
0,048 $/milione di campioni: prossimi 50-250 miliardi di campioni importati
0,036 $/milione di campioni: successivi 250-500 miliardi di campioni importati
0,024 $/milione di campioni: >500 miliardi importati		 Non applicabile 8 agosto 2023
Chiamate API di Monitoring 0,01 $/1000 chiamate API Read
(le chiamate API Write sono sempre gratuite)		 Primo milione di chiamate API Read incluso per account di fatturazione 1° luglio 2018
Esecuzione del monitoraggio dei controlli di uptime 0,30 $/1000 esecuzioni‡ 1 milione di esecuzioni per progetto Google Cloud 1 ottobre 2022
Esecuzione del monitoraggio dei monitor sintetici 1,20 $/1000 esecuzioni* 100 esecuzioni per account di fatturazione 1 novembre 2023
Criteri di avviso 1,50 $ al mese per ogni condizione in un criterio di avviso
0,35 $ ogni 1.000.000 di serie temporali restituite dalla query di una condizione del criterio di avviso per una metrica♣		 Non applicabile Aprile 2025
†  Google Cloud Managed Service per Prometheus utilizza lo spazio di archiviazione di Cloud Monitoring per dati metriche creati esternamente e utilizza l'API Monitoring per recuperare questi dati. Managed Service per gli strumenti di misurazione Prometheus si basa su campioni importati anziché sui byte, per allinearsi alle convenzioni di Prometheus. Per ulteriori informazioni sulla misurazione basata su campioni, consulta Prezzi relativi a controllabilità e prevedibilità. Per gli esempi di calcolo, consulta la sezione Esempi di prezzi in base ai campioni importati.
 #  I campioni vengono conteggiati per ogni account di fatturazione.
 ‡  Le esecuzioni vengono addebitate all'account di fatturazione in cui sono definite. Per ulteriori informazioni, consulta la pagina Prezzi per l'esecuzione dei controlli di uptime.
 *  Le esecuzioni vengono addebitate all'account di fatturazione in cui sono definite. Per ogni esecuzione, potrebbero esserti addebitati costi aggiuntivi di altri servizi Google Cloud, inclusi servizi come le funzioni Cloud Run, Cloud Storage e Cloud Logging. Per informazioni su questi addebiti aggiuntivi, consulta il documento sui prezzi del rispettivo servizio Google Cloud.
 ♣  Per ulteriori informazioni, consulta Prezzi per gli avvisi.

Riepilogo dei prezzi di Cloud Trace

Funzionalità Prezzo Allocazione gratuita mensile Data di validità
Importazione in Trace $ 0,20/milione di intervalli Primi 2,5 milioni di intervalli per account di fatturazione 1° novembre 2018

Per informazioni dettagliate sui costi dei prodotti Google Cloud Observability, consulta le seguenti sezioni di questa pagina:

Per informazioni sui prezzi di GKE Enterprise, consulta GKE Enterprise.

Visualizzazione dell'utilizzo

Per visualizzare il tuo utilizzo attuale, vai alla pagina Report di fatturazione Cloud della console Google Cloud

Vai a Fatturazione Cloud

Sulla base dei dati sull'utilizzo attuale, puoi stimare l'importo delle fatture utilizzando il calcolatore prezzi.

Ad esempio, considera una configurazione in cui ogni istanza VM di Compute Engine genera 10 GiB di log addebitabili e 20 MiB di metriche addebitabili al mese. Il calcolatore prezzi consente di determinare i costi previsti per Cloud Monitoring e Cloud Logging:

1 VM 10 VM 100 VM 1000 VM
Costo mensile delle metriche $ 0,00 $ 12,90 $ 477,30 $ 5.121,30
Costo mensile di Logging $ 0,00 $ 25,00 $ 475,00 $ 4.975,00
Costo totale: $ 0,00 $ 37,90 $ 952,30 $ 10.096,30

Configurazione di un avviso di fatturazione

Per ricevere notifiche se gli addebiti fatturabili o previsti superano un budget, crea un avviso utilizzando la pagina Budget e avvisi della console Google Cloud:

  1. Nella console Google Cloud, vai alla pagina Fatturazione:

    Vai a Fatturazione.

    Puoi trovare questa pagina anche utilizzando la barra di ricerca.

    Se disponi di più account di fatturazione Cloud, esegui una delle seguenti 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.
  2. Nel menu di navigazione Fatturazione, seleziona Budget e avvisi.
  3. Fai clic su Crea budget.
  4. 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 Gestire budget e avvisi di spesa.

Cloud Logging

I bucket di log sono i container di Logging in cui sono archiviati i dati di log. Logging addebita un costo per il volume di dati di log archiviati nel bucket di log _Default e nei bucket di log definiti dall'utente. I prezzi si applicano ai log di rete non venduti quando il volume supera l'allocazione mensile gratuita e ai log di rete venduti.

Per il bucket di log _Default e per i bucket di log definiti dall'utente, Logging addebita anche quando i log vengono conservati per un periodo superiore al periodo di conservazione predefinito, che è di 30 giorni.

Logging non prevede costi aggiuntivi per il routing dei log, per l'utilizzo dell'API Cloud Logging, per la configurazione di ambiti di log o per i log archiviati nel bucket di log _Required, che ha un periodo di conservazione fisso di 400 giorni.

Questa sezione fornisce informazioni sui seguenti argomenti:

Per un riepilogo delle informazioni sui prezzi, vedi Riepilogo dei prezzi di Cloud Logging.

Per i limiti applicati all'uso di Logging, compresi i periodi di conservazione dei dati, consulta Quote e limiti.

Per visualizzare e comprendere i dati sull'utilizzo di Cloud Logging, consulta Stima delle fatture.

Modello di archiviazione di Cloud Logging

Per ogni progetto Google Cloud, Logging crea automaticamente due bucket di log: _Required e _Default. Per questi due bucket, Logging crea automaticamente sink di log denominati _Required e _Default che instradano i log ai bucket di log denominati corrispondenti. Non puoi disattivare o modificare il sink _Required. Puoi disabilitare o modificare il sink _Default per impedire al bucket _Default di archiviare nuovi log.

Puoi creare bucket di log definiti dall'utente in qualsiasi progetto Google Cloud. Puoi anche configurare i sink per instradare qualsiasi combinazione di log, anche tra progetti Google Cloud nella tua organizzazione Google Cloud, a questi bucket di log.

Per il bucket di log _Default e per i bucket di log definiti dall'utente, puoi configurare un periodo di conservazione personalizzato.

Puoi eseguire l'upgrade dei bucket di log per utilizzare Analisi dei log. L'upgrade di un bucket di log per utilizzare Analisi dei log non comporta alcun costo.

Per ulteriori informazioni sui bucket e sui sink di Cloud Logging, consulta Panoramica del routing e dell'archiviazione.

Prezzi di archiviazione

Logging non addebita alcun costo per i log archiviati nel bucket _Required. Non puoi eliminare il bucket _Required o modificare il sink _Required. Il bucket _Required archivia i seguenti log:

Logging addebita un costo per il volume pre-indicizzato dei dati di log archiviato nel bucket di log _Default e nei bucket di log definiti dall'utente, quando il volume totale supera l'allocazione mensile gratuita. Ogni scrittura di una voce di log nel bucket di log _Default o in un bucket di log definito dall'utente viene conteggiata ai fini dell'allocazione dello spazio di archiviazione. Ad esempio, se hai sink che instradano una voce di log a tre bucket di log, questa voce di log viene archiviata tre volte.

Prezzi di conservazione

La tabella seguente elenca i periodi di conservazione dei dati per i log archiviati nei bucket di log:

Bucket Periodo di conservazione predefinito Conservazione personalizzata
_Required 400 giorni Non configurabile
_Default 30 giorni Configurabile
Definito dall'utente 30 giorni Configurabile

Logging addebita i costi di conservazione quando i log vengono conservati per un periodo di tempo più lungo rispetto al periodo di conservazione predefinito. Non puoi configurare il periodo di conservazione per il bucket di log _Required. Non sono previsti costi di conservazione se i log vengono archiviati solo per il periodo di conservazione predefinito del bucket di log.

Se riduci il periodo di conservazione di un bucket di log, esiste un periodo di tolleranza di sette giorni in cui i log scaduti non vengono eliminati. Non puoi eseguire query o visualizzare i log scaduti. Tuttavia, in questi sette giorni, puoi ripristinare l'accesso completo estendendo il periodo di conservazione del bucket di log. I log archiviati durante il periodo di tolleranza vengono conteggiati ai fini dei costi di conservazione.

Se esegui il routing di una voce di log a più bucket di log, ti potrebbero essere addebitati costi di archiviazione e conservazione più volte. Ad esempio, supponi di instradare una voce di log al bucket di log _Default e a un bucket di log definito dall'utente. Inoltre, supponiamo che per entrambi i bucket venga configurato un periodo di conservazione personalizzato di oltre 30 giorni. Per questa configurazione, ricevi due costi di archiviazione e due costi di conservazione.

Log di rete vended

I log di rete forniti sono disponibili solo quando configuri la generazione dei log. I servizi che generano registri di rete venduti addebitano i costi per la generazione dei log. Se archivi questi log in un bucket di log o li instrada a un'altra destinazione supportata, sono previsti inoltre addebiti da Cloud Logging o dalla destinazione. Per informazioni sui costi di generazione dei log, consulta Prezzi della telemetria di rete.

Per informazioni su come abilitare i log di rete venduti, consulta Configurare i log di flusso VPC, Utilizzare il logging delle regole firewall e Cloud NAT: log e metriche.

Per trovare i log di rete venduti, nel filtro Esplora log in base ai seguenti nomi di log:

  • projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows
  • projects/PROJECT_ID/logs/compute.googleapis.com%2Ffirewall
  • projects/PROJECT_ID/logs/compute.googleapis.com%2Fnat_flows
  • projects/PROJECT_ID/logs/networkmanagement.googleapis.com%2Fvpc_flows

Riduci lo spazio di archiviazione dei log

Per ridurre i costi di archiviazione di Cloud Logging, configura filtri di esclusione nei 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. Quando una voce di log corrisponde a un filtro di esclusione di un sink, il sink non instrada la voce di log alla destinazione. Le voci di log escluse non vengono conteggiate ai fini dell'allocazione dello 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 consiste nell'instradare i log in uscita da Cloud Logging a una destinazione supportata. Cloud Logging non addebita costi per il routing dei log alle destinazioni supportate. Tuttavia, potrebbe esserti addebitato un costo quando i log vengono ricevuti da una destinazione:

Per informazioni sul routing dei log in Cloud Logging, consulta Routing dei log alle destinazioni supportate.

Prezzi delle metriche basate su log

Le metriche basate su log definite dal sistema vengono fornite per tutti i progetti Google Cloud e non sono addebitabili.

Le metriche basate su log definite dall'utente sono una classe di metriche personalizzate di Cloud Monitoring e sono addebitabili. Per i dettagli dei prezzi, consulta Metriche addebitabili.

Per ulteriori informazioni, consulta Panoramica delle metriche basate su log.

Crea un criterio di avviso sui byte di log mensili importati

Per creare un criterio di avviso che si attiva 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.

Nuovo campo condizione
Valore
Risorsa e metrica Nel menu Risorse, seleziona Globale.
Nel menu Categorie di metriche, seleziona Metrica basata su log.
Nel menu Metriche, seleziona Rileva byte di log mensili importati.
Filtro Nessuno.
In più serie temporali
Aggregazione di serie temporali		 sum
Finestra scorrevole 60 m
Funzione finestra temporale continua max
Campo Configura trigger avviso
Valore
Tipo di condizione Threshold
Trigger di avviso Any time series violates
Posizione soglia Above threshold
Valore soglia Sei tu a determinare il valore accettabile.
Finestra di nuovo test Il valore minimo accettabile è di 30 minuti.

Cloud Monitoring

Monitoring addebita i seguenti costi:

  • Metriche misurate in byte importati, quando i dati delle metriche importate superano l'allocazione mensile gratuita per le metriche.

    Le metriche non addebitabili non vengono conteggiate ai fini del limite di allocazione.

  • Metriche misurate in base al numero di campioni importati.

  • Chiamate API di lettura di Cloud Monitoring che superano l'allocazione mensile gratuita per le API.

    Le chiamate API di scrittura di Cloud Monitoring non vengono conteggiate ai fini del limite di allocazione.

  • Esecuzione dei controlli di uptime.

  • Esecuzione di monitoraggi sintetici.

  • Condizioni dei criteri di avviso misurate in base al numero di condizioni attive al mese.

  • Serie temporale restituita dalla query di una condizione del criterio di avviso.

In Monitoring, importazione fa riferimento al processo di scrittura di serie temporali in Monitoring. Ogni serie temporale include alcuni punti dati, che sono la base degli addebiti per l'importazione. Per le informazioni sui prezzi, consulta Prezzi di Cloud Monitoring.

Questa sezione fornisce le seguenti informazioni:

Per informazioni sui prezzi attuali, consulta Prezzi di Cloud Monitoring.

Per i limiti applicati all'uso di Monitoring, consulta Quote e limiti.

Per visualizzare l'utilizzo attuale, effettua una delle seguenti operazioni:

  • Nella console Google Cloud, vai alla pagina Fatturazione:

    Vai a Fatturazione.

    Puoi trovare questa pagina anche utilizzando la barra di ricerca.

  • Nella console Google Cloud, vai alla pagina  Impostazioni:

    Vai a Impostazioni

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

Sulla base dei dati sull'utilizzo attuale, puoi ottenere una stima delle fatture.

Metriche non addebitabili

I dati delle metriche di Google Cloud, GKE Enterprise e Knative non sono addebitabili. Le metriche non addebitabili (gratuite) includono:

Metriche addebitabili

Per i dati di tutte le metriche, ad eccezione di quelle elencate nella sezione Metriche non addebitabili, sono previsti addebiti. La maggior parte delle importazioni delle metriche viene addebitata in base al numero di byte, mentre alcune vengono addebitate in base al numero di campioni. Questi modelli di prezzi sono descritti nelle sezioni riportate di seguito.

I seguenti fattori contribuiscono ai costi di importazione:

  • Il tipo di punti dati (valori scalari o valori di distribuzione) raccolti dalle metriche.

    • Per informazioni sul tipo di dati associato a un tipo di metrica specifico, consulta l'elenco delle metriche.
    • Per informazioni sui tipi di dati scalari e di distribuzione, consulta la sezione Tipo di valore.

  • Il numero di punti dati scritti in serie temporali. Questo valore dipende dalla frequenza con cui i dati vengono campionati e dalla cardinalità dei tuoi dati. La cardinalità determina il numero di serie temporali generate per una combinazione di tipi di metriche e risorse monitorate. Per ulteriori informazioni, consulta la Cardinalità.

I valori per le etichette delle metriche e delle risorse che fanno parte della serie temporale non contribuiscono ai tuoi addebiti.

Metriche addebitate in base ai byte importati

Le seguenti metriche sono addebitabili e il relativo prezzo viene calcolato in base al numero di byte importati:

Ai fini della determinazione del prezzo, il volume di importazione viene calcolato come segue:

  • Per un tipo di dati scalare: 8 byte per ogni punto dati scritto in una serie temporale. In questa categoria rientrano le metriche dei contatori basate su log definite dall'utente.
  • Per un tipo di dati di distribuzione: 80 byte per ogni punto dati scritto in una serie temporale.

Per informazioni sui punti dati delle serie temporali, consulta Serie temporali: dati di una risorsa monitorata.

Metriche addebitate in base ai campioni importati

Le seguenti metriche sono addebitabili e il relativo prezzo viene calcolato in base al numero di campioni importati:

Ai fini della determinazione del prezzo, il numero di campioni viene calcolato come segue:

  • Per un tipo di dati scalare: 1 per ogni punto scritto in una serie temporale.
  • Per un tipo di dati di distribuzione: 2 per ogni punto scritto in una serie temporale, più 1 per ogni bucket di istogrammi che ha un conteggio diverso da zero.

Per informazioni sui punti dati delle serie temporali, consulta Serie temporali: dati di una risorsa monitorata.

Avvisi sulle metriche 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, consulta Configurazione di un avviso di fatturazione.

Esempi di prezzi in base ai byte importati

I seguenti esempi mostrano come effettuare una stima dei costi per la raccolta di dati delle metriche per le metriche addebitate in base ai byte importati. Questi esempi hanno lo scopo di illustrare i calcoli. Per una stima completa, utilizza il Calcolatore prezzi. Se accedi a questo strumento, utilizza il prodotto Google Cloud Observability per inserire i dati di metriche, logging e traccia.

Lo scenario di base è il seguente: hai alcune risorse monitorate (Compute Engine, Google Kubernetes Engine o App Engine) che ogni mese scrivono dati provenienti da alcune metriche.

Tra le variabili presenti in tutti gli scenari figurano:

  • Il numero di risorse.
  • Il numero di metriche.
  • Il tipo di metriche: Google Cloud o di altro tipo.
  • La frequenza con cui vengono scritti i dati delle metriche.

Gli esempi in questa sezione si riferiscono ai prezzi di Monitoring a partire da luglio 2020.

Background comune

Negli esempi di prezzi seguenti, si presume che ogni punto dati della metrica importato sia di tipo double, int64 o bool. Questi tipi vengono conteggiati come 8 byte ai fini della determinazione del prezzo. In un mese ci sono circa 730 ore (365 giorni / 12 mesi * 24 ore) o 43.800 minuti.

Per una metrica di scrittura di dati alla frequenza di 1 punto dati/minuto per un mese:

  • I punti dati totali sono 43.800
  • Il volume totale importato è:
    • 350.400 byte (43.800 punti dati * 8 byte)
    • 0,33416748 MiB (350.400 byte / 1.048.576 byte/MiB)

Per una metrica di scrittura di dati alla frequenza di 1 punto dati/ora per un mese:

  • I punti dati totali sono 730
  • Il volume totale importato è:
    • 5840 byte (730 punti dati * 8 byte)
    • 0,005569458 MiB (5840 byte / 1.048.576 byte/MiB)

Esempi

Scenario 1: hai 1000 risorse e ognuna scrive 75 metriche. Si tratta di metriche Google Cloud, che scrivono alla frequenza di 1 punto dati/minuto.

  • Importazione mensile: 25.063 MiB: 0,33416748 MiB per una metrica * 75.000 (ossia 1000 risorse, 75 metriche)
  • Costo approssimativo mensile: $ 0,00 (le metriche Google Cloud sono gratuite)
MiB importati Tariffa ($/MiB) Costo ($)
Nessun limite 0,00 $ 0,00
Totale 25.063 $ 0,00

Scenario 2: hai 1000 risorse e ognuna scrive 75 metriche personalizzate. Si tratta di metriche addebitabili che scrivono alla frequenza di 1 punto dati/minuto.

  • Importazione mensile: 25.063 MiB (come sopra)
  • Costo approssimativo mensile: $ 6427,55
MiB importati Tariffa ($/MiB) Costo ($)
150 0,00 $ 0,00
24.913 0,258 $ 6427,55
Totale 25.063 $ 6427,55

Scenario 3: hai 1000 risorse e ognuna scrive 75 metriche personalizzate. Si tratta di metriche addebitabili che scrivono alla frequenza di 1 punto dati/ora.

  • Importazione mensile: 418 MiB = 0,005569458 MiB per una metrica * 75.000
  • Costo approssimativo mensile: $ 69,14
MiB importati Tariffa ($/MiB) Costo ($)
150 0,00 $ 0,00
267 0,258 $ 69,14
Totale 417 $ 69,14

Scenario 4: hai 1 risorsa che scrive 500.000 metriche. Si tratta di metriche addebitabili che scrivono ognuna alla frequenza di 1 punto dati/minuto.

  • Importazione mensile: 167.084 MiB: 0,33416748 MiB per una metrica * 500.000
  • Costo approssimativo mensile: $ 35.890,98
MiB importati Tariffa ($/MiB) Costo ($)
150 0,00 $ 0,00
99.850 0,258 $ 25.761,30
67.084 0,151 $ 10.129,68
Totale 167.084 $ 35.890,98

Prezzi relativi a controllabilità e prevedibilità

I prezzi di Managed Service per Prometheus sono progettati 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.

  • Filtri: puoi utilizzare i filtri per ridurre il numero di esempi inviati all'datastore lobal del servizio. Per saperne di più, consulta Filtrare le metriche esportate. Utilizza le configurazioni di rietichettatura delle metriche nella configurazione dello scrape di Prometheus per eliminare le metriche al momento dell'importazione in base ai matcher delle etichette.

  • Mantieni locali i dati ad alta cardinalità e di scarso valore. Puoi eseguire Prometheus standard insieme al servizio gestito, utilizzando le stesse configurazioni di scape e conservare localmente i dati che non vale la pena inviarli al datastore globale del servizio.

I prezzi di Managed Service per Prometheus sono progettati 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 14 viene 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 ti venisse addebitato in base alle metriche, pagherai la cardinalità di un mese intero, il tutto una sola volta, 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 eseguite dall'utente, incluse quelle eseguite quando vengono eseguite le regole di registrazione di Prometheus, vengono addebitate tramite le chiamate 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.

Esempi di prezzi in base ai campioni importati

I seguenti esempi mostrano come stimare i costi per la raccolta di metriche addebitate in base ai campioni importati. Il ricaricamento basato su campioni viene utilizzato per Google Cloud Managed Service per Prometheus.

Questi esempi hanno lo scopo di illustrare le tecniche di calcolo, non per fornire dati di fatturazione.

Lo scenario di base è il seguente: hai un certo numero di container o pod che scrivono punti in un certo numero di serie temporali ogni mese. I dati possono essere costituiti da distribuzioni o valori scalari.

Tra le variabili presenti in tutti gli scenari figurano:

  • Il numero di container o pod.
  • Il numero di serie temporali.
  • L'eventualità che i dati siano costituiti da valori scalari o distribuzioni oppure da entrambi.
  • La frequenza con cui vengono scritti i dati.

Conteggio dei campioni

Prima di poter stimare i prezzi, devi sapere come conteggiare i campioni. Il numero di campioni conteggiati per un valore dipende da:

  • L'eventualità che il valore sia scalare o una distribuzione
  • La frequenza con cui vengono scritti i valori

Questa sezione descrive come stimare il numero di campioni scritti per una serie temporale nel periodo di fatturazione mensile.

In un mese, ci sono circa 730 ore (365 giorni/12 mesi * 24 ore), 43.800 minuti o 2.628.000 secondi.

Se una serie temporale scrive valori scalari, ciascun valore viene conteggiato come un campione. Il numero di esempi scritti in un mese dipende solo dalla frequenza di scrittura dei valori. Considera i seguenti esempi:

  • Per i valori scritti ogni 15 secondi:
    • Frequenza di scrittura: 1 valore/15 secondi = 1 campione/15 secondi
    • Campioni al mese: 175.200 (1 campione / 15 secondi * 2.628.000 secondi/mese)
  • Per i valori scritti ogni 60 secondi:
    • Frequenza di scrittura: 1 valore/60 secondi = 1 campione/60 secondi
    • Campioni al mese: 43.800 (1 campione/60 secondi * 2.628.000 secondi/mese)

Se una serie temporale scrive valori di distribuzione, ogni valore può contenere 2 + n campioni, dove n è il numero di bucket nell'istogramma. Il numero di esempi scritti in un mese dipende dal numero di bucket negli istogrammi e dalla frequenza di scrittura dei valori.

Ad esempio, ciascuna istanza di un istogramma di 50 bucket può contenere 52 campioni. Se i valori vengono scritti una volta ogni 60 secondi, un istogramma di 50 bucket scrive al massimo 2.277.600 campioni al mese. Se l'istogramma ha 100 bucket e viene scritto una volta ogni 60 secondi, ogni istogramma può contenere 102 campioni e scrive al massimo 4.467.600 campioni al mese.

La maggior parte delle serie temporali di distribuzione contiene un numero di esempi inferiore al massimo. In pratica, una percentuale compresa tra il 20% e il 40% dei bucket degli istogrammi è vuota. Questa percentuale è ancora più elevata per gli utenti con istogrammi sparsi, come quelli generati da Istio.

Quando conteggi i campioni per determinarne il prezzo, sono inclusi solo i bucket con valori non vuoti. Il numero massimo di campioni per istogramma è 2 + n. Se il 25% dei bucket è vuoto, il numero previsto di campioni è 2 + 0,75n per istogramma. Se il 40% dei bucket è vuoto, il numero previsto di campioni è 2 + 0,60n per istogramma.

I seguenti calcoli e la tabella di riepilogo mostrano il numero massimo di campioni e un numero previsto di campioni più realistico:

  • Per valori relativi a istogrammi con 50 bucket scritti ogni 15 secondi:

    • Frequenza di scrittura: 1 valore/15 secondi
    • Numero massimo di campioni:
      • Per istogramma: 52
      • Al mese: 9.110.400 (52 * 1 valore/15 secondi * 2.628.000 secondi/mese)
    • Campioni previsti, supponendo che il valore sia vuoto al 25%:
      • Per istogramma: 39,5 (2 + 0,75(50) o 2 + (50 - 12,5))
      • Al mese: 6.920.400 (39,5 * 1 valore/15 secondi * 2.628.000 secondi/mese)
    • Campioni previsti, supponendo che il 40% sia vuoto:
      • Per istogramma: 32 (2 + 0,6(50) o 2 + (50 - 20))
      • Al mese: 5.606.400 (32 * 1 valore/15 secondi * 2.628.000 secondi/mese)

  • Per valori relativi a istogrammi con 50 bucket scritti ogni 60 secondi:

    • Frequenza di scrittura: 1 valore/60 secondi
    • Numero massimo di campioni:
      • Per istogramma: 52
      • Al mese: 2.277.600 (52 * 1 valore/60 secondi * 2.628.000 secondi/mese)
    • Campioni previsti, supponendo che il valore sia vuoto al 25%:
      • Per istogramma: 39,5 (2 + 0,75(50) o 2 + (50 - 12,5))
      • Al mese: 1.730.100 (39,5 * 1 valore/60 secondi * 2.628.000 secondi/mese)
    • Campioni previsti, supponendo che il 40% sia vuoto:
      • Per istogramma: 32 (2 + 0,6(50) o 2 + (50 - 20))
      • Al mese: 1.401.600 (32 * 1 valore/60 secondi * 2.628.000 secondi/mese)

  • Per valori relativi a istogrammi con 100 bucket scritti ogni 15 secondi:

    • Frequenza di scrittura: 1 valore/15 secondi
    • Numero massimo di campioni:
      • Per istogramma: 102
      • Al mese: 17.870.400 102 * 1 valore/15 secondi * 2.628.000 secondi/mese
    • Campioni previsti, supponendo che il valore sia vuoto al 25%:
      • Per istogramma: 77 (2 + 0,75(100) o 2 + (100 - 25))
      • Al mese: 13.490.400 (77 * 1 valore/15 secondi * 2.628.000 secondi/mese)
    • Campioni previsti, supponendo che il 40% sia vuoto:
      • Per istogramma: 62 (2 + 0,6(100) o 2 + (100 - 40))
      • Al mese: 10.862.400 (62 * 1 valore/15 secondi * 2.628.000 secondi/mese)

  • Per valori relativi a istogrammi con 100 bucket scritti ogni 60 secondi:

    • Frequenza di scrittura: 1 valore/60 secondi
    • Numero massimo di campioni:
      • Per istogramma: 102
      • Al mese: 4.467.600 (102 * 1 valore/60 secondi * 2.628.000 secondi/mese)
    • Campioni previsti, supponendo che il valore sia vuoto al 25%:
      • Per istogramma: 77 (2 + 0,75(100) o 2 + (100 - 25))
      • Al mese: 3.372.600 (77 * 1 valore/60 secondi * 2.628.000 secondi/mese)
    • Campioni previsti, supponendo che il 40% sia vuoto:
      • Per istogramma: 62 (2 + 0,6(100) o 2 + (100 - 40))
      • Al mese: 2.715.600 (62 * 1 valore/60 secondi * 2.628.000 secondi/mese)

La tabella seguente riassume le informazioni precedenti:

Numero di bucket Tasso di scrittura Campioni al mese
(max)		 Campioni al mese
(25% vuoto)		 Esempi al mese
(40% vuoto)
50 1 campione/15 secondi 9.110.400 6.920.400 5.606.400
50 1 campione/60 secondi 2.277.600 1.730.100 1.401.600
100 1 campione/15 secondi 17.870.400 13.490.400 10.862.400
100 1 campione/60 secondi 4.467.600 3.372.600 2.715.600

Esempi

Per una stima dei prezzi, conteggia il numero di campioni scritti in un mese e applica i valori dei prezzi, stabiliti sulla base di un milione di campioni, per gli intervalli di importazione seguenti:

Intervallo di importazione Managed Service per Prometheus Massimo per intervallo
Fino a 50 miliardi (50.000 milioni) 0,06 $/milione 3000,00 $
Da 50 a 250 miliardi (250.000 milioni) 0,048 $/milione 9600,00 $
Da 250 a 500 miliardi (500.000 milioni) 0,036 $/milione 9000,00 $
Oltre 500 miliardi (500.000 milioni) 0,024 $/milione  

Il resto di questa sezione illustra gli scenari possibili.

Scenario 1: hai 100 container, ognuno dei quali scrive 1000 serie temporali scalari.

Variante A: se ogni serie temporale viene scritta ogni 15 secondi (1 campione/15 secondi), il numero di campioni scritti al mese è 17.520.000.000 (175.200 campioni/mese * 1000 serie temporali * 100 container), ovvero 17.520 milioni.

Variante B: se ogni serie temporale viene scritta ogni 60 secondi (1 campione/60 secondi), il numero di campioni scritti al mese è 4.380.000.000 (43.800 campioni/mese * 1000 serie temporali * 100 container), ovvero 4.380 milioni.

In entrambi i casi, ci sono meno di 50.000 milioni di esempi, pertanto viene applicata solo la prima tariffa. Le altre tariffe non prevedono alcun addebito.

Variante Campioni importati Intervallo di importazione Managed Service per Prometheus
(0,06 $, 0,048 $, 0,036 $, 0,024 $)
A (1 campione/15 sec)



Totale 		17.520 milioni



17.520 milioni 		Fino a 50.000 milioni
Fino a 250.000 milioni
Fino a 500.000 milioni
Oltre 500.000 milioni 		1051,20 $



1051,20$
B (1 campione/60 s)



Totale 		4380 milioni



4380 milioni 		Fino a 50.000 milioni
Fino a 250.000 milioni
Fino a 500.000 milioni
Oltre 500.000 milioni 		262,80 $



262,80$

Scenario 2: hai 1000 container, ognuno dei quali scrive 1000 serie temporali scalari.

Variante A: se ogni serie temporale è scritta ogni 15 secondi (1 campione/15 secondi), il numero di campioni scritti al mese è 175.200.000.000, ovvero 175.200 milioni:

  • I primi 50.000 milioni di campioni vengono addebitati alla prima tariffa.
  • I restanti 125.200 milioni di campioni vengono addebitati alla seconda tariffa.
  • Non vengono addebitati campioni alle altre tariffe.

Variante B: se ogni serie temporale viene scritta ogni 60 secondi (1 campione/60 secondi), il numero di campioni scritti al mese è 43.800.000.000, ovvero 43.800 milioni. Questo valore mensile è inferiore a 50.000 milioni di campioni, quindi si applica solo la prima tariffa.

Variante Campioni importati Intervallo di importazione Managed Service per Prometheus
(0,06 $, 0,048 $, 0,036 $, 0,024 $)
A (1 campione/15 sec)



Totale 		50.000 milioni
125.200 milioni


175.200 milioni 		Fino a 50.000 milioni
Fino a 250.000 milioni
Fino a 500.000 milioni
Oltre 500.000 milioni 		3000,00 $
6009,60 $


9009,60$
B (1 campione/60 s)



Totale 		43.800 milioni



43.800 milioni 		Fino a 50.000 milioni
Fino a 250.000 milioni
Fino a 500.000 milioni
Oltre 500.000 milioni 		2628,00 $



2628,00$

Scenario 3: hai 100 container, ognuno dei quali scrive 1000 serie temporali di distribuzione da 100 bucket. Prevedi che il 25% dei bucket sia vuoto.

Variante A: se ogni serie temporale viene scritta ogni 15 secondi (1 campione/15 secondi), il numero di campioni scritti al mese è 1.349.040.000.000 (13.490.400 campioni/mese * 1000 serie temporali * 100 container), ovvero 1.349.040 milioni.

  • I primi 50.000 milioni di campioni vengono addebitati alla prima tariffa.
  • I successivi 200.000 milioni di campioni vengono addebitati alla seconda tariffa.
  • I successivi 250.000 milioni di campioni vengono addebitati alla terza tariffa.
  • I restanti 749.040 milioni di campioni vengono addebitati alla quarta tariffa.

Variante B: se ogni serie temporale viene scritta ogni 60 secondi (1 campione/60 secondi), il numero di campioni scritti al mese è 337.260.000.000 (3.372.600 campioni/mese * 1000 serie temporali * 100 container), ovvero 337.260 milioni.

  • I primi 50.000 milioni di campioni vengono addebitati alla prima tariffa.
  • I successivi 200.000 milioni di campioni vengono addebitati alla seconda tariffa.
  • I restanti 87.260 milioni di campioni vengono addebitati alla terza tariffa.
Variante Campioni importati Intervallo di importazione Managed Service per Prometheus
(0,06 $, 0,048 $, 0,036 $, 0,024 $)
A (1 campione/15 sec)



Totale 		50.000 milioni
200.000 milioni
250.000 milioni
749.040 milioni
1.349.040 milioni 		Fino a 50.000 milioni
Fino a 250.000 milioni
Fino a 500.000 milioni
Oltre 500.000 milioni 		3000,00 $
9600,00 $
9000,00 $
17.976,96 $
39.576,96$
B (1 campione/60 sec)



Totale 		50.000 milioni
200.000 milioni
87.260 milioni

337.260 milioni 		Fino a 50.000 milioni
Fino a 250.000 milioni
Fino a 500.000 milioni
Oltre 500.000 milioni 		3000,00 $
9600,00 $
3141,36 $

15.741,36$

Scenario 4: hai 1000 container, ognuno dei quali scrive 10.000 serie temporali di distribuzione da 100 bucket. Prevedi che il 40% dei bucket sia vuoto.

Variante A: se ogni serie temporale viene scritta ogni 15 secondi (1 campione/15 secondi), il numero di campioni scritti al mese è 108.624.000.000.000 (10.862.400 campioni/mese * 10.000 serie temporali * 1000 container), ovvero 108.624.000 milioni.

  • I primi 50.000 milioni di campioni vengono addebitati alla prima tariffa.
  • I successivi 200.000 milioni di campioni vengono addebitati alla seconda tariffa.
  • I successivi 250.000 milioni di campioni vengono addebitati alla terza tariffa.
  • I restanti 108.124.000 milioni di campioni vengono addebitati alla quarta velocità.

Variante B: se ogni serie temporale viene scritta ogni 60 secondi (1 campione/60 secondi), il numero di campioni scritti al mese è 27.156.000.000.000 (2.715.600 campioni/mese * 10.000 serie temporali * 1000 container), ovvero 27.156.000 milioni.

  • I primi 50.000 milioni di campioni vengono addebitati alla prima tariffa.
  • I successivi 200.000 milioni di campioni vengono addebitati alla seconda tariffa.
  • I successivi 250.000 milioni di campioni vengono addebitati alla terza tariffa.
  • I restanti 26.656.000 milioni di campioni vengono addebitati alla quarta velocità.
Variante Campioni importati Intervallo di importazione Managed Service per Prometheus
(0,06 $, 0,048 $, 0,036 $, 0,024 $)
A (1 campione/15 sec)



Totale 		50.000 milioni
200.000 milioni
250.000 milioni
108.124.000 milioni
108.624.000 milioni 		Fino a 50.000 milioni
Fino a 250.000 milioni
Fino a 500.000 milioni
Oltre 500.000 milioni 		3000,00 $
9600,00 $
9000,00 $
2.594.976,00 $
2.616.576,00$
B (1 campione/60 s)



Totale 		50.000 milioni
200.000 milioni
250.000 milioni
26.656.000 milioni
27.156.000 milioni 		Fino a 50.000 milioni
Fino a 250.000 milioni
Fino a 500.000 milioni
Oltre 500.000 milioni 		3000,00 $
9600,00 $
9000,00 $
639.744,00 $
661.344,00$

Scenario 5: hai quanto segue:

  • 1000 container, ognuno dei quali scrive 1000 serie temporali scalari ogni 15 secondi. Il numero di campioni scritti al mese è 175.200.000.000, ovvero 175.200 milioni. (Scenario 2, variante A).

  • 1000 container, ognuno dei quali scrive 10.000 serie temporali di distribuzione da 100 bucket ogni 15 secondi. Prevedi che il 40% dei bucket sia vuoto. Il numero di campioni scritti al mese è 108.624.000.000.000 o 108.624.000 milioni. (Scenario 4, variante A).

Il numero totale di campioni al mese è 108.799.200 milioni (175.200 milioni + 108.624.000 milioni).

  • I primi 50.000 milioni di campioni vengono addebitati alla prima tariffa.
  • I successivi 200.000 milioni di campioni vengono addebitati alla seconda tariffa.
  • I successivi 250.000 milioni di campioni vengono addebitati alla terza tariffa.
  • I restanti 108.299.200 milioni di campioni vengono addebitati alla quarta velocità.
Variante Campioni importati Intervallo di importazione Managed Service per Prometheus
(0,06 $, 0,048 $, 0,036 $, 0,024 $)
2 A + 4 A



Totale 		50.000 milioni
200.000 milioni
250.000 milioni
108.299.200 milioni
108.799.200 milioni 		Fino a 50.000 milioni
Fino a 250.000 milioni
Fino a 500.000 milioni
Oltre 500.000 milioni 		3000,00 $
9600,00 $
9000,00 $
2.599.180,80 $
2.620.780,80$

Prezzi per l'esecuzione dei controlli di uptime (data di validità: 1° ottobre 2022)

Il monitoraggio addebita i costi per ogni esecuzione regionale di un controllo di uptime, oltre l'allocazione mensile gratuita di 1 milione di esecuzioni. Un controllo eseguito in tre regioni viene conteggiato come tre esecuzioni.

Il costo di esecuzione dei controlli di uptime è di 0,30 $/1000 esecuzioni. L'addebito viene visualizzato sulla fattura come SKU "CA14-D3DE-E67F" per "Monitoraggio dei controlli di uptime".

I seguenti esempi illustrano come stimare i costi per l'esecuzione dei controlli di uptime. Questi esempi hanno lo scopo di illustrare le tecniche di calcolo, non di fornire dati di fatturazione.

Conta le esecuzioni dei controlli di uptime

Per stimare il costo dei controlli di uptime, devi sapere quante esecuzioni regionali vengono eseguite in un mese. Monitoring addebita 0,30 $/1000 esecuzioni, con un'allocazione mensile gratuita di 1 milione di esecuzioni.

Per stimare il costo dei controlli di uptime, puoi utilizzare il seguente calcolo:

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

Per ogni controllo di uptime, il numero di esecuzioni dipende dalle seguenti scelte di configurazione:

  • La frequenza di esecuzione del controllo di uptime: ogni minuto, 5 minuti, 10 minuti o 15 minuti.

  • Il numero di regioni in cui viene eseguito il controllo di uptime.

  • Il numero di target per i quali è configurato il controllo di uptime. Se il controllo di uptime è configurato per una singola VM, il numero di target è 1. Se il controllo di uptime è configurato per un gruppo di risorse, il numero di destinazioni corrisponde al numero di risorse nel gruppo.

Quando configuri un controllo di uptime, specifichi una località per il controllo di uptime e ogni località viene mappata a una o più regioni. La tabella seguente mostra le località valide per i controlli di uptime e le regioni a cui mappano:

Posizione per la configurazione del controllo di uptime Include le regioni Google Cloud
ASIA_PACIFIC asia-southeast1
EUROPE europe-west1
SOUTH_AMERICA southamerica-east1
USA us-central1, us-east4 e us-west1
GLOBAL Tutte le regioni incluse in altre località

Devi configurare i controlli di uptime in modo che vengano eseguiti in almeno tre regioni.

Per stimare il numero di esecuzioni per un controllo di uptime, è necessario sapere quante regioni sono coperte dalla località del controllo di uptime:

  • ASIA_PACIFIC, EUROPE e SOUTH_AMERICA includono ciascuna 1 regione.
  • USA include tre regioni.
  • GLOBAL include sei regioni.

In un mese ci sono circa 730 ore (365 giorni / 12 mesi * 24 ore) o 43.800 minuti.

  • Un controllo di uptime configurato per essere eseguito una volta al minuto in USA viene eseguito in tre regioni. Se questo controllo di uptime è configurato per controllare una singola VM, questo controllo di uptime viene eseguito 131.400 (3 * 43.800) volte al mese. Se il controllo è configurato per controllare un gruppo di risorse di 10 membri, il controllo di uptime viene eseguito 1.314.000 (10 * 131.400) volte al mese.

  • Un controllo di uptime configurato per essere eseguito una volta al minuto in ASIA_PACIFIC e EUROPE, mentre USA viene eseguito in 5 regioni. Questo controllo di uptime viene eseguito 219.000 volte in un mese se configurato per un singolo target.

La tabella seguente mostra i conteggi delle esecuzioni orarie e mensili per un singolo controllo di uptime configurato per l'esecuzione con frequenze diverse in numeri diversi di regioni:

Frequenza di esecuzione dei controlli, una volta ogni:
 Numero di regioni
 Esecuzioni orarie
per target		 Esecuzioni mensili
per target
1 minuto 3
4
5
6 		180
240
300
360 		131.400
175.200
219.000
262.800
5 minuti 3
4
5
6 		36
48
60
72 		26.280
35.040
43.000
52.660
10 minuti 3
4
5
6 		18
24
30
36 		13.140
17.520
21.900
26.280
15 minuti 3
4
5
6 		12
16
20
24 		8.760
11.680
14.600
17.520

Esempi

Per stimare i prezzi, determina le esecuzioni mensili totali e sottrai 1.000.000. Eventuali esecuzioni rimanenti vengono addebitate a 0,30 $/1000 esecuzioni, quindi moltiplica le esecuzioni rimanenti per 0,0003.

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

Scenario 1: hai 1 controllo di uptime nella località USA che controlla 1 VM una volta al minuto. Questo controllo viene eseguito in tre regioni. Il controllo viene eseguito 131.400 volte al mese e non costa nulla.

Esecuzioni mensili totali
 Esecuzioni mensili addebitabili
(oltre 1.000.000)		 Costo
(0,30 $/1000 esecuzioni)
131.400 0 $ 0,00

Scenario 2: hai 1 controllo di uptime nella località USA che controlla un gruppo di risorse di 10 membri una volta al minuto. Questo controllo viene eseguito in tre regioni. Il controllo viene eseguito 10 * 131.400 volte al mese e costa 94,20 $/mese. L'unica differenza tra questo scenario e lo scenario 1 è il numero di target.

Esecuzioni mensili totali
 Esecuzioni mensili addebitabili
(oltre 1.000.000)		 Costo
(0,30 $/1000 esecuzioni)
1.314.000 (10 obiettivi) 314.000 94,20 $

Scenario 3: hai 10 controlli di uptime GLOBAL, ognuno dei quali controlla 1 VM una volta al minuto. Questi controlli vengono eseguiti in 6 regioni, quindi ogni controllo viene eseguito 262.800 volte al mese. Il totale delle esecuzioni mensili è 2.628.000 (10 * 262.800). Questo scenario costa 488,40 $/mese.

Esecuzioni mensili totali
 Esecuzioni mensili addebitabili
(oltre 1.000.000)		 Costo
(0,30 $/1000 esecuzioni)
2.628.000 1.628.000 488,40 $

Scenario 4: hai 5 controlli di uptime nella località USA che controllano una VM una volta ogni 5 minuti. Questi controlli vengono eseguiti in tre regioni, quindi ogni controllo viene eseguito 26.280 volte al mese. Il totale delle esecuzioni mensili per questo insieme di controlli è 105.120 (4 * 26.280).

Sono inoltre disponibili 2 controlli di uptime GLOBAL che controllano una VM una volta ogni 15 minuti. Questi controlli vengono eseguiti in 6 regioni, quindi ogni controllo viene eseguito 17.520 volte al mese. Il totale delle esecuzioni mensili per questo insieme di controlli è 35.040 (2 * 17.520).

Il totale delle esecuzioni mensili è 140.160 (105.120 + 35.040). Questo scenario non costa nulla.

Esecuzioni mensili totali
 Esecuzioni mensili addebitabili
(oltre 1.000.000)		 Costo
(0,30 $/1000 esecuzioni)
140.160 0 $ 0,00

Prezzi per l'esecuzione di monitoraggio sintetico (data di validità: 1° novembre 2023)

Cloud Monitoring addebita i costi per ogni esecuzione di un monitoraggio sintetico, oltre l'allocazione gratuita mensile di 100 esecuzioni per account di fatturazione. Ad esempio, se crei tre monitor sintetici e li configuri ciascuno in modo che venga eseguito ogni 5 minuti, il numero totale di esecuzioni al mese è 26.784:

Number of executions per month =  3 synthetic monitors * 1 execution per monitor per 5 minutes *
                                  1440 minutes per day * 31 days per month
                               =  26,784

Per determinare il numero di esecuzioni addebitabili, sottrai l'allocazione gratuita dal numero totale di esecuzioni, quindi moltiplica il risultato per il costo:

Esecuzioni mensili totali
 Esecuzioni mensili addebitabili
(oltre 100 esecuzioni per account di fatturazione)		 Costo
(1,20 $/1000 esecuzioni)
26.784 26.684 32,02 $

Prezzi per gli avvisi

A partire da aprile 2025, Cloud Monitoring inizierà ad addebitare i costi degli avvisi. Il modello di determinazione del prezzo è il seguente:

  • 1,50 $ al mese per ogni condizione in un criterio di avviso.
  • 0,35 $ per 1.000.000 di serie temporali restituite dalla query di una condizione del criterio di avviso per la metrica.

Questa sezione fornisce le seguenti informazioni:

Definizioni

  • Condizione: la condizione di un criterio di avviso descrive quando una risorsa o un gruppo di risorse si trova in uno stato che richiede una risposta.

    L'addebito si riferisce a ogni condizione a 1,50 $al mese. Per interrompere l'addebito per una condizione, devi eliminare il criterio di avviso. Posticipare o disattivare il criterio non ti impedisce di ricevere addebiti.

  • Criteri di avviso relativi alle metriche e basati su log: i criteri di avviso che utilizzano qualsiasi tipo di condizione tranne le condizioni di corrispondenza dei log sono criteri di avviso relativi alle metriche, mentre le condizioni dei criteri di avviso delle metriche restituiscono serie temporali. Durante ogni periodo di esecuzione, le condizioni nei criteri di avviso delle metriche eseguono le loro query sul datastore di Cloud Monitoring. Le serie temporali restituite vengono quindi valutate in base a una soglia per determinare se viene attivato il criterio di avviso.

    I criteri di avviso basati su log utilizzano condizioni di corrispondenza dei log. Le condizioni di corrispondenza dei log non restituiscono serie temporali.

  • Periodo di esecuzione: la frequenza con cui Cloud Monitoring esegue la condizione. Per la maggior parte dei tipi di condizione, questo valore è di 30 secondi e non può essere modificato. Le condizioni che utilizzano una query PromQL possono impostare questo periodo. Per ulteriori informazioni, consulta Aumentare la durata del periodo di esecuzione (solo PromQL).

  • Serie temporali restituite: durante ogni periodo di esecuzione, un criterio di avviso della metrica esegue la query della sua condizione sul datastore di Cloud Monitoring. Cloud Monitoring restituisce i dati delle serie temporali in risposta a ogni query. Ogni serie temporale nella risposta viene conteggiata come una serie temporale restituita.

    Il numero di serie temporali restituite in un mese è determinato da tre fattori:

    • La forma e l'ambito dei dati sottostanti.
    • I filtri e le aggregazioni che utilizzi nella query della condizione.
    • Il periodo di esecuzione.

    Ad esempio, considera una configurazione in cui:

    • 100 macchine virtuali (VM), in cui ogni VM appartiene a un servizio.
    • Ogni VM emette una metrica, metric_name, che ha un'etichetta con 10 valori.
    • Cinque servizi in totale.

    Dal momento che hai 100 VM, ciascuna delle quali può generare 10 serie temporali (una per ogni valore di etichetta), hai un totale di 1000 serie temporali sottostanti. Ogni VM contiene anche un'etichetta simile ai metadati che registra a quale dei cinque servizi appartiene la VM.

    Puoi configurare i criteri di avviso nei seguenti modi utilizzando PromQL, dove ogni configurazione genera un numero diverso di serie temporali restituite per periodo di esecuzione:

    Configurazione Query PromQL Serie temporali restituite per periodo
    Nessuna aggregazione rate(metric_name[1m]) 1000
    Aggrega nella VM sum by (vm) (rate(metric_name[1m])) 100
    Aggrega in valore etichetta sum by (label_key) (rate(metric_name[1m])) 10
    Aggrega al servizio sum by (service) (rate(metric_name[1m])) 5
    Aggrega per etichetta valore e servizio sum by (service, label_key) (rate(metric_name[1m])) 50
    Aggrega nel parco risorse sum (rate(metric_name[1m])) 1
    Filtra e aggrega in una VM sum (rate(metric_name{vm="my_vm_name"}[1m])) 1
    Filtra e aggrega in un servizio sum (rate(metric_name{service="my_service_name"}[1m])) 1

Esempi di prezzi

I seguenti esempi si verificano in un mese di 30 giorni, generando i seguenti periodi di valutazione:

  • 86.400 periodi di esecuzione di 30 secondi al mese
  • 172.800 periodi di esecuzione di 15 secondi al mese (solo query PromQL)

Esempio 1: un unico criterio, aggregazione alla VM, 30 secondi

In questo esempio, utilizza le seguenti configurazioni:

Dati

  • 100 VM
  • Ogni VM emette una metrica, metric_name
  • metric_name ha un'etichetta con 10 valori
Criterio di avviso
  • Una condizione di avviso
  • La condizione viene aggregata a livello di VM
  • Periodo di esecuzione di 30 secondi
Costi risultanti
  • Costo della condizione: 1 condizione * 1,50 $ al mese = 1,50 $ al mese
  • Costo di 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: 100 criteri (uno per VM), aggregazione nella VM, 30 secondi

In questo esempio, utilizza le seguenti configurazioni:

Dati

  • 100 VM
  • Ogni VM emette una metrica, metric_name
  • metric_name ha un'etichetta con 10 valori
Criteri di avviso
  • 100 condizioni
  • Ogni condizione viene filtrata e aggregata in una VM
  • Periodo di esecuzione di 30 secondi
Costi risultanti
  • Costo condizione: 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

Esempio 3: un unico criterio, aggregazione alla VM, 15 secondi

In questo esempio, utilizza le seguenti configurazioni:

Dati

  • 100 VM
  • Ogni VM emette una metrica, metric_name
  • metric_name ha un'etichetta con 10 valori
Criterio di avviso
  • Una condizione di avviso PromQL
  • La condizione viene aggregata a livello di VM
  • Periodo di esecuzione di 15 secondi
Costi risultanti
  • Costo della condizione: 1 condizione * 1,50 $ al mese = 1,50 $ al mese
  • Costo delle serie temporali: 100 serie temporali restituite per periodo * 172.800 periodi al mese = 17,3 milioni di serie temporali restituite al mese * 0,35 $ per milione di serie temporali = 6,05 $ al mese
  • Costo totale: 7,55$al mese

Esempio 4: aggrega un criterio per ciascun servizio, 30 secondi

In questo esempio, utilizza le seguenti configurazioni:

Dati

  • 100 VM, ciascuna delle quali appartiene a un servizio
  • Cinque servizi in totale
  • Ogni VM emette una metrica, metric_name
  • metric_name ha un'etichetta con 10 valori
Criterio di avviso
  • Una condizione
  • La condizione viene aggregata al livello di servizio
  • Periodo di esecuzione di 30 secondi
Costi risultanti
  • 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: aggrega un criterio nella VM; cardinalità di base più alta per VM, 30 secondi

In questo esempio, utilizza le seguenti configurazioni:

Dati

  • 100 VM
  • Ogni VM emette una metrica, metric_name
  • metric_name ha 100 etichette con 1000 valori ciascuna
Criterio di avviso
  • Una condizione
  • La condizione viene aggregata a livello di VM
  • Periodo di esecuzione di 30 secondi
Costi risultanti
  • Costo della condizione: 1 condizione * 1,50 $ al mese = 1,50 $ al mese
  • Costo di 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.

Esempio 6: aggrega un criterio nella VM; unisci due metriche in una condizione di 30 secondi

In questo esempio, utilizza le seguenti configurazioni:

Dati

  • 100 VM
  • Ogni VM emette due metriche, metric_name_1 e metric_name_2
  • Entrambe le metriche hanno un'etichetta con 10 valori ciascuna
Criterio di avviso
  • Una condizione
  • La condizione viene aggregata a livello di VM
  • La condizione utilizza un operatore OR per unire le metriche
  • Periodo di esecuzione di 30 secondi
Costi risultanti
  • Costo della condizione: 1 condizione * 1,50 $ al mese = 1,50 $ al mese
  • Costo delle serie temporali: 2 metriche * 100 serie temporali restituite per metrica per periodo * 86.400 periodi al mese = 17,3 milioni di serie temporali restituite al mese * 0,35 $ per milione di serie temporali = 6,05 $ al mese
  • Costo totale: 7,55$al mese

Esempio 7: 100 criteri di avviso basati su log

In questo esempio, utilizza la seguente configurazione:

Criteri di avviso

  • 100 condizioni (una condizione per criterio di avviso basato su log)
Costi risultanti
  • Costo della condizione: 100 condizioni * $1,50 al mese = $ 150,00 al mese
  • Costo per serie temporali: $0 (i criteri di avviso basati su log non restituiscono serie temporali.)
  • Costo totale: 150,00$al mese

Suggerimenti per ridurre la fattura per gli avvisi

Quando configuri i criteri di avviso basati su metriche, utilizza i seguenti suggerimenti per ridurre il costo delle fatture per gli avvisi.

Consolida i criteri di avviso per operare su più risorse

A causa del costo di 1,50 $per condizione, è più conveniente utilizzare un singolo criterio di avviso per monitorare più risorse che utilizzare un solo criterio di avviso per monitorare ogni risorsa. Ad esempio, confronta Esempio 1 con Esempio 2: in entrambi gli esempi viene monitorato lo stesso numero di risorse. Tuttavia, l'esempio 2 utilizza 100 criteri di avviso, mentre l'esempio 1 utilizza un solo criterio di avviso. Di conseguenza, l'esempio 1 costa quasi 150 $in meno al mese.

Aggrega solo in base al livello per cui devi inviare l'avviso

L'aggregazione a livelli di granularità più elevati comporta costi maggiori rispetto all'aggregazione a livelli di granularità inferiori. Ad esempio, l'aggregazione a livello di progetto Google Cloud è più economica rispetto all'aggregazione a livello di cluster e l'aggregazione a livello di cluster è più economica che aggregare a livello di cluster e spazio dei nomi.

Confronta l'esempio 1 con l'esempio 4: entrambi gli esempi operano sugli stessi dati sottostanti e hanno un unico criterio di avviso. Tuttavia, poiché il criterio di avviso nell'esempio 4 aggrega il servizio, è meno costoso del criterio di avviso nell'esempio 1, che aggrega 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é il criterio di avviso nell'esempio 1 e nell'esempio 5 si aggregano entrambi nella VM, e poiché il numero di VM è lo stesso in entrambi gli esempi, il prezzo degli esempi è equivalente.

Quando configuri i criteri di avviso, scegli i livelli di aggregazione più adatti al tuo caso d'uso. Ad esempio, se vuoi creare avvisi sull'uso della CPU, potresti aggregarli a livello di VM e CPU. Se vuoi ricevere avvisi sulla latenza per endpoint, potresti voler aggregare i dati a livello di endpoint.

Non generare avvisi su dati non elaborati e non aggregati

Il monitoraggio utilizza un sistema di metriche dimensionali, in cui ogni metrica ha una cardinalità totale uguale al numero di risorse monitorate moltiplicato per il numero di combinazioni di etichette su quella metrica. Ad esempio, se hai 100 VM che emettono una metrica e questa ha 10 etichette con 10 valori ciascuna, la cardinalità totale è 100 * 10 * 10 = 10.000.

Per via della scalabilità della cardinalità, gli avvisi sui dati non elaborati possono essere estremamente costosi. Nell'esempio precedente, sono state restituite 10.000 serie temporali per ogni periodo di esecuzione. Tuttavia, se aggrega i dati 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 consentono anche di aumentare le 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 il criterio di avviso rimane invariato. Se invece esegui l'aggregazione nella VM, nonostante l'aumento della cardinalità sottostante, vengono comunque restituite solo 100 serie temporali.

Escludi le risposte non necessarie

Configura le condizioni per valutare solo i dati necessari per le tue esigenze di avviso. Se non intervieni per risolvere un problema, escludi il problema dai criteri di avviso. Ad esempio, non avrai bisogno di avvisare su una VM di sviluppo di uno stagista.

Per ridurre gli avvisi e i costi inutili, puoi filtrare le serie temporali non importanti. Puoi utilizzare le etichette dei metadati di Google Cloud per taggare le risorse con categorie e quindi filtrare le categorie di metadati non necessari.

Utilizzare 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.

La limitazione a un numero massimo di serie temporali potrebbe causare 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 in violazione si verifica al di fuori delle prime N serie temporali, i tuoi incidenti potrebbero chiudersi automaticamente nonostante le serie temporali escluse violano ancora la soglia.
  • Le query sulla condizione potrebbero non mostrarti un contesto importante, come le serie temporali di riferimento che funzionano come previsto.

Per mitigare questi rischi, scegli valori elevati per N e utilizza l'operatore dei flussi principali solo nei criteri di avviso che valutano molte serie temporali, ad esempio gli avvisi per singoli container Kubernetes.

Aumentare 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 generano un numero inferiore di serie temporali restituite al mese. Ad esempio, una query su una condizione con un intervallo di 15 secondi viene eseguita il doppio delle volte rispetto a una query con un intervallo di 30 secondi, mentre una query con un intervallo di 1 minuto viene eseguita la metà di una query con un intervallo di 30 secondi.

Disattivazione in corso…

Se hai già un contratto Google Cloud che non scade fino ad aprile 2025, puoi ritardare la fatturazione per gli avvisi fino alla scadenza del contratto richiedendo un'esenzione al team di fatturazione degli avvisi di Cloud Monitoring. Le esenzioni per i clienti con contratti attivi verranno valutate caso per caso.

Puoi richiedere un'esenzione fino al 1° novembre 2024. Per richiedere un'esenzione dalla fatturazione fino al rinnovo del contratto, compila il modulo di richiesta di esenzione dalla fatturazione.

Error Reporting

I dati di errore possono essere segnalati nel progetto Google Cloud utilizzando l'API Error Reporting o l'API Cloud Logging.

Non ci sono costi per l'utilizzo di Error Reporting. Tuttavia, potrebbero esserti addebitati i costi di Cloud Logging perché le voci di log vengono generate e quindi archiviate da Cloud Logging.

Per i limiti applicati all'uso di Error Reporting, consulta Quote e limiti.

Cloud Profiler

Non sono previsti costi associati all'utilizzo di Cloud Profiler.

Per i limiti applicati all'uso di Profiler, consulta Quote e limiti.

Cloud Trace

Gli addebiti di Trace si basano sul numero di intervalli di traccia importati e scansionati. Quando i dati di latenza vengono inviati a Trace, vengono pacchettizzati come traccia, composta da intervalli che vengono importati dal backend di Cloud Trace. Quando visualizzi i dati di traccia, gli intervalli archiviati vengono scansionati da Cloud Trace. Questa sezione fornisce le seguenti informazioni:

  • Definizione di intervalli di traccia addebitabili e non addebitabili
  • Esempio di prezzo
  • Informazioni su come ridurre l'importazione di intervalli di traccia.
  • Impostazioni per un criterio di avviso che invia una notifica se l'importazione di intervalli di traccia raggiunge una determinata soglia.

Per informazioni sui prezzi attuali, consulta Prezzi di Cloud Trace.

Per i limiti applicati all'uso di Trace, consulta Quote e limiti.

Per informazioni su come visualizzare l'utilizzo attuale o passato, consulta la pagina Stima delle fatture.

Intervalli di traccia non addebitabili

I prezzi di Cloud Trace non si applicano agli intervalli generati automaticamente da App Engine Standard, funzioni Cloud Run o Cloud Run: l'importazione di queste tracce non è addebitabile.

Intervalli di traccia a pagamento

Per l'importazione di intervalli di traccia, ad eccezione di quelli elencati nella sezione Intervalli di traccia non addebitabili sono previsti addebiti in base al volume importato. Sono compresi gli intervalli creati dalla strumentazione aggiunta all'applicazione standard di App Engine.

Esempi di prezzi

L'esempio si riferisce ai prezzi di Trace a partire da luglio 2020.

  • Se importi 2 milioni di intervalli in un mese, il costo è pari a $ 0 (i primi 2,5 milioni di intervalli importati in un mese sono gratuiti).
  • Se importi 14 milioni di intervalli in un mese, il costo è pari a $ 2,30 (I primi 2,5 milioni di intervalli in un mese sono gratuiti, mentre il costo degli intervalli rimanenti viene così calcolato: 11,5 milioni di intervalli * $ 0,20 / milione di intervalli = $ 2,30).
  • Se importi 1 miliardo di intervalli in un mese, il costo è pari a $ 199 (I primi 2,5 milioni di intervalli in un mese sono gratuiti, mentre il costo degli intervalli rimanenti viene così calcolato: 997,5 milioni di intervalli * $ 0,20 / milione di intervalli = $ 199,50).

Riduzione dell'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.

Avvisi sugli intervalli mensili importati

Per creare un criterio di avviso che si attiva quando gli intervalli mensili importati di Cloud Trace superano un limite definito dall'utente, utilizza le impostazioni seguenti.

Nuovo campo condizione
Valore
Risorsa e metrica Nel menu Risorse, seleziona Globale.
Nel menu Categorie di metriche, seleziona Fatturazione.
Nel menu Metriche, seleziona Intervalli di tracce mensili importati.
Filtro
In più serie temporali
Aggregazione di serie temporali		 sum
Finestra scorrevole 60 m
Funzione finestra temporale continua max
Campo Configura trigger avviso
Valore
Tipo di condizione Threshold
Trigger di avviso Any time series violates
Posizione soglia Above threshold
Threshold value Sei tu a determinare il valore accettabile.
Finestra di nuovo test Il valore minimo accettabile è di 30 minuti.

GKE Enterprise

Non è previsto alcun costo per i log di sistema e le metriche di GKE Enterprise. I log del piano di controllo, le metriche del piano di controllo e un sottoinsieme selezionato di metriche di stato Kube sono abilitati per impostazione predefinita per i cluster GKE su Google Cloud registrati al momento della creazione del cluster in un progetto abilitato per GKE Enterprise. I log del piano di controllo sono soggetti agli addebiti di Cloud Logging, mentre le metriche attive per impostazione predefinita sono incluse senza costi aggiuntivi.

Per l'elenco delle metriche e dei log GKE inclusi, consulta Quali log vengono raccolti e Metriche disponibili.

In un cluster Google Distributed Cloud, i log di sistema e le metriche di GKE Enterprise includono quanto segue:

  • Log e metriche di tutti i componenti in un cluster di amministrazione
  • Log e metriche dei componenti nei seguenti spazi dei nomi di un cluster utente: kube-system, gke-system, gke-connect, knative-serving, istio-system, monitoring-system, config-management-system, gatekeeper-system, cnrm-system

Domande frequenti

Quali funzionalità dei prodotti sono gratuite?

I prezzi di utilizzo dei prodotti Google Cloud Observability variano in base al volume di dati. A parte i costi del volume di dati descritti in questa pagina, l'utilizzo di tutte le funzionalità aggiuntive del prodotto Google Cloud Observability è gratuito.

Quanto dovrò pagare?

Per stimare i costi di utilizzo, consulta la pagina Stima delle fatture.

Per ricevere assistenza in merito alle domande sulla fatturazione, consulta la pagina Domande sulla fatturazione.

Come faccio a leggere i dettagli del mio utilizzo?

Varie metriche ti consentono di approfondire e comprendere il volume di metriche e log con Metrics Explorer. Per i dettagli, visita la pagina relativa alla visualizzazione dell'utilizzo dettagliato in Metrics Explorer.

Se ti interessa sapere come gestire i costi, consulta questi post del blog:

In che modo gli ambiti delle metriche e di log influiscono sulla fatturazione?

Per la maggior parte, gli ambiti delle metriche e gli ambiti di log non influiscono sulla fatturazione. I log e le metriche vengono addebitati in base al progetto, all'account di fatturazione, alla cartella o all'organizzazione che riceve i dati. L'ambito delle metriche per un progetto definisce la raccolta delle risorse di cui il progetto può visualizzare e monitorare. Quando definisci un ambito delle metriche, non influisce sulla risorsa che riceve i dati sulle metriche né causa la duplicazione dei dati. Analogamente, un ambito di log elenca solo le risorse che archiviano o instradano le voci di log che vuoi visualizzare.

Ad esempio, supponiamo che la tua organizzazione abbia 100 macchine virtuali (VM): 60 VM sono ospitate da Project-A e 40 VM si trovano in Project-B. Project-A riceve e archivia le metriche per le proprie VM e vengono addebitati costi quando le metriche sono addebitabili. Allo stesso modo, Project-B riceve e archivia le metriche per le sue VM e vengono addebitati i costi quando le metriche sono addebitabili. Se crei un ambito delle metriche che include Project-A e Project-B, puoi visualizzare le metriche combinate per le tue 100 VM. Ora puoi visualizzare solo le metriche di Project-A, solo le metriche di Project-B o la combinazione di metriche. Anche se hai due modi per visualizzare le metriche di Project-A, non ci sono implicazioni in termini di fatturazione.

Che cosa succede se supero le allocazioni gratuite?

Per l'eventuale utilizzo che supera le allocazioni gratuite, la fatturazione avviene in modo automatico. Non perderai alcun log o metrica. Per una migliore comprensione dei costi potenziali, consulta la pagina Stima delle fatture.

Puoi creare un criterio di avviso per monitorare l'utilizzo e ricevere notifiche quando ti avvicini alla soglia di fatturazione.

Nei miei progetti ho un volume elevato di log Google Cloud che non uso. Temo gli addebiti per questi log. Come faccio a evitarli?

Per controllare i log che vengono importati in Logging puoi usare l'esclusione dei log. Per i dettagli, consulta Ridurre l'utilizzo dei log.

I servizi che inviano i log al mio progetto riceveranno un messaggio di errore se i log vengono esclusi?

No, i servizi che inviano le voci di log non possono stabilire se le voci vengono importate in Logging o meno.

Mi verranno addebitati costi doppi per i log di flusso Virtual Private Cloud?

Se invii i tuoi log di flusso VPC a Logging, i costi di generazione dei log di flusso VPC vengono esclusi e si applicano solo i costi di Logging. Tuttavia, se invii e poi escludi i log di flusso VPC da Logging, si applicano i costi dei log di flusso VPC. Per ulteriori informazioni, consulta il Calcolatore prezzi di Google Cloud, quindi seleziona la scheda "Cloud Load Balancing e servizi di rete".

1 Ai fini della determinazione del prezzo, tutte le unità vengono trattate come misure binarie, ad esempio, come mebibyte (MiB o 220 byte) o gibibyte (GiB o 230 byte).

2 Non è previsto alcun costo per le metriche di Google Cloud o per le metriche GKE Enterprise misurate fino a 1 punto dati al minuto, ovvero alla risoluzione attuale più elevata. In futuro potrebbero venire addebitati i costi delle metriche con risoluzioni più elevate.

3 Le metriche di processo vengono attualmente raccolte a una frequenza predefinita di una volta al minuto, che non può essere modificata. In genere, i dati cambiano lentamente, quindi queste metriche al momento sono sovracampionate. Pertanto, l'addebito delle metriche di processo al 5% della tariffa standard è coerente con la tariffa standard se le metriche vengono campionate ogni 20 minuti. Agli utenti che raccolgono 100 MiB di dati da queste metriche vengono addebitati solo 5 MiB.

Passaggi successivi

Richiedi un preventivo personalizzato

Con i prezzi con pagamento a consumo di Google Cloud, paghi solo per i servizi che utilizzi. Per ricevere un preventivo personalizzato per la tua organizzazione, contatta il nostro team di vendita.
Contatta il team di vendita