Panoramica delle metriche definite dall'utente

Le metriche definite dall'utente (chiamate anche metriche personalizzate) in Cloud Monitoring ti consentono di acquisire dati di telemetria specifici dell'applicazione o lato client che non vengono raccolti dalle metriche Google Cloud integrate. Ad esempio, puoi registrare il numero di routine in background generate dalla tua applicazione, quindi creare grafici, leggere e generare avvisi su queste metriche, proprio come per le metriche integrate.

Modi per raccogliere e leggere le metriche definite dall'utente

Per instrumentare il codice e raccogliere metriche definite dall'utente, ti consigliamo di utilizzare OpenTelemetry, anche se puoi utilizzare direttamente anche Prometheus o l'API Cloud Monitoring. Per ricavare metriche dalle voci di log, crea invece metriche basate su log in Cloud Logging. Puoi monitorare l'importazione delle metriche nella pagina Gestione delle metriche della console Google Cloud .

Per informazioni su come creare metriche definite dall'utente, consulta i seguenti documenti:

  • Raccogli metriche e tracce OTLP descrive come utilizzare Ops Agent e il ricevitore OpenTelemetry Protocol (OTLP) dell'agente per raccogliere metriche e tracce dalle applicazioni strumentate utilizzando OpenTelemetry ed eseguite su Compute Engine.

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

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

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

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

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

  • Elenca i 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 in quel documento per elencare tutti i descrittori delle metriche definite dall'utente nel tuo progetto.
  • Recupera i 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 tuo progetto Google Cloud .

Descrittori delle metriche per le metriche definite dall'utente

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

Cloud Monitoring può creare il descrittore della metrica per te utilizzando i dati della metrica che scrivi oppure puoi creare esplicitamente il descrittore della metrica e poi scrivere i dati della metrica. In entrambi i casi, devi decidere come organizzare i dati delle metriche.

Esempio di design

Supponiamo che tu abbia un programma eseguito su una singola macchina e che questo programma chiami i 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 che tu abbia un singolo progetto Google Cloud e che preveda di scrivere i dati sulla 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 al programma A 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 temporale.

    Con questo modello dei dati, puoi creare una singola criterio di avviso con due condizioni oppure puoi creare due policy di avviso, ciascuna con una condizione. Una 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 le somiglianze nei dati tra le attività monitorate. In questo esempio, le attività sono la frequenza delle chiamate ai programmi A e B.

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

    Come per il modello precedente, puoi creare una singola criterio di avviso o due policy di avviso. Tuttavia, le condizioni per la criterio di avviso sono più complicate. Una condizione che genera un avviso 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 quale parte del totale è dovuta alle chiamate a A.

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

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

Per saperne di più, consulta 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 definite dall'utente nel progettoGoogle Cloud e deve utilizzare un prefisso che contrassegni la metrica come 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 informazioni dettagliate sul modo consigliato per assegnare un nome a una metrica, consulta Convenzioni di denominazione delle metriche. Ecco 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 riguardano metriche che misurano l'utilizzo della CPU, ma utilizzano modelli organizzativi diversi. Se 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 a livello globale chiamati nomi delle risorse. La struttura di un nome della 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 vengono creati nel progetto my-project-id, i nomi delle risorse per queste metriche sono 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 da dove provengono. Per specificare l'origine dei dati, scegli un tipo di risorsa monitorata che rappresenta la provenienza dei dati, quindi 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 descrive l'origine dei dati.

Considera 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 una risorsa VM di Compute Engine, le etichette delle risorse includono l'ID istanza, quindi non hai bisogno di un'etichetta per l'ID istanza nel descrittore della metrica.

Ogni punto dati della metrica deve essere associato a un oggetto risorsa monitorata. I punti di diversi oggetti risorsa monitorata sono contenuti in diverse serie temporali.

Con le metriche definite dall'utente devi utilizzare uno dei seguenti tipi di risorsa monitorata:

Una pratica comune è 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.
  • Eviti dati non ordinati causati da più processi che scrivono nella stessa serie temporale.
  • Puoi raggruppare i dati delle metriche definite 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 in situazioni in cui nessuno dei tipi di risorse più specifici è appropriato. Il tipo generic_task è utile per definire risorse simili ad attività, come 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 risorsa univoci, semplificandone l'utilizzo 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 di metriche all'interno di un progetto, 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 tabella seguente mostra quali metodi dell'API Monitoring supportano le metriche definite dall'utente e quali supportano le metriche integrate:

Metodo API Monitoring Utilizzo con metriche definite dall'utente
 Utilizza 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 nelle metriche definite dall'utente, consulta Latenza dei dati delle metriche.

Passaggi successivi