Panoramica delle metriche definite dall'utente

Le metriche definite dall'utente sono tutte metriche che non sono definite da Google Cloud. Queste includono metriche che potresti definire e metriche definite da un'applicazione di terze parti. Le metriche definite dall'utente 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 indicarti, ad esempio, quante routine in background sono state generate dalla tua applicazione. Puoi anche creare metriche basate sui contenuti delle voci di log. Per informazioni su questi tipi di metriche, consulta la panoramica delle metriche basate su log.

Le metriche definite dall'utente vengono talvolta chiamate metriche personalizzate o metriche specifiche dell'applicazione. Queste metriche consentono a te o a un'applicazione di terze parti di definire e raccogliere informazioni che le metriche integrate di Cloud Monitoring non possono effettuare. Puoi acquisire queste metriche utilizzando un'API fornita da una libreria per perfezionare il codice, quindi inviare le metriche a un'applicazione di backend come Cloud Monitoring.

Puoi creare metriche definite dall'utente 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:

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

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

  • Raccogli metriche Prometheus descrive come utilizzare Ops Agent per raccogliere metriche Prometheus dalle applicazioni in esecuzione su Compute Engine.

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

  • Crea metriche personalizzate in Cloud Run mostra come utilizzare OpenTelemetry Collector come agente collaterale nei deployment Cloud Run.

Per quanto riguarda Cloud Monitoring, puoi utilizzare metriche definite dall'utente come quelle integrate. Puoi creare grafici, impostare avvisi, leggere e monitorare in altro modo. Per informazioni sulla lettura dei dati delle metriche, consulta i seguenti documenti:

  • Elenca metriche e tipi di 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 progetto.
  • La sezione 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 utilizzare l'API per ottenere l'utilizzo della CPU per le istanze di macchine virtuali (VM) nel progetto Google Cloud.

La console Google Cloud fornisce una pagina dedicata per aiutarti a visualizzare il tuo utilizzo delle metriche definite dall'utente. Per informazioni sui contenuti di questa pagina, consulta Visualizzare l'utilizzo e la diagnostica delle metriche.

Descrittori delle metriche per le metriche definite dall'utente

Ogni tipo di metrica deve avere un descrittore della metrica che definisca il modo in cui sono organizzati i dati della metrica. Il descrittore della metrica definisce anche le etichette e il nome della metrica. Ad esempio, gli elenchi delle metriche mostrano i descrittori delle metriche per tutti i tipi di metriche integrati.

Cloud Monitoring può creare automaticamente il descrittore della metrica, utilizzando i dati delle metriche scritti, oppure puoi creare il descrittore della metrica in modo esplicito per poi scrivere i dati della metrica. In entrambi i casi, devi decidere come organizzare i dati delle metriche.

Esempio di design

Supponi di avere un programma che viene eseguito su una singola macchina e che questo programma chiama programmi ausiliari A e B. Vuoi contare la frequenza con cui vengono chiamati i programmi A e B. Vuoi anche 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 solo progetto Google Cloud e di voler scrivere i dati relativi alla risorsa monitorata global.

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

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

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

    Questo modello potrebbe essere appropriato quando non ti interessano analogie nei dati tra le attività monitorate. In questo esempio, le attività corrispondono alla frequenza delle chiamate ai programmi A e B.

  • Utilizzi una sola metrica e un'etichetta per memorizzare un identificatore del programma. Ad esempio, l'etichetta potrebbe archiviare il valore A o B. Monitoring crea una serie temporale per ogni combinazione univoca di etichette. Pertanto, esiste una serie temporale il cui valore di etichetta è A e un'altra serie temporale il cui valore di etichetta è B.

    Come con il 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. Ad esempio, puoi determinare in che misura il totale è dovuto alle chiamate a A.

  • Utilizzi una singola metrica per contare il numero di chiamate, ma non utilizzi un'etichetta per registrare il programma chiamato. In questo modello, è presente un'unica serie temporale che combina i dati dei due programmi. Tuttavia, non puoi creare un criterio di avviso che soddisfi i tuoi obiettivi perché i dati di due programmi non possono essere separati.

I primi due progetti consentono di soddisfare le esigenze di analisi dei dati, a differenza dell'ultimo.

Per scoprire di più, consulta Creare una metrica definita dall'utente.

Nomi delle metriche definite dall'utente

Quando crei una metrica definita dall'utente, definisci un identificatore stringa che rappresenta il tipo di metrica. Questa stringa deve essere univoca tra le metriche definite dall'utente nel progetto Google Cloud e deve utilizzare un prefisso che la contrassegni come metrica definita dall'utente. Per Monitoring, 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. Ecco alcuni esempi dei due tipi di identificatori relativi ai 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 riguardano metriche che misurano l'utilizzo della CPU, ma utilizzano modelli organizzativi diversi. Quando prevedi di avere un numero elevato di metriche definite dall'utente, ti consigliamo di utilizzare una struttura di denominazione gerarchica come quella utilizzata nel secondo esempio.

Tutti i tipi di metriche hanno identificatori univoci globali denominati nomi delle risorse. La struttura di un nome risorsa per un tipo di metrica è:

projects/PROJECT_ID/metricDescriptors/METRIC_TYPE

dove METRIC_TYPE è l'identificatore stringa del tipo di metrica. Se gli esempi di metriche precedenti vengono creati nel progetto my-project-id, i nomi delle risorse corrispondenti 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, mentre il campo type archivia la stringa METRIC_TYPE.

Tipi di risorse monitorate per le metriche definite dall'utente

Quando scrivi i dati in una serie temporale, devi indicare la provenienza dei dati. Per specificare l'origine dei dati, scegli un tipo di risorsa monitorata che rappresenta la provenienza dei dati e poi utilizzalo per descrivere l'origine specifica. La risorsa monitorata non fa parte del tipo di metrica. La serie temporale in cui scrivi i dati include invece un riferimento al tipo di metrica e un riferimento alla risorsa monitorata. Il tipo di metrica descrive i dati, mentre la risorsa monitorata indica da dove hanno avuto origine.

Prima di creare il descrittore della metrica, considera la risorsa monitorata. Il tipo di risorsa monitorata che utilizzi determina le etichette da includere nel descrittore della metrica. Ad esempio, la risorsa VM di Compute Engine contiene le etichette per l'ID progetto, l'ID istanza e la zona dell'istanza. Di conseguenza, se prevedi di scrivere la metrica su una risorsa VM di Compute Engine, le etichette della risorsa includono l'ID istanza in modo che non sia necessaria un'etichetta per l'ID istanza nel descrittore della metrica.

Ciascun punto dati della metrica deve essere associato a un oggetto risorsa monitorato. I punti di diversi oggetti delle risorse monitorate si trovano in serie temporali diverse.

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

Una pratica comune consiste nell'utilizzare gli oggetti risorsa monitorata che rappresentano le risorse fisiche in cui è in esecuzione il codice dell'applicazione. Questo approccio presenta diversi vantaggi:

  • Ottieni un rendimento migliore rispetto all'utilizzo di un singolo tipo di risorsa.
  • Puoi evitare di avere dati non in ordine causato dalla scrittura di più processi nella stessa serie temporale.
  • Puoi raggruppare i dati delle metriche definiti dall'utente con altri dati delle metriche provenienti dalle stesse risorse.

global e risorse generiche

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

Al contrario, il tipo di risorsa global ha solo etichette project_id e location. Se in un progetto sono presenti molte origini delle metriche, l'utilizzo dello stesso oggetto risorsa global può causare collisioni e sovrascritture dei dati delle metriche.

Metodi API che supportano le metriche definite dall'utente

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

Metodo API Monitoring Utilizza con le
metriche definite dall'utente
Utilizza con le
metriche integrate
monitoredResourceDescriptors.get
monitoredResourceDescriptors.list
metricDescriptors.get
metricDescriptors.list
timeSeries.list
timeSeries.create
metricDescriptors.create
metricDescriptors.delete

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 località, ad esempio Cloud Storage o BigQuery.

Per informazioni sulle latenze associate alla scrittura dei dati nelle metriche definite dall'utente, consulta Latenza dei dati delle metriche.

Passaggi successivi