Ottimizzazione dei costi per Google Cloud Observability

Google Cloud Observability è una raccolta di servizi gestiti basati su cloud progettati per fornire un'osservabilità approfondita dei servizi per 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 fornire un vantaggio in termini di costi rispetto alle licenze software standard, potrebbe rendere difficile prevedere i costi. Questa soluzione descrive i modi in cui puoi comprendere l'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 che forniscono, anziché sull'infrastruttura necessaria per utilizzare questi servizi. Quando utilizzi questi servizi, non devi pagare singolarmente macchine virtuali, licenze software, analisi della sicurezza, manutenzione dell'hardware o 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. Il prodotto di logging Error Reporting non ha costi a parte mentre è ancora in versione beta e puoi utilizzare Cloud Profiler senza costi. Per Error Reporting, ti potrebbero venire addebitati dei costi minimi 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. Il prezzo di questo prodotto prevede un semplice costo per GiB. Si tratta di un'allocazione gratuita al mese e alcuni log, come Cloud Audit Logs, non sono addebitabili.

Esempio di utilizzo del prodotto che genera costo tramite un volume di log aggiuntivo include:

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

Monitoraggio dei costi

I prezzi per il monitoraggio si basano sul volume di metriche addebitabili importate e sul numero di chiamate API addebitabili. Ad esempio, le metriche non Google Cloud come quelle degli agenti, 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 gratuita per volume di metriche al mese e molte delle metriche, incluse tutte quelle di Google Cloud, sono gratuite. Consulta i prezzi di Monitoring per ulteriori informazioni sulle metriche addebitabili.

L'utilizzo di un prodotto di esempio che genera costo tramite il volume delle metriche e le chiamate API include l'utilizzo di:

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

Trace i costi

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

L'utilizzo di un prodotto di esempio che genera costi tramite intervalli importati include l'aggiunta di una strumentazione per:

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

Utilizzo

Comprendere l'utilizzo può fornire insight su quali componenti generano costi. Questo ti aiuta a identificare le aree che potrebbero essere appropriate per l'ottimizzazione.

Analisi delle fatture di Google Cloud

Il primo passo per comprendere l'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 un'utile gamma di filtri per restringere i risultati in base a ora, progetto, prodotti, SKU ed etichette. Puoi utilizzare 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 ciascun progetto. Puoi rivedere questi dettagli per ciascun progetto mentre esamini gli addebiti di Logging nella fattura di Google Cloud. In questo modo è facile visualizzare quali log hanno il volume più elevato e, di conseguenza, contribuiscono maggiormente al costo.

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

Questa analisi consente di sviluppare 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

Il monitoraggio, 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 ciascun 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 l'esame degli addebiti di Monitoring nella fattura di Google Cloud. Puoi quindi esaminare i volumi specifici delle metriche e capire quali componenti contribuiscono maggiormente in termini di volume e costi.

Trace

Trace fornisce una visualizzazione dettagliata degli intervalli importati per il mese corrente e precedente. Puoi esaminare questi dettagli nella console Google Cloud per ogni progetto che identifichi durante l'esame 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. In seguito, potrai esaminare il numero specifico di intervalli importati e capire quali progetti e servizi stanno contribuendo con il maggior numero di intervalli e con il relativo costo.

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, inclusi l'archiviazione per GiB, l'inserimento di flussi di dati e i costi delle query.

Per comprendere i costi generati dalle tue esportazioni, considera questi passaggi:

1. Trova i sink di logging. Scopri quali sono i sink di logging, se presenti, che hai abilitato. Ad esempio, il tuo progetto potrebbe avere già diversi sink di logging creati per diversi scopi, come operazioni di sicurezza o per soddisfare requisiti normativi.
2. Rivedi i dettagli di utilizzo. Esamina l'utilizzo per la destinazione delle esportazioni. Ad esempio, le dimensioni delle tabelle 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 potrebbero essere a livello di progetto (uno o più sink per progetto) o a livello di organizzazione di Google Cloud, chiamati esportazioni aggregate. I sink potrebbero includere i log di molti progetti nella stessa organizzazione Google Cloud.

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

Rivedi i tuoi dettagli di utilizzo

Monitoring fornisce un ricco insieme di metriche non solo per le app, ma anche per l'utilizzo dei prodotti Google Cloud. Puoi ottenere le 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 di utilizzo.

Cloud Storage

Utilizzando Esplora metriche in Monitoring, puoi visualizzare le dimensioni dello spazio di archiviazione per i tuoi bucket Cloud Storage. Usa 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, segui questi passaggi:

1. Nella console Google Cloud, vai alla pagina  Esplora metriche:

   Vai a Esplora metriche

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

2. Nell'elemento Metrica, espandi il menu Seleziona una metrica, inserisci Total bytes nella barra dei filtri e 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 di questa metrica è storage.googleapis.com/storage/total_bytes.
3. Configura la modalità di visualizzazione dei dati.
   • 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. Seleziona il nome del bucket di esportazione di Cloud Storage.
   • Nella voce Aggregazione, imposta il primo menu su Non aggregato.

   Per saperne di più sulla configurazione di un grafico, consulta Selezionare le metriche quando si utilizza Esplora metriche.

Il grafico precedente mostra la dimensione dei dati in TB esportati nel tempo, il che fornisce insight sull'utilizzo dell'esportazione di Logging in Cloud Storage.

BigQuery

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

Per visualizzare le metriche per una risorsa monitorata utilizzando Metrics Explorer, segui questi passaggi:

1. Nella console Google Cloud, vai alla pagina  Esplora metriche:

   Vai a Esplora metriche

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

2. Nell'elemento Metrica, espandi il menu Seleziona una metrica, inserisci Stored bytes nella barra dei filtri e 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 di questa metrica è bigquery.googleapis.com/storage/stored_bytes.
3. Configura la modalità di visualizzazione dei dati.
   • 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. Per il valore, seleziona il nome del set di dati di esportazione BigQuery.
   • Nella voce Aggregazione, imposta il primo menu su Media e il secondo su dataset_id.
   • Nel riquadro Visualizzazione, imposta Tipo di widget su Grafico a barre in pila.
   • Imposta la finestra temporale su almeno 1 giorno.

   Per saperne di più sulla configurazione di un grafico, consulta Selezionare le metriche quando si utilizza Esplora metriche.

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

Pub/Sub

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

Per visualizzare le metriche per una risorsa monitorata utilizzando Metrics Explorer, segui questi passaggi:

1. Nella console Google Cloud, vai alla pagina  Esplora metriche:

   Vai a Esplora metriche

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

2. Nell'elemento Metrica, espandi il menu Seleziona una metrica, inserisci Byte cost nella barra dei filtri e 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 di questa metrica è pubsub.googleapis.com/topic/byte_cost.
3. Configura la modalità di visualizzazione dei dati.
   • 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 Pub/Sub.
   • Nella voce Aggregazione, imposta il primo menu su Non aggregato.

   Per saperne di più sulla configurazione di un grafico, consulta Selezionare le metriche quando si utilizza Esplora metriche.

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

Implementazione del controllo dei costi

Le seguenti opzioni descrivono potenziali modi per ridurre i costi. Ogni opzione comporta la limitazione di insight sulle app e sull'infrastruttura. Scegli l'opzione che offre il miglior compromesso tra osservabilità e costo.

Logging dei controlli dei costi

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

Escludi log

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

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 valore pratico.

Di seguito sono riportati alcuni esempi di esclusione comuni:

• Escludere i log da Cloud Load Balancing. I bilanciatori del carico possono produrre 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 da Cloud Load Balancing.

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

  • Escludi per contenuto delle voci di log. Escludere la maggior parte dei log di flusso VPC, conservando solo i messaggi di log specifici che potrebbero essere utili. Ad esempio, se hai VPC privati che non devono ricevere traffico in entrata da origini esterne, potresti voler conservare solo i log di flusso con i campi delle origini provenienti da indirizzi IP esterni.
  • Escludi per percentuale. Un altro approccio consiste nel campionare solo una percentuale di log identificati dal filtro. Ad esempio, puoi 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 molti insight e possono produrre un volume elevato di log per le app a traffico elevato.

Leggi Esclusioni di log per implementare le esclusioni di log.

Esporta log

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

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

Riduci l'utilizzo dell'agente Logging

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

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

Monitoraggio del controllo dei costi

Per ottimizzare l'utilizzo di Monitoring, puoi ridurre il volume delle 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 continuando a mantenere quelle necessarie a sviluppatori e operatori.

Ottimizza le metriche e l'utilizzo delle etichette

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

Se disponi di una metrica personalizzata con due etichette, ad esempio 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, significa che è possibile generare fino a 55 serie temporali. Ecco perché l'aggiunta di altre etichette delle metriche può aggiungere un volume di metriche significativo e, di conseguenza, aumentare il costo. Per una descrizione dettagliata della cardinalità delle metriche, vedi il post del blog Suggerimenti e suggerimenti utili su Cloud Monitoring: comprensione di metriche e creazione di grafici.

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

• Se possibile, limita il numero di etichette delle metriche personalizzate.
• Seleziona le etichette con cura 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 elevato se hai molto traffico.

Riduci l'utilizzo degli agenti Monitoring

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

Ad esempio, è possibile ridurre i volumi delle metriche scegliendo di non aggiungere a Monitoring i progetti Google Cloud nel proprio sviluppo o altri ambienti non essenziali. Inoltre, puoi scegliere di non includere l'agente Monitoring nelle VM in ambiente 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 qualsiasi metrica utilizzata 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 metriche a più backend, incluso Monitoring, utilizzando metriche personalizzate. Queste metriche vengono visualizzate in Monitoring nel tipo di risorsa prefisso custom.googleapis.com/opencensus. Ad esempio, la latenza del roundtrip del client riportata da OpenCensus viene visualizzata in Monitoring nel tipo di risorsa custom.googleapis.com/opencensus/grpc.io/client/roundtrip_latency.

Più app usi per inviare metriche, più verranno generate metriche di monitoraggio personalizzate. Se vuoi ridurre i volumi delle metriche, puoi ridurre 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 instruisci la tua app per generare report su intervalli in Trace, utilizzi il campionamento per importare una parte del traffico. Il campionamento è una parte fondamentale di un sistema di tracciamento perché fornisce insight sull'analisi della latenza causata dai componenti delle app, come le chiamate RPC. Non solo questa è una best practice per l'utilizzo di Trace, ma potresti ridurre il volume del tuo intervallo anche per motivi di riduzione dei costi.

Utilizzare il campionamento di OpenCensus

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

Ad esempio, se hai un'app web molto conosciuta con 5000 query al secondo, potresti ottenere informazioni sufficienti campionando il 5% del traffico della tua app anziché il 20%. Questo 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. Ad 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 degli intervalli dell'API Cloud Trace

Puoi usare le quote per limitare l'utilizzo di Trace e i costi. Puoi applicare le quote dell'intervallo con la pagina delle quote specifica dell'API nella console Google Cloud.

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

Se riduci la quota di intervallo, dovresti anche prendere in considerazione il monitoraggio delle metriche della quota dell'intervallo 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 potrebbe generare il grande volume di intervalli. Se imposti una quota di intervalli e questa viene superata, gli intervalli vengono eliminati finché non modifichi la quota.

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

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 nel riquadro Destinazione specificano la risorsa e la metrica da monitorare. Fai clic sulla casella di testo per attivare un menu e 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 seleziona true.
   4. Le impostazioni nel riquadro Configurazione del criterio di avviso determinano quando l'avviso viene attivato. Completa i seguenti campi:
   • Per Trigger condizione seleziona Qualsiasi violazione delle serie temporali
   • Per 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 vedere 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 l'app genera report su intervalli, il numero di intervalli riportati dall'app potrebbe dipendere dal traffico in entrata ricevuto 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 del frontend. Comprendere come interagiscono le app instrumentate ti consente di valutare l'impatto del numero di intervalli importati.

Esportazione di Logging

Se i costi relativi alle esportazioni di Logging sono un problema, una soluzione è aggiornare il sink di logging per utilizzare un filtro di logging per ridurre il volume dei log esportati. Puoi escludere dall'esportazione i log che non ti servono.

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 che utilizza Cloud SQL, Cloud Storage e BigQuery, puoi limitare i log risultanti in modo da includere solo le informazioni relative a questi prodotti. Il filtro seguente limita l'esportazione nei log per Cloud Audit Logs, Compute Engine, Cloud Storage, Cloud SQL e BigQuery. Puoi usare 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

Google Cloud Observability 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.