Le metriche definite dall'utente sono tutte le metriche che non sono definite da Google Cloud. Queste includono le metriche che potresti definire e quelle 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 fornire informazioni sulla latenza del backend o sull'utilizzo del disco, ma non possono indicare, ad esempio, il numero di routine in background generate dall'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 crearle da Cloud Logging. Per ulteriori informazioni sulle metriche basate su log, consulta la panoramica delle metriche basate su log.
Le metriche definite dall'utente sono talvolta chiamate metriche personalizzate o metriche specifiche per l'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. Acquisici queste metriche utilizzando un'API fornita da una libreria per instrumentare il codice, quindi invii le metriche a un'applicazione di backend come Cloud Monitoring.
Puoi creare metriche definite dall'utente, ad eccezione di quelle 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 strumentate utilizzando OpenTelemetry ed eseguite su Compute Engine.
Servizio gestito per Prometheus di Google Cloud descrive come raccogliere le metriche Prometheus dalle applicazioni in esecuzione su Google Kubernetes Engine e Kubernetes.
Raccogli le metriche Prometheus descrive come utilizzare Ops Agent per raccogliere le metriche 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 metrici a queste metriche. Questo documento illustra come utilizzare l'API Monitoring con esempi che utilizzano APIs Explorer e i linguaggi di programmazione C#, Go, Java, Node.js, PHP, Python e Ruby.
Crea metriche personalizzate su Cloud Run mostra come utilizzare OpenTelemetry Collector come agente sidecar nei deployment Cloud Run.
Per quanto riguarda Cloud Monitoring, puoi utilizzare le metriche definite dall'utente come le metriche integrate. Puoi creare grafici, impostare avvisi, leggerli e monitorarli in altro modo. Per informazioni sulla lettura dei dati delle metriche, consulta i seguenti documenti:
- Elenca tipi di metriche e risorse spiega come elencare ed esaminare i tipi di metriche integrati e definiti dall'utente. Ad esempio, puoi utilizzare le informazioni contenute in questo documento per elencare tutti i descrittori di metriche definite dall'utente nel tuo progetto.
- Recuperare 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 .
La console Google Cloud fornisce una pagina dedicata per aiutarti a visualizzare l'utilizzo delle 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 definisca come sono organizzati i dati delle metriche. 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 incorporate.
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 progettazione
Supponiamo di avere un programma in esecuzione 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 tu preveda di scrivere i dati rispetto alla risorsa monitorata global
.
Questo esempio descrive alcuni design diversi che potresti utilizzare per le tue metriche definite dall'utente:
Utilizzi due metriche:
Metric-type-A
conteggia le chiamate al programmaA
eMetric-type-B
conteggia le chiamate al programmaB
. In questo caso,Metric-type-A
contiene una serie temporale eMetric-type-B
ne contiene una.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 una sola 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
eB
.Utilizzi una singola metrica e un'etichetta per memorizzare un identificatore del programma. Ad esempio, l'etichetta potrebbe memorizzare il valore
A
oB
. Il monitoraggio 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 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
.Uno dei vantaggi di questo modello è che è semplice calcolare i rapporti. Ad esempio, puoi determinare la percentuale del totale dovuta alle chiamate al numero
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 di due programmi non possono essere separati.
I primi due progetti ti consentono di soddisfare i requisiti di analisi dei dati, mentre l'ultimo no.
Per saperne di più, vedi 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 tuo progettoGoogle Cloud e deve utilizzare un prefisso che contrassegna la metrica 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 informazioni dettagliate sul modo consigliato per denominare una metrica, vedi Convenzioni di denominazione delle metriche. Ecco alcuni esempi dei due tipi di identificatori per i tipi di metrica:
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 metriche 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 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 relativi nomi delle risorse per queste metriche sarebbero 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 la loro origine. Per specificare l'origine dei dati, scegli un tipo di risorsa monitorata che rappresenta l'origine dei dati e poi utilizzalo per descrivere l'origine specifica. La risorsa monitorata non fa parte del tipo di metrica. Al contrario, la serie temporale in cui scrivi i dati include un riferimento al tipo di metrica e un riferimento alla risorsa monitorata. Il tipo di metrica descrive i dati, mentre la risorsa monitorata descrive la loro origine.
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 base a 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 oggetti risorsa monitorati diversi sono contenuti in serie temporali diverse.
Devi utilizzare uno dei seguenti tipi di risorsa monitorata con metriche definite dall'utente:
aws_ec2_instance
: Istanza Amazon EC2.dataflow_job
: Job Dataflow.gae_instance
: Istanza App Engine.gce_instance
: Istanza Compute Engine.generic_node
: Nodo di calcolo specificato dall'utente.generic_task
: Attività definita dall'utente.gke_container
: Istanza container GKE.global
: Utilizza questa risorsa quando nessun altro tipo di risorsa è adatto. Per la maggior parte dei casi d'uso,generic_node
ogeneric_task
sono scelte migliori rispetto aglobal
.k8s_cluster
: Cluster Kubernetes.k8s_container
: Container Kubernetes.k8s_node
: Nodo Kubernetes.k8s_pod
: Pod Kubernetes.
Una pratica comune è utilizzare gli oggetti risorsa monitorata che rappresentano le risorse fisiche in cui viene eseguito il codice dell'applicazione. Questo approccio presenta diversi vantaggi:
- Ottieni un rendimento migliore rispetto all'utilizzo di un singolo tipo di risorsa.
- Eviti dati fuori ordine causati da più processi che scrivono nella stessa serie temporale.
- Puoi raggruppare i dati delle metriche definite dall'utente con altri dati delle metriche delle 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 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 unici, in modo da poterli utilizzare 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 di metriche all'interno di un progetto, l'utilizzo dello stesso oggetto risorsa global
può causare conflitti 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 le metriche definite dall'utente | Utilizzo con le metriche integrate di |
---|---|---|
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 dei dati nelle metriche definite dall'utente, consulta Latenza dei dati delle metriche.
Passaggi successivi
- Utilizza Google Cloud Managed Service for Prometheus per raccogliere le metriche Prometheus dalle applicazioni in esecuzione su Google Kubernetes Engine e Kubernetes.
- Raccogli le metriche Prometheus dalle applicazioni in esecuzione su Compute Engine.
- Raccogli metriche e tracce OTLP dalle applicazioni strumentate utilizzando OpenTelemetry e in esecuzione su Compute Engine.
- Creare metriche definite dall'utente con l'API
- Introduzione all'API Cloud Monitoring
- Metriche, serie temporali e risorse