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 dipendono dal volume o dall'utilizzo dei dati. Puoi iniziare con le allocazioni per l'utilizzo gratuito dei dati 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 per log*
ad eccezione dei log di rete di terzi.		 0, 50 $/GiB;
addebito una tantum per lo streaming dei log nei bucket di log per l'indicizzazione, le 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 di terzi† 0,25 $/GiB;
addebito una tantum per lo streaming dei log di telemetria di rete nello spazio di archiviazione dei bucket di log per l'indicizzazione, l'interrogazione con 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:
Conservazione di 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 le dimensioni effettive delle voci di log prima dell'indicizzazione. Non sono previsti costi per l'archiviazione dei log archiviati nel _Required bucket di log.
 †  I log di terzi sono i log di networking di Google Cloud generati dai servizi Google Cloud quando la generazione di questi log è abilitata. I log di terze parti includono i log di flusso VPC, la registrazione delle regole firewall e i log Cloud NAT. Questi log sono inoltre soggetti ai prezzi di telemetria di rete. Per saperne di più, consulta la sezione dedicata ai log di terze parti.
 ‡  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 l'inoltro dei log ricevuti tramite l'API Cloud Logging a 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 al fine di utilizzare Log Analytics o per eseguire query SQL dalla pagina Analisi dei log.
 Nota: il linguaggio dei prezzi di Cloud Logging è cambiato il 19 luglio 2023. Tuttavia, le allocazioni gratuite e le tariffe non sono state modificate. La tua fattura potrebbe fare riferimento al precedente linguaggio dei prezzi.

Riepilogo dei prezzi di Cloud Monitoring

Funzionalità Prezzo Allocazione gratuita mensile Data di validità
Tutti i dati di Monitoring, tranne quelli importati utilizzando Managed Service per 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 Google Cloud non addebitabili
Primi 150 MiB per account di fatturazione per metriche addebitate in base ai byte importati		 1° luglio 2018
Metriche importate utilizzando Google Cloud Managed Service per Prometheus, comprese le metriche del piano di controllo GKE 0,06 $/milione di campioni†: primi 0-50 miliardi di campioni importati#
0,048 $/milione di campioni: successivi 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 di campioni 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 dei controlli di uptime di Monitoring 0,30 $/1000 esecuzioni‡ 1 milione di esecuzioni per progetto Google Cloud 1 ottobre 2022
Esecuzione dei monitoraggi sintetici di Monitoring 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 le metriche♣		 Non applicabile Aprile 2026
†  Google Cloud Managed Service per Prometheus utilizza lo spazio di archiviazione di Cloud Monitoring per i dati delle metriche creati esternamente e l'API Monitoring per recuperarli. Managed Service per Prometheus viene misurato in base ai campioni importati anziché ai byte, in modo da 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.
 #  Gli esempi vengono conteggiati per ogni account di fatturazione.
 ‡  Le esecuzioni vengono addebitate all'account di fatturazione in cui sono definite. Per saperne di più, consulta Prezzi relativi all'esecuzione dei controlli di uptime.
 *  Le esecuzioni vengono addebitate all'account di fatturazione in cui sono definite. Per ogni esecuzione, potrebbero essere addebitati costi aggiuntivi di altri servizi Google Cloud, tra cui servizi come le funzioni Cloud Run, Cloud Storage e Cloud Logging. Per informazioni su questi addebiti aggiuntivi, consulta il documento sui prezzi per il rispettivo servizio Google Cloud.
 ♣  Per ulteriori informazioni, vedi 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 di osservabilità di Google Cloud, consulta le sezioni seguenti di questa pagina:

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

Visualizzazione dell'utilizzo

Per visualizzare l'utilizzo attuale, vai alla pagina dei report di fatturazione Cloud sulla 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 degli addebiti fatturabili o previsti che superano un dato budget, crea un avviso nella 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 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.
  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 che archiviano i dati dei log. Logging addebita un costo per il volume di dati dei log archiviati nel bucket dei log _Default e in bucket dei 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 più del periodo di conservazione predefinito, che è di 30 giorni.

Logging non prevede costi aggiuntivi per il routing dei log, l'uso dell'API Cloud Logging, la configurazione degli scatti 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, consulta la sezione 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 ciascun progetto Google Cloud, Logging crea automaticamente due bucket di log: _Required e _Default. Per questi due bucket, Logging crea automaticamente i sink di log denominati _Required e _Default che scrivono i log nei bucket di log con nome corrispondente. Non puoi disabilitare o modificare il sink _Required. Puoi disabilitare o altrimenti 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 in modo che eseguano il routing di qualsiasi combinazione di log, anche tra progetti Google Cloud nella tua organizzazione Google Cloud, a questi bucket di log.

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

Puoi eseguire l'upgrade dei bucket di log per utilizzare Analisi dei log. Non è previsto alcun costo per eseguire l'upgrade di un bucket di log al fine di utilizzare Analisi dei log.

Per ulteriori informazioni su bucket e sink di Cloud Logging, consulta la Panoramica su routing e archiviazione.

Prezzi di archiviazione

Il servizio di logging non prevede costi 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 di dati dei log preindicizzati archiviato nel bucket dei log _Default e in bucket dei 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 della tua quota di spazio di archiviazione. Ad esempio, se i sink inoltrano una voce di log a tre bucket di log, questa viene archiviata tre volte.

Prezzi di fidelizzazione

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

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

I costi di conservazione dei dati di logging vengono addebitati 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 dei 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 accorci il periodo di conservazione di un bucket dei log, c'è 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 quei sette giorni puoi ripristinare l'accesso completo estendendo il periodo di conservazione del bucket dei log. I log archiviati durante il periodo di tolleranza vengono conteggiati ai fini dei costi di conservazione.

Se selezioni voce di log su più bucket di log, ti verranno addebitati più volte i costi di archiviazione e conservazione. Ad esempio, supponiamo che tu indirizzi una voce di log al bucket di log _Default e a un bucket di log definito dall'utente. Inoltre, supponiamo che tu abbia configurato un periodo di conservazione personalizzato per entrambi i bucket che è più lungo di 30 giorni. Per questa configurazione, ricevi due addebiti per l'archiviazione e due addebiti per la conservazione.

Log di rete di terze parti

I log di rete venduti sono disponibili solo quando configuri la generazione dei log. I servizi che generano log di rete di terze parti addebitano la generazione dei log. Se archivi questi log in un bucket di log o li invii a un'altra destinazione supportata, sono inoltre soggetti a addebiti da parte di Cloud Logging o dalla destinazione. Per informazioni sui costi di generazione dei log, consulta la pagina Prezzi di Network Telemetry.

Per scoprire come attivare i log di rete venduti, consulta Configurare i log di flusso VPC, Utilizza il logging delle regole firewall e Cloud NAT: log e metriche.

Per trovare i log di rete venduti, in Esplora log filtra 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 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 o solo una percentuale dei log. Quando una voce di log corrisponde a un filtro di esclusione di un sink, il sink non inoltra la voce di log alla destinazione. Le voci di log escluse non vengono conteggiate ai fini dell'allocazione 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 è quella di instradare i log da Cloud Logging a una destinazione supportata. Cloud Logging non prevede costi per il routing dei log verso le destinazioni supportate. Tuttavia, potresti ricevere addebiti quando una destinazione riceve i log:

Per informazioni sull'instradamento dei log al di fuori di Cloud Logging, consulta la pagina Instrada i log verso 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 attivi quando il numero di byte di log scritti nei bucket dei log supera il limite definito dall'utente per Cloud Logging, utilizza le seguenti impostazioni.

Nuova condizione
Campo
Valore
Risorse e metriche Nel menu Risorse, seleziona Globale.
Nel menu Categorie di metriche, seleziona Metrica basata su log.
Nel menu Metriche, seleziona Byte di log importati mensili.
Filtro Nessuno.
Tra serie temporali
Aggregazione di serie temporali		 sum
Finestra temporale continua 60 m
Funzione finestra temporale continua max
Configura trigger di avviso
Campo
Valore
Tipo di condizione Threshold
Avviso attivato Any time series violates
Posizione soglia Above threshold
Valore soglia Sei tu a determinare il valore accettabile.
Finestra di retest 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 monitor sintetici.

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

  • Serie temporali restituite 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 il tuo utilizzo attuale, esegui 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 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 del 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 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 le metriche di Managed Service per Prometheus vengono addebitate in base alla metrica, pagherai 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.

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. Per Google Cloud Managed Service per Prometheus viene utilizzato il pagamento basato su campione.

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

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

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, ogni valore conta come un campione. Il numero di campioni scritti in un mese dipende solo dalla frequenza con cui vengono scritti i 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 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 campioni scritti in un mese dipende dal numero di bucket nei tuoi istogrammi e dalla frequenza con cui i valori vengono scritti.

Ad esempio, ogni istanza di un istogramma a 50 bucket può contenere 52 campioni. Se i valori vengono scritti una volta ogni 60 secondi, un istogramma con 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, allora 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 meno del numero massimo di campioni. In pratica, tra il 20% e il 40% dei bucket dell'istogramma sono vuoti. Questa percentuale è ancora più alta 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 un 25% vuoto:
      • 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 un 40% vuoto:
      • Per istogramma: 32 (2 + .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 un 25% vuoto:
      • 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 un 40% vuoto:
      • Per istogramma: 32 (2 + .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 un 25% vuoto:
      • Per istogramma: 77 (2 + .75(100), o 2 + (100 - 25))
      • Al mese: 13.490.400 (77 * 1 valore/15 secondi * 2.628.000 secondi/mese)
    • Campioni previsti, supponendo un 40% di bucket vuoti:
      • Per istogramma: 62 (2 + .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 un 25% vuoto:
      • Per istogramma: 77 (2 + .75(100), o 2 + (100 - 25))
      • Al mese: 3.372.600 (77 * 1 valore/60 secondi * 2.628.000 secondi/mese)
    • Campioni previsti, supponendo un 40% di bucket vuoti:
      • Per istogramma: 62 (2 + .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 Velocità di scrittura Campioni al mese
(massimo)		 Campioni al mese
(25% vuoto)		 Campioni 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 miliardi a 250 miliardi (250.000 milioni) 0,048 $/milione 9600,00 $
Da 250 miliardi 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 campioni, quindi si applica solo la prima tariffa. Nessun campione viene addebitato alle altre tariffe.

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



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 secondi)



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.000.000 campioni vengono addebitati alla seconda tariffa.
  • Nessun campione viene addebitato 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 secondi)



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 secondi)



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.000.000 campioni vengono addebitati alla seconda tariffa.
  • I successivi 250.000.000.000 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.000.000 di campioni vengono addebitati alla seconda tariffa.
  • Gli 87.260 milioni di campioni rimanenti 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 secondi)



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 		3.000,00 $
9.600,00 $
9.000,00
17.976,96 $
39.576,96 $
B (1 campione/60 secondi)



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 $

15741,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.000.000 campioni vengono addebitati alla seconda tariffa.
  • I successivi 250.000.000.000 di campioni vengono addebitati alla terza tariffa.
  • I restanti 108.124.000 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 è 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.000.000 campioni vengono addebitati alla seconda tariffa.
  • I successivi 250.000.000.000 di campioni vengono addebitati alla terza tariffa.
  • I restanti 26.656.000 milioni di campioni vengono addebitati alla quarta tariffa.
Variante Campioni importati Intervallo di importazione Managed Service per Prometheus
(0,06 $, 0,048 $, 0,036 $, 0,024 $)
A (1 campione/15 secondi)



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 		3.000,00 $
9.600,00
9.000,00
2.594.976,00
2.616.576,00
B (1 campione/60 secondi)



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 		3.000,00 $
9.600,00 $
9.000,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, ovvero 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.000.000 campioni vengono addebitati alla seconda tariffa.
  • I successivi 250.000.000.000 di campioni vengono addebitati alla terza tariffa.
  • I restanti 108.299.200 milioni di campioni vengono addebitati alla quarta tariffa.
Variante Campioni importati Intervallo di importazione Managed Service per Prometheus
(0,06 $, 0,048 $, 0,036 $, 0,024 $)
2A + 4A



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 		3.000,00 $
9.600,00
9.000,00
2.599.180,80
2.620.780,80

Prezzi relativi all'esecuzione dei controlli di uptime (data di efficacia: 1° ottobre 2022)

Costi di monitoraggio 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 conta come tre esecuzioni.

Il costo per l'esecuzione dei controlli di uptime è di 0,30 $per 1000 esecuzioni. L'addebito compare nella fattura come SKU "CA14-D3DE-E67F" per "Monitoring Uptime Checks".

I seguenti esempi mostrano 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.

Contare le esecuzioni dei controlli di uptime

Per stimare il costo dei controlli di uptime, devi sapere quante esecuzioni a livello di regione si verificano in un mese. Monitoraggio: 0,30 $ per 1000 esecuzioni, con un contingente mensile gratuito 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:

  • Frequenza di esecuzione del controllo dell'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 cui è 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 target è pari al numero di risorse nel gruppo.

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

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, us-west1
GLOBAL Tutte le regioni incluse da altre località

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

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

  • ASIA_PACIFIC, EUROPE e SOUTH_AMERICA includono ciascuno 1 regione.
  • USA include 3 regioni.
  • GLOBAL include 6 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 in 3 regioni. Se questo controllo di uptime è configurato per controllare una singola VM, viene eseguito 131.400 volte (3 * 43.800) in un mese. Se il controllo è configurato per controllare un gruppo di risorse con 10 membri, il controllo di uptime viene eseguito 1.314.000 (10 * 131.400) volte in un mese.

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

La seguente tabella mostra il conteggio delle esecuzioni orarie e mensili per un singolo controllo di uptime configurato per essere eseguito con frequenze diverse in un numero diverso di regioni:

Frequenza di esecuzione del controllo, 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 il totale delle esecuzioni mensili e sottrai 1.000.000. Qualsiasi esecuzione rimanente viene addebitata a 0,30 $per 1000 esecuzioni, quindi moltiplica le esecuzioni rimanenti per 0,0003.

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

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

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

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

Esecuzioni mensili totali
 		 Esecuzioni mensili soggette a pagamento
(oltre 1.000.000)		 Costo
($0,30/1000 esecuzioni)
1.314.000 (10 target) 314.000 94,20 $

Scenario 3: hai 10 GLOBAL controlli di uptime, 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 ha un costo di 488,40 $ al mese.

Esecuzioni mensili totali
 		 Esecuzioni mensili soggette a pagamento
(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 posizione USA che controllano 1 VM una volta ogni 5 minuti. Questi controlli vengono eseguiti in 3 regioni, quindi ciascuno viene eseguito 26.280 volte al mese. Il totale delle esecuzioni mensili per questo insieme di controlli è 105.120 (4 * 26.280).

Hai anche 2 GLOBAL controlli di uptime che controllano 1 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 set di controlli è 35.040 (2 * 17.520).

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

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

Prezzi per l'esecuzione dei monitor sintetici (data di validità: 1° novembre 2023)

Cloud Monitoring applica costi per ogni esecuzione di un monitor sintetico, oltre all'importo dell'allocazione gratuita mensile di 100 esecuzioni per account di fatturazione. Ad esempio, se crei 3 monitor sintetici e configuri ciascuno di essi per l'esecuzione 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 soggette a pagamento, sottrai la quota gratuita dal numero totale di esecuzioni, quindi moltiplica il risultato per il costo:

Esecuzioni mensili totali
 		 Esecuzioni mensili soggette a pagamento
(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 2026, Cloud Monitoring inizierà a addebitare gli avvisi. Il modello di prezzi è il seguente:

  • 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 le metriche.

Questa sezione fornisce le seguenti informazioni:

Definizioni

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

    L'addebito è di 1,50 $al mese per ogni condizione. Per interrompere gli addebiti per una condizione, devi eliminare il criterio di avviso. Posticipare o disattivare le norme non impedisce l'addebito.

  • Criteri di avviso basati su metriche e sui log: i criteri di avviso che utilizzano qualsiasi tipo di condizione, ad eccezione delle condizioni di corrispondenza dei log, sono criteri di avviso basati su metriche; le condizioni dei criteri di avviso basati su metriche restituiscono serie temporali. Durante ogni periodo di esecuzione, le condizioni nei criteri di avviso sulle metriche eseguono le loro query nel data store di Cloud Monitoring. Le serie temporali restituite vengono quindi valutate rispetto a una soglia per determinare se il criterio di avviso viene attivato.

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

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

  • Serie temporali restituite: durante ogni periodo di esecuzione, un criterio di avviso per le metriche esegue la query della sua condizione nel database Cloud Monitoring. Cloud Monitoring restituisce dati delle serie temporali come 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 usi nella query della tua condizione.
    • Il periodo di esecuzione.

    Ad esempio, considera una configurazione in cui hai:

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

    Poiché hai 100 VM, ognuna 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 restituisce un numero diverso di serie temporali per periodo di esecuzione:

    Configurazione Query PromQL Serie temporali restituite per periodo
    Nessuna aggregazione rate(metric_name[1m]) 1000
    Aggregati alla VM sum by (vm) (rate(metric_name[1m])) 100
    Aggregato al valore dell'etichetta sum by (label_key) (rate(metric_name[1m])) 10
    Aggregati al servizio sum by (service) (rate(metric_name[1m])) 5
    Aggregare per etichettare il valore e il servizio sum by (service, label_key) (rate(metric_name[1m])) 50
    Aggregati al 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 unico servizio sum (rate(metric_name{service="my_service_name"}[1m])) 1

Esempi di prezzi

I seguenti esempi si basano su un mese di 30 giorni, con 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 criterio, aggregato 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
  • Condizione aggregata a livello di VM
  • Periodo di esecuzione: 30 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 * 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), aggregati 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
Criteri di avviso
  • 100 condizioni
  • Ogni condizione viene filtrata e aggregata a una VM
  • Periodo di esecuzione: 30 secondi
Costi risultanti
  • Costo delle condizioni: 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 criterio, aggregato 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
  • Condizione aggregata a livello di VM
  • Periodo di esecuzione: 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: aggregazione di un criterio per ogni servizio, 30 secondi

In questo esempio, utilizza le seguenti configurazioni:

Dati

  • 100 VM, ognuna 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
  • Condizione aggregata al livello del servizio
  • Periodo di esecuzione: 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 alla VM; cardinalità di base più elevata 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
  • Condizione aggregata a livello di VM
  • Periodo di esecuzione: 30 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 * 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 alla VM; unisci due metriche in una condizione, 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
  • Condizione aggregata a livello di VM
  • La condizione utilizza un operatore OR per unire le metriche
  • Periodo di esecuzione: 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 * 86400 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 delle condizioni: 100 condizioni * 1,50 $ al mese = 150,00 $ al mese
  • Costo delle serie temporali: 0 $ (I criteri di avviso basati su log non restituiscono serie temporali.)
  • Costo totale: 150,00$al mese

Suggerimenti per ridurre la tua spesa per le notifiche

Quando configuri i criteri di avviso basati sulle metriche, utilizza i seguenti suggerimenti per contribuire a ridurre i costi delle fatture degli avvisi.

Consolida i criteri di avviso per operare su più risorse

Dato il costo di 1,50 $per condizione, è più conveniente utilizzare un criterio di avviso per monitorare più risorse che utilizzare un criterio di avviso per monitorare ogni risorsa. Ad esempio, confronta l'Esempio 1 con l'Esempio 2: in entrambi gli esempi, monitori lo stesso numero di risorse. Tuttavia, l'esempio 2 utilizza 100 criteri di avviso, mentre l'esempio 1 ne utilizza solo uno. Di conseguenza, l'esempio 1 è quasi 150 $più economico al mese.

Aggrega solo al livello per cui devi ricevere gli avvisi

L'aggregazione a livelli di granularità più elevati comporta costi più elevati rispetto all'aggregazione a livelli di granularità più bassi. 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 rispetto all'aggregazione a livello di cluster e spazio dei nomi.

Ad esempio, confronta l'Esempio 1 con l'Esempio 4: entrambi gli esempi operano sugli stessi dati sottostanti e hanno un unico criterio di segnalazione. Tuttavia, poiché il criterio di avviso nell'esempio 4 viene aggregato al servizio, è meno costoso del criterio di avviso nell'esempio 1, che viene aggregato in modo più granulare alla VM.

Inoltre, confronta l'Esempio 5 con l'Esempio 1: 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 sono entrambi aggregati alla VM e poiché il numero di VM è lo stesso in entrambi gli esempi, i due esempi hanno lo stesso 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 aggregare a livello di VM e CPU. Se ti interessa ricevere avvisi sulla latenza per endpoint, potresti voler aggregare i dati a livello di endpoint.

Non creare avvisi su dati non aggregati e non elaborati

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 su 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, 10.000 serie temporali vengono restituite per ogni periodo di esecuzione. Tuttavia, se effettui l'aggregazione nella VM, ti vengono restituite solo 100 serie temporali per periodo di esecuzione, a prescindere dalla cardinalità dell'etichetta dei dati sottostanti.

Gli avvisi sui dati non elaborati aumentano anche il rischio di serie temporali quando le metriche ricevono nuove etichette. Nell'esempio precedente, se un utente aggiunge una nuova etichetta alla metrica, la cardinalità totale aumenta a 100 * 11 * 10 = 11.000 serie temporali. In questo caso, il numero di serie temporali restituite aumenta di 1000 ogni periodo di esecuzione,anche se il tuo criterio di avviso non cambia. Se invece esegui l'aggregazione a livello di VM, nonostante l'aumento della cardinalità sottostante, vengono restituite solo 100 serie temporali.

Filtra le risposte non necessarie

Configura le condizioni in modo da valutare solo i dati necessari per le tue esigenze di invio di avvisi. Se non vuoi correggere un problema, escludilo dai tuoi criteri di avviso. Ad esempio, probabilmente non hai bisogno di ricevere avvisi sulla VM di sviluppo di un tirocinante.

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

Usa operatori top-stream per ridurre il numero di serie temporali restituite

Se la tua 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ù 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.

Limitare il numero massimo di serie temporali potrebbe comportare la mancanza di dati e avvisi errati, ad esempio:

  • Se più di N serie temporali violano la soglia, non saranno disponibili 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 la serie temporale esclusa stia ancora violando la soglia.
  • Le query delle condizioni potrebbero non mostrare un contesto importante come 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 in criteri di avviso che valutano molte serie temporali, come gli avvisi per singoli container Kubernetes.

Aumenta la durata del periodo di esecuzione (solo PromQL)

Se la condizione utilizza una query PromQL, puoi modificare la lunghezza del periodo di esecuzione impostando il campo evaluationInterval nella condizione.

Intervalli di valutazione più lunghi comportano un numero inferiore di serie temporali restituite al mese; ad esempio, una query di condizione con un intervallo di 15 secondi viene eseguita il doppio di 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 un contratto Google Cloud esistente che non scade prima di aprile 2026, puoi ritardare la fatturazione per gli avvisi fino al rinnovo del contratto richiedendo un'esenzione al team di fatturazione degli avvisi di Cloud Monitoring. Le esenzioni per i clienti con contratti attivi saranno considerate 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 al tuo progetto Google Cloud utilizzando l'API Error Reporting o l'API Cloud Logging.

Non sono previsti costi per l'utilizzo di Error Reporting. Tuttavia, potresti sostenere 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 relativa alla stima delle fatture.

Intervalli di traccia non addebitabili

I prezzi di Cloud Trace non si applicano agli intervalli generati automaticamente da Cloud Functions, Cloud Run o dall'ambiente standard di App Engine, poiché l'importazione di queste tracce non è addebitabile.

Le tracce generate automaticamente non consumano quote dell'Cloud Trace API e non vengono conteggiate nelle metriche sull'utilizzo dell'API.

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 attivi quando gli intervalli mensili importati di Cloud Trace superano un limite definito dall'utente, utilizza le impostazioni seguenti.

Nuova condizione
Campo
Valore
Risorse e metriche Nel menu Risorse, seleziona Globale.
Nel menu Categorie di metriche, seleziona Fatturazione.
Nel menu Metriche, seleziona Importazione di intervalli di traccia mensili.
Filtro
Tra serie temporali
Aggregazione di serie temporali		 sum
Finestra temporale continua 60 m
Funzione finestra temporale continua max
Configura trigger di avviso
Campo
Valore
Tipo di condizione Threshold
Avviso attivato Any time series violates
Posizione soglia Above threshold
Threshold value Sei tu a determinare il valore accettabile.
Finestra di retest Il valore minimo accettabile è di 30 minuti.

GKE Enterprise

Non sono previsti costi per i log di sistema e le metriche di GKE Enterprise. I log del control plane, le metriche del control plane e un subset selezionato di metriche di stato kube sono abilitati per impostazione predefinita per i cluster GKE su Google Cloud che vengono registrati al momento della creazione del cluster in un progetto con GKE Enterprise abilitato. I log del piano di controllo comportano costi di Cloud Logging, mentre le metriche attive per impostazione predefinita sono incluse senza costi aggiuntivi.

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

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

  • 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 per l'utilizzo dei prodotti Google Cloud Observability vengono calcolati in base al volume di dati. Oltre ai costi relativi al volume di dati descritti in questa pagina, l'utilizzo di tutte le funzionalità aggiuntive dei prodotti di 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 vuoi scoprire come gestire i costi, leggi questi post del blog:

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

Nella maggior parte dei casi, gli ambiti delle metriche e gli ambiti dei log non influiscono sulla fatturazione. Il costo di log e metriche viene addebitato 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 le cui metriche il progetto può visualizzare e monitorare. Quando definisci un ambito delle metriche, non influisci su quale risorsa riceve i dati delle metriche o causi la duplicazione dei dati. Analogamente, un ambito di log elenca solo le risorse che archiviano o instrada 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 saperne di più, consulta il Calcolatore prezzi di Google Cloud e seleziona la scheda intitolata "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 viene addebitato alcun costo per le metriche Google Cloud o GKE Enterprise misurate fino a 1 punto dati al minuto, ossia 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