Objectifs de niveau de service (SLO)

Vous pouvez utiliser la vigie applicative pour créer des objectifs de niveau de service pour les services de vos opérations ou dépendances critiques. En créant des SLO sur ces services, vous pourrez les suivre sur le tableau de bord SLO, ce qui vous donnera une vue d’ensemble de vos opérations les plus importantes.

En plus de créer un aperçu rapide que vos opérateurs peuvent utiliser pour connaître l’état actuel des opérations critiques, vous pouvez utiliser les SLO pour suivre les performances à long terme de vos services, afin de vous assurer qu’ils répondent à vos attentes. Si vous avez conclu des accords de niveau de service avec des clients, les SLO sont un excellent outil pour garantir leur respect.

L’évaluation de l’état de santé de vos services à l’aide des SLO commence par la définition d’objectifs clairs et mesurables basés sur des indicateurs de performance clés, à savoir des indicateurs de niveau de service (SLI). Un SLO suit les performances du SLI par rapport au seuil et à l’objectif que vous avez définis, et indique dans quelle mesure les performances de votre application se situent par rapport au seuil.

Application Signals vous aide à définir des SLO sur vos indicateurs de performance clés. Application Signals collecte les métriques Latency et Availability automatiquement pour chaque service et chaque opération qu’elle découvre, et ces métriques sont souvent idéales pour être utilisées en tant que SLI. Avec l’assistant de création de SLO, vous pouvez utiliser ces métriques pour vos SLO. Vous pouvez ensuite suivre l’état de tous vos SLO à l’aide des tableaux de bord d’Application Signals.

Vous pouvez définir des SLO pour des opérations ou des dépendances spécifiques que votre service appelle ou utilise. Vous pouvez utiliser n’importe quelle métrique ou expression de métrique CloudWatch en tant que SLI, en plus des métriques Latency et Availability.

La création de SLO est très importante pour tirer le meilleur parti d’CloudWatch Application Signals. Une fois que vous avez créé des SLO, vous pouvez consulter leur état dans la console Application Signals pour voir rapidement lesquels de vos services et opérations critiques fonctionnent bien et lesquels ne le sont pas. Le fait d’avoir des SLO à suivre offre les principaux avantages suivants :

En choisissant les paramètres sur lesquels définir les SLO, vous priorisez ce qui est important pour vous. Les tableaux de bord d’Application Signals présentent automatiquement des informations sur ce que vous avez priorisé.

Lorsque vous créez un SLO, vous pouvez également choisir de créer des alarmes CloudWatch en même temps pour surveiller ces SLO. Vous pouvez définir des alarmes qui surveillent les dépassements du seuil, ainsi que les niveaux d’alerte. Ces alarmes peuvent vous avertir automatiquement si les métriques SLO dépassent le seuil que vous avez défini ou s’approchent d’un seuil d’avertissement. Par exemple, un SLO proche de son seuil d’alerte peut vous indiquer que votre équipe devra peut-être ralentir le taux de désabonnement de l’application pour s’assurer que les objectifs de performance à long terme sont atteints.

Concepts SLO

Un SLO comprend les composants suivants :

Par exemple, un objectif de 99 % avec un intervalle calendaire d’un jour et une période d’une minute signifie que l’application doit atteindre ou atteindre le seuil de réussite pendant 99 % des périodes d’une minute de la journée. Si c’est le cas, le SLO est atteint pour ce jour-là. Le jour suivant correspond à un nouvel intervalle d’évaluation, et l’application doit atteindre ou atteindre le seuil de réussite pendant 99 % des périodes d’une minute du deuxième jour pour atteindre le SLO du deuxième jour.

Un SLI peut être basé sur l’une des nouvelles métriques d’application standard collectées par Application Signals. Il peut également s’agir de n’importe quelle métrique ou expression de métrique CloudWatch. Les métriques d’application standard que vous pouvez utiliser pour un SLI sont Latency et Availability. Availability représente le nombre de réponses réussies divisé par le nombre total de demandes. Il est calculé sous la forme (1 - taux de défaillance) * 100, les réponses aux défaillances étant des erreurs 5xx. Les réponses positives sont des réponses sans erreur 5XX. Les réponses 4XX sont considérées comme réussies.

Calculer le budget d’erreurs et l’atteinte pour les SLO basés sur la période

Lorsque vous consultez les informations relatives à un SLO, vous pouvez voir son état de santé actuel et son budget d’erreurs. Le budget d’erreur est le laps de temps compris dans l’intervalle pendant lequel il est possible de dépasser le seuil tout en permettant d’atteindre le SLO. Le budget d’erreurs total est la quantité totale de temps de dépassement qui peut être tolérée sur l’ensemble de l’intervalle. Le budget d’erreurs restant est le temps de dépassement restant qui peut être toléré pendant l’intervalle en cours. Ceci après avoir soustrait du budget d’erreur total le temps de dépassement qui s’est déjà produit.

La figure suivante illustre les concepts de budget de réalisation et d’erreur pour un objectif avec un intervalle de 30 jours, des périodes d’une minute et un objectif de réalisation de 99 %. 30 jours comprennent 43 200 périodes d’une minute. 99 % de 43 200, c’est 42 768, donc 42 768 minutes par mois doivent être saines pour que le SLO soit atteint. Jusqu’à présent, dans l’intervalle actuel, 130 des périodes d’une minute n’étaient pas saines.

Détermination du succès au cours de chaque période

Au cours de chaque période, les données du SLI sont agrégées en un seul point de données sur la base des statistiques utilisées pour le SLI. Ce point de données représente la durée totale de la période. Ce point de données unique est comparé au seuil SLI pour déterminer si la période est saine. L’affichage sur le tableau de bord des périodes non saines pendant l’intervalle de temps en cours peut avertir vos opérateurs de services que le service doit être trié.

S’il est déterminé que la période n’est pas saine, la durée totale de la période est prise en compte comme un échec dans le calcul du budget d’erreur. Le suivi du budget d’erreurs vous permet de savoir si le service atteint les performances souhaitées sur une longue période.

Exclusions de fenêtres temporelles

Les exclusions de fenêtres temporelles sont un bloc de temps avec une date de début et de fin définie. Cette période de temps est exclue des métriques de performance du SLO et vous pouvez planifier des fenêtres d’exclusions temporelles uniques ou récurrentes. Par exemple, la maintenance planifiée.

Calculer le budget d’erreurs et le taux d’atteinte pour les OLS basés sur une demande

Une fois que vous avez créé un SLO, vous pouvez récupérer des rapports sur le budget d’erreurs. Un budget d’erreurs correspond au nombre de demandes pour lesquelles votre application peut ne pas être conforme à l’objectif du SLO, tout en atteignant l’objectif. Pour un SLO basé sur les demandes, le budget d’erreurs restant est dynamique et peut augmenter ou diminuer, en fonction du rapport entre les bonnes demandes et le nombre total de demandes

Le tableau suivant illustre le calcul pour un SLO basé sur les demandes avec un intervalle de 5 jours et un objectif d’atteinte de 85 %. Dans cet exemple, nous supposons qu’il n’y a pas de trafic avant le jour 1. Le SLO n’a pas atteint l’objectif au jour 10.

Calculer les taux de consommation et définir éventuellement des alarmes de taux de consommation

Vous pouvez utiliser la vigie applicative pour calculer les taux de consommation de vos objectifs de niveau de service. Un taux de consommation est une métrique qui indique la vitesse à laquelle le service consomme le budget d’erreurs, par rapport à l’objectif d’atteinte du SLO. Ce taux est exprimé comme un facteur multiple du taux d’erreur de base.

Le taux de consommation est calculé en fonction du taux d’erreur de base, qui dépend de l’objectif de réalisation. L’objectif de réalisation est le pourcentage de périodes saines ou de demandes réussies qui doit être atteint pour réaliser l’objectif du SLO. Le taux d’erreur de référence est égal à (100 % - pourcentage de l’objectif à atteindre), et ce chiffre utiliserait exactement le budget d’erreurs complet à la fin de l’intervalle de temps du SLO. Ainsi, un SLO dont l’objectif de réalisation est de 99 % aurait un taux d’erreur de base de 1 %.

Le suivi du taux de consommation nous indique à quel point nous nous éloignons du taux d’erreur de référence. Si l’on reprend l’exemple d’un objectif de réalisation de 99 %, la règle suivante s’applique :

Lorsque vous créez des taux de consommation pour vos SLO, vous pouvez également choisir de créer des alarmes CloudWatch en même temps pour surveiller les taux de consommation. Vous pouvez définir un seuil pour les taux de consommation et les alarmes peuvent vous avertir automatiquement si les métriques du taux de consommation dépassent le seuil que vous avez défini. Par exemple, un taux de consommation proche de son seuil peut vous indiquer que le SLO consomme le budget d’erreurs plus rapidement que votre équipe ne peut le tolérer et que votre équipe peut avoir besoin de ralentir la consommation dans l’application pour s’assurer que les objectifs de performance à long terme sont atteints.

La création d’alarmes entraîne des frais. Pour plus d'informations sur la tarification CloudWatch, consultez Tarification d'Amazon CloudWatch.

Calculer le taux de consommation

Pour calculer le taux de consommation, vous devez spécifier une fenêtre d’observation rétrospective. Cette fenêtre correspond à la durée sur laquelle le taux d’erreur doit être mesuré.

burn rate = error rate over the look-back window / (100% - attainment goal)

Le taux d’erreur est calculé comme le rapport du nombre de mauvais événements sur le nombre total d’événements pendant la fenêtre de taux de consommation :

Cette fenêtre doit être un multiple de la durée de la période du SLO et doit être inférieure à l’intervalle du SLO.

Déterminer le seuil approprié pour une alarme de taux de consommation

Lorsque vous configurez une alarme de taux de consommation, vous devez choisir une valeur pour le taux de consommation comme seuil d’alarme. La valeur de ce seuil dépend de la longueur de l’intervalle du SLO et de la fenêtre d’observation rétrospective, ainsi que de la méthode ou du modèle mental que votre équipe veut adopter. Il existe deux méthodes principales pour déterminer le seuil.

Méthode 1 : déterminer le pourcentage du budget total estimé pour les erreurs que votre équipe est prête à consacrer à la fenêtre d’observation rétrospective.

Si vous voulez être alerté lorsque X % du budget d’erreur estimé est dépensé au cours des dernières heures d’observation rétrospective du taux de consommation, le seuil du taux de consommation est le suivant :

burn rate threshold = X% * SLO interval length / look-back window size

Par exemple, 5 % d’un budget d’erreur de 30 jours (720 heures) dépensés en une heure nécessitent un taux de consommation de 5% * 720 / 1 = 36. Par conséquent, si la fenêtre d’observation rétrospective du taux de consommation est de 1 heure, nous fixons le seuil du taux de consommation à 36.

Vous pouvez utiliser la console CloudWatch pour créer des alarmes de taux de consommation à l’aide de cette méthode. Vous pouvez spécifier le nombre X, et le seuil est déterminé à l’aide de la formule ci-dessus.

La longueur de l’intervalle du SLO est déterminée en fonction du type d’intervalle du SLO :

Méthode 2 : déterminer le temps restant jusqu’à épuisement du budget pour l’intervalle suivant

Pour que l’alarme vous avertisse lorsque le taux d’erreur actuel dans la fenêtre d’observation rétrospective la plus récente indique qu’il reste moins de X heures avant l’épuisement du budget (en supposant que le budget restant est actuellement de 100 %), vous pouvez utiliser la formule suivante pour déterminer le seuil du taux de consommation.

burn rate threshold = SLO interval length / X

Nous insistons sur le fait que le temps restant jusqu’à épuisement du budget (X) dans la formule ci-dessus suppose que le budget total restant est actuellement de 100 %, et ne prend donc pas en compte le montant du budget qui a déjà été dépensé dans cet intervalle. Nous pouvons également considérer qu’il s’agit du temps restant jusqu’à épuisement du budget pour l’intervalle suivant.

Démonstrations pour les alarmes de taux de consommation

Prenons l’exemple d’un SLO dont l’intervalle de roulement est de 28 jours. La définition d’une alarme de taux de consommation pour ce SLO se fait en deux étapes :

Pour commencer, déterminez la part du budget d’erreur total que le service est prêt à dépenser dans un délai spécifique. En d’autres termes, énoncez votre objectif en utilisant la phrase suivante : « Je veux être alerté lorsque X % de mon budget total d’erreurs est consommé dans un délai de M minutes. »

Par exemple, vous pourriez vouloir fixer l’objectif d’être alerté lorsque 2 % du budget total d’erreurs est consommé dans les 60 minutes.

Pour définir le taux de consommation, vous devez d’abord définir la fenêtre d’observation rétrospective. La fenêtre d’observation rétrospective est M, soit, dans cet exemple, 60 minutes.

Ensuite, vous créez l’alarme CloudWatch. Ce faisant, vous devez spécifier un seuil pour la vitesse de combustion. Si le taux de consommation dépasse ce seuil, l’alarme vous en informera. Pour trouver le seuil, utilisez la formule suivante :

burn rate threshold = X% * SLO interval length/ look-back window size

Dans cet exemple, X est égal à 2, car nous voulons être alertés si 2 % du budget d’erreur est consommé en 60 minutes. La durée de l’intervalle est de 40 320 minutes (28 jours) et 60 minutes est la fenêtre d’observation rétrospective :

burn rate threshold = 2% * 40,320 / 60 = 13.44.

Dans cet exemple, vous devez définir 13,44 comme seuil d’alarme.

Alarmes multiples avec des fenêtres différentes

En définissant des alarmes sur plusieurs fenêtres d’observation rétrospectives, vous pouvez détecter rapidement les fortes augmentations du taux d’erreur avec la fenêtre courte et, en même temps, détecter les augmentations plus faibles du taux d’erreur qui finissent par épuiser le budget d’erreur si elles restent inaperçues.

En outre, vous pouvez définir une alarme composite sur un taux de consommation avec une fenêtre longue et sur un taux de consommation avec une fenêtre courte (1/12e de la fenêtre longue), et n’être informé que lorsque les deux taux de consommation dépassent un seuil. De cette façon, vous pouvez vous assurer que vous n’êtes alerté que pour des situations qui sont encore en cours. Pour plus d’informations sur les alarmes composites dans CloudWatch, consultez Combinaison d'alarmes.

Une stratégie d’alarme composite recommandée dans le manuel Google Site Reliability Engineering comprend trois alarmes composites :

Les étapes de cette configuration sont les suivantes :

La stratégie précédente n’est possible que pour les SLO dont la longueur d’intervalle est d’au moins trois heures. Pour les SLO avec des longueurs d’intervalle plus courtes, nous vous recommandons de commencer par une paire d’alarmes de taux de consommation où une alarme a une fenêtre d’observation rétrospective qui est 1/12e de la fenêtre d’observation rétrospective de l’autre alarme. Définissez ensuite une alarme composite sur cette paire.

Création d’un SLO

Nous vous recommandons de définir des SLO de latence et de disponibilité pour vos applications critiques. Ces indicateurs collectés par Application Signals correspondent aux objectifs métier communs.

Vous pouvez également définir des SLO pour n’importe quelle métrique CloudWatch ou toute expression mathématique de métrique qui aboutit à une seule série temporelle.

La première fois que vous créez un SLO dans votre compte, CloudWatch crée automatiquement le rôle lié au service AWSServiceRoleForCloudWatchApplicationSignals dans votre compte, s’il n’existe pas déjà. Ce rôle lié à un service permet à CloudWatch de collecter les données des journaux CloudWatch, les données de trace X-Ray, les données de métriques CloudWatch et les données de balisage des applications de votre compte. Pour plus d’informations sur les rôles liés à un service de CloudWatch, consultez Utilisation des rôles liés à un service pour CloudWatch.

Lorsque vous créez un SLO, vous indiquez s’il s’agit d’un SLO basé sur une période ou d’un SLO basé sur une demande. Chaque type de SLO a une façon différente d’évaluer les performances de votre application par rapport à son objectif d’atteinte.

Créer un SLO basé sur les périodes

Utilisez la procédure suivante pour créer un SLO basé sur les périodes.

Créer un SLO basé sur les demandes

Suivez la procédure suivante pour créer un SLO basé sur les demandes.

Afficher et trier le statut du SLO

Vous pouvez rapidement vérifier l’état de vos SLO à l’aide des options Objectifs de niveau de service ou Services de la console CloudWatch. La vue Services fournit une vue d’ensemble du taux de services non sains, calculé en fonction des SLO que vous avez définis. Pour plus d’informations sur l’utilisation de l’option Services, veuillez consulter la rubrique Surveillez l’état de fonctionnement de vos applications avec Application Signals.

La vue des Objectifs de niveau de service fournit une vue macro de votre organisation. Vous pouvez voir les SLO atteints et non atteints dans leur ensemble. Cela vous donne une idée du nombre de vos services et opérations qui répondent à vos attentes sur de longues périodes, en fonction des SLI que vous avez choisis.

Modification d’un SLO existant

Suivez ces étapes pour modifier un SLO existant. Lorsque vous modifiez un SLO, vous ne pouvez modifier que le seuil, l’intervalle, l’objectif de réalisation et les balises. Pour modifier d’autres aspects tels que le service, le fonctionnement ou les métriques, créez un SLO au lieu d’en modifier un existant.

La modification d’une partie de la configuration de base d’un SLO, telle que la période ou le seuil, invalide tous les points de données et évaluations précédents concernant les résultats et l’état de santé. En réalité, cela supprime et recrée le SLO.

Suppression d’un SLO

Suivez ces étapes pour supprimer un SLO existant.