Los servicios de datos de Google Cloud que se analizan en esta página incluyen aquellos que proporcionan datos y generan los resultados de ese procesamiento, ya sea en respuesta a una solicitud o de forma continua. En lugar de usar la disponibilidad y la latencia como los SLI principales para estos servicios, las opciones más adecuadas son las siguientes:
- Precisión, una medición de la cantidad de errores de procesamiento que genera la canalización.
- Actualidad, una medición de la rapidez con la que se procesan los datos.
Para obtener más información sobre las canalizaciones de datos desde la perspectiva de SRE, consulta Canalizaciones de procesamiento de datos en la Hoja de trabajo de ingeniería de confiabilidad de sitios.
Puedes expresar un SLI de exactitud basado en solicitudes mediante la estructura TimeSeriesRatio para configurar una proporción de elementos que tuvieron problemas de procesamiento de todos los elementos que se procesaron.
Tú decides cómo filtrar la métrica con las etiquetas disponibles para llegar a la determinación que prefieras de los totales de “problema” y “válida”.
Puedes expresar un SLI de actualidad basado en solicitudes con una estructura DistributionCut.
Dataflow
Dataflow es un servicio de análisis de transmisiones completamente administrado que minimiza la latencia, el tiempo de procesamiento y los costos. Puedes usar Dataflow para procesar datos como una transmisión o en lotes con el SDK de Apache Beam.
Para obtener información adicional, consulta las siguientes secciones:
- Documentación de Dataflow.
- Lista de tipos de métricas de
dataflow.googleapis.com.
SLI de exactitud
Dataflow escribe datos de métricas en Cloud Monitoring con el tipo de recurso supervisado dataflow_job y el tipo de métrica job/element_count, que cuenta la cantidad de elementos que se agregaron a la PCollection hasta ahora. Si completas la etiqueta de recurso job_name, aparece la cantidad de elementos que procesará el trabajo.
Por otra parte, puedes usar el tipo de métrica logging.googleapis.com/log_entry_countdataflow_job para contar la cantidad de errores que registra un trabajo en particular mediante la etiqueta de métrica severity.
Puedes usar estas métricas para expresar un SLI de exactitud basado en solicitudes como una fracción de errores y todos los elementos procesados mediante una estructura de TimeSeriesRatio, como se muestra en el campo siguiente ejemplo:
"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\"",
}
}
}
Frecuencia de SLI
Dataflow también escribe los datos de las métricas en Cloud Monitoring mediante el tipo de recurso supervisado dataflow_job y el tipo de métrica job/per_stage_system_lag, que mide la duración máxima actual que un elemento de datos procesó o esperaba procesar.
Puedes expresar un SLI de actualización con esta métrica mediante una estructura DistributionCut.
En el siguiente ejemplo de SLO, se espera que el elemento de datos más antiguo se procese en menos de 100 segundos el 99% de las veces durante un período de una hora progresiva:
{
"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"
}
También puedes expresar un SLI de actualización mediante una estructura WindowsBasedSli.
En el siguiente ejemplo de SLO, se espera que el 99% de las ventanas de cinco minutos durante un período progresivo de un día no vean elementos (cero) procesados en más de 100 segundos:
{
"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"
}
Ten en cuenta que, para que una ventana se considere “correcta”, la métrica no puede exceder el límite especificado en range en cualquier momento durante la ventana de evaluación.
Dataproc
Dataproc proporciona un clúster completamente administrado y con propósitos específicos que puede realizar un ajuste de escala automático para admitir cualquier trabajo de procesamiento de estadísticas, Hadoop o Spark.
Para obtener información adicional, consulta las siguientes secciones:
- Documentación de Dataproc.
- Lista de tipos de métricas de
dataproc.googleapis.com.
SLI de exactitud
Dataproc escribe datos de métricas en Cloud Monitoring con el tipo de recurso supervisado cloud_dataproc_cluster y los siguientes tipos de métricas:
-
cluster/job/submitted_count, que cuenta la cantidad total de trabajos enviados. -
cluster/job/failed_count, que cuenta la cantidad total de trabajos con errores.
Puedes usar estas métricas para expresar un SLI de exactitud basado en solicitudes como una proporción, TimeSeriesRatio, de los trabajos con errores a todos los trabajos enviados, como se muestra en el siguiente ejemplo:
"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\"",
}
}
}
Frecuencia de SLI
Dataproc escribe datos de métricas en Cloud Monitoring con el tipo de recurso supervisado cloud_dataproc_cluster y los siguientes tipos de métricas:
-
cluster/job/duration, que mide cuánto tiempo permanecen los trabajos en los estados de procesamiento. Puedes filtrar datos en la etiqueta de métricastatepara identificar el tiempo empleado en los estados específicos. Por ejemplo, puedes crear un SLI que mida cuánto tiempo están los trabajos en el estadoPENDINGpara establecer un tiempo de espera máximo permitido antes de que el trabajo comience a procesarse. -
cluster/job/completion_time, que mide cuánto tiempo permanecen los trabajos en la métricacluster/job/completion_time. Se usa cuando la finalización del trabajo es una métrica aceptable o cuando el volumen de datos procesados por los trabajos en un clúster no varía, lo que afectaría el tiempo de procesamiento.
Puedes expresar un SLI de actualización con estas métricas mediante una estructura DistributionCut, como se muestra en los siguientes ejemplos.
En el siguiente ejemplo de SLO, se usa cluster/job/duration y se espera que el 99% de los trabajos en "my_cluster" estén en el estado PENDING durante menos de 100 segundos en un período de 24 horas progresivos:
{
"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"
}
En el siguiente ejemplo de SLO, se usa cluster/job/completion_time y se espera que el 99% de los trabajos de “my_cluster” se completen en menos de 100 segundos en un período continuo de 24 horas:
{
"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"
}