Servicios de solicitudes y respuestas

Un servicio de solicitud-respuesta es aquel en el que un cliente pide explícitamente al servicio que realice alguna tarea y espera a que se complete correctamente. Los ejemplos más habituales de estos servicios son los siguientes:

  • Aplicaciones web con las que los usuarios interactúan directamente mediante un navegador.
  • Aplicaciones móviles que constan de una aplicación cliente en el teléfono móvil de un usuario y un backend de API con el que interactúa el cliente.
  • Back-ends de APIs que utilizan otros servicios (en lugar de usuarios humanos).

En todos estos servicios, el enfoque habitual es empezar con los indicadores de nivel de servicio de disponibilidad (que miden la proporción de solicitudes correctas) y latencia (que miden la proporción de solicitudes que se completan en un umbral de tiempo). Para obtener más información sobre los SLIs de disponibilidad y latencia, consulta el artículo sobre conceptos de monitorización de servicios.

Para expresar un indicador de nivel de servicio de disponibilidad basado en solicitudes, usa la estructura TimeSeriesRatio para configurar una proporción de solicitudes válidas con respecto al total de solicitudes. Tú decides cómo filtrar la métrica usando las etiquetas disponibles para llegar a la determinación que prefieras de "buena" o "válida".

Para expresar un SLI de latencia basado en solicitudes, se usa una estructura DistributionCut.

Cloud Endpoints

Cloud Endpoints es un servicio para gestionar APIs. Te permite usar una API que ya tengas y exponerla con autenticación, cuotas y monitorización.

Endpoints se implementa como un proxy delante del servidor de aplicaciones gRPC. Si mides las métricas en el proxy, puedes gestionar correctamente el caso en el que todos los back-ends no estén disponibles y los usuarios vean errores. Endpoints escribe datos en tipos de métricas que empiezan por el prefijo serviceruntime.googleapis.com.

Para obtener más información, consulta las siguientes secciones:

Indicadores de nivel de servicio de disponibilidad

Cloud Endpoints escribe datos de métricas en Cloud Monitoring mediante el tipo de recurso monitorizado api y el tipo de métrica api/request_count de tiempo de ejecución del servicio, que puede filtrar mediante la etiqueta de métrica response_code para contar las solicitudes correctas y totales.

Para expresar un indicador de nivel de servicio de disponibilidad basado en solicitudes, crea una estructura TimeSeriesRatio de solicitudes correctas con respecto al total de solicitudes, 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\""),
    }
  }
}

Indicadores de nivel de servicio de latencia

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

  • api/request_latencies: distribución de latencias en segundos de las solicitudes que no son de streaming. Úsala cuando la experiencia de usuario general sea lo más importante.
  • api/request_latencies_backend: una distribución de las latencias de backend en segundos de las solicitudes que no son de streaming. Úsala para medir las latencias del backend directamente.
  • api/request_latencies_overhead: una distribución de las latencias de las solicitudes en segundos para las solicitudes que no son de streaming, sin incluir el backend. Se usa para medir la sobrecarga introducida por el proxy de Endpoints.

Ten en cuenta que la latencia total de la solicitud es la suma de las latencias del backend y de la sobrecarga:

request_latencies = request_latencies_backend + request_latencies_overhead

Endpoints escribe datos de métricas en Cloud Monitoring mediante el tipo de recurso monitorizado api y uno de los tipos de métrica de latencia de las solicitudes. Ninguno de estos tipos de métricas proporciona una etiqueta response_code o response_code_class, por lo que registran la latencia de todas las solicitudes.

Para expresar un indicador de nivel de servicio de latencia basado en solicitudes, se usa una estructura DistributionCut, como se muestra en los ejemplos siguientes.

En el siguiente ejemplo de SLO, se espera que el 99% de todas las solicitudes del proyecto tengan una latencia total de entre 0 y 100 ms durante un periodo 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"
}

El siguiente ejemplo de SLO espera que el 98% de las solicitudes tengan una latencia de backend de entre 0 y 100 ms durante un periodo 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 computación totalmente gestionada para desplegar y escalar aplicaciones en contenedores de forma rápida y segura. Su objetivo es abstraer toda la gestión de la infraestructura respondiendo a los cambios en el tráfico mediante el escalado automático, que se adapta a la carga de tu aplicación. Solo se te cobrarán los recursos que utilices.

Para obtener más información sobre la observabilidad de Cloud Run, consulta lo siguiente:

Indicadores de nivel de servicio de disponibilidad

Cloud Run escribe datos de métricas en Cloud Monitoring mediante el tipo de recurso monitorizado cloud_run_revision y el tipo de métrica request_count. Puede filtrar los datos mediante la etiqueta de métrica response_codeo laresponse_code_class para contabilizar las solicitudes "buenas" y "totales".

Para expresar un indicador de nivel de servicio de disponibilidad basado en solicitudes, crea una estructura TimeSeriesRatio de solicitudes correctas con respecto al total de solicitudes, 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\""),
     }
  }
}

Indicadores de nivel de servicio 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 la latencia de las solicitudes en milisegundos hasta llegar a la revisión. Puede filtrar los datos mediante la etiqueta de métrica response_code o response_code_class si necesita medir explícitamente la latencia de todas las solicitudes o solo de las que se han completado correctamente.

Para expresar un SLI de latencia basado en solicitudes, se usa una estructura DistributionCut. En el siguiente ejemplo de SLO, se espera que el 99% de las solicitudes tengan una latencia total de entre 0 y 100 ms durante un periodo 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"
}

Cloud Run Functions

Cloud Run functions es una función como servicio (FaaS) escalable y de pago por uso que ejecuta tu código sin necesidad de gestionar ninguna infraestructura. Las funciones se usan en muchos patrones de arquitectura para realizar tareas como el procesamiento de eventos, la automatización y el servicio de solicitudes HTTP/HTTPS.

Para obtener información sobre la observabilidad de Cloud Run Functions, consulta lo siguiente:

Indicadores de nivel de servicio de disponibilidad

Las funciones de Cloud Run escriben datos de métricas en Cloud Monitoring mediante el tipo de recurso monitorizado cloud_function y el tipo de métrica function/execution_time. Puede filtrar los datos mediante la etiqueta de métrica status para contar las ejecuciones "buenas" y "totales".

Para expresar un indicador de nivel de servicio de disponibilidad basado en solicitudes, crea una estructura TimeSeriesRatio de solicitudes correctas con respecto al total de solicitudes, 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\"",
     }
  }
}

Indicadores de nivel de servicio de latencia

Para medir la latencia, las funciones de Cloud Run escriben datos de métricas en Cloud Monitoring con el tipo de recurso monitorizado 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." Puede filtrar los datos con status si necesita medir explícitamente la latencia de todas las ejecuciones o solo de las que se han completado correctamente.

Para expresar un SLI de latencia basado en solicitudes, se usa 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 entre 0 y 100 ms durante un periodo 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 ofrece una plataforma sin servidor totalmente gestionada para crear y ejecutar aplicaciones. Puedes elegir entre dos entornos: estándar o flexible. Para obtener más información, consulta el artículo Elegir un entorno de App Engine.

Para obtener más información sobre App Engine, consulta los siguientes recursos:

Indicadores de nivel de servicio de disponibilidad

App Engine escribe datos de métricas en Cloud Monitoring mediante el tipo de recurso monitorizado 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 "buenas" y "totales".

Para expresar un indicador de nivel de servicio de disponibilidad basado en solicitudes de App Engine, crea una estructura TimeSeriesRatio para las solicitudes correctas en relación con el total de solicitudes, 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\"",
     }
  }
}

Indicadores de nivel de servicio de latencia

Para medir la latencia, App Engine escribe datos de métricas en Cloud Monitoring mediante el tipo de recurso monitorizado gae_app y el tipo de métrica http/server/response_latencies. Puede filtrar los datos mediante la etiqueta de métrica response_code para contar las ejecuciones correctas y totales.

Para expresar un SLI de latencia basado en solicitudes de App Engine, usa una estructura DistributionCut. El siguiente ejemplo de objetivo de nivel de servicio espera que el 99% de todas las solicitudes tengan una latencia total de entre 0 y 100 ms durante un periodo 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"
}

GKE e Istio

Google Kubernetes Engine (GKE) es el servicio de Kubernetes seguro y gestionado de Google, con autoescalado en cuatro vías y asistencia multiclúster. 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 complemento (Cloud Service Mesh) o por el usuario desde el proyecto de código abierto. En ambos casos, Istio proporciona una telemetría excelente, que incluye información sobre el tráfico, los errores y la latencia de cada servicio gestionado por la malla.

Para ver una lista completa de las métricas de Istio, consulta los tipos de métricas de istio.io.

Indicadores de nivel de servicio 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 monitorizados:

Puede 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 para contar las solicitudes de un servicio específico.

Para expresar un SLI de disponibilidad basado en solicitudes de un servicio que se ejecuta en GKE y que gestiona la malla de servicios Istio, crea una estructura TimeSeriesRatio de solicitudes correctas con respecto al total de solicitudes, 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\"",
    }
  }
}

Indicadores de nivel de servicio 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 monitorizados:

Puedes filtrar los datos mediante la etiqueta de métrica response_code para contar la etiqueta de métrica "good" and "total" requests. You can also use thedestination_service_name` para contar las solicitudes de un servicio específico.

Para expresar un SLI de latencia basado en solicitudes de un servicio que se ejecuta en GKE y que gestiona la malla de servicios de Istio, usa una estructura DistributionCut. El siguiente ejemplo de SLO espera que el 99% de todas las solicitudes al servicio frontend tengan una latencia total de entre 0 y 100 ms durante un periodo 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"
}