In questa pagina vengono spiegate le nozioni di base della creazione di metriche OpenCensus per gli SLI di disponibilità e latenza. Fornisce inoltre esempi di implementazione di come definire gli SLO utilizzando le metriche OpenCensus.
Nozioni di base su OpenCensus
OpenCensus è una singola distribuzione open source di librerie, disponibile nella pagina di GitCensus GitHub, che raccoglie automaticamente tracce e metriche e le invia a qualsiasi backend. OpenCensus può essere utilizzato per utilizzare i tuoi servizi per emettere metriche personalizzate che possono essere importate in Cloud Monitoring. Puoi utilizzare queste metriche come SLI.
Per un esempio che utilizza OpenCensus per creare metriche di Monitoring non destinate specificamente agli SLI, consulta Metriche personalizzate con OpenCensus.
Metriche
Per raccogliere dati delle metriche dal tuo servizio utilizzando OpenCensus, devi utilizzare i seguenti costrutti OpenCensus:
-
Measure
, che rappresenta il tipo di metrica da registrare, specificato con un nome. UnMeasure
può registrare valori Int64 o Float64. -
Measurement
: registra un punto dati specifico raccolto e scritto daMeasure
per un particolare evento. Ad esempio, un elementoMeasurement
potrebbe registrare la latenza di una risposta specifica. -
View
, che specifica un'aggregazione applicata a un elementoMeasure
. OpenCensus supporta i seguenti tipi di aggregazione:- Conteggio: un conteggio del numero di punti di misurazione.
- Distribuzione: distribuzione di un istogramma dei punti di misurazione.
- Somma: una somma dei valori di misurazione.
- LastValue: l'ultimo valore registrato dalla misurazione.
Per ulteriori informazioni, consulta la pagina Statistiche/metriche OpenCensus. Tieni presente che OpenCensus spesso fa riferimento alle metriche come stats.
Strumentazione
Le librerie OpenCensus sono disponibili per diverse lingue. Per informazioni specifiche sulla lingua per la strumentazione del servizio per l'emissione di metriche, consulta la pagina relativa al supporto per la lingua di OpenCensus. Inoltre, le metriche personalizzate con OpenCensus forniscono esempi di lingue comunemente utilizzate con Monitoring.
Nel caso di base, devi eseguire queste operazioni:
- Instrumenta il tuo servizio per registrare ed esportare le metriche.
- Definisci un esportatore per ricevere le metriche.
Per ogni metrica devi definire un Measure
per specificare il tipo di valore:
Int64 o Float64. Devi anche definire e registrare il View
per specificare il
tipo di aggregazione (conteggio, distribuzione, somma o ultimo valore). Per utilizzare il tipo di aggregazione della distribuzione, devi specificare anche i limiti del bucket dell'istogramma in modo esplicito. Puoi anche specificare un nome per la metrica in View
.
Esportatore
Infine, devi utilizzare un esportatore per raccogliere le metriche e scriverle in Cloud Monitoring o un altro backend. Per informazioni sugli esportatori specifici per lingua disponibili per Monitoring, consulta la pagina relativa agli esportatori OpenCensus.
Puoi anche scrivere il tuo esportatore; per ulteriori informazioni, consulta la pagina Scrivere un esportatore personalizzato.
Creazione di metriche per SLI
La tua applicazione deve creare metriche OpenCensus che possono essere utilizzate come SLI in Cloud Monitoring:
- Per gli SLI di disponibilità su numero di richieste ed errori, utilizza un elemento
Measure
con aggregazione dei conteggi. - Per gli SLI di latenza, utilizza un
Measure
con aggregazione di distribuzione.
Metriche per SLI di disponibilità
Invii uno SLI di disponibilità basata su richiesta nell'API Cloud Monitoring utilizzando la struttura di TimeSeriesRatio
per impostare un rapporto di richieste "buone" o "brutte"; rispetto alle richieste totali. Questo rapporto viene utilizzato nel campo goodTotalRatio
di una struttura RequestBasedSli
.
La tua applicazione deve creare metriche OpenCensus che possono essere utilizzate per creare questo rapporto. Nella tua applicazione, devi creare almeno due dei seguenti elementi:
Una metrica che conteggia il totale degli eventi; utilizzala nel rapporto
totalServiceFilter
.Puoi creare una metrica OpenCensus di tipo Int64 con aggregazione del conteggio, in cui registri un valore
1
per ogni richiesta ricevuta.Una metrica che conteggia gli eventi"cattivi", usala nel rapporto
badServiceFilter
.Puoi creare una metrica OpenCensus di tipo Int64 con aggregazione dei conteggi, in cui registri un valore
1
per ogni richiesta non riuscita o errata.Una metrica che conta gli eventi validi, utilizzala nel rapporto
goodServiceFilter
.Puoi creare una metrica OpenCensus di tipo Int64 con aggregazione dei conteggi, in cui registri un valore
1
per ogni risposta riuscita.
Metriche per SLI di latenza
Puoi esprimere uno SLI di latenza basato su richiesta nell'API Cloud Monitoring utilizzando una struttura DistributionCut
. Questa
struttura è utilizzata nel campo distributionCut
di una struttura
RequestBasedSli
.
Puoi creare un Measure
Int64 o Float64 con un View
utilizzando il tipo di aggregazione della distribuzione. Devi inoltre definire esplicitamente i
limiti del bucket. Tieni presente che è fondamentale definire i bucket in modo da poter misurare con precisione la percentuale di richieste che rientrano nella soglia desiderata. Per una discussione su questo argomento, consulta la pagina relativa all'implementazione degli SLO nella Site Reliability Engineering Workbook.
Esempio di implementazione
Questa sezione presenta un esempio che implementa le metriche per gli SLI di base relativi a disponibilità e latenza utilizzando OpenCensus in Node.js.
Strumentazione
Per utilizzare il tuo servizio per l'emissione di metriche tramite OpenCensus, procedi nel seguente modo:
- Includi le librerie necessarie:
Go
Node.js
Python
- Definisci e registra l'esportatore:
Go
Node.js
Python
- Definisci un
Measure
per ogni metrica:Go
Node.js
Python
- Definisci e registra l'elemento
View
per ogniMeasure
con il tipo di aggregazione appropriato e, per la latenza di risposta, i limiti del bucket:
Go
Node.js
Python
- Registra i valori per le metriche relative al numero di richieste e agli errori:
Go
Node.js
Python
- Registra valori di latenza:
Go
Node.js
Python
Metriche importate
Quando le metriche vengono esportate in Cloud Monitoring, vengono visualizzate come tipi di metriche con un prefisso che indica che hanno avuto origine da OpenCensus. Ad esempio, il nome di ogni View
OpenCensus nell'implementazione Node.js è mappato come segue:
request_count_sli
diventacustom.googleapis.com/opencensus/request_count_sli
.error_count_sli
diventacustom.googleapis.com/opencensus/error_count_sli
.response_latency_sli
diventacustom.googleapis.com/opencensus/response_latency_sli
.
Dopo l'esecuzione del tuo servizio, puoi confermare che le metriche vengano importate in Monitoring cercandole in Metrics Explorer.
SLI di disponibilità
In Cloud Monitoring, esprimi uno SLI di disponibilità basato su richiesta utilizzando una struttura
TimeSeriesRatio
. L'esempio seguente mostra uno SLO che utilizza le metriche OpenCensus importate e prevede che il servizio abbia una disponibilità del 98%, calcolato da un rapporto di error_count_sli
a request_count_sli
, in una finestra continuativa di 28 giorni:
{
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"custom.googleapis.com/opencensus/request_count_sli\",
"badServiceFilter":
"metric.type=\"custom.googleapis.com/opencensus/error_count_sli\"
}
}
},
"goal": 0.98,
"rollingPeriod": "2419200s",
"displayName": "98% Availability, rolling 28 days"
}
SLI di latenza
In Cloud Monitoring, esprimi uno SLI di latenza basato su richiesta utilizzando una struttura DistributionCut
. L'esempio seguente mostra uno SLO che utilizza la metrica di latenza OpenCensus importati e prevede che il 98% delle richieste venga completato in meno di 1000 ms in una finestra continuativa di un giorno:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"custom.googleapis.com/opencensus/response_latency_sli\",
"range": {
"min": 0,
"max": 1000
}
}
}
},
"goal": 0.98,
"rollingPeriod": "86400s",
"displayName": "98% requests under 1000 ms"
}