I dati di Google Cloud illustrati in questa pagina includono quelli che elaborano i dati forniti e restituiscono i risultati di tale elaborazione, in risposta a una richiesta o in modo continuo. Invece di utilizzare disponibilità e latenza come SLI principali per questi servizi, le scelte più appropriate sono le seguenti:
- Correttezza, ovvero la misura del numero di errori di elaborazione riscontrati dalla pipeline.
- Frequenza di aggiornamento: misura della velocità di elaborazione dei dati.
Per ulteriori informazioni sulle pipeline di dati dal punto di vista SRE, consulta la pagina relativa alle pipeline di elaborazione dati nella guida dell'ingegneria di Site Reliability Engineering.
Per esprimere uno SLI di correzione basato su richiesta, utilizza la struttura
TimeSeriesRatio
per configurare
un rapporto di elementi con problemi di elaborazione di tutti gli elementi elaborati.
Decidi di filtrare la metrica utilizzando le etichette disponibili per ottenere il risultato che ritieni migliore per il problema.
Per esprimere uno SLI di aggiornamento basato su richiesta, utilizza una struttura
DistributionCut
.
Dataflow
Dataflow è un servizio completamente gestito di analisi dei flussi di dati, che riduce al minimo latenza, tempi di elaborazione e costi. Puoi utilizzare Cloud Dataflow per elaborare i dati in modalità flusso o in batch utilizzando l'SDK Apache Beam.
Per ulteriori informazioni, consulta quanto segue:
- Documentazione per Dataflow.
- Elenco dei tipi di metriche
dataflow.googleapis.com
.
SLI di correttezza
Dataflow scrive i dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa monitorata, dataflow_job
e il tipo di metrica job/element_count
, che conteggia il numero di elementi aggiunti finora alla raccolta dei dati. La somma in tutta l'etichetta delle risorse job_name
ti fornisce il numero di elementi che il job deve elaborare.
Separatamente, puoi utilizzare il tipo di metrica
con il tipo di risorsa monitorata con
logging.googleapis.com
/log_entry_countdataflow_job
per conteggiare il numero di errori
registrati da un determinato job, utilizzando l'etichetta della metrica severity
.
Puoi utilizzare queste metriche per esprimere uno SLI di correttezza basato su richiesta come frazione di errori e tutti gli elementi elaborati utilizzando una struttura TimeSeriesRatio
, come mostrato nell'esempio seguente:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"dataflow.googleapis.com/job/element_count\"
resource.type=\"dataflow_job\"
resource.label.\"job_name\"=\"my_job\"",
"badServiceFilter":
"metric.type=\"logging.googleapis.com/log_entry_count\"
resource.type=\"dataflow_job\"
resource.label.\"job_name\"=\"my_job\"
metric.label.\"severity\"=\"error\"",
}
}
}
SLI di aggiornamento
Dataflow scrive i dati delle metriche anche in Cloud Monitoring utilizzando il tipo di risorsa monitorato di dataflow_job
e il tipo di metrica job/per_stage_system_lag
, che misura la durata massima corrente di elaborazione o di attesa di un elemento di dati.
Per esprimere uno SLI di aggiornamento utilizzando questa metrica, puoi utilizzare una struttura DistributionCut
.
Il seguente SLO di esempio prevede che l'elemento di dati meno recente venga elaborato in meno di 100 secondi per il 99% delle volte in un periodo continuativo di un'ora:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"dataflow.googleapis.com/job/per_stage_system_lag\"
resource.type=\"dataflow_job\"
resource.label.\"job_name\"=\"my_job\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% data elements processed under 100 s"
}
Puoi anche esprimere uno SLI di aggiornamento utilizzando una struttura
WindowsBasedSli
.
Nell'esempio seguente lo SLO prevede che il 99% delle finestre di cinque minuti in un periodo continuativo di 1 giorno non visualizzi alcun elemento (zero) elaborato in più di 100 secondi:
{
"displayName": "Dataflow - windowed freshness",
"serviceLevelIndicator": {
"windowsBased": {
"windowPeriod": "300s",
"metricMeanInRange": {
"timeSeries":
"metric.type=\"dataflow.googleapis.com/job/per_stage_system_lag\"
resource.type=\"dataflow_job\"
resource.label.\"job_name\"=\"my_job\"",
"range": {
"min": "0",
"max": "100"
}
}
}
},
"goal": 0.99,
"rollingPeriod": "86400s"
}
Tieni presente che, affinché una finestra venga considerata"buona", la metrica non può superare la soglia specificata in range
in nessun momento della finestra di valutazione.
Dataproc
Dataproc fornisce un cluster creato appositamente e completamente gestito che può scalare automaticamente per supportare qualsiasi job di elaborazione di dati o analisi Hadoop o Spark.
Per ulteriori informazioni, consulta quanto segue:
- Documentazione per Dataproc.
- Elenco dei tipi di metriche
dataproc.googleapis.com
.
SLI di correttezza
Dataproc scrive i dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa monitorata cloud_dataproc_cluster
e i seguenti tipi di metriche:
-
cluster/job/submitted_count
, che conta il numero totale di job inviati. -
cluster/job/failed_count
, che conta il numero totale di job non riusciti.
Puoi utilizzare queste metriche per esprimere uno SLI di correttezza basato su richiesta come rapporto,
TimeSeriesRatio
, di job non riusciti in tutti i job
inviati, come mostrato nell'esempio seguente:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"dataproc.googleapis.com/cluster/job/submitted_count\"
resource.type=\"cloud_dataproc_cluster\"
resource.label.\"cluster_name\"=\"my_cluster\"",
"badServiceFilter":
"metric.type=\"dataproc.googleapis.com/cluster/job/failed_count\"
resource.type=\"cloud_dataproc_cluster\"
resource.label.\"cluster_name\"=\"my_cluster\"",
}
}
}
SLI di aggiornamento
Dataproc inoltre scrive i dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa monitorata cloud_dataproc_cluster
e i seguenti tipi di metriche:
-
cluster/job/duration
, che misura la durata dei job negli stati di elaborazione. Puoi filtrare i dati sull'etichetta della metricastate
in modo da identificare il tempo trascorso in stati specifici. Ad esempio, puoi creare uno SLI che misura la durata dei job nello statoPENDING
per impostare un tempo massimo di attesa consentito prima che il job inizi l'elaborazione. -
cluster/job/completion_time
, che misura la durata dei job nella metricacluster/job/completion_time
. Da utilizzare quando una completazione del job è una metrica ben compresa o quando il volume dei dati elaborati dai job in un cluster non varia, il che influisce sul tempo di elaborazione.
Puoi esprimere uno SLI di aggiornamento utilizzando queste metriche utilizzando una struttura DistributionCut
, come mostrato negli esempi seguenti.
L'SLO di esempio seguente utilizza cluster/job/duration
e si aspetta che il 99% dei job in "my_cluster" si trovi nello stato PENDING
per meno di 100 secondi
in un periodo continuativo di 24 ore:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"dataproc.googleapis.com/cluster/job/duration\"
resource.type=\"cloud_dataproc_cluster\"
resource.label.\"cluster_name\"=\"my_cluster\"
metric.label.\"state\"=\"PENDING\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "86400s",
"displayName": "Dataproc pending jobs"
}
L'SLO di esempio seguente utilizza cluster/job/completion_time
e prevede che il 99% dei job in "my_cluster" vengano completati in meno di 100 secondi in un periodo continuativo di 24 ore:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"dataproc.googleapis.com/cluster/job/completion_time\"
resource.type=\"cloud_dataproc_cluster\"
resource.label.\"cluster_name\"=\"my_cluster\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "86400s",
"displayName": "Dataproc completed jobs"
}