I servizi di dati di Google Cloud descritti in questa pagina includono quelli che elaborano i dati forniti e generano i risultati di questa elaborazione, in risposta a una richiesta o in modo continuo. Anziché utilizzare la disponibilità e la latenza come SLI principali per questi servizi, le scelte più appropriate sono le seguenti:
- Correttezza, una misura del numero di errori di elaborazione riscontrati dalla pipeline.
- Aggiornamento, una misura della velocità di elaborazione dei dati.
Per ulteriori informazioni sulle pipeline di dati dal punto di vista dell'SRE, consulta Pipeline di elaborazione dei dati nel Foglio di lavoro Site Reliability Engineering.
Per esprimere uno SLI di correttezza basato sulla richiesta, utilizza
TimeSeriesRatio per configurare una
rapporto tra gli articoli con problemi di elaborazione e tutti gli articoli elaborati.
Sei tu a decidere come filtrare la metrica utilizzando
disponibili per arrivare alla determinazione del "problema" che preferisci
e "valido" totali.
Un SLI di aggiornamento basato su richiesta viene espresso utilizzando una struttura DistributionCut.
Dataflow
Dataflow è un servizio completamente gestito di analisi dei flussi di dati che riduce al minimo la latenza, i tempi di elaborazione e i costi. Puoi utilizzare la modalità Dataflow per elaborare i dati come flusso o in batch utilizzando SDK Apache Beam.
Per ulteriori informazioni, consulta quanto segue:
- Documentazione di Dataflow.
- Elenco dei tipi di metriche
dataflow.googleapis.com.
SLI di correttezza
Dataflow scrive i dati delle metriche in Cloud Monitoring utilizzando
dataflow_job tipo di risorsa monitorata e
job/element_count, che conteggia il numero di
elementi aggiunti alla raccolta finora. La somma dell'etichetta della risorsa job_name
ti fornisce il numero di elementi da elaborare dal job.
Separatamente, puoi utilizzare il tipo di metrica
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
una frazione di errori e di tutti gli elementi elaborati utilizzando
TimeSeriesRatio, come mostrato nella
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 anche i dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa monitorata dataflow_job e il tipo di metrica job/per_stage_system_lag, che misura la durata massima attuale per la quale un elemento di dati è in attesa di elaborazione o è in fase di elaborazione.
Puoi esprimere uno SLI di aggiornamento utilizzando questa metrica utilizzando una
Struttura di DistributionCut.
Il seguente esempio di SLO prevede che l'elemento di dati più antico venga elaborato in meno di 100 secondi il 99% delle volte in un periodo 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
Struttura di WindowsBasedSli.
Lo SLO di esempio seguente prevede che il 99% delle finestre di cinque minuti periodo continuativo di un giorno non vede (zero) elementi elaborati 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 sia considerata "buona", la metrica non può superare la
soglia specificata in range in nessun momento durante la finestra di valutazione.
Dataproc
Dataproc fornisce un cluster completamente gestito e creato appositamente può scalare automaticamente per supportare qualsiasi tipo di dati Hadoop o Spark, di elaborazione delle analisi.
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
cloud_dataproc_cluster tipo di risorsa monitorata e quanto segue
tipi di metriche:
-
cluster/job/submitted_count, che conteggia le numero totale di job inviati. -
cluster/job/failed_count, che conteggia le numero totale di job non riusciti.
Puoi utilizzare queste metriche per esprimere un SLI di correttezza basato su richiesta come rapporto,
TimeSeriesRatio, tra i job non riusciti e 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 scrive anche i dati delle metriche in Cloud Monitoring
utilizzando
cloud_dataproc_cluster tipo di risorsa monitorata e quanto segue
tipi di metriche:
-
cluster/job/duration, che misura il tempo di permanenza dei job in di elaborazione. Puoi filtrare i dati dell'etichetta della metricastateper identificare il tempo trascorso in stati specifici. Ad esempio, puoi creare uno SLI che misura per quanto tempo i job si trovano nello statoPENDING, per impostare un valore massimo consentito prima dell'inizio dell'elaborazione del job. -
cluster/job/completion_time, che misura il tempo di permanenza dei job nella metricacluster/job/completion_time. Da utilizzare se il completamento di un job una metrica ben compresa o quando il volume di dati elaborati dai job in un cluster non varia, il che influirebbe sui tempi di elaborazione.
Puoi esprimere un SLI di aggiornamento utilizzando queste metriche con una struttura DistributionCut, come mostrato nei seguenti esempi.
Lo SLO di esempio seguente utilizza cluster/job/duration e prevede che
99% dei job in "my_cluster" Sono 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'esempio seguente di SLO utilizza cluster/job/completion_time e prevede che il 99% dei job in "my_cluster" venga completato in meno di 100 secondi in un periodo 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"
}