Servicios de solicitud y respuesta

Un servicio de solicitud-respuesta es donde un cliente le pide explícitamente al servicio que realice algunas tareas y espera a que el trabajo se complete con éxito. Los ejemplos más comunes de estos servicios son los siguientes:

  • Aplicaciones web con las que interactúan los usuarios humanos directamente con un navegador
  • Aplicaciones para dispositivos móviles que consisten en una aplicación cliente en el teléfono celular de un usuario y un backend de API con el que interactúa el cliente.
  • Backends de API que usan otros servicios (en lugar de usuarios humanos).

Para todos estos servicios, el enfoque común consiste en comenzar con la disponibilidad (que mide la proporción de solicitudes exitosas) y la latencia (que mide la proporción de solicitudes que se completan con un límite de tiempo). Para obtener más información sobre los SLI de disponibilidad y latencia, consulta Conceptos en la supervisión de servicios.

Expresas un SLI de disponibilidad basado en solicitudes mediante la estructura TimeSeriesRatio a fin de establecer una proporción entre solicitudes aceptables y 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. Te permite tomar una API existente y exponerla con autenticación, cuotas y supervisión.

Endpoints se implementa como un proxy frente al servidor de aplicaciones de gRPC. Mediante la medición de las métricas en el proxy, puedes controlar correctamente el caso cuando todos los backends no estén disponibles y los usuarios vean 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:

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\">\"499\"
         metric.label.\"response_code_class\"<\"399\"",
      "goodServiceFilter":
        "metric.type=\"serviceruntime.googleapis.com/api/request_count\"
         resource.type=\"api\"
         metric.label.\"response_code_class\"<=\"299\"",
    }
  }
}

SLI de latencia

Cloud Endpoints usa los siguientes tipos de métricas principales para capturar la latencia:

  • api/request_latencies: Es una distribución de latencias en segundos para las solicitudes sin transmisión. Se usa cuando la experiencia del usuario general es de suma importancia.
  • api/request_latencies_backend: 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: Una distribución de las latencias de solicitud en segundos para las solicitudes sin transmisión, excluye 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 del backend y las latencias sobrecargas:

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 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 mediante el uso de una estructura DistributionCut, como se muestra en los siguientes ejemplos.

En el siguiente ejemplo de SLO, se espera que el 99% de las solicitudes del proyecto caiga entre 0 y 100 ms en la latencia total durante un período de una hora progresiva:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"serviceruntime.googleapis.com/ap/request_latencies\"
           resource.type=\"api\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "86400s",
  "displayName": "98% requests under 100 ms"
}

En el siguiente SLO de ejemplo, se espera que el 98% de las solicitudes caiga entre 0 y 100 ms en latencia de backend en un período de una hora progresiva:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"serviceruntime.googleapis.com/api/backend_latencies\"
           resource.type=\"api\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.98,
  "rollingPeriod": "86400s",
  "displayName": "98% requests under 100 ms"
}

Cloud Run

Cloud Run es una plataforma de procesamiento completamente administrada para implementar y escalar aplicaciones en contenedores con rapidez y seguridad. Se busca abstraer toda la administración de infraestructura mediante la respuesta a cambios en el tráfico mediante el aumento y la reducción, de forma automática desde cero, y la carga de los recursos exactos que usas de manera instantánea.

Para obtener información adicional sobre la observabilidad de Cloud Run. Consulta lo siguiente:

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\">\"499\"
         metric.label.\"response_code_class\"<\"399\"",
      "goodServiceFilter":
        "metric.type=\"run.googleapis.com/request_count\"
         resource.type=\"cloud_run_revision\"
         metric.label.\"response_code_class\"<=\"299\"",
     }
  }
}

SLI de latencia

Para medir la latencia, Cloud Run escribe datos de métricas en Cloud Monitoring con el ipot de recurso cloud_run_revision supervisado y el tipo de métrica request_latencies. Los datos son una distribución de latencia de solicitud en milisegundos que alcanza la revisión. Puedes filtrar los datos con la etiqueta de métrica response_code o response_code_class si necesitas medir explícitamente la latencia de todas las solicitudes o solo las solicitudes exitosas.

Puedes expresar un SLI de latencia basado en solicitudes mediante una estructura DistributionCut. En el siguiente SLO, se espera que el 99% de las solicitudes caiga entre 0 y 100 ms en latencia total durante un período de una hora progresiva:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"run.googleapis.com/https/request_latencies\"
           resource.type=\"cloud_run_revision"",
        "range": {
           "min": 0,
           "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "86400s",
  "displayName": "98% requests under 100 ms"
}

Cloud Functions

Cloud Functions es una oferta de servicio como servicio escalable de prepago que ejecuta tu código sin necesidad de administrar ninguna 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 Cloud Functions, consulta los siguientes vínculos:

SLI de disponibilidad

Cloud Functions escribe los 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, Cloud Functions escribe los 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 con status si necesitas medir explícitamente la latencia de todas las ejecuciones o solo de las ejecuciones correctas.

Puedes expresar un SLI de latencia basado en solicitudes mediante una estructura DistributionCut. En el siguiente SLO, se espera que el 99% de todas las ejecuciones de Cloud Functions caigan entre 0 y 100 ms en la latencia total durante un período de una hora progresiva:

{
  "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": "86400s",
  "displayName": "98% 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.

El entorno flexible de App Engine no proporciona ninguna métrica que puedas usar fácilmente como SLI de disponibilidad o latencia. Recomendamos el uso de Cloud Load Balancing o una métrica basada en registros para tus SLI. Para obtener más información, consulta la siguiente documentación de SLI:

Para obtener más información sobre App Engine, consulta lo siguiente:

SLI de disponibilidad

El entorno estándar de App Engine escribe datos de métricas en Cloud Monitoring con 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 el entorno estándar de 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, el entorno estándar de 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”.

Expresas un SLI de latencia basado en solicitudes para el entorno estándar de App Engine mediante una estructura DistributionCut. En el siguiente ejemplo de SLO, se espera que el 99% de las solicitudes caiga entre 0 y 100 ms en latencia total en un período de una hora progresiva:

{
  "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": "86400s",
  "displayName": "98% requests under 100 ms"
}

GKE y Istio

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 puede instalarse en GKE como complemento Istio en GKE, o el usuario del proyecto de código abierto. En ambos casos, Istio proporciona telemetría extensa, 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 con la etiqueta de métrica response_code para contar las solicitudes “correctas” y “totales”. También puedes usar la etiqueta de métrica destination_service_name a fin de contar las solicitudes para 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 con 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 frontend caiga entre 0 y 100 ms en la latencia total durante un período de una hora progresiva:

{
  "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": "86400s",
  "displayName": "98% requests under 100 ms"
}