Le metriche definite dall'utente sono tutte metriche non definite da Google Cloud. Includono metriche che tu puoi definire e metriche che definiti da un'applicazione di terze parti. Le metriche definite dall'utente ti consentono di acquisire specifici delle applicazioni o dati di sistema lato client. Le metriche integrate raccolte da Cloud Monitoring possono fornirti informazioni sulla latenza di backend o sull'uso del disco, ma non sono in grado di ad esempio quante routine in background hanno generato la 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 sono chiamate metriche personalizzate o specifiche per l'applicazione. Queste metriche consentono a te o a una terza parte definire l'applicazione, e raccolgono informazioni che le metriche integrate di Cloud Monitoring non possono. Puoi acquisire queste metriche utilizzando un'API fornita da una libreria per instrumentare il tuo codice, quindi invii le metriche a un'applicazione di backend come e configurazione in 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:
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 instrumentate utilizzando OpenTelemetry 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.
Raccogli le metriche di Prometheus descrive come per utilizzare Ops Agent per raccogliere le metriche 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.
Crea metriche personalizzate Cloud Run mostra come utilizzare OpenTelemetry Collector come agente collaterale nei deployment di Cloud Run.
Per quanto riguarda Cloud Monitoring, puoi usare le metriche definite dall'utente come le metriche integrate. Potete creare grafici, impostare avvisi, leggere per poi monitorarli. 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 in tale documento per elencare tutti i i descrittori delle metriche nel tuo progetto.
- Istruzioni per il recupero dei dati delle serie temporali 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 a 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
. Da contare
frequenza di chiamata dei programmi A
e B
. Vuoi anche sapere quando
il programma A
viene chiamato più di 10 volte al minuto e quando il programma B
è
chiamata 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
.
L'esempio descrive alcuni design diversi che puoi utilizzare le metriche definite dall'utente:
Utilizzi due metriche:
Metric-type-A
conteggia le chiamate al programmaA
eMetric-type-B
conteggiano le chiamate al programmaB
. In questo caso,Metric-type-A
contiene 1 serie temporale eMetric-type-B
contiene 1 serie temporali.Puoi creare un unico criterio di avviso con due condizioni oppure creare 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 le somiglianze nei dati tra le attività da monitorare. In questo esempio, attività corrispondono alla percentuale di chiamate ai programmi
A
eB
.Utilizzi una singola metrica e un'etichetta per memorizzare un identificatore di programma. Ad esempio, l'etichetta potrebbe memorizzare il valore
A
oB
. Monitoring 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 due criteri di avviso. Tuttavia, le condizioni per il criterio di avviso sono più complicate. Una condizione che genera incidente quando la frequenza delle chiamate per il programma
A
supera una soglia: utilizza 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 esiste un'unica serie temporale che combina i dati dei due programmi. Tuttavia, non puoi creare un criterio di avviso che soddisfi le tue perché i dati di due programmi non possono essere separati.
I primi due progetti ti consentono di soddisfare i requisiti di analisi dei dati. ma l'ultimo design non lo è.
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 definite dall'utente
progetto Google Cloud e deve utilizzare un prefisso che contrassegna la metrica 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
descrivono 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 sia
sono metriche definite dall'utente. Entrambi gli esempi riguardano metriche che misurano
utilizzo della CPU; ma utilizzano modelli organizzativi diversi. Quando
avere un gran numero di metriche definite dall'utente, ti consigliamo di
una struttura di denominazione gerarchica come quella del secondo esempio.
Tutti i tipi di metriche hanno identificatori univoci globali denominati 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 vengono creati nel progetto my-project-id
,
i 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 la
nome della risorsa del tipo di metrica e il campo type
archivia il METRIC_TYPE
stringa.
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'opzione tipo di risorsa monitorata rappresenta la provenienza dei dati e quindi usala per descrivere un'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 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, Risorsa VM Compute Engine contiene etichette per l'ID progetto, l'ID istanza e la zona dell'istanza. Pertanto, se scrivere la metrica su una risorsa VM di Compute Engine, le etichette delle risorse includono l'ID istanza, non necessitano di 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 si trovano in serie temporali.
Devi utilizzare uno dei seguenti tipi di risorsa monitorata con metriche definite dall'utente:
aws_ec2_instance
: Amazon EC2.dataflow_job
: del job Dataflow.gae_instance
: dell'istanza di App Engine.gce_instance
: di Compute Engine.generic_node
: Nodo di computing specificato dall'utente.generic_task
: Attività definita dall'utente.gke_container
: un'istanza di container GKE.global
: Usa questa risorsa quando non sono presenti altri tipi di risorsa adatto. Nella maggior parte dei casi d'uso,generic_node
ogeneric_task
sono scelte migliori diglobal
.k8s_cluster
: in un cluster Kubernetes.k8s_container
: container Kubernetes.k8s_node
: nodo Kubernetes.k8s_pod
: nel pod Kubernetes.
Una pratica comune consiste nell'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:
- Ottieni prestazioni migliori rispetto all'utilizzo di un singolo tipo di risorsa.
- Eviterai problemi di funzionamento dei dati causati da più processi che scrivono nel le stesse serie temporali.
- 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
ma nessuno dei tipi di risorse più specifici è appropriato.
Il tipo generic_task
è utile per definire risorse simili a quelle delle attività, come
diverse applicazioni. Il tipo generic_node
è utile per definire
di risorse come le macchine virtuali. Entrambi i tipi di generic_*
hanno diverse etichette comuni che puoi usare per definire oggetti risorse univoci,
semplificando il loro utilizzo nei filtri delle metriche per le aggregazioni e le riduzioni.
Al contrario, il tipo di risorsa global
ha solo project_id
e location
etichette. 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 i metodi nell'API Monitoring supportano le metriche definite dall'utente e i metodi che supportano le metriche integrate:
Metodo API Monitoring | Utilizza 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 copiare manualmente i dati in un'altra posizione, ad esempio Cloud Storage o in BigQuery.
Per informazioni sulle latenze associate alla scrittura di dati in metriche definite dall'utente. Consulta Latenza dei dati delle metriche.
Passaggi successivi
- Utilizza Google Cloud Managed Service per Prometheus per raccogliere Prometheus delle metriche di applicazioni in esecuzione su Google Kubernetes Engine e Kubernetes.
- Raccogli le metriche di Prometheus da in esecuzione su Compute Engine.
- Raccogliere metriche e tracce OTLP dalle applicazioni instrumentati mediante OpenTelemetry e l'esecuzione su Compute Engine.
- Creare metriche definite dall'utente con l'API
- Introduzione all'API Cloud Monitoring
- Metriche, serie temporali e risorse