Mesurer vos SLO

Ce document du framework d'architecture Google Cloud s'appuie sur les discussions précédentes sur les objectifs de niveau de service (SLO) en explorant quoi mesurer et comment le faire par rapport aux charges de travail de service courantes. Ce document s'appuie sur les concepts définis dans la section Composants des objectifs de niveau de service.

Décider des éléments à mesurer

Quel que soit votre domaine, de nombreux services partagent des fonctionnalités communes et peuvent utiliser des SLO génériques. Cette section traite des SLO génériques pour différents types de services et fournit des explications détaillées sur les SLI qui s'appliquent à chaque SLO.

Chacune des sous-sections suivantes identifie un type de service particulier et fournit une brève description de ce service. Ensuite, sous chaque type de service, sont listés les SLI possibles, une définition de l'indicateur et d'autres informations le concernant.

Services basés sur des requêtes

Ce type de service reçoit une requête d'un client (un utilisateur ou un autre service), effectue des calculs, envoie éventuellement des requêtes réseau à un backend, puis renvoie une réponse au client.

Disponibilité en tant que SLI

La disponibilité correspond à la proportion de requêtes valides traitées avec succès. La liste suivante présente les informations à prendre en compte lors de l'utilisation de la disponibilité en tant que SLI :

• En tant que propriétaire du service, vous décidez de ce qui constitue une requête valide. Les définitions courantes incluent non nulle ou adhère à un protocole client-serveur. Une méthode pour évaluer la validité consiste à examiner les codes de réponse HTTP (ou RPC). Par exemple, les codes HTTP 5xx sont des erreurs liées au serveur qui sont comptabilisées dans un SLO, tandis que les codes 4xx sont des erreurs client qui ne le sont pas.
• Chaque code de réponse renvoyé par votre service doit être examiné pour vous assurer que l'application les utilise correctement et de manière cohérente. Le code est-il un indicateur précis de l'expérience de vos utilisateurs vis-à-vis du service ? Par exemple, comment un site e-commerce répond-il lorsqu'un utilisateur tente de commander un article non disponible ? La requête échoue-t-elle et renvoie-t-elle un message d'erreur ? Le site propose-t-il des produits similaires ? Les codes d'erreur doivent être liés aux attentes des utilisateurs.
• Les développeurs peuvent faire un usage abusif par inadvertance des erreurs. En utilisant le scénario non disponible du point précédent, un développeur peut renvoyer par erreur une erreur, alors que le système fonctionne correctement. Le code doit être renvoyé comme réussi, même si l'utilisateur n'a pas pu acheter l'article. Bien que les propriétaires de services doivent être informés de la faible disponibilité des stocks, l'impossibilité de réaliser la vente n'est pas une erreur du point de vue du client et n'est pas comptabilisée dans un SLO.
• Un service plus complexe est celui qui gère des requêtes asynchrones ou fournit un processus s'exécutant longuement aux clients. Bien que vous puissiez exposer la disponibilité d'une autre manière, nous vous recommandons de la représenter en tant que proportion de requêtes valides qui réussissent. La disponibilité peut également être définie comme le nombre de minutes d'exécution de la charge de travail d'un client (parfois appelée bonnes minutes).
• Prenons l'exemple d'un service proposant des machines virtuelles (VM). Vous pouvez mesurer la disponibilité en termes de nombre de minutes après une requête initiale pendant lesquelles la VM est disponible pour l'utilisateur.

Latence en tant que SLI

La latence (ou vitesse) correspond à la proportion de requêtes valides traitées avant atteinte d'un seuil. Par conséquent, la latence indique la rapidité du service et peut être mesurée en calculant la différence entre les heures de début et d'arrêt d'un type de requête donné. N'oubliez pas qu'il s'agit de la perception de la latence par l'utilisateur. Les propriétaires de services mesurent généralement cette valeur avec trop de précision. En réalité, les utilisateurs ne peuvent pas faire la distinction entre une actualisation de 100 millisecondes (ms) et de 300 ms, et peuvent même accepter des réponses comprises entre 300 ms et 1 000 ms normalement. Pour en savoir plus, consultez la section Modèle rail.

Développez des métriques axées sur l'activité qui se concentrent sur l'utilisateur. Voici quelques exemples de ces métriques :

• Interactive : un utilisateur attend 1 000 ms pour obtenir une sortie après avoir cliqué sur un élément.
• Écriture : une modification apportée à un système distribué sous-jacent prend 1 500 ms. Bien que cette durée soit considérée comme lente, les utilisateurs ont tendance à l'accepter. Nous vous recommandons de faire explicitement la distinction entre les écritures et les lectures dans vos métriques.
• Contexte : Les actions non visibles par l'utilisateur, telles qu'une actualisation périodique des données ou d'autres requêtes asynchrones, ne prennent pas plus de 5 000 ms.

La latence est couramment mesurée en tant que distribution, comme indiqué dans la section Choisir vos SLI. Avec une distribution, vous pouvez mesurer différents centiles. Par exemple, vous pouvez mesurer le nombre de requêtes qui sont plus lentes que le 99e centile de l'historique. Les événements plus rapides que ce seuil sont considérés comme satisfaisants, les requêtes plus lentes sont considérées comme moins bonnes. Vous définissez ce seuil en fonction des exigences du produit. Vous pouvez même définir plusieurs SLO de latence, par exemple la latence typique par rapport à la latence de queue.

N'utilisez pas uniquement la latence moyenne (ou médiane) comme SLI. Si la latence médiane est trop lente, la moitié de vos utilisateurs sont déjà insatisfaits. En outre, votre service peut rencontrer une mauvaise latence pendant des jours avant que vous ne détectez le problème. Par conséquent, définissez votre SLO pour la latence de queue (95e centile) et pour la latence médiane (50e centile).

Dans l'article d'ACM Métriques importantes, Benjamin Tinyor Sloss écrit ce qui suit :

• "Une bonne règle de base...est que la latence du 99e centile ne doit pas dépasser de trois à cinq fois la latence médiane."
• "Les valeurs des 50e, 95e et 99e centiles de latence d'un service ont chacune leur utilité et les SLO doivent être définis idéalement autour de ces valeurs."

Déterminez vos seuils de latence en fonction des centiles historiques, puis mesurez le nombre de requêtes comprises dans chaque bucket. Cette approche est un bon modèle à suivre.

Qualité en tant que SLI

La qualité correspond à la proportion de requêtes valides traitées sans dégradation du service. Par exemple, la qualité est un SLI utile pour les services complexes conçus pour échouer de manière élégante. Prenons l'exemple d'une page Web qui charge son contenu principal à partir d'un datastore et des éléments facultatifs à partir de 100 autres services et datastores. Si l'un des éléments facultatifs est hors service ou trop lent, la page est toujours affichée sans les éléments facultatifs. Dans ce scénario, vous pouvez utiliser des SLI pour effectuer les opérations suivantes :

• En mesurant le nombre de requêtes qui reçoivent une réponse dégradée (une réponse n'ayant pas reçu une réponse d'au moins un service de backend), vous pouvez signaler le ratio de requêtes insatisfaisantes.
• Vous pouvez suivre le nombre de réponses n'ayant pas reçu de réponse d'un ou de plusieurs backends.

Services de traitement des données

Ces services utilisent les données d'une entrée, traitent ces données et génèrent une sortie. Les performances du service aux étapes intermédiaires ne sont pas aussi importantes que la sortie finale. Les SLI les plus performants sont la fraîcheur, la couverture, l'exactitude et le débit. La latence et la disponibilité sont moins utiles.

Actualité en tant que SLI

L'actualité correspond à la proportion de données valides mises à jour plus récemment qu'un certain seuil. La liste suivante fournit quelques exemples d'utilisation de l'actualité en tant que SLI :

• Dans un système de traitement par lots, l'actualité correspond au temps écoulé lors d'une exécution de traitement avec succès pour une sortie donnée.
• Dans le traitement en temps réel ou dans des systèmes plus complexes, l'actualité suit l'âge du dernier enregistrement traité dans un pipeline.
• Dans un jeu en ligne qui génère des tuiles d'un plan en temps réel, les utilisateurs risquent de ne pas remarquer la rapidité de création des tuiles, mais ils peuvent remarquer si les données du plan sont manquantes ou non actualisées. Dans ce cas, l'actualisation suit les données manquantes ou non actualisées.
• Dans un service qui lit les enregistrements d'un système de suivi pour générer le message "X articles en stock" pour un site Web d'e-commerce, un SLI d'actualité peut être défini comme le pourcentage de requêtes utilisant des informations sur les stocks actualisées (de la dernière minute).
• Vous pouvez également utiliser une métrique pour diffuser des données non actualisées afin de mettre à jour le SLI de qualité.

Couverture en tant que SLI

La couverture correspond à la proportion de données valides traitées avec succès.

Pour définir la couverture, procédez comme suit :

1. Déterminez si une entrée doit être acceptée comme valide ou ignorée. Par exemple, si un enregistrement d'entrée est corrompu ou présente une longueur nulle et ne peut pas être traité, vous pourriez considérer cet enregistrement comme non valide en tant que métrique.
2. Comptez le nombre d'enregistrements valides. Ce nombre peut être réalisé à l'aide d'une simple méthode *count()* et représente le nombre total d'enregistrements.
3. Enfin, comptez le nombre d'enregistrements traités avec succès et comparez ce nombre au nombre total d'enregistrements valides. Cette valeur correspond à votre SLI pour la couverture.

Exactitude en tant que SLI

L'exactitude correspond à la proportion de données valides ayant généré une sortie correcte. Tenez compte des points suivants lorsque vous utilisez l'exactitude en tant que SLI :

• Dans certains cas, les méthodes permettant de déterminer l'exactitude d'une sortie sont utilisées pour valider le traitement de la sortie. Par exemple, un système qui fait pivoter ou colorise une image ne doit jamais produire une image de zéro octet, ou une image dont la longueur ou la largeur est égale à zéro. Il est important de séparer cette logique de validation de la logique de traitement elle-même.
• Une méthode permettant de mesurer un SLI d'exactitude consiste à utiliser des données d'entrée de test connues comme correctes. Il s'agit de données qui génèrent un résultat correct connu. N'oubliez pas que les données d'entrée doivent être représentatives des données utilisateur.
• Dans d'autres cas, il est possible d'utiliser une vérification mathématique ou logique sur la sortie, comme dans l'exemple précédent de rotation d'une image.
• Enfin, considérons un système de facturation qui détermine la validité des transactions en vérifiant la différence entre le solde avant et après une transaction. Si cette valeur correspond à celle de la transaction elle-même, il s'agit d'une transaction valide.

Débit en tant que SLI

Le débit correspond à la proportion de temps pendant laquelle le taux de traitement des données était plus rapide que le seuil. Voici quelques points à prendre en compte lors de l'utilisation du débit en tant que SLI :

• Dans un système de traitement de données, le débit est souvent plus représentatif de la satisfaction des utilisateurs qu'une seule mesure de latence pour une opération donnée. Si la taille de chaque entrée varie considérablement, il peut être inutile de comparer le temps nécessaire à l'exécution de chaque élément (si tous les jobs progressent à un débit acceptable).
• Les octets par seconde sont un moyen courant d'évaluer la quantité de travail nécessaire au traitement des données, quelle que soit la taille de l'ensemble de données. Cependant, toute métrique qui évolue de manière linéaire par rapport au coût de traitement fonctionnera.
• Il peut être utile de partitionner vos systèmes de traitement des données en fonction des taux de débit attendus. Vous pouvez également mettre en œuvre un système de qualité de service qui garantit le traitement des entrées à priorité élevée et la mise en file d'attente des entrées à faible priorité. Dans les deux cas, la mesure du débit telle que définie dans cette section permet de déterminer si votre système fonctionne conformément à l'objectif de disponibilité.

Services d'exécution planifiée

Pour les services qui doivent effectuer une action à intervalles réguliers, tels que les jobs Cron Kubernetes, vous pouvez mesurer le décalage et la durée d'exécution. Voici un exemple de job Cron Kubernetes planifié :

  apiVersion: batch/v1beta1
  kind: CronJob
  metadata:
  name: hello
  spec:

  schedule: "0 * * * *"
  

Décalage en tant que SLI

Le décalage est la proportion d'exécutions qui commencent dans un intervalle acceptable de l'heure de début attendue. Lorsque vous utilisez le décalage, tenez compte des points suivants :

• Le décalage évalue la différence entre le moment où un job est planifié et son heure de début réelle. Prenons l'exemple de job Cron Kubernetes précédent. S'il est configuré pour démarrer à la minute zéro de chaque heure, mais qu'il commence trois minutes après, le décalage est de trois minutes. Lorsqu'un job s'exécute en avance, le décalage est négatif.
• Vous pouvez évaluer le décalage en tant que distribution dans le temps, avec des plages acceptables qui définissent un décalage correct. Pour déterminer le SLI, comparez le nombre d'exécutions comprises dans une plage acceptable.

Exécution en tant que SLI

La durée d'exécution correspond à la proportion d'exécutions qui se terminent dans l'intervalle de temps acceptable. Voici quelques concepts importants liés à l'utilisation de la durée d'exécution :

• La durée d'exécution correspond au temps nécessaire à la réalisation d'un job. Pour une exécution donnée, un mode d'échec courant consiste à ce que la durée réelle dépasse la durée programmée.
• Il est intéressant d'appliquer ce SLI à un job qui ne se termine jamais. Étant donné que ces jobs ne se terminent pas, enregistrez le temps passé sur un job donné au lieu d'attendre qu'il se termine. Cette approche fournit une répartition précise de la durée du travail à effectuer, même dans le pire des cas.
• Comme pour le décalage, vous pouvez suivre la durée d'exécution comme une distribution et définir des limites supérieures et inférieures acceptables pour les événements satisfaisants.

Métriques pour d'autres types de systèmes

De nombreuses autres charges de travail ont leurs propres métriques pour générer des SLI et des SLO. Prenons les exemples suivants :

• Systèmes de stockage : durabilité, débit, délai avant le premier octet, disponibilité des objets blob
• Média/vidéo : continuité de lecture du client, délai de démarrage de la lecture, exhaustivité du transcodage de l'exécution de graphe
• Jeux vidéo : temps nécessaire pour associer les joueurs actifs et temps nécessaire pour générer une carte

Décider comment mesurer

La section précédente a abordé ce que vous mesurez. Une fois que vous avez déterminé ce que vous souhaitez mesurer, vous pouvez décider comment mesurer. Vous pouvez collecter des métriques SLI de plusieurs manières. Les sections suivantes identifient différentes méthodes de mesure, fournissent une brève description de la méthode, répertorient ses avantages et ses inconvénients et identifient les outils d'implémentation appropriés.

Journalisation côté serveur

La méthode de journalisation côté serveur implique le traitement des journaux côté serveur de requêtes ou de données traitées.

Métriques des serveurs d'applications

La méthode des métriques des serveurs d'applications implique l'exportation de métriques SLI à partir du code qui diffuse les requêtes utilisateur ou traite leurs données.

Métriques de l'infrastructure d'interface

La méthode des métriques d'infrastructure d'interface utilise les métriques de l'infrastructure d'équilibrage de charge (par exemple, un équilibreur de charge global de couche 7 dans Google Cloud).

Clients ou données synthétiques

La méthode des clients synthétiques ou des données implique l'utilisation de clients qui envoient des requêtes fabriquées à intervalles réguliers, puis valide les réponses.

Instrumentation du client

La méthode d'instrumentation du client consiste à ajouter des fonctionnalités d'observabilité au client avec lequel l'utilisateur interagit, et à journaliser les événements dans votre infrastructure de diffusion qui suit les SLI.

Choisir une méthode d'évaluation

Une fois que vous avez choisi quel SLO mesurer et comment le faire, l'étape suivante consiste à choisir la méthode de mesure qui correspond le mieux à l'expérience client de votre service et nécessite le moins d'efforts de votre part. Pour atteindre cet idéal, vous devrez peut-être utiliser une combinaison des méthodes des tables précédentes. Vous trouverez ci-dessous des suggestions d'approches que vous pouvez mettre en œuvre au fil du temps, répertoriées par ordre d'efforts croissants :

• Utilisez les exportations du serveur d'applications et les métriques d'infrastructure. En règle générale, vous pouvez accéder immédiatement à ces métriques et elles fournissent rapidement une valeur. Certains outils APM incluent des outils de SLO intégrés.
• Utilisez l'instrumentation du client. étant donné que les anciens systèmes ne disposent généralement pas d'une instrumentation intégrée du client final, l'instrumentation peut entraîner un investissement important. Toutefois, si vous utilisez une suite APM ou un framework d'interface fournissant une instrumentation client, vous pouvez rapidement obtenir des tendances sur la satisfaction de vos clients.
• Utilisez le traitement des journaux. Si vous ne pouvez pas implémenter d'exportations de serveurs ni d'instrumentation du client (points précédents), mais que des journaux existent, le traitement des journaux est peut-être la meilleure approche. Une autre méthode consiste à combiner les exportations et le traitement des journaux. Utilisez les exportations comme source immédiate pour certains SLI (tels que la disponibilité immédiate) et le traitement des journaux pour les signaux à long terme (tels que les alertes d'utilisation lente décrites dans le guide SLO et alertes).
• Mettez en œuvre des tests synthétiques. Une fois que vous avez une bonne compréhension de l'utilisation de votre service par vos clients, vous pouvez tester votre service. Par exemple, vous pouvez alimenter les comptes de test avec des données correctes et effectuer une requête. Cette approche peut vous aider à mettre en évidence les modes de défaillance qui ne sont pas facilement observés, par exemple pour les services à faible trafic.

Étape suivante

• Consultez SLO et alertes.
• Lisez L'art des SLO, un atelier développé par l'équipe Google chargée de l'Ingénierie en fiabilité client.
• Suivez le cours en ligne sur la création des SLO Ingénierie de la fiabilité des sites : évaluation et gestion de la fiabilité.
• Consultez la page Ingénierie de la fiabilité des sites : mettre en œuvre des SLO.
• Consultez la page Concepts de surveillance des services.
• Lisez Implémenter des objectifs de niveau de service par Alex Hidalgo.
• Consultez la page Développer des SLO avec Cloud Monitoring.
• Essayez le Générateur de SLO flexible de la Professional Services Organization de Google (PSO).
• Consultez nos ressources sur DevOps.

• Obtenez davantage d'informations sur les capacités DevOps associées à cette série :

  • Surveillance et observabilité
  • Systèmes de surveillance permettant d'éclairer les décisions métier
  • Notification proactive des échecs

• Effectuez l'évaluation DevOps rapide pour comprendre votre position par rapport au reste du secteur.

• Découvrez les recommandations des autres piliers du framework d'architecture.

• Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.