Un servicio de solicitud/respuesta es el que un cliente solicita de manera explícita que el servicio realice un trabajo y espera a que ese trabajo se complete de forma correcta. Los ejemplos más comunes de esos servicios son los siguientes:
- Aplicaciones web con las que los usuarios humanos interactúan directamente mediante un navegador.
- Aplicaciones para dispositivos móviles que consisten en una aplicación cliente en el teléfono de un usuario y un backend de API con el que el cliente interactúa.
- Backends de API que usan otros servicios (en lugar de usuarios humanos).
Para todos estos servicios, el enfoque común es comenzar con la disponibilidad (medición de la proporción de solicitudes exitosas) y la latencia (medición de la proporción de solicitudes que se completan con un SLI de tiempo límite). Para obtener más información sobre los SLI de disponibilidad y latencia, consulta Conceptos de la supervisión del servicio.
Puedes expresar un SLI de disponibilidad basado en solicitudes mediante la estructura TimeSeriesRatio para configurar una proporción de solicitudes correctasa solicitudes totales. Tú decides cómo filtrar la métrica con las etiquetas disponibles para llegar a la determinación preferida de “correcta” o “válida”.
Puedes expresar un SLI de latencia basado en solicitudes mediante una estructura DistributionCut.
Cloud Endpoints
Cloud Endpoints es un servicio para administrar API. Este te permite tomar una API existente y exponerla con autenticación, cuotas y supervisión.
Endpoints se implementan como un proxy frente al servidor de aplicaciones de gRPC. Cuando mides las métricas en el proxy, puedes manejar correctamente el caso cuando todos los backends no están disponibles y los usuarios ven errores.
Endpoints escribe datos en los tipos de métricas que comienzan con el prefijo serviceruntime.googleapis.com.
Para obtener más información, consulta lo siguiente:
- Consulta la documentación de Cloud Endpoints.
- Lista de tipos de métricas de
serviceruntime.googleapis.com.
SLI de disponibilidad
Cloud Endpoints escribe datos de métricas en Cloud Monitoring con el tipo de recurso supervisado api y el tipo de métrica del entorno de ejecución de servicio api/request_count, que puedes filtrar con la etiqueta de métricas response_code para contar las solicitudes “correctas” y “totales”.
Para expresar un SLI de disponibilidad basado en solicitudes, crea una estructura TimeSeriesRatio para las solicitudes “correctas” a las solicitudes totales, como se muestra en el siguiente ejemplo:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"serviceruntime.googleapis.com/api/request_count\"
resource.type=\"api\"
metric.label.\"response_code_class\"!=\"4xx\"",
"goodServiceFilter":
"metric.type=\"serviceruntime.googleapis.com/api/request_count\"
resource.type=\"api\"
(metric.label.\"response_code_class\"=\"1xx\"" OR
metric.label.\"response_code_class\"=\"2xx\""),
}
}
}
SLI de latencia
Cloud Endpoints usa los siguientes tipos de métricas principales para capturar la latencia:
-
api/request_latencies: una distribución de latencias en segundos para solicitudes sin transmisión. Se usa cuando la experiencia general del usuario es de suma importancia. -
api/request_latencies_backend: Es una distribución de latencias de backend en segundos para solicitudes sin transmisión. Se usa para medir las latencias de backend directamente. -
api/request_latencies_overhead: Es una distribución de latencias de solicitud en segundos para solicitudes que no son de transmisión, sin incluir el backend. Se usa para medir la sobrecarga que presenta el proxy de Endpoints.
Ten en cuenta que la latencia total de la solicitud es la suma de las latencias de backend y sobrecarga:
request_latencies = request_latencies_backend + request_latencies_overhead
Endpoints escribe datos de métricas en Cloud Monitoring mediante el tipo de recurso supervisado api y uno de los tipos de métricas de latencia de la solicitud.
Ninguno de estos tipos de métricas proporciona una etiqueta response_code o response_code_class. por lo tanto, informan latencias para todas las solicitudes.
Expresas un SLI de latencia basado en solicitudes con una estructura DistributionCut, como se muestra en los siguientes ejemplos.
En el siguiente ejemplo de SLO, se espera que el 99% de todas las solicitudes en el proyecto se encuentren entre 0 y 100 ms en latencia total durante un período progresivo de una hora:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"serviceruntime.googleapis.com/ap/request_latencies\"
resource.type=\"api\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}
En el siguiente ejemplo de SLO, se espera que el 98% de las solicitudes estén entre 0 y 100 ms en la latencia de backend durante un período progresivo de una hora:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"serviceruntime.googleapis.com/api/backend_latencies\"
resource.type=\"api\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Cloud Run
Cloud Run es una plataforma de procesamiento completamente administrada con la que se pueden implementar y escalar aplicaciones alojadas en contenedores de con rapidez y de forma segura. Está diseñado a fin de abstraer toda la administración de la infraestructura; para ello, responde a los cambios en el tráfico mediante el ajuste de escala automático que aumenta o disminuye desde cero, de forma casi instantánea, y solo te cobra por los recursos exactos que usas.
Para obtener información adicional sobre la observabilidad de Cloud Run. Consulta lo siguiente:
- Documentación de Cloud Run.
- Lista de tipos de métricas de
run.googleapis.com.
SLI de disponibilidad
Cloud Run escribe datos de métricas en Cloud Monitoring mediante el tipo de recurso supervisado cloud_run_revision y el tipo de métrica request_count. Puedes filtrar los datos con las etiquetas response_code o response_code_class para contar las solicitudes “correctas” y “totales”.
Para expresar un SLI de disponibilidad basado en solicitudes, crea una estructura TimeSeriesRatio para las solicitudes “correctas” a las solicitudes totales, como se muestra en el siguiente ejemplo:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"run.googleapis.com/request_count\"
resource.type=\"cloud_run_revision\"
metric.label.\"response_code_class\"!=\"4xx\"",
"goodServiceFilter":
"metric.type=\"run.googleapis.com/request_count\"
resource.type=\"cloud_run_revision\"
(metric.label.\"response_code_class\"=\"1xx\"" OR
metric.label.\"response_code_class\"=\"2xx\""),
}
}
}
SLI de latencia
Para medir la latencia, Cloud Run escribe datos de métricas en Cloud Monitoring con el tipo de recurso supervisado cloud_run_revision y el tipo de métrica request_latencies. Los datos son una distribución de latencia de solicitud en milisegundos que alcanzan la revisión. Puedes filtrar los datos mediante la etiqueta de métrica response_code o response_code_class si necesitas medir de forma explícita la latencia de todas las solicitudes o solo las que se completaron de forma correcta.
Puedes expresar un SLI de latencia basado en solicitudes mediante una estructura DistributionCut. En el siguiente ejemplo de SLO, se espera que el 99% de las solicitudes se encuentren entre 0 y 100 ms en latencia total durante un período progresivo de una hora:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"run.googleapis.com/request_latencies\"
resource.type=\"cloud_run_revision"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}
Funciones de Cloud Run
Las funciones de Cloud Run son una oferta escalable de funciones como servicio, con modalidad de pago por uso, que ejecutan tu código sin que debas administrar la infraestructura. Las funciones se usan en muchos patrones de arquitectura para realizar tareas como el procesamiento de eventos, la automatización y la entrega de solicitudes HTTP/S.
Para obtener información sobre la observabilidad de las funciones de Cloud Run, consulta los siguientes vínculos:
- Documentación de las funciones de Cloud Run.
- Lista de tipos de métricas de
run.googleapis.com.
SLI de disponibilidad
Las funciones de Cloud Run escriben datos de métricas en Cloud Monitoring con el tipo de recurso supervisado
cloud_function y el tipo de métrica
function/execution_time.
Puedes filtrar los datos con la etiqueta de métrica status para contar las ejecuciones “correctas” y “totales”.
Para expresar un SLI de disponibilidad basado en solicitudes, crea una estructura TimeSeriesRatio para las solicitudes “correctas” a las solicitudes totales, como se muestra en el siguiente ejemplo:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"cloudfunctions.googleapis.com/function/execution_count\"
resource.type=\"cloud_function\"",
"goodServiceFilter":
"metric.type=\"cloudfunctions.googleapis.com/function/execution_count\"
resource.type=\"cloud_function\
metric.label.\"status\"=\"ok\"",
}
}
}
SLI de latencia
Para medir la latencia, las funciones de Cloud Run escriben datos de métricas en Cloud Monitoring
con el tipo de recurso supervisado
cloud_function y el tipo de métrica
function/execution_times. Los datos son una distribución de los tiempos de ejecución de las funciones en nanosegundos.
Puedes filtrar los datos mediante status si necesitas medir de forma explícita la latencia de todas las ejecuciones o solo de las correctas.
Puedes expresar un SLI de latencia basado en solicitudes mediante una estructura DistributionCut. En el siguiente
ejemplo de SLO, se espera que el 99% de todas las ejecuciones de funciones de Cloud Run tengan una latencia total
de 0 ms a 100 ms durante un período progresivo de una hora:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"cloudfunctions.googleapis.com/function/execution_times\"
resource.type=\"cloud_function\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}
App Engine
App Engine proporciona una plataforma sin servidores completamente administrada para compilar y ejecutar aplicaciones. Puedes elegir entre dos entornos, estándar o flexible. Para obtener más información, consulta Elige un entorno de App Engine.
Para obtener más información sobre App Engine, consulta lo siguiente:
- Documentación de App Engine.
- Lista de tipos de métricas de
appengine.googleapis.com.
SLI de disponibilidad
App Engine escribe datos de métricas en Cloud Monitoring mediante el tipo de recurso supervisado gae_app y el tipo de métrica http/server/response_count.
Puedes filtrar los datos con la etiqueta de métrica response_code para contar las respuestas “correctas” y “totales”.
Debes expresar un SLI de disponibilidad basado en solicitudes para App Engine mediante la creación de una estructura TimeSeriesRatio para las solicitudes correctas y totales, como se muestra en el siguiente ejemplo:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"appengine.googleapis.com/http/server/response_count\"
resource.type=\"gae_app\"
metric.label.\"response_code\">\"499\"
metric.label.\"response_code\"<\"399\"",
"goodServiceFilter":
"metric.type=\"appengine.googleapis.com/http/server/response_count\"
resource.type=\"gae_app\"
metric.label.\"response_code\"<\"299\"",
}
}
}
SLI de latencia
Para medir la latencia, App Engine escribe datos de métricas en Cloud Monitoring mediante el tipo de recurso supervisado gae_app y el tipo de métrica http/server/response_latencies.
Puedes filtrar los datos con la etiqueta de métrica response_code para contar las ejecuciones “correctas” y “totales”.
Debes expresar un SLI de latencia basado en solicitudes para App Engine mediante una estructura DistributionCut. En el siguiente ejemplo de SLO, se espera que el 99% de todas las solicitudes se encuentren entre 0 y 100 ms en latencia total durante un período progresivo de una hora:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"appengine.googleapis.com/http/server/response_latencies\"
resource.type=\"gae_app\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}
Istio y GKE
Google Kubernetes Engine (GKE) es el servicio de Kubernetes seguro y administrado de Google con ajuste de escala automático en cuatro direcciones y compatibilidad con varios clústeres. Istio es una malla de servicios de código abierto que te permite conectar, proteger, controlar y observar servicios. Istio se puede instalar en GKE como un complemento (Cloud Service Mesh) o el usuario puede instalarlo desde el proyecto de código abierto. En ambos casos, Istio proporciona telemetría excelente, incluida la información sobre el tráfico, los errores y la latencia para cada servicio administrado por la malla.
Para obtener una lista completa de las métricas de Istio, consulta Tipos de métricas istio.io.
SLI de disponibilidad
Istio escribe datos de métricas en Cloud Monitoring mediante el tipo de métrica service/server/request_count y uno de los siguientes tipos de recursos supervisados:
Puedes filtrar los datos mediante la etiqueta de métrica response_code para contar las ejecuciones “correctas” y “totales”. También puedes usar la etiqueta de métrica destination_service_name para contar las solicitudes de un servicio específico.
Debes expresar un SLI de disponibilidad basado en solicitudes para un servicio que se ejecuta en GKE administrado por la malla de servicios de Istio mediante la creación de una estructura TimeSeriesRatio para solicitudes buenas a las solicitudes totales, como se muestra en el siguiente ejemplo:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"istio.io/service/server/request_count\"
resource.type=\"k8s_container\"
metric.label.\"destination_service_name\"=\"frontend\"",
"goodServiceFilter":
"metric.type=\istio.io/server/response_count\"
resource.type=\"k8s_container\"
metric.label.\"destination_service_name\"=\"frontend\"
metric.label.\"response_code\"<\"299\"",
}
}
}
SLI de latencia
Para medir la latencia, Istio escribe datos de métricas en Cloud Monitoring mediante el tipo de métrica service/server/response_latencies y uno de los siguientes tipos de recursos supervisados:
Puedes filtrar los datos con la etiqueta de métrica response_code para contar la etiqueta de métrica "good" and "total" requests. You can also use the destination_service_name` a fin de contar las solicitudes de un servicio específico.
Expresas un SLI de latencia basado en solicitudes para un servicio que se ejecuta en GKE administrado por la malla de servicios de Istio mediante una estructura DistributionCut.
En el siguiente ejemplo de SLO, se espera que el 99% de las solicitudes al servicio de frontend caigan entre 0 y 100 ms de latencia total durante un período progresivo de una hora:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"istio.io/server/response_latencies\"
resource.type=\"k8s_container\"
metric.label.\"destination_service_name\"=\"frontend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}