Ottimizzazione dei costi per l'osservabilità di Google Cloud

L'osservabilità di Google Cloud è una raccolta di servizi gestiti basati su cloud progettati per fornire osservabilità approfondita dei servizi di app e infrastruttura. Uno dei vantaggi dei servizi gestiti su Google Cloud è che i servizi sono basati sull'utilizzo, il che significa che paghi solo per ciò che utilizzi. Sebbene questo modello di prezzi possa offrire un vantaggio in termini di costi rispetto alle licenze software standard, potrebbe rendere difficile prevedere i costi. Questa soluzione descrive come comprendere il tuo utilizzo di questi servizi e ottimizzare i costi.

Prezzi

Poiché i servizi di osservabilità di Google Cloud sono servizi gestiti, ti consentono di concentrarti sugli insight forniti, anziché sull'infrastruttura necessaria per utilizzarli. Quando utilizzi questi servizi, non devi pagare singolarmente per le macchine virtuali, le licenze software, l'analisi della sicurezza, la manutenzione dell'hardware o lo spazio in un data center. I servizi offrono un semplice costo per utilizzo.

I costi includono gli addebiti per Cloud Logging, Cloud Monitoring e Cloud Trace. Mentre è ancora in versione beta, il prodotto di logging Error Reporting non ha un costo separato e puoi utilizzare Cloud Profiler senza costi. Per Error Reporting, potresti incorrere in costi modesti se gli errori vengono importati da Logging.

Puoi anche leggere un riepilogo di tutte le informazioni sui prezzi

Costi di logging e segnalazione degli errori

I prezzi di Logging si basano sul volume di log addebitabili importati. I prezzi di questo prodotto prevedono un semplice costo per GiB. Si tratta di un'allocazione gratuita al mese e alcuni log, come Cloud Audit Logs, non sono addebitabili.

Gli esempi di utilizzo del prodotto che generano costi tramite un volume di log aggiuntivo includono:

• Cloud Load Balancing
• L'agente Logging su Compute Engine
• L'agente Logging su Amazon Web Services (AWS)
• L'operazione di scrittura nell'API Cloud Logging

Monitoraggio dei costi

Il monitoraggio dei prezzi si basa sul volume di metriche addebitabili importate e sul numero di chiamate API addebitabili. Ad esempio, le metriche non Google Cloud, come quelle di agente, personalizzate, esterne e AWS, sono addebitabili. Il metodo projects.timeSeries.list nell'API Cloud Monitoring viene addebitato tramite chiamata API, mentre il resto dell'utilizzo dell'API è gratuito. Si tratta di un'allocazione mensile gratuita in base al volume delle metriche e molte delle metriche, incluse quelle di Google Cloud, sono gratuite. Per ulteriori informazioni sulle metriche addebitabili, consulta la pagina Prezzi di Monitoring.

Un esempio di utilizzo del prodotto che genera costi tramite il volume delle metriche e le chiamate API include:

• Monitoraggio delle metriche personalizzate
• Agente Monitoring su Compute Engine
• L'agente Monitoring su AWS
• L'operazione di lettura nell'API Monitoring

Costi di Trace

I prezzi di tracciamento si basano sul numero di intervalli importati e infine analizzati. Alcuni servizi Google Cloud, come l'ambiente standard di App Engine, producono automaticamente intervalli non addebitabili. È prevista un'allocazione gratuita al mese per Trace.

Un esempio di utilizzo del prodotto che genera un costo tramite gli intervalli importati include l'aggiunta degli strumenti per:

• Intervalli per le app App Engine al di fuori degli intervalli predefiniti
• Cloud Load Balancing
• App personalizzate

Utilizzo

Comprendere il tuo utilizzo può fornire insight su quali componenti generano costi. In questo modo puoi identificare le aree che potrebbero essere appropriate per l'ottimizzazione.

Analisi delle fatture di Google Cloud

Il primo passo per capire il tuo utilizzo è esaminare la fattura di Google Cloud e comprendere i costi. Un modo per ottenere insight è utilizzare i report di fatturazione disponibili nella console Google Cloud.

La pagina Report offre una gamma utile di filtri per restringere i risultati in base a tempo, progetto, prodotti, SKU ed etichette. Puoi usare il filtro Prodotti per restringere i dati di fatturazione ai costi di monitoraggio e logging.

Logging

Logging fornisce elenchi dettagliati di log, volume di log attuale e volume mensile previsto per ogni progetto. Puoi esaminare questi dettagli per ogni progetto mentre esamini gli addebiti di Logging nella fattura di Google Cloud. In questo modo è semplice visualizzare quali log hanno il volume più elevato e, di conseguenza, contribuiscono maggiormente al costo.

Puoi trovare il volume dei log importati nel tuo progetto nella pagina Archiviazione dei log. La pagina Archiviazione dei log fornisce un elenco dei log e i relativi volumi per il mese precedente e quello corrente, nonché i volumi previsti per la fine del mese.

Questa analisi consente di ricavare insight sull'utilizzo dei log in progetti specifici e su come il loro volume è cambiato nel tempo. Puoi utilizzare questa analisi per identificare i log da ottimizzare.

Monitoraggio

Monitoring, organizzato in ambiti delle metriche, fornisce un elenco dettagliato dei progetti e dei volumi di metriche precedenti, attuali e previsti. Poiché un ambito delle metriche potrebbe includere più di un progetto, i volumi per ogni progetto sono elencati separatamente, come illustrato nell'immagine seguente.

Scopri come trovare i dettagli di utilizzo di Monitoring.

Puoi visualizzare il grafico dettagliato della metrica di volume delle metriche per ogni progetto in Metrics Explorer in Monitoring, che fornisce insight sul volume delle metriche importate nel tempo.

Questa analisi fornisce i volumi delle metriche di Monitoring per ogni progetto che hai identificato durante la revisione degli addebiti di Monitoring nella tua fattura Google Cloud. Puoi quindi esaminare i volumi delle metriche specifiche e capire quali componenti stanno generando la maggior parte del volume e dei costi.

Traccia

Trace fornisce una visualizzazione dettagliata degli intervalli importati per il mese corrente e quello precedente. Puoi esaminare questi dettagli nella console Google Cloud per ogni progetto che identifichi durante la revisione degli addebiti di Trace nella fattura di Google Cloud.

Questa analisi fornisce il numero di intervalli importati per ogni progetto in un'area di lavoro che hai identificato durante la revisione degli addebiti di Trace nella fattura di Google Cloud. Quindi puoi esaminare il numero specifico di intervalli importati e capire quali progetti e servizi contribuiscono con il maggior numero di intervalli e costi.

Esportazione di Logging

Logging fornisce un sink di logging per esportare i log in Cloud Storage, BigQuery e Pub/Sub.

Ad esempio, se esporti tutti i tuoi log da Logging a BigQuery per l'archiviazione e l'analisi a lungo termine, ti vengono addebitati i costi di BigQuery, tra cui spazio di archiviazione per GiB, inserimento di flussi di dati ed eventuali costi delle query.

Per comprendere i costi generati dalle esportazioni, considera i seguenti passaggi:

1. Trova i sink di logging. Scopri quali sono i sink di logging che hai abilitato. Ad esempio, il tuo progetto potrebbe avere già diversi sink di logging creati per scopi diversi, come le operazioni di sicurezza o per soddisfare i requisiti normativi.
2. Rivedi i dettagli di utilizzo. Esamina l'utilizzo della destinazione delle esportazioni. Ad esempio, le dimensioni della tabella BigQuery per un'esportazione BigQuery o le dimensioni dei bucket per le esportazioni di Cloud Storage.

Trova i sink di logging

I sink di logging possono essere a livello di progetto (uno o più sink per progetto) o a livello di organizzazione di Google Cloud, dette esportazioni aggregate. I sink potrebbero includere i log di molti progetti nella stessa organizzazione Google Cloud.

Puoi visualizzare i sink di logging esaminando progetti specifici. La console Google Cloud fornisce un elenco dei sink e della destinazione. Per visualizzare le esportazioni aggregate per la tua organizzazione, puoi utilizzare la riga di comando dell'elenco dei sink di logging di gcloud --organization ORGANIZATION_ID.

Rivedi i dettagli di utilizzo

Monitoring offre un ampio set di metriche non solo per le app, ma anche per l'utilizzo dei prodotti Google Cloud. Puoi ottenere metriche di utilizzo dettagliate per Cloud Storage, BigQuery e Pub/Sub visualizzando le metriche di utilizzo in Metrics Explorer.

Nota: le aree di lavoro potrebbero includere più di un progetto. Utilizza l'area di lavoro che include il bucket Cloud Storage, il set di dati BigQuery e gli argomenti Pub/Sub utilizzati per l'esportazione per visualizzare i dettagli sull'utilizzo.

Cloud Storage

Utilizzando Metrics Explorer in Monitoring, puoi visualizzare le dimensioni dello spazio di archiviazione per i bucket Cloud Storage. Utilizza i valori seguenti in Metrics Explorer per visualizzare le dimensioni di archiviazione dei bucket Cloud Storage utilizzati per i sink di logging.

Per visualizzare le metriche per una risorsa monitorata utilizzando Metrics Explorer, procedi come segue:

1. Nel pannello di navigazione della console Google Cloud, seleziona Monitoring e poi  Metrics Explorer:

   Vai a Metrics Explorer

2. Nell'elemento Metrica, espandi il menu Seleziona una metrica, inserisci Total bytes nella barra dei filtri, quindi utilizza i sottomenu per selezionare un tipo di risorsa e una metrica specifici:
   1. Nel menu Risorse attive, seleziona Bucket GCS.
   2. Nel menu Categorie di metriche attive, seleziona Spazio di archiviazione.
   3. Nel menu Metriche attive, seleziona Byte totali.
   4. Fai clic su Applica.
   Il nome completo per questa metrica è storage.googleapis.com/storage/total_bytes.
3. Configurare il modo in cui i dati vengono visualizzati.
   • Nell'elemento Filter, fai clic su Aggiungi filtro, quindi seleziona project_id. Come valore, seleziona il tuo ID progetto Google Cloud.
   • Nell'elemento Filter, fai clic su Aggiungi filtro, quindi seleziona bucket_name. Come valore, seleziona il nome del bucket di esportazione di Cloud Storage.
   • Nella voce Aggregation, imposta il primo menu su Unaggregated (Non aggregato).

   Per maggiori informazioni sulla configurazione di un grafico, consulta Selezionare le metriche quando si utilizza Metrics Explorer.

Il grafico precedente mostra le dimensioni dei dati in TB esportati nel tempo, che fornisce insight sull'utilizzo per l'esportazione di Logging in Cloud Storage.

BigQuery

Utilizzando Metrics Explorer in Monitoring, puoi visualizzare le dimensioni di archiviazione per il tuo set di dati BigQuery. Utilizza i valori seguenti in Metrics Explorer per visualizzare le dimensioni di archiviazione del set di dati BigQuery utilizzato per il sink di logging.

Per visualizzare le metriche per una risorsa monitorata utilizzando Metrics Explorer, procedi come segue:

1. Nel pannello di navigazione della console Google Cloud, seleziona Monitoring e poi  Metrics Explorer:

   Vai a Metrics Explorer

2. Nell'elemento Metrica, espandi il menu Seleziona una metrica, inserisci Stored bytes nella barra dei filtri, quindi utilizza i sottomenu per selezionare un tipo di risorsa e una metrica specifici:
   1. Nel menu Risorse attive, seleziona Set di dati BigQuery.
   2. Nel menu Categorie di metriche attive, seleziona Spazio di archiviazione.
   3. Nel menu Metriche attive, seleziona Byte archiviati.
   4. Fai clic su Applica.
   Il nome completo per questa metrica è bigquery.googleapis.com/storage/stored_bytes.
3. Configurare il modo in cui i dati vengono visualizzati.
   • Nell'elemento Filter, fai clic su Aggiungi filtro, quindi seleziona project_id. Come valore, seleziona il tuo ID progetto Google Cloud.
   • Nell'elemento Filter, fai clic su Aggiungi filtro, quindi seleziona dataset_id. Come valore, seleziona il nome del set di dati di esportazione BigQuery.
   • Nella voce Aggregation, imposta il primo menu su Mean e il secondo su dataset_id.
   • Nel riquadro Display, imposta il Tipo di widget su Grafico a barre in pila.
   • Imposta una finestra temporale di almeno un giorno.

   Per maggiori informazioni sulla configurazione di un grafico, consulta Selezionare le metriche quando si utilizza Metrics Explorer.

Il grafico precedente mostra le dimensioni nel tempo del set di dati di esportazione in TB, che fornisce insight sull'utilizzo per l'esportazione di Logging in BigQuery.

Pub/Sub

Utilizzando Metrics Explorer in Monitoring, puoi visualizzare il numero di messaggi e le dimensioni dei messaggi esportati in Pub/Sub. Utilizza i seguenti valori in Metrics Explorer per visualizzare le dimensioni di archiviazione dell'argomento Pub/Sub utilizzato per il sink di logging.

Per visualizzare le metriche per una risorsa monitorata utilizzando Metrics Explorer, procedi come segue:

1. Nel pannello di navigazione della console Google Cloud, seleziona Monitoring e poi  Metrics Explorer:

   Vai a Metrics Explorer

2. Nell'elemento Metrica, espandi il menu Seleziona una metrica, inserisci Byte cost nella barra dei filtri, quindi utilizza i sottomenu per selezionare un tipo di risorsa e una metrica specifici:
   1. Nel menu Risorse attive, seleziona Argomento Cloud Pub/Sub.
   2. Nel menu Categorie di metriche attive, seleziona Argomento.
   3. Nel menu Metriche attive, seleziona Costo byte argomento.
   4. Fai clic su Applica.
   Il nome completo per questa metrica è pubsub.googleapis.com/topic/byte_cost.
3. Configurare il modo in cui i dati vengono visualizzati.
   • Nell'elemento Filter, fai clic su Aggiungi filtro, quindi seleziona project_id. Come valore, seleziona il tuo ID progetto Google Cloud.
   • Nell'elemento Filter, fai clic su Aggiungi filtro, quindi seleziona topic_id. Per il valore, seleziona il nome dell'argomento di esportazione di Pub/Sub.
   • Nella voce Aggregation, imposta il primo menu su Unaggregated (Non aggregato).

   Per maggiori informazioni sulla configurazione di un grafico, consulta Selezionare le metriche quando si utilizza Metrics Explorer.

Il grafico precedente mostra le dimensioni dei dati in kB esportati nel tempo, fornendo insight sull'utilizzo dell'esportazione di Logging in Pub/Sub.

Implementazione del controllo dei costi

Le seguenti opzioni descrivono i possibili modi per ridurre i costi. Ogni opzione incide sulla limitazione degli insight relativi ad app e infrastruttura. Scegli l'opzione che offre il miglior compromesso tra osservabilità e costo.

Controlli dei costi di Logging

Per ottimizzare l'utilizzo di Logging, puoi ridurre il numero di log importati in Logging. Puoi utilizzare diverse strategie per ridurre il volume dei log continuando a conservare i log necessari per gli sviluppatori e gli operatori.

Escludi log

Puoi escludere la maggior parte dei log non necessari per i team di sviluppatori e operativi da Logging o Error Reporting.

Se escludi i log, questi non vengono visualizzati nell'interfaccia utente di Logging o Error Reporting. Puoi utilizzare i filtri di logging per selezionare voci di log specifiche o interi log da escludere. Puoi anche utilizzare le regole di esclusione di campionamento per escludere una percentuale di voci di logging. Ad esempio, potresti scegliere di escludere determinati log in base al volume elevato o alla mancanza di un valore pratico.

Di seguito sono riportati alcuni esempi di esclusione comuni:

• Escludi i log da Cloud Load Balancing. I bilanciatori del carico possono generare un volume elevato di log per le app a traffico elevato. Ad esempio, puoi utilizzare un filtro di logging per configurare un'esclusione per il 90% dei messaggi provenienti da Cloud Load Balancing.

• Escludi i log di flusso Virtual Private Cloud (Controlli di servizio VPC). I log di flusso includono i log per ogni comunicazione tra macchine virtuali in una rete di Controlli di servizio VPC, che può produrre un volume elevato di log. Esistono due approcci per ridurre il volume dei log, che puoi utilizzare insieme o separatamente.

  • Escludi in base ai contenuti delle voci di log. Escludi la maggior parte dei log di flusso VPC, conservando solo i messaggi di log specifici che potrebbero essere utili. Ad esempio, se disponi di VPC privati che non devono ricevere traffico in entrata da origini esterne, potresti voler conservare solo i log di flusso con campi di origini da indirizzi IP esterni.
  • Escludi per percentuale. Un altro approccio è campionare solo una percentuale di log identificati dal filtro. Ad esempio, potresti escludere il 95% e conservare solo il 5% dei log di flusso.

• Escludi le risposte HTTP 200 OK dai log delle richieste. Per le app, i messaggi HTTP 200 OK potrebbero non fornire molte informazioni e generare un volume elevato di log per le app a traffico elevato.

Per implementare le esclusioni di logging, consulta Esclusioni di log.

Esporta log

Puoi esportare i log ed escluderli dall'importazione in Logging. In questo modo puoi conservare i log in Cloud Storage e BigQuery o utilizzare Pub/Sub per elaborarli, escludendoli da Logging, il che potrebbe contribuire a ridurre i costi. Ciò significa che i log non vengono visualizzati in Logging, ma sono esportati.

Utilizza questo metodo per conservare i log per le analisi a più lungo termine senza dover sostenere il costo di importazione in Logging. Per una comprensione dettagliata dell'interazione tra esclusioni ed esportazioni, consulta la durata di un diagramma dei log, che illustra come vengono trattate le voci di log esportate in Logging.

Riduci l'utilizzo dell'agente Logging

Puoi ridurre i volumi dei log non inviando a Logging i log aggiuntivi generati dall'agente Logging. L'agente Logging trasmette il flusso dei log da app di terze parti comuni, come Apache, Mongodb e MySQL.

Ad esempio, puoi ridurre i volumi dei log scegliendo di non aggiungere l'agente Logging alle macchine virtuali nel tuo ambiente di sviluppo o in altri ambienti non essenziali a Logging. Le macchine virtuali continuano a segnalare i log standard a Logging, ma non quelli di app di terze parti né di syslog.

Monitoraggio del controllo dei costi

Per ottimizzare l'utilizzo di Monitoring, puoi ridurre il volume di metriche addebitabili importate in Monitoring e il numero di chiamate di lettura all'API Monitoring. Esistono diverse strategie che puoi utilizzare per ridurre il volume delle metriche, pur continuando a mantenere quelle necessarie per i tuoi sviluppatori e operatori.

Ottimizza le metriche e l'utilizzo delle etichette

Il modo in cui utilizzi le etichette nelle metriche personalizzate di Monitoring può influire sul volume di serie temporali generate.

Se hai una metrica personalizzata con due etichette, ad esempio i valori cost_center e env, puoi calcolare il numero massimo di serie temporali moltiplicando la cardinalità di entrambe le etichette.

total_num_time_series = cost_center_cardinality * env_cardinality

Se sono presenti 11 valori cost_center e 5 valori env, è possibile generare fino a 55 serie temporali. È per questo motivo che aggiungere altre etichette delle metriche può aumentare un volume significativo delle metriche e, di conseguenza, un aumento del costo. Per una descrizione dettagliata della cardinalità delle metriche, consulta il post del blog Suggerimenti utili per la comprensione delle metriche e la creazione di grafici su Cloud Monitoring.

Per ridurre al minimo il numero di serie temporali, consigliamo quanto segue:

• Se possibile, limita il numero di etichette delle metriche personalizzate.
• Seleziona le etichette con attenzione per evitare valori con cardinalità elevata. Ad esempio, l'utilizzo di user_id come etichetta genera almeno una serie temporale per ogni utente, il che potrebbe essere un numero molto grande se hai molto traffico.

Riduci l'utilizzo degli agenti Monitoring

Le metriche inviate dall'agente Monitoring sono metriche addebitabili. L'agente Monitoring trasmette in streaming le metriche di app e di sistema da app di terze parti comuni, come Apache, MySQL e Nginx, oltre a metriche aggiuntive a livello di VM Google Cloud. Se non hai bisogno delle metriche o delle metriche di sistema dettagliate delle app di terze parti per determinate VM, puoi ridurre il volume non inviando queste metriche. Puoi anche ridurre i volumi delle metriche riducendo il numero di VM utilizzando l'agente Monitoring.

Ad esempio, puoi ridurre i volumi delle metriche scegliendo di non aggiungere a Monitoring progetti Google Cloud nei tuoi ambienti di sviluppo o non essenziali. Inoltre, puoi scegliere di non includere l'agente Monitoring nelle VM in ambienti di sviluppo o in altri ambienti non essenziali.

Riduci l'utilizzo delle metriche personalizzate

Le metriche personalizzate sono metriche addebitabili create utilizzando l'API Monitoring per monitorare le metriche scelte da un utente. Puoi creare queste metriche utilizzando l'API Monitoring o le integrazioni.

Una di queste integrazioni è OpenCensus. OpenCensus è una distribuzione di librerie che raccolgono metriche e tracce distribuite dalle tue app. Le app instrumentate con OpenCensus possono segnalare le metriche a più backend, incluso Monitoring, utilizzando metriche personalizzate. Queste metriche vengono visualizzate in Monitoring nel tipo di risorsa con prefisso custom.googleapis.com/opencensus. Ad esempio, la latenza di roundtrip del client segnalata da OpenCensus viene visualizzata in Monitoring nel tipo di risorsa custom.googleapis.com/opencensus/grpc.io/client/roundtrip_latency.

Più app usi lo strumento per inviare metriche, più metriche di monitoraggio personalizzate vengono generate. Se vuoi ridurre i volumi delle metriche, puoi diminuire il numero di metriche di monitoraggio personalizzate inviate dalle tue app.

Trace dei controlli dei costi

Per ottimizzare l'utilizzo di Trace, puoi ridurre il numero di intervalli importati e scansionati. Quando instrusci la tua app per generare report sugli intervalli in Trace, utilizzi il campionamento per importare una parte del traffico. Il campionamento è una parte fondamentale di un sistema di tracciamento in quanto fornisce insight sulla suddivisione della latenza causata dai componenti delle app, come le chiamate RPC. Non solo questa è una best practice per l'utilizzo di Trace, ma potresti anche ridurre il volume di intervallo per motivi di riduzione dei costi.

Usare il campionamento OpenCensus

Se usi Trace come destinazione di esportazione per le tracce OpenCensus, puoi utilizzare la funzionalità di campionamento di OpenCensus per ridurre il volume delle tracce importate.

Ad esempio, se hai un'app web molto conosciuta con 5000 query/sec, potresti ottenere informazioni sufficienti dal campionamento del 5% del traffico della tua app anziché del 20%. In questo modo si riduce a un quarto il numero di intervalli importati in Trace.

Puoi specificare il campionamento nella configurazione della strumentazione utilizzando le librerie Python di OpenCensus per Trace. A titolo di esempio, l'esportatore Python di OpenCensus fornisce un ProbabilitySampler che puoi utilizzare per specificare una frequenza di campionamento.

from opencensus.trace.samplers import probability
from opencensus.trace import tracer as tracer_module

# Sampling the requests at the rate equals 0.05
sampler = probability.ProbabilitySampler(rate=0.05)
tracer = tracer_module.Tracer(sampler=sampler)

Usa le quote di intervallo dell'API Cloud Trace

Puoi utilizzare le quote per limitare l'utilizzo di Trace e costi. Per applicare le quote di intervalli, puoi consultare la pagina delle quote specifica dell'API nella console Google Cloud.

L'impostazione di una quota specifica inferiore a quella predefinita per i prodotti garantisce che il progetto non supererà il limite di quota specifico. Questo è un modo per garantire che i costi siano previsti. Puoi monitorare questa quota dalla pagina della quota specifica dell'API, come illustrato nell'immagine seguente.

Se riduci la quota di intervalli, dovresti anche considerare il monitoraggio delle relative metriche e la configurazione di un criterio di avviso in Monitoring per inviare un avviso quando l'utilizzo sta per raggiungere la quota. Questo avviso ti chiede di esaminare l'utilizzo e identificare l'app e lo sviluppatore che potrebbero generare il grande volume di intervalli. Se imposti una quota di intervalli che viene superata, gli intervalli vengono eliminati finché non modifichi la quota.

Ad esempio, se la tua quota di intervalli è 50 milioni di intervalli importati, puoi impostare un avviso ogni volta che hai utilizzato l'80% della quota API, ovvero 40 milioni di intervalli. Segui le istruzioni per la gestione dei criteri di avviso per creare un criterio di avviso utilizzando i dettagli riportati di seguito.

1. Nella console Google Cloud, vai a Monitoring o utilizza il pulsante seguente:
   Vai a Monitoring
2. Nel riquadro di navigazione di Monitoring, seleziona Avvisi, quindi Crea criterio.
3. Inserisci un nome per il criterio di avviso.
4. Fai clic su Aggiungi condizione:
   1. Le impostazioni del riquadro Destinazione specificano la risorsa e la metrica da monitorare. Fai clic sulla casella di testo per attivare un menu e poi seleziona la risorsa global.
   2. Fai clic sulla casella di testo per attivare un menu, quindi seleziona cloudtrace.googleapis.com/billing/monthly_spans_ingested.
   3. Aggiungi i seguenti valori di Filtro:
   • Fai clic su project_id e seleziona il tuo ID progetto Google Cloud.
   • Fai clic su chargeable e poi seleziona true.
   4. Le impostazioni nel riquadro Configurazione del criterio di avviso determinano quando viene attivato l'avviso. Completa i seguenti campi:
   • Per gli attivatori delle condizioni se seleziona Qualsiasi serie temporale viola le norme
   • In corrispondenza di Soglia, inserisci 40000000
   • Per, seleziona il valore più recente
   5. Fai clic su Salva.

5. Fai clic su Salva.

   L'avviso generato dal criterio di avviso è simile al seguente. Nell'avviso puoi visualizzare i dettagli del progetto, il criterio di avviso che ha generato l'avviso e il valore attuale della metrica.

Ottimizza i chiamanti di terze parti

La tua app potrebbe essere chiamata da un'altra app. Se i report dell'app sono estesi, il numero di intervalli riportato dall'app potrebbe dipendere dal traffico in entrata che ricevi dall'app di terze parti. Ad esempio, se hai un microservizio frontend che chiama un microservizio di pagamento ed entrambi sono instrumentati con OpenCensus, la frequenza di campionamento per il traffico è almeno pari alla frequenza di campionamento frontend. Comprendere l'interazione delle app con strumenti ti consente di valutare l'impatto del numero di intervalli importati.

Esportazione di Logging

Se i costi relativi alle esportazioni di Logging ti preoccupano, una soluzione è aggiornare il sink di logging in modo da utilizzare un filtro di logging per ridurre il volume dei log esportati. Puoi escludere dall'esportazione i log non necessari.

Nota: se escludi i log da Logging e li escludi anche dall'esportazione di Logging, non hai accesso a questi log.

Ad esempio, se hai un ambiente con un'app in esecuzione su Compute Engine e che utilizza Cloud SQL, Cloud Storage e BigQuery, puoi limitare i log risultanti per includere solo le informazioni relative a quei prodotti. Il filtro seguente limita l'esportazione ai log per Cloud Audit Logs, Compute Engine, Cloud Storage, Cloud SQL e BigQuery. Puoi utilizzare questo filtro per un sink di logging e includere solo i log selezionati.

logName:"/logs/cloudaudit.googleapis.com" AND
(resource.type:gce OR
resource.type=gcs_bucket OR
resource.type=cloudsql_database OR
resource.type=bigquery_resource)

Conclusione

L'osservabilità di Google Cloud offre la possibilità di visualizzare i dati sull'utilizzo del prodotto in modo da poter comprendere i dettagli dell'utilizzo del prodotto. Questi dati sull'utilizzo consentono di configurare i prodotti in modo da ottimizzare in modo appropriato l'utilizzo e i costi.

Passaggi successivi

• Scopri di più sull'API Logging.
• Scopri di più sull'API Monitoring.
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.