Ce document de la section Framework d'architecture Google Cloud : Fiabilité fournit des détails sur les alertes concernant les SLO.
Une approche erronée lors de l'introduction d'un nouveau système d'observabilité comme celui des SLO consiste à complètement remplacer un ancien système par le nouveau. À la place, vous devez voir les SLO comme un système complémentaire. Par exemple, au lieu de supprimer vos alertes existantes, nous vous recommandons de les exécuter en parallèle avec les alertes SLO mentionnées ici. Cette approche vous permet d'identifier les anciennes alertes prévisibles des alertes SLO, celles qui se déclenchent en parallèle avec vos alertes SLO, et celles qui ne se déclenchent jamais.
Un principe d'ingénierie SRE consiste à envoyer des alertes en fonction des symptômes, et non des causes. Les SLO sont, par nature, des évaluation des symptômes. À mesure que vous adoptez des alertes SLO, vous pouvez constater que l'alerte des symptômes se déclenche avec d'autres alertes. Si vous constatez que vos anciennes alertes basées sur les causes se déclenchent sans SLO ni symptômes, elles peuvent être complètement désactivées, transformées en alertes relatives à la gestion des requêtes ou consignées pour être consultées ultérieurement.
Pour plus d'informations, consultez le classeur d'ingénierie SRE, chapitre 5.
Taux d'utilisation des SLO
Le taux d'utilisation d'un SLO permet de mesurer la rapidité avec laquelle une indisponibilité expose les utilisateurs aux erreurs et consomme la marge d'erreur. En mesurant votre taux d'utilisation, vous pouvez déterminer le temps s'écoulant avant qu'un service ne viole son SLO. Les alertes basées sur le taux d'utilisation de SLO sont une approche intéressante. N'oubliez pas que votre SLO repose sur une durée, qui peut être très longue (des semaines, voire des mois). Toutefois, l'objectif est de détecter rapidement une condition qui entraîne une violation de SLO avant que cette violation ne se produise.
Le tableau suivant indique le temps nécessaire pour dépasser un objectif si 100 % des requêtes échouent pour l'intervalle spécifié, en supposant que le nombre de requêtes par seconde (RPS) est constant. Par exemple, si un SLO de 99,9 % est mesuré sur une période de 30 jours, vous pouvez supporter 43,2 minutes de temps d'arrêt complet pendant cette période. Par exemple, ce temps d'arrêt peut survenir en une seule fois ou se répartir sur plusieurs incidents.
| Objectif | 90 jours | 30 jours | 7 jours | 1 jour |
|---|---|---|---|---|
| 90 % | 9 jours | 3 jours | 16,8 heures | 2,4 heures |
| 99 % | 21,6 heures | 7,2 heures | 1,7 heure | 14,4 minutes |
| 99,9 % | 2,2 heures | 43,2 minutes | 10,1 minutes | 1,4 minute |
| 99,99 % | 13 minutes | 4,3 minutes | 1 minute | 8,6 secondes |
| 99,999 % | 1,3 minute | 25,9 secondes | 6 secondes | 0,9 secondes |
En pratique, vous ne pouvez pas supporter d'incidents avec une interruption à 100 % si vous souhaitez atteindre des pourcentages élevés. Cependant, de nombreux systèmes distribués peuvent partiellement échouer ou se dégrader de manière concertée. Même dans ce cas, vous devez toujours savoir si une intervention humaine est nécessaire, même dans des échecs partiels, et les alertes SLO vous permettent de le déterminer.
Quand alerter
Une question importante consiste à savoir quand agir en fonction de votre taux d'utilisation de SLO. En règle générale, si vous épuisez votre marge d'erreur en 24 heures, le moment auquel appeler une personne pour résoudre un problème est maintenant.
Il n'est pas toujours simple d'évaluer le taux d'échec. Une série d'erreurs mineures peut sembler effrayante sur le moment, mais s'avérer de courte durée et n'avoir qu'un impact indirect sur votre SLO. De même, si un système est légèrement défectueux depuis longtemps, ces erreurs peuvent entraîner une violation du SLO.
Dans l'idéal, votre équipe réagira à ces signaux afin que vous dépensiez la quasi-totalité de votre marge d'erreur (mais sans la dépasser) pendant une période donnée. Si vous dépensez trop, vous enfreignez votre SLO. Si vous dépensez trop peu, vous ne prenez aucun risque ou vous risquez de surmener votre équipe d'astreinte.
Il vous faut un moyen de déterminer si un système est suffisamment défectueux pour qu'un humain intervienne. Les sections suivantes présentent certaines approches à cette question.
Utilisation rapide
L'un des types d'utilisation du SLO est une utilisation rapide du SLO, car il consomme rapidement votre marge d'erreur et nécessite votre intervention pour éviter la violation du SLO.
Supposons que votre service fonctionne normalement à 1 000 requêtes par seconde (RPS) et que vous souhaitez maintenir une disponibilité de 99 % telle que mesurée sur une semaine de sept jours. Votre marge d'erreur correspond à environ 6 millions d'erreurs autorisées (environ 600 millions de requêtes). Par exemple, si vous disposez de 24 heures avant l'épuisement de votre marge d'erreur, la limite est d'environ 70 erreurs par seconde, soit 252 000 erreurs par heure. Ces paramètres sont basés sur la règle générale selon laquelle les incidents nécessitant une intervention doivent consommer au moins 1 % de la marge d'erreur trimestriel.
Vous pouvez choisir de détecter ce taux d'erreurs avant qu'une heure ne soit écoulée. Par exemple, après avoir observé 15 minutes d'un taux d'erreur de 70 par seconde, vous pouvez décider de faire appel à l'ingénieur par téléphone, comme le montre le schéma suivant.
Idéalement, le problème est résolu avant que vous ne dépensiez une heure de votre marge d'erreur pour 24 heures. Le fait de choisir de détecter ce taux dans une période plus courte (par exemple, une minute) risque de générer trop d'erreurs. Si votre délai de détection est inférieur à 15 minutes, ce nombre peut être ajusté.
Utilisation lente
Un autre type de taux d'utilisation est l'utilisation lente. Supposons que vous introduisez un bug qui consomme votre marge d'erreur hebdomadaire au bout de cinq ou six jours, ou votre budget mensuel à la deuxième semaine. Quelle est la meilleure réponse ?
Dans ce cas, vous risquez d'introduire une alerte d'utilisation lente de SLO, qui vous informe que vous êtes sur le point d'épuiser votre marge d'erreur avant la fin de la période d'alerte. Bien entendu, cette alerte peut renvoyer de nombreux faux positifs. Par exemple, il arrive souvent que des erreurs surviennent brièvement, mais à un rythme qui consomme rapidement votre marge d'erreur. Dans ces cas, la condition est un faux positif, car elle ne dure que peu de temps et ne menace pas votre marge d'erreur à long terme. N'oubliez pas que l'objectif n'est pas de supprimer toutes les sources d'erreurs, mais de ne pas dépasser la plage acceptable pour ne pas dépasser votre marge d'erreur. Vous souhaitez éviter d'alerter un agent afin d'identifier les événements qui ne constituent pas une menace légitime de votre marge d'erreur.
Nous vous recommandons de prévenir une file d'attente de billets (plutôt que d'appeler ou d'envoyer un e-mail) en cas d'événements d'utilisation lente. Les événements d'utilisation lente ne sont pas des urgences, mais nécessitent une attention humaine avant l'expiration du budget. Ces alertes ne doivent pas être des e-mails adressés à une liste d'équipes, qui deviennent rapidement une gêne à ignorer. Les billets doivent être traçables, attribuables et transférables. Les équipes doivent développer des rapports sur la charge des billets, les taux de fermeture, les possibilités d'action et les doublons. Les billets inexploitables excessifs constituent un bon exemple de tâche laborieuse.
L'utilisation optimale des alertes SLO peut prendre du temps, et dépendre de la culture et des attentes de votre équipe. N'oubliez pas que vous pouvez affiner vos alertes SLO au fil du temps. Vous pouvez également utiliser plusieurs méthodes d'alerte avec différentes périodes d'alerte, en fonction de vos besoins.
Alertes de latence
En plus des alertes de disponibilité, vous pouvez également avoir des alertes de latence. Avec les SLO de latence, vous évaluez le pourcentage de requêtes qui n'atteignent pas une cible de latence. En utilisant ce modèle, vous pouvez utiliser le même modèle d'alerte que celui utilisé pour détecter les utilisations rapides ou lentes de votre marge d'erreur.
Comme indiqué plus haut à propos des SLO de latence médiane, la moitié de vos requêtes peuvent être hors du SLO. En d'autres termes, vos utilisateurs peuvent faire l'expérience d'une mauvaise latence pendant des jours avant que vous ne détectez l'impact sur votre marge d'erreur à long terme. Les services doivent plutôt définir des objectifs de latence de queue et des objectifs de latence typique. Nous vous suggérons d'utiliser le 90e centile historique pour définir la latence typique et le 99e centile pour la queue. Une fois ces cibles définies, vous pouvez définir des SLO en fonction du nombre de requêtes que vous prévoyez de recevoir dans chaque catégorie de latence et du nombre de requêtes trop lentes. Le concept de cette approche est identique à celui d'une marge d'erreur et doit être traitée de la même manière. Ainsi, vous pouvez obtenir une déclaration du type "90 % des requêtes seront traitées dans les limites de la latence typique et 99,9 % dans les limites de la latence de queue". Ces cibles garantissent que la plupart des utilisateurs feront l'expérience d'une latence typique, mais vous permettent de suivre le nombre de requêtes plus lentes que vos cibles de latence de queue.
Certains services peuvent disposer d'environnements d'exécution avec des variantes très élevées. Par exemple, pour un système de datastore, les attentes en termes de lecture peuvent être très différentes par rapport à celles d'écriture. Au lieu d'énumérer toutes les attentes possibles, vous pouvez introduire des buckets de performances d'exécution, comme le montrent les tableaux suivants. Cette approche suppose que ces types de requêtes sont identifiables et pré-.classés dans chaque bucket. Il ne faut pas s'attendre à classer les requêtes à la volée.
| Site Web pour l'utilisateur | |
|---|---|
| Bucket | Exécution maximale attendue |
| Lire | 1 seconde |
| Écrire/Mettre à jour | 3 secondes |
| Systèmes de traitement des données | |
|---|---|
| Bucket | Exécution maximale attendue |
| S | 10 secondes |
| M | 1 minute |
| L | 5 minutes |
| Géante | 1 heure |
| Énorme | 8 heures |
En évaluant le système tel qu'il est actuellement, vous pouvez connaître le temps nécessaire à l'exécution de ces requêtes. Prenons l'exemple d'un système de traitement de vidéos mises en ligne. Si la vidéo est très longue, le temps de traitement doit être plus long. Nous pouvons utiliser la durée de la vidéo en secondes pour classer ce travail dans un bucket, comme le montre le tableau suivant. La table enregistre le nombre de requêtes par bucket et plusieurs centiles pour la distribution de l'exécution au cours de la semaine.
| Durée de la vidéo | Nombre de requêtes évaluées en une semaine | 10 % | 90 % | 99,95 % |
|---|---|---|---|---|
| S | 0 | - | - | - |
| M | 1,9 million | 864 millisecondes | 17 secondes | 86 secondes |
| L | 25 millions | 1,8 secondes | 52 secondes | 9,6 minutes |
| Géante | 4,3 millions | 2 secondes | 43 secondes | 23,8 minutes |
| Énorme | 81 000 | 36 secondes | 1,2 minute | 41 minutes |
À partir de cette analyse, vous pouvez déduire quelques paramètres d'alerte :
- fast_typical : au maximum, 10 % des requêtes sont plus rapides que ce délai. Si trop de requêtes sont plus rapides que ce délai, vos cibles sont peut-être incorrectes ou votre système a peut-être changé.
- slow_typical : au moins 90 % des requêtes sont plus rapides que ce délai. Cette limite permet d'augmenter votre SLO principal de latence. Ce paramètre indique si la plupart des requêtes sont suffisamment rapides.
- slow_tail : au moins 99,95 % des requêtes sont plus rapides que ce délai. Cette limite garantit qu'il n'y a pas trop de requêtes lentes.
- deadline : point auquel le RPC ou le traitement en arrière-plan de l'utilisateur expire et échoue (une limite généralement déjà codée en dur dans le système). Ces requêtes ne seront pas réellement lentes, mais auront réellement échoué avec une erreur et à la place sont comptabilisées dans votre SLO de disponibilité.
Dans le cadre de la définition de buckets, il est recommandé de conserver les valeurs fast_typical, slow_typical et slow_tail d'un bucket selon un ordre de grandeur défini. Cela vous permet de ne pas disposer d'un bucket trop large. Nous vous recommandons de ne pas essayer de prévenir les chevauchements ou les écarts entre les buckets.
| Bucket | fast_typical | slow_typical | slow_tail | deadline |
|---|---|---|---|---|
| S | 100 millisecondes | 1 seconde | 10 secondes | 30 secondes |
| M | 600 millisecondes | 6 secondes | 60 secondes (1 minute) | 300 secondes |
| L | 3 secondes | 30 secondes | 300 secondes (5 minutes) | 10 minutes |
| Géante | 30 secondes | 6 minutes | 60 minutes (1 heure) | 3 heures |
| Énorme | 5 minutes | 50 minutes | 500 minutes (8 heures) | 12 heures |
Ceci résulte dans une règle telle que api.method: SMALL => [1s, 10s].
Dans ce cas, le système de suivi SLO voit une requête, en détermine le bucket (peut-être en analysant son URI ou son nom de méthode et en comparant le nom à une table de conversion), puis met la statistique à jour en fonction de l'environnement d'exécution de cette requête. Si cela prend 700 millisecondes, c'est dans l'ordre de la valeur cible slow_typical. Si cela prend 3 millisecondes, c'est dans l'ordre de la valeur slow_tail. Si cela prend 22 millisecondes, c'est au-delà de la valeur slow_tail, sans encore constituer une erreur.
En termes de satisfaction utilisateur, la latence de queue manquante équivaut à l'indisponibilité. (La réponse est si lente que la réponse doit être considérée comme un échec.) C'est pourquoi nous vous suggérons d'utiliser le même pourcentage que celui utilisé pour la disponibilité, par exemple :
Ce que vous considérez comme une latence typique dépend de vous. Certaines équipes de Google considèrent 90 % comme une bonne cible. Cela est lié à votre analyse et à la façon dont vous avez choisi les durées pour slow_typical. Exemple :
Alertes suggérées
Compte tenu de ces consignes, le tableau suivant inclut un ensemble de référence d'alertes de SLO.
| SLO | Période d'évaluation | Budget dépensé | Action |
|---|---|---|---|
|
Disponibilité, utilisation rapide Latence typique latence de queue |
Période d'une heure | Moins de 24 heures pour la violation du SLO | Envoyer une alerte à quelqu'un |
|
Disponibilité, utilisation lente Latence typique, utilisation lente Latence de queue, utilisation lente |
Période de sept jours | Plus de 24 heures avant la violation du SLO | Créer une demande |
Cela peut prendre du temps de développer des alertes SLO optimales. Les durées présentées dans cette section sont des suggestions. vous pouvez les ajuster en fonction de vos besoins et de votre niveau de précision. Vous pouvez régler les alertes en fonction de la période d'évaluation ou l'épuisement de la marge d'erreur. Vous pouvez également ajouter une couche d'alerte supplémentaire entre les utilisations rapides et lentes.