Panoramica delle metriche definite dall'utente

Le metriche definite dall'utente sono tutte le metriche non definite da Google Cloud. Sono incluse le metriche che potresti definire e quelle definite da un'applicazione di terze parti. Le metriche definite dall'utente ti consentono di acquisire dati specifici dell'applicazione o dati di sistema lato client. Le metriche integrate raccolte da Cloud Monitoring possono fornirti informazioni sulla latenza del backend o sull'utilizzo del disco, ma non possono dirti, ad esempio, quante routine in background sono state generate dalla tua applicazione.

Puoi anche creare metriche basate sui contenuti delle voci di log. Le metriche basate su log sono una classe di metriche definite dall'utente, ma devi creare da Cloud Logging. Per ulteriori informazioni sulle metriche basate su log, consulta Panoramica delle metriche basate su log.

Le metriche definite dall'utente a volte vengono chiamate metriche personalizzate o specifiche per l'applicazione. Queste metriche consentono a te o a un'applicazione di terze parti di definire e raccogliere informazioni che non possono essere acquisite dalle metriche di Cloud Monitoring integrate. Puoi acquisire queste metriche utilizzando un'API fornita da una libreria per instrumentare il codice e poi inviarle a un'applicazione di backend come Cloud Monitoring.

Puoi creare metriche definite dall'utente, ad eccezione delle metriche basate su log, utilizzando direttamente l'API Cloud Monitoring. Tuttavia, ti consigliamo di utilizzare OpenTelemetry. Per informazioni su come creare metriche definite dall'utente, consulta i seguenti documenti:

  • Raccogliere metriche e tracce OTLP descrive come utilizzare Ops Agent e il ricevitore OpenTelemetry Protocol (OTLP) dell'agente per raccogliere metriche e tracce dalle applicazioni instrumentate utilizzando OpenTelemetry e in esecuzione su Compute Engine.

  • Google Cloud Managed Service per Prometheus descrive come raccogliere Prometheus delle metriche di applicazioni in esecuzione su Google Kubernetes Engine e Kubernetes.

  • La pagina Raccogliere le metriche di Prometheus descrive come utilizzare l'agente operativo per raccogliere le metriche di Prometheus dalle applicazioni in esecuzione su Compute Engine.

  • Creare metriche definite dall'utente con l'API descrive come creare metriche utilizzando l'API Cloud Monitoring e come aggiungere i dati delle metriche a queste metriche. Questo documento illustra come utilizzare l'API Monitoring con di esempio utilizzando Explorer API, C#, Go, Linguaggio di programmazione Java, Node.js, PHP, Python e Ruby.

  • Creare metriche personalizzate su Cloud Run mostra come utilizzare OpenTelemetry Collector come agente sidecar nei deployment di Cloud Run.

Per quanto riguarda Cloud Monitoring, puoi usare le metriche definite dall'utente come le metriche integrate. Puoi visualizzarli in grafici, impostare avvisi, leggerli e monitorarli in altro modo. Per informazioni sulla lettura dei dati delle metriche, consulta i seguenti documenti:

  • Elenco dei tipi di metriche e risorse spiega come elencare ed esaminare i tipi di metriche integrate e definite dall'utente. Ad esempio, puoi utilizzare le informazioni contenute nel documento per elencare tutti i descrittori delle metriche definiti dall'utente nel tuo progetto.
  • L'articolo Recupero dei dati delle serie temporali spiega come recuperare i dati delle serie temporali dalle metriche utilizzando l'API Monitoring. Ad esempio, questo documento descrive come puoi usa l'API per ottenere l'utilizzo della CPU di macchine virtuali (VM) nel tuo progetto Google Cloud.

La console Google Cloud offre una pagina dedicata per aiutarti a visualizzare l'utilizzo metriche definite dall'utente. Per informazioni sui contenuti di questa pagina, vedi Visualizzare e gestire l'utilizzo delle metriche.

Descrittori delle metriche per le metriche definite dall'utente

Ogni tipo di metrica deve avere un descrittore della metrica che definisce in cui vengono organizzati i dati delle metriche. Il descrittore della metrica definisce anche le etichette per la metrica e il nome di quest'ultima. Ad esempio, elenchi di metriche mostrano i descrittori delle metriche per tutti i tipi di metriche.

Cloud Monitoring può creare il descrittore della metrica per te, utilizzando il metodo che scrivi oppure puoi creare la metrica in modo esplicito e scrivi i dati delle metriche. In entrambi i casi, devi decidere come organizzare i dati delle metriche.

Esempio di design

Supponiamo di avere un programma che viene eseguito su una singola macchina, e che questo programma chiama i programmi ausiliari A e B. Vuoi conteggiare la frequenza con cui vengono richiamati i programmi A e B. Inoltre, vuoi sapere quando il programma A viene chiamato più di 10 volte al minuto e quando il programma B viene chiamato più di 5 volte al minuto. Infine, supponiamo di avere un singolo progetto Google Cloud e prevedi di scrivere i dati e la risorsa monitorata global.

Questo esempio descrive alcuni diversi design che puoi utilizzare per le tue metriche definite dall'utente:

  • Utilizzi due metriche: Metric-type-A conteggia le chiamate al programmaA e Metric-type-B conteggia le chiamate al programma B. In questo caso, Metric-type-A contiene 1 serie temporale e Metric-type-B contiene 1 serie temporali.

    Con questa modalità di dati, puoi creare un singolo criterio di avviso con due condizioni oppure due criteri di avviso ciascuno con una condizione. Un criterio di avviso può supportare più condizioni, ma ha un'unica configurazione per i canali di notifica.

    Questo modello potrebbe essere appropriato se non ti interessano le somiglianze tra i dati delle attività monitorate. In questo esempio, le attività sono la frequenza delle chiamate ai programmi A e B.

  • Utilizza una singola metrica e un'etichetta per memorizzare un identificatore del programma. Ad esempio, l'etichetta potrebbe memorizzare il valore A o B. Il monitoraggio crea una serie temporale per ogni combinazione unica di etichette. Di conseguenza, esiste una serie temporale il cui valore dell'etichetta è A e un'altra serie temporale il cui valore dell'etichetta è B.

    Come nel modello precedente, puoi creare un singolo criterio di avviso o due criteri di avviso. Tuttavia, le condizioni per il criterio di avviso sono più complicate. Una condizione che genera un incidente quando la frequenza delle chiamate per il programma A supera una soglia deve utilizzare un filtro che includa solo i punti dati il cui valore dell'etichetta è A.

    Un vantaggio di questo modello è che è semplice calcolare i rapporti. Per Ad esempio, puoi determinare quale percentuale del totale è dovuta alle chiamate al numero A.

  • Utilizzi una sola metrica per contare il numero di chiamate, non usare una casa discografica per registrare il programma chiamato. In questo modello, esiste una singola serie temporale che combina i dati dei due programmi. Tuttavia, non puoi creare un criterio di avviso che soddisfi i tuoi scopi perché i dati di due programmi non possono essere separati.

I primi due design ti consentono di soddisfare i requisiti di analisi dei dati, ma non l'ultimo.

Per ulteriori informazioni, vedi Crea una metrica definita dall'utente.

Nomi delle metriche definite dall'utente

Quando crei una metrica definita dall'utente, definisci un identificatore di stringa che rappresenta il tipo di metrica. Questa stringa deve essere univoca tra le metriche predefinite dall'utente nel progetto Google Cloud e deve utilizzare un prefisso che la contrassegni come metrica definita dall'utente. Per il monitoraggio, i prefissi consentiti sono custom.googleapis.com/, workload.googleapis.com/, external.googleapis.com/user e external.googleapis.com/prometheus. Il prefisso è seguito da un nome che descrive ciò che stai raccogliendo. Per maggiori dettagli sul modo consigliato per assegnare un nome a una metrica, consulta Convenzioni di denominazione delle metriche. Di seguito sono riportati alcuni esempi dei due tipi di identificatori per i tipi di metriche:

    custom.googleapis.com/cpu_utilization
    custom.googleapis.com/instance/cpu/utilization

Nell'esempio precedente, il prefisso custom.googleapis.com indica che entrambe le metriche sono definite dall'utente. Entrambi gli esempi si riferiscono a metriche che misurano l'utilizzo della CPU, ma utilizzano modelli organizzativi diversi. Quando prevedi di avere un gran numero di metriche definite dall'utente, ti consigliamo una struttura di denominazione gerarchica come quella del secondo esempio.

Tutti i tipi di metriche hanno identificatori univoci a livello globale chiamati nomi delle risorse. La struttura del nome di una risorsa per un tipo di metrica è:

projects/PROJECT_ID/metricDescriptors/METRIC_TYPE

dove METRIC_TYPE è l'identificatore di stringa del tipo di metrica. Se gli esempi di metriche precedenti sono stati creati nel progetto my-project-id, i relativi nomi delle risorse saranno i seguenti:

    projects/my-project-id/metricDescriptors/custom.googleapis.com/cpu_utilization
    projects/my-project-id/metricDescriptors/custom.googleapis.com/instance/cpu/utilization

Nome o tipo? Nel descrittore della metrica, il campo name memorizza il nome della risorsa del tipo di metrica e il campo type memorizza la stringa METRIC_TYPE.

Tipi di risorse monitorate per le metriche definite dall'utente

Quando scrivi i dati in una serie temporale, devi indicare il punto in cui da cui provengono i dati. Per specificare l'origine dei dati, scegli un tipo di risorsa monitorata che rappresenta la provenienza dei dati e poi utilizzala per descrivere l'origine specifica. La risorsa monitorata non fa parte del tipo di metrica. Al contrario, le serie temporali a cui scrivi i dati include un riferimento al tipo di metrica e riferimento alla risorsa monitorata. Il tipo di metrica descrive i dati, mentre la risorsa monitorata descrive la loro origine.

Prendi in considerazione la risorsa monitorata prima di creare il descrittore della metrica. Il tipo di risorsa monitorata che utilizzi influisce sulle etichette che devi includere nel descrittore della metrica. Ad esempio, la risorsa VM di Compute Engine contiene etichette per l'ID progetto, l'ID istanza e la zona dell'istanza. Pertanto, se prevedi di scrivere la metrica in base a una risorsa VM Compute Engine, le etichette delle risorse includono l'ID istanza, quindi non è necessaria un'etichetta per l'ID istanza nel descrittore della metrica.

Ciascun punto dati della metrica deve essere associato a un . I punti di diversi oggetti di risorse monitorate sono memorizzati in diverse serie temporali.

Devi utilizzare uno dei seguenti tipi di risorsa monitorata con metriche definite dall'utente:

È pratica comune utilizzare gli oggetti di risorsa monitorata che rappresentano e le risorse fisiche su cui è in esecuzione il codice dell'applicazione. Questo approccio ha diversi vantaggi:

  • Il rendimento è migliore rispetto all'utilizzo di un singolo tipo di risorsa.
  • Eviti i dati fuori sequenza causati da più processi che scrivono nella stessa serie temporale.
  • Puoi raggruppare i dati delle metriche definite dall'utente con altri dati di metriche provenienti dal le stesse risorse.

global e risorse generiche

I tipi di risorse generic_task e generic_node sono utili in situazioni in cui nessuno dei tipi di risorse più specifici è appropriato. Il tipo generic_task è utile per definire risorse simili a attività, come le applicazioni. Il tipo generic_node è utile per definire risorse simili a nodi come le macchine virtuali. Entrambi i tipi di generic_* hanno diverse etichette comuni che puoi utilizzare per definire oggetti di risorse univoci, grazie ai quali puoi utilizzarli facilmente nei filtri delle metriche per aggregazioni e riduzioni.

Al contrario, il tipo di risorsa global ha solo l'etichetta project_id. Quando hai molte origini delle metriche all'interno di un progetto, utilizzando lo stesso oggetto risorsa global può causare collisioni e sovrascritture dei dati delle metriche.

Metodi API che supportano metriche definite dall'utente

La tabella seguente mostra quali metodi nell'API Monitoring supportano le metriche definite dall'utente e i metodi che supportano le metriche integrate:

Metodo API di monitoraggio Da utilizzare con le
metriche definite dall'utente		 Utilizzo con
metriche integrate
monitoredResourceDescriptors.get sì sì
monitoredResourceDescriptors.list sì sì
metricDescriptors.get sì sì
metricDescriptors.list sì sì
timeSeries.list sì sì
timeSeries.create sì
metricDescriptors.create sì
metricDescriptors.delete sì

Limiti e latenze

Per i limiti relativi alle metriche definite dall'utente e alla conservazione dei dati, consulta Quote e limiti.

Per conservare i dati delle metriche oltre il periodo di conservazione, devi copiarli manualmente in un'altra posizione, ad esempio Cloud Storage o BigQuery.

Per informazioni sulle latenze associate alla scrittura di dati in metriche definite dall'utente. Consulta Latenza dei dati delle metriche.

Passaggi successivi