Services de requête-réponse

Un service de requête-réponse est un service dans lequel un client demande explicitement au service d'effectuer un travail et attend que cette tâche soit terminée. Les exemples les plus courants de ces services sont les suivants :

• Les applications Web avec lesquelles les utilisateurs interagissent directement via un navigateur
• les applications mobiles qui comprennent une application cliente sur le téléphone mobile d'un utilisateur et un backend d'API avec lequel le client interagit ;
• Backends d'API utilisés par d'autres services (plutôt que des utilisateurs humains).

Pour tous ces services, l'approche courante consiste à commencer par des SLI de disponibilité (mesurez le ratio de requêtes réussies) et de latence (mesure du ratio de requêtes qui se terminent sous un seuil de temps). Pour plus d'informations sur les SLI de disponibilité et de latence, consultez la section Concepts de la surveillance des services.

Vous pouvez exprimer un SLI de disponibilité basé sur les requêtes en utilisant la structure TimeSeriesRatio pour configurer un ratio de bonnes requêtes par rapport au nombre total de requêtes. Vous décidez de la manière de filtrer la métrique à l'aide de ses étiquettes disponibles afin d'obtenir votre détermination de "bonne" ou "valide".

Vous pouvez exprimer un SLI de latence basé sur les requêtes à l'aide d'une structure DistributionCut.

Remarque : Dans certains de ces exemples, les chaînes de filtre comportent des sauts de ligne afin d'améliorer la lisibilité.

Cloud Endpoints

Cloud Endpoints est un service permettant de gérer les API. Il vous permet d'utiliser une API existante et de l'exposer avec l'authentification, les quotas et la surveillance.

Cloud Endpoints est mis en œuvre en tant que proxy devant le serveur d'application gRPC. En mesurant les métriques au niveau du proxy, vous pouvez gérer correctement le scénario lorsqu'aucun backend n'est disponible et que des utilisateurs voient des erreurs. Endpoints écrit les données sur les types de métriques commençant par le préfixe serviceruntime.googleapis.com.

Pour en savoir plus, consultez les ressources suivantes :

• Documentation pour Cloud Endpoints.
• Liste des types de métriques serviceruntime.googleapis.com.

SLI de disponibilité

Cloud Endpoints écrit les données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée api et du type de métrique "service-runtime" api/request_count que vous pouvez filtrer à l'aide du libellé de métrique response_code pour comptabiliser les requêtes "good" et "total".

Vous pouvez exprimer un SLI de disponibilité basé sur les requêtes en créant une structure TimeSeriesRatio pour les requêtes satisfaisantes par rapport au nombre total de requêtes, comme indiqué dans l'exemple suivant :

"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 latence

Cloud Endpoints utilise les types de métriques principales suivants pour capturer la latence :

• api/request_latencies : distribution des latences en secondes pour les requêtes non diffusées en continu. À utiliser lorsque l'expérience utilisateur globale a une importance majeure.
• api/request_latencies_backend : distribution des latences de backend en secondes pour les requêtes non diffusées en continu. Permet de mesurer directement les latences de backend.
• api/request_latencies_overhead : distribution des latences de requête en secondes pour les requêtes non diffusées en continu, à l'exclusion du backend. Permet de mesurer la surcharge introduite par le proxy Endpoints.

Notez que la latence totale des requêtes correspond à la somme du backend et des latences induites :

request_latencies = request_latencies_backend + request_latencies_overhead

Endpoints écrit les données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée api et de l'un des types de métriques de latence des requêtes. Aucun de ces types de métriques ne fournit de libellé response_code ou response_code_class. et signalent donc les latences pour toutes les requêtes.

Vous pouvez exprimer un SLI de latence basé sur les requêtes à l'aide d'une structure DistributionCut, comme illustré dans les exemples suivants.

L'exemple de SLO suivant attend que 99 % de toutes les requêtes du projet tombent entre 0 et 100 ms de latence totale sur une période glissante d'une heure :

{
  "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"
}

L'exemple de SLO suivant attend que 98 % des requêtes tombent entre 0 et 100 ms de latence du backend sur une période glissante d'une heure :

{
  "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 est une plate-forme de calcul entièrement gérée permettant de déployer et de faire évoluer rapidement et en toute sécurité des applications conteneurisées. Elle a pour objectif d'éliminer toute la gestion de l'infrastructure en répondant aux changements du trafic en procédant à un scaling automatique à la hausse ou à la baisse, à partir de zéro presque instantanément, et à ne facturer que les ressources utilisées.

Pour plus d'informations sur l'observabilité Cloud Run, consultez les pages suivantes :

• Documentation pour Cloud Run.
• Liste des types de métriques run.googleapis.com.

SLI de disponibilité

Cloud Run écrit les données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée cloud_run_revision et du type de métrique request_count. Vous pouvez filtrer les données à l'aide des libellés de métrique response_code ou response_code_class pour comptabiliser les requêtes "good" et "total".

Vous pouvez exprimer un SLI de disponibilité basé sur les requêtes en créant une structure TimeSeriesRatio pour les requêtes satisfaisantes par rapport au nombre total de requêtes, comme indiqué dans l'exemple suivant :

"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 latence

Pour mesurer la latence, Cloud Run écrit les données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée cloud_run_revision et du type de métrique request_latencies. Les données correspondent à la distribution de la latence de la requête en millisecondes atteignant la révision. Vous pouvez filtrer les données à l'aide du libellé de métrique response_code ou response_code_class si vous devez mesurer explicitement la latence de toutes les requêtes ou uniquement les requêtes réussies.

Vous pouvez exprimer un SLI de latence basé sur les requêtes à l'aide d'une structure DistributionCut. L'exemple de SLO suivant attend que 99 % des requêtes tombent entre 0 et 100 ms de latence totale sur une période glissante d'une heure :

{
  "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 Functions est une fonctionnalité Functions as a Service évolutive basée sur le paiement à l'usage qui exécute votre code sans avoir à gérer d'infrastructure. Les fonctions sont utilisées dans de nombreux modèles d'architecture pour effectuer des opérations telles que le traitement d'événements, l'automatisation et la diffusion des requêtes HTTP/S.

Pour en savoir plus sur l'observabilité de Cloud Run Functions, consultez les ressources suivantes :

• Documentation sur Cloud Run Functions
• Liste des types de métriques run.googleapis.com.

SLI de disponibilité

Cloud Run Functions écrit les données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée cloud_function et du type de métrique function/execution_time. Vous pouvez filtrer les données à l'aide du libellé de métrique status pour comptabiliser les exécutions "good" et "total".

Vous pouvez exprimer un SLI de disponibilité basé sur les requêtes en créant une structure TimeSeriesRatio pour les requêtes satisfaisantes par rapport au nombre total de requêtes, comme indiqué dans l'exemple suivant :

"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 latence

Pour mesurer la latence, Cloud Run Functions écrit les données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée cloud_function et du type de métrique function/execution_times. Les données sont une distribution des temps d'exécution des fonctions en nanosecondes. Vous pouvez filtrer les données à l'aide de status si vous devez mesurer explicitement la latence de toutes les exécutions ou uniquement les exécutions réussies.

Vous pouvez exprimer un SLI de latence basé sur les requêtes à l'aide d'une structure DistributionCut. L'exemple de SLO suivant suppose que 99 % des exécutions de Cloud Run Functions se situent entre 0 et 100 ms de latence totale sur une période glissante d'une heure :

{
  "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 fournit une plate-forme sans serveur entièrement gérée pour créer et exécuter des applications. Vous avez le choix entre deux environnements : standard ou flexible. Pour plus d'informations, consultez la section Choisir un environnement App Engine.

Pour en savoir plus sur App Engine, consultez les ressources suivantes :

• Documentation pour App Engine.
• Liste des types de métriques appengine.googleapis.com.

SLI de disponibilité

App Engine écrit des données de métriques dans Cloud Monitoring à l'aide du type de ressource surveillée gae_app et du type de métrique http/server/response_count. Vous pouvez filtrer les données à l'aide du libellé de métrique response_code pour compter les réponses "good" et "total".

Pour exprimer un SLI de disponibilité basé sur les requêtes pour App Engine, vous devez créer une structure TimeSeriesRatio pour les requêtes satisfaisantes par rapport au nombre total de requêtes, comme illustré dans l'exemple suivant :

"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 latence

Pour mesurer la latence, App Engine écrit des données de métriques dans Cloud Monitoring à l'aide du type de ressource surveillée gae_app et du type de métrique http/server/response_latencies. Vous pouvez filtrer les données à l'aide du libellé de métrique response_code pour compter les exécutions "good" et "total".

Pour exprimer un SLI de latence basée sur les requêtes pour App Engine, vous devez utiliser une structure DistributionCut. L'exemple de SLO suivant attend que 99 % de toutes les requêtes tombent entre 0 et 100 ms de latence totale sur une période glissante d'une heure :

{
  "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 et Istio

Google Kubernetes Engine (GKE) est le service Kubernetes sécurisé et géré de Google qui propose un scaling automatique à quatre voies et une compatibilité multicluster. Istio est un maillage de services Open Source qui vous permet de connecter, de sécuriser, de contrôler et de détecter des services. Istio peut être installé sur GKE en tant que module complémentaire (Cloud Service Mesh) ou par l'utilisateur à partir du projet Open Source. Dans les deux cas, Istio fournit une télémétrie exceptionnelle, y compris des informations sur le trafic, les erreurs et la latence pour chaque service géré par le maillage.

Pour obtenir la liste complète des métriques Istio, consultez la section Types de métriques istio.io.

SLI de disponibilité

Istio écrit les données de métrique dans Cloud Monitoring à l'aide du type de métrique service/server/request_count et de l'un des types de ressources surveillés suivants :

• gce_instance
• istio_canonical_service
• k8s_container

Vous pouvez filtrer les données à l'aide du libellé de métrique response_code pour compter les requêtes "good" et "total". Vous pouvez également utiliser le libellé de métrique destination_service_name pour comptabiliser les requêtes pour un service spécifique.

Vous exprimez un SLI de disponibilité basé sur les requêtes pour un service s'exécutant sur GKE géré par le maillage de services Istio. Pour ce faire, vous créez une structure TimeSeriesRatio des requêtes "good" par rapport au nombre total de requêtes, comme illustré dans l'exemple suivant :

"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 latence

Pour mesurer la latence, Istio écrit des données de métrique dans Cloud Monitoring à l'aide du type de métrique service/server/response_latencies et de l'un des types de ressources surveillés suivants :

• gce_instance
• istio_canonical_service
• k8s_container

Vous pouvez filtrer les données à l'aide du libellé de métrique response_code pour compter le libellé de métrique "good" and "total" requests. You can also use thedestination_service_name` afin de comptabiliser les requêtes pour un service spécifique.

Vous pouvez exprimer un SLI de latence basé sur les requêtes pour un service exécuté sur GKE géré par le maillage de services Istio à l'aide d'une structure DistributionCut. L'exemple de SLO suivant attend que 99 % de toutes les requêtes adressées au service frontend tombent entre 0 et 100 ms de latence totale sur une période glissante d'une heure :

{
  "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"
}