La fonctionnalité de surveillance des services et l'API SLO vous aident à gérer vos services de la même manière que Google les siens. Les notions centrales de la surveillance des services sont les suivantes :
- Sélection de métriques qui font office d'indicateurs de niveau de service (SLI, Service Level Indicator)
- Utilisation des SLI pour définir des objectifs de niveau de service (SLO, Service Level Objective) pour les valeurs de SLI
- Utilisation de la marge d'erreur définie de manière implicite par le SLO pour limiter les risques dans votre service
Cette page présente ces concepts et décrit certains éléments à prendre en compte lors de la conception d'un SLO. Les autres pages de cette section mettent ces concepts en pratique.
Terminologie
La surveillance des services comporte un ensemble de concepts clés, qui sont présentés ici :
- Indicateur de niveau de service (SLI) : mesure des performances
- Objectifs de niveau de service (SLO) : énoncé des performances souhaitées
- Marge d'erreur : commence à 1 - SLO et diminue à mesure que les performances réelles restent non conformes au SLO.
Indicateurs de niveau de service
Cloud Monitoring collecte des métriques qui mesurent les performances de l'infrastructure de service. Voici quelques exemples de métriques de performances :
- Nombre de requêtes : par exemple, nombre de requêtes HTTP par minute générant des réponses 2xx ou 5xx
- Latences de réponse : par exemple, latence pour les réponses HTTP 2xx
Les métriques de performances sont automatiquement identifiées en fonction d'un ensemble de types de services connus : Cloud Service Mesh, Istio sur Google Kubernetes Engine et App Engine. Vous pouvez également définir votre propre type de service et sélectionner ses métriques de performances.
Les métriques de performances constituent la base des SLI de votre service. Un SLI décrit les performances de certains aspects de votre service. Pour les services sur Cloud Service Mesh, Istio sur Google Kubernetes Engine et App Engine, les SLI utiles sont déjà connus. Par exemple, si votre service dispose de métriques du nombre de requêtes ou de la latence de réponse, des SLI standards peuvent être dérivés de ces métriques en créant des ratios comme suit :
- Un SLI de disponibilité correspond au ratio entre le nombre de réponses indiquant une réussite et le nombre total de réponses.
- Un SLI de latence correspond au ratio entre le nombre d'appels sous un seuil de latence et le nombre total d'appels.
Vous pouvez également configurer des SLI propres à un service afin d'obtenir une autre mesure de "performances satisfaisantes". Ces SLI appartiennent généralement à deux catégories :
- Les SLI basés sur des requêtes, où un service satisfaisant est mesuré en comptabilisant les unités de service atomiques, comme le nombre de requêtes HTTP affichant un état de réussite
- Les SLI basés sur des fenêtres, où un service satisfaisant est mesuré en comptabilisant le nombre de périodes, ou fenêtres, au cours desquelles les performances réponde un critère de satisfaction, comme une latence de réponse inférieure à un seuil donné
Ces SLI sont décrits plus en détail dans la section Conformité dans les SLO basés sur des requêtes et des fenêtres.
Pour obtenir des exemples illustrant la création de SLI pour les services sélectionnés, consultez la page Créer des SLI à partir de métriques.
Objectifs de niveau de service
Un SLO est une valeur cible pour un SLI, mesurée sur une période donnée. Le service détermine les SLI disponibles, et vous spécifiez des SLO en fonction des SLI. Le SLO définit ce qui fait qu'un service est considéré comme satisfaisant. Vous pouvez créer jusqu'à 500 SLO pour chaque service dans Cloud Monitoring.
Il repose sur les types d'informations suivants :
- Un SLI, qui mesure les performances du service
- Un objectif de performances, qui spécifie le niveau de performances souhaité
- Une période, appelée "période de conformité", qui permet de mesurer comment le SLI se situe par rapport à l'objectif de performances
Par exemple, vous pouvez avoir les exigences suivantes :
- La latence ne peut dépasser 300 ms que dans 5 % des requêtes sur une période glissante de 30 jours.
- Le système doit avoir une disponibilité de 99 %, mesurée sur une semaine calendaire.
Des exigences de ce type peuvent servir de base pour les SLO. Pour obtenir des conseils concernant la définition de SLO appropriés, consultez la section Concevoir et utiliser des SLO.
La survenue de changements dans la conformité avec les SLO peut également être le signe avant-coureur de défaillances. La surveillance de ces changements peut vous avertir suffisamment tôt pour vous permettre de résoudre un problème avant qu'il ne prenne de l'ampleur. Des règles d'alerte sont donc généralement utilisées pour surveiller la conformité avec les SLO. Pour plus d'informations, consultez la page Créer des alertes sur votre marge d'erreur.
Un SLO utile cible moins de 100 %, car le SLO détermine votre marge d'erreur. Les SLO sont généralement décrits comme un "nombre composé de chiffres 9" : 99 % (deux chiffres 9), 99,9 % (trois chiffres 9), etc. La valeur maximale que vous pouvez définir est 99,9 %, mais vous pouvez utiliser n'importe quelle valeur inférieure appropriée pour votre service.
Marges d'erreur
Un SLO spécifie le niveau de performances attendu pour un service pendant une période de conformité. Le restant dans la période de conformité devient la marge d'erreur. La marge d'erreur quantifie le niveau acceptable de défaillance des performances pendant la période de conformité pour un service, lequel continue de respecter le SLO.
Les marges d'erreur vous permettent de suivre le nombre d'événements individuels insatisfaisants (tels que des requêtes) autorisés pendant le reste de votre période de conformité avant que vous n'enfreigniez le SLO. Vous pouvez utiliser la marge d'erreur pour gérer les tâches de maintenance, telles que le déploiement de nouvelles versions. Si la marge d'erreur est presque épuisée, des actions risquées telles que le stockage de nouvelles mises à jour peuvent entraîner le non-respect d'un SLO.
Votre marge d'erreur pour une période de conformité est calculée comme suit : (1 − objectif SLO) × (événements éligibles dans la période de conformité). Par exemple, si le SLO exige que 85 % des requêtes soient satisfaisantes sur une période glissante de sept jours, la marge d'erreur permet 15 % de requêtes insatisfaisantes. Si vous avez reçu, par exemple, 60 480 requêtes au cours de la semaine dernière, votre marge d'erreur correspond à 15 % de ce total, soit 9 072 requêtes insatisfaisantes autorisées. Si vous avez diffusé plus d'erreurs, cela signifie que votre service n'était pas conforme au SLO pendant la période de conformité de sept jours.
Concevoir et utiliser des SLO
En quoi consiste un bon SLO ? Quels éléments prendre en compte pour faire vos choix ? Cette section présente quelques-uns des concepts généraux qui sous-tendent la conception et l'utilisation des SLO. Ce sujet est décrit plus en détail dans la publication Site Reliability Engineering: How Google Runs Production Systems (Ingénierie en fiabilité des sites : Comment Google exécute des système de production), dans le chapitre consacré aux SLO.
Les SLO définissent les performances cibles souhaitées pour votre service. En règle générale, les SLO ne doivent pas être plus élevés que cela est nécessaire ou utile. Si vos utilisateurs ne peuvent pas faire la différence entre une disponibilité de 99 % et une disponibilité de 99,9 % de votre service, prenez la valeur la plus basse comme SLO. La valeur la plus élevée est plus onéreuse à atteindre et ne fera pas de différence pour vos utilisateurs. Un service soumis à un objectif SLO de 100 % n'a pas de marge d'erreur. Il est déconseillé de définir un SLO de ce type.
Les SLO sont habituellement plus stricts que les engagements publics ou contractuels. Vous souhaitez définir un SLO plus strict qu'un engagement public de sorte que, si un problème entraîne le non-respect du SLO, vous en ayez connaissance et puissiez le corriger avant qu'il n'entraîne une violation de l'engagement ou du contrat. Le non-respect d'un engagement ou d'un contrat peut avoir des implications sur le plan juridique ou financier, et ternir une réputation. Pour éviter que cela ne se produise, un SLO fait partie d'un système d'alerte précoce.
Périodes de conformité
Il existe deux types de périodes de conformité pour les SLO :
- Les périodes calendaires (d'une date à une autre)
- Les périodes glissantes (comprises entre n jours en arrière et le moment présent, où n varie de 1 à 30 jours)
Périodes de conformité calendaires
Les périodes de conformité peuvent être définies sur des périodes calendaires, par exemple une semaine ou un mois.
La période de conformité et la marge d'erreur sont réinitialisées en fonction de limites de calendrier connues.
Pour connaître les valeurs possibles, consultez la section sur CalendarPeriod.
Avec une période calendaire, vous obtenez un score de performances à la fin de la période. Mesuré par rapport au seuil de performances, ce score de performances vous permet de savoir si votre service était conforme ou non. Lorsque vous utilisez une période calendaire, vous n'obtenez qu'une évaluation de la conformité par période de conformité, même si vous observez les performances tout au long de la période. Cependant, le score de fin de période vous fournit une valeur facile à lire qui peut être aisément comparée avec vos périodes de facturation client (si vous avez des clients externes qui paient un service).
À l'instar des mois d'un calendrier, le nombre de jours des périodes de conformité mensuelles varie.
Périodes de conformité glissantes basées sur des fenêtres
Vous pouvez également mesurer la conformité sur une période glissante, de sorte à toujours évaluer les performances, par exemple, sur les 30 derniers jours. Avec une période glissante, les données les plus anciennes du calcul précédent sont supprimées du calcul en cours et les nouvelles données les remplacent.
Avec une fenêtre glissante, vous obtenez davantage de mesures de conformité (vous obtenez ainsi une mesure de conformité pour les 30 derniers jours, plutôt qu'une par mois). Les services peuvent osciller entre conformité et non-conformité, car l'état du SLO change quotidiennement, les anciens points de données étant supprimés et de nouveaux ajoutés.
Conformité dans les SLO basés sur des requêtes et des fenêtres
La détermination de la conformité d'un SLO dépend de deux facteurs :
- Le mode de détermination de la période de conformité. Cette détermination est abordée dans la section Périodes de conformité.
- Le type de SLO. Il existe deux types de SLO :
- Les SLO basés sur des requêtes
- Les SLO basés sur des fenêtres
La conformité correspond au ratio entre les événements satisfaisants et le nombre total d'événements, mesuré sur la période de conformité. Le type de SLO détermine ce qui constitue un "événement".
Si votre SLO est de 99,9 %, vous le respectez si votre taux de conformité est d'au moins 99,9 %. La valeur maximale est de 100 %.
SLO basés sur des requêtes
Un SLO basé sur des requêtes repose sur un SLI, lequel est défini comme le ratio entre le nombre de requêtes satisfaisantes et le nombre total de requêtes. Ce type de SLO est respecté lorsque ce ratio atteint ou dépasse l'objectif fixé pour la période de conformité.
Prenons l'exemple du SLO basé sur des requêtes suivant : "La latence est inférieure à 100 ms pour au moins 95 % des requêtes". Une requête est satisfaisante si elle a un temps de réponse inférieur à 100 ms, donc la mesure de la conformité correspond à la fraction de requêtes présentant des temps de réponse en deçà de 100 ms. Le service est conforme si la fraction est d'au moins 0,95.
Les SLO basés sur des requêtes vous donnent une idée du pourcentage de travail effectué correctement par votre service pendant toute la période de conformité, quelle que soit la répartition de la charge.
SLO basés sur des fenêtres
Un SLO basé sur des fenêtres repose sur un SLI, lequel est défini comme le ratio entre le nombre d'intervalles de mesure répondant à un critère de satisfaction et le nombre total d'intervalles. Ce type de SLO est respecté lorsque ce ratio atteint ou dépasse l'objectif fixé pour la période de conformité.
Prenons par exemple le SLO suivant : "La métrique de latence du 95e centile est inférieure à 100 ms pour au moins 99 % des fenêtres de 10 minutes". Une période de mesure satisfaisante est un intervalle de 10 minutes au cours duquel 95 % des requêtes présentent une latence inférieure à 100 ms. La mesure de conformité correspond à la fraction de ces périodes satisfaisantes. Le service est conforme si cette fraction est supérieure ou égale à 0,99.
Supposons, par exemple, que vous configuriez une période de conformité glissante de 30 jours, un intervalle de mesure d'une minute et un objectif SLO de 99 %. Pour respecter ce SLO, votre service doit avoir 42 768 intervalles "satisfaisants" sur 43 200 minutes (99 % du nombre de minutes sur 30 jours).
Un SLO basé sur des fenêtres vous donne une idée du pourcentage de temps où vos clients ont trouvé que le service fonctionnait bien ou mal. Ce type de SLO peut masquer les effets d'un comportement "en rafales". En effet, un intervalle de mesure dont chaque appel a échoué compte autant dans le SLO qu'un intervalle de mesure ayant rencontré une erreur de trop. En outre, un intervalle avec un faible nombre d'appels compte autant dans le SLO qu'un intervalle de mesure présentant une forte activité.
Trajectoire des marges d'erreur
La marge d'erreur correspond à la différence entre un service satisfaisant à 100 % et votre SLO, le niveau souhaité de satisfaction du service. La différence est votre marge de manœuvre.
En général, une marge d'erreur commence à une valeur maximale et diminue au fil du temps, déclenchant un non-respect du SLO lorsque la marge d'erreur chute en dessous de 0.
Il existe quelques exceptions notables à cette règle :
Si vous avez mesuré un SLO basé sur des requêtes sur une période de conformité calendaire et que l'activité du service s'intensifie pendant cette période, la marge d'erreur peut en fait augmenter.
Comment est-ce possible ? Le système SLO ne peut pas connaître à l'avance l'activité du service pour chaque période de conformité. Il extrapole donc une valeur probable. Cette valeur correspond au ratio des appels reçus jusqu'à présent par rapport au temps écoulé depuis le début de la période de conformité, multiplié par la durée de la période de conformité.
À mesure que le taux d'activité augmente, le trafic attendu pour la période s'accroît également et, par conséquent, la marge d'erreur augmente.
Si vous mesurez un SLO sur une période de conformité glissante, vous êtes toujours à la fin d'une période de conformité. Plutôt que de repartir de zéro, les anciens points de données sont supprimés et de nouveaux points de données ajoutés en permanence.
Si une période de conformité médiocre sort de la fenêtre de conformité et si le moment présent, en la remplaçant, est conforme, la marge d'erreur augmente. À tout moment, une marge d'erreur supérieure ou égale à 0 indique une fenêtre de SLO glissante conforme, et une marge d'erreur inférieure à 0 indique une fenêtre de SLO glissante non conforme.
Surveiller votre marge d'erreur
Vous pouvez créer des règles d'alerte afin d'être averti si votre marge d'erreur est consommée à une vitesse supérieure à celle souhaitée. Pour plus d'informations, consultez la page Créer des alertes sur votre marge d'erreur.
Étape suivante
- Microservices décrit les microservices et explique comment utiliser Google Cloud Console pour configurer, afficher et gérer vos microservices.
- La page Créer des alertes sur votre marge d'erreur décrit comment surveiller vos SLI afin d'être averti en cas de problème.
- La page Travailler avec l'API SLO montre comment utiliser l'API SLO, un sous-ensemble de l'API Cloud Monitoring, pour créer des services, des SLO et des structures associées.