Exemples de configuration d'objectifs de niveau de service (SLO)
Exemple 1 : SLO d'application avec modèle de latence
Objectif : garantir que 90 % des appels de l'application « Robot-shop » aient une latence moyenne inférieure à 100 ms sur une période fixe d'une semaine.
La configuration du SLO serait la suivante :
Entité : Application Robot-shop
- Portée :
- Limite : tous les services
- Inclure les appels internes : faux
- Inclure les appels synthétiques : faux
- Service : Tous les services
- Point final : Tous les points finaux
Indicateur :
- Plan directeur : Latence
- Type : Temps
- Agrégation : moyenne
- Seuil : 100 ms
Objectif :
- Objectif SLO : 90 %
- Type de fenêtre temporelle : glissante
- Durée de la fenêtre temporelle : 1 semaine
Scénario : en supposant que le SLO ait enregistré 400 minutes de mauvaise qualité au cours de la période SLO d'une semaine (400 minutes avec une latence moyenne > 100 ms) à compter du 04/03/2025 :
Le budget d'erreur pour ce SLO serait calculé comme suit :
- Minutes dans la période x (1 - pourcentage cible SLO)
- Nombre total de minutes dans la fenêtre temporelle : 24 × 60 × 7 minutes en 1 semaine = 10 080 minutes
- Pourcentage cible SLO : 90 % ( 0.9 )
- Budget d'erreur : 10080 x (1 - 0.9 ) = 1008 minutes
Le statut SLO serait calculé comme suit :
- Statut SLO = 100 % x (nombre total de minutes dans la fenêtre temporelle - nombre de minutes incorrectes dans la fenêtre temporelle) / nombre total de minutes dans la fenêtre temporelle
- 100 % x (10 080 minutes totales - 400 minutes incorrectes) / 10 080 minutes totales = 96.03 %
Exemple 2 : SLO de site Web avec plan de disponibilité basé sur les événements
Objectif : garantir que les requêtes HTTP vers la page du panier ( cart.html ) du site Web de démonstration atteignent un taux de disponibilité de 95 % sur une période fixe de 4 jours à compter du 1er mars 2025.
La configuration du SLO serait la suivante :
- Entité : Site web de démonstration
- Beacon : requêtes HTTP
- Filtre personnalisé : Emplacement > Nom de la page = Panier
- Indicateur :
- Plan directeur : Disponibilité
- Type : Nombre d'événements (nombre total d'appels corrects par rapport au nombre total d'appels incorrects)
- Objectif :
- Objectif SLO : 95 %
- Type de fenêtre temporelle : Fixe
- Durée de la fenêtre temporelle : 4 jours
- Début : 01/03/2025 à 0 h 00
Scénario : en supposant qu'il y ait 234 requêtes HTTP réussies et 11 requêtes HTTP échouées pendant la période SLO commençant le 1er mars 2025 :
Le budget d'erreur pour ce SLO serait calculé comme suit :
- Evénement :
- Nombre d'événements positifs : 234 balises
- Nombre d'événements négatifs : 11 balises
- Nombre total d'événements : 234 + 11 = 245 balises
- Pourcentage cible SLO : 95 % ( 0.95 )
- Budget d'erreur : 245 x (1 - 0.95 ) = 12 balises
- Budget d'erreur restant : 12 - 11 = 1 balise
- Pourcentage restant du budget d'erreur : 100 % * (12 - 11) / 12 = 8.33 %
Le statut SLO serait calculé comme suit :
- Statut SLO = 100 % x nombre total d'événements positifs dans la fenêtre temporelle / nombre total d'événements dans la fenêtre temporelle
- 100 % x 234 balises / 245 balises = 95.5 %
Exemple 3 : Surveillance synthétique avec modèle de trafic
Objectif : Veiller à ce que 3 tests de surveillance synthétiques (panier d'achat, page d'accueil et page de liste de produits) soient exécutés 15 fois par minute, avec un objectif de 99 % de régularité, pendant une période fixe d'une semaine à compter du 18 mars 2025.
La configuration du SLO serait la suivante :
Entités :
- test du panier d'achat
- test de la page d'accueil
- Test de la page de liste des produits
Indicateur :
- Plan directeur : Circulation
- Seuil : > 15 résultats par minute
Objectif :
- Objectif SLO : 99 %
- Type de fenêtre temporelle : Fixe
- Durée de la fenêtre temporelle : 1 semaine
- Début : 18 mars 2025 à minuit
Scénario : en supposant que le SLO dispose de 21 minutes pendant lesquelles les tests synthétiques sont exécutés moins de 15 fois pendant la fenêtre temporelle du SLO à partir du 18 mars 2025 :
Le budget d'erreur pour ce SLO serait calculé comme suit :
- Minutes dans la période x (1 - pourcentage cible SLO)
- Total minutes : 24 × 60 × 7 minutes en 1 semaine = 10 080 minutes
- Objectif SLO : 99 % ( 0.99 )
- Budget d'erreur : 10080 x (1 - 0.99 ) = 101 minutes
- Budget d'erreurs restant : 101 - 21 = 80
- Pourcentage restant du budget d'erreur : 100 % * (101 - 21) / 101 = 79.21 %
Le statut SLO serait calculé comme suit :
- Statut SLO = 100 % x (nombre total de minutes dans la fenêtre temporelle - nombre de minutes incorrectes dans la fenêtre temporelle) / nombre total de minutes dans la fenêtre temporelle
- 100 % x (10 080 minutes totales - 21 minutes mauvaises) / 10 080 minutes totales = 99.8 %
Exemple 4 : Surveillance synthétique des SLO avec disponibilité basée sur les événements à l'aide de filtres de balises
Objectif : Veiller à ce que les tests du parcours de paiement synthétique atteignent une disponibilité d'au moins 99 % sur une période fixe d'une journée.
La configuration du SLO serait la suivante :
- Entité : Synthétique
- Portée :
- Méthode de sélection : en fonction de filtres
- Expression de filtre de balises : synthetic.testName startsWith « checkout »
- Indicateur :
- Plan directeur : Disponibilité
- Type : Nombre d'événements (nombre total de résultats de test positifs par rapport au nombre de résultats de test négatifs)
- Événement réussi : call.erroneous = false
- Événement indésirable : call.erroneous = true
- Objectif :
- Objectif SLO : 99 %
- Type de fenêtre temporelle : Fixe
- Durée de la fenêtre temporelle : 1 jour
- Début : 18 janvier 2026 à 0 h 00
Scénario : supposons 14 850 exécutions de tests synthétiques réussies et 150 exécutions ayant échoué au cours de la fenêtre temporelle SLO débutant le 18 janvier 2026.
Le budget d'erreur pour ce SLO serait calculé comme suit :
- Evénement :
- Nombre d'événements réussis : 14 850 exécutions de tests
- Nombre d'événements indésirables : 150 exécutions de tests
- Nombre total d'événements : 14 850 + 150 = 15 000 exécutions
- Pourcentage cible SLO : 99 % ( 0.99 )
- Marge d'erreur : 15 000 × (1 − 0.99 ) = 150 exécutions
- Budget d'erreur restant : 150 − 150 = 0 exécutions
- Pourcentage restant du budget d'erreur : 100 % × (0 / 150) = 0 %
Le statut SLO serait calculé comme suit :
- Taux de SLO = 100 % × nombre total d'événements positifs / nombre total d'événements
- 100 % × 14 850 / 15 000 = 99 %
Exemple 5 : SLO d'application avec un modèle personnalisé
Objectif : garantir que 98 % des appels de l'application « Robot-shop » ne génèrent pas de code d'état d' HTTP 400 sur une période continue d'un jour.
La configuration du SLO serait la suivante :
Entité : Application Robot-shop
- Portée :
- Limite : tous les services
- Inclure les appels internes : faux
- Inclure les appels synthétiques : faux
- Service : Tous les services
- Point final : Tous les points finaux
Indicateur :
- Plan : Personnalisé
- Type : Nombre d'événements (nombre total d'appels corrects par rapport au nombre total d'appels incorrects)
- Bon filtre : HTTP code d'état!= 400
- Mauvais filtre : HTTP code d'état = 400
Objectif :
- Objectif SLO : 98 %
- Type de fenêtre temporelle : glissante
- Durée de la fenêtre temporelle : 1 jour
Scénario : en supposant que le SLO ait reçu 25 000 appels valides et 200 appels non valides au cours de la période SLO d'une journée commençant le 10 mars 2025 :
Le budget d'erreur pour ce SLO serait calculé comme suit :
- Evénement :
- Les bons événements comptent : 25 000 appels
- Nombre d'événements négatifs : 200 appels
- Nombre total d'événements : 25 000 + 200 = 25 200 appels
- Pourcentage cible SLO : 98 % ( 0.98 )
- Budget d'erreur : 25 200 x (1 - 0.98 ) = 504 appels
- Budget d'erreurs restant : 504 - 200 = 304 appels
- Pourcentage restant de la marge d'erreur : 100 % * (504 - 200) / 504 = 60.32 %
Le statut SLO serait calculé comme suit :
- Statut SLO = 100 % x nombre total d'événements positifs dans la fenêtre temporelle / nombre total d'événements dans la fenêtre temporelle
- 100 % x 25 000 appels / 25 200 appels = 99.2 %
Exemple 6 : SLO d'application avec modèle de latence basé sur les événements
Objectif : garantir que 92 % des appels de l'application « Robot-shop » aient une latence inférieure à 100 ms sur une période fixe de deux semaines.
La configuration du SLO serait la suivante :
Entité : Application Robot-shop
- Portée :
- Limite : tous les services
- Inclure les appels internes : faux
- Inclure les appels synthétiques : faux
- Service : Tous les services
- Point final : Tous les points finaux
Indicateur :
- Plan directeur : Latence
- Type : Nombre d'événements (nombre total d'appels corrects par rapport au nombre total d'appels incorrects)
- Bon choix : latence < 100 ms
- Mauvaise décision : latence >= 100 ms
Objectif :
- Objectif SLO : 92 %
- Type de fenêtre temporelle : Fixe
- Durée de la fenêtre temporelle : 2 semaines
- Début : 10 mars 2025 à minuit
Scénario : en supposant que le SLO ait reçu 50 000 appels valides et 1 000 appels non valides au cours de la période de deux semaines débutant le 10 mars 2025 :
Le budget d'erreur pour ce SLO serait calculé comme suit :
- Evénement :
- Les bons événements comptent : 50 000 appels
- Nombre d'événements négatifs : 1 000 appels
- Nombre total d'événements : 50 000 + 1 000 = 51 000 appels
- Pourcentage cible SLO : 92 % ( 0.92 )
- Budget d'erreur : 51 000 x (1 - 0.92 ) = 4 080 appels
- Budget d'erreurs restant : 4080 - 1000 = 3080 appels
- Pourcentage restant du budget d'erreur : 100 % * (4080 - 1000) / 4080 = 75.49 %
Le statut SLO serait calculé comme suit :
- Statut SLO = 100 % x nombre total d'événements positifs dans la fenêtre temporelle / nombre total d'événements dans la fenêtre temporelle
- 100 % x 50 000 appels / 51 000 appels = 98.04 %
Exemple 7 : SLO d'un site web avec un modèle de disponibilité basé sur le temps
Objectif : garantir que les requêtes d' HTTP s vers le site Web de démonstration atteignent un taux de disponibilité de 92 % avec un taux d'erreur inférieur à 5 % sur une période glissante de 3 jours.
La configuration du SLO serait la suivante :
- Entité : Site web de démonstration
- Beacon : requêtes HTTP
- Indicateur :
- Plan directeur : Disponibilité
- Type : Temps
- Seuil de taux d'erreur : 5 %
- Objectif :
- Objectif SLO : 92 %
- Type de fenêtre temporelle : glissante
- Durée de la fenêtre temporelle : 3 jours
Scénario : en supposant que le SLO ait enregistré 200 minutes défectueuses au cours de la fenêtre SLO de 3 jours (200 minutes avec un taux d'erreur moyen supérieur à 5 %) à compter du 05/03/2025 :
Le budget d'erreur pour ce SLO serait calculé comme suit :
- Minutes dans la période x (1 - pourcentage cible SLO)
- Nombre total de minutes dans la fenêtre temporelle : 24 × 60 × 3 minutes en 3 jours = 4320 minutes
- Pourcentage cible SLO : 92 % ( 0.92 )
- Budget d'erreur : 4320 x (1 - 0.92 ) = 346 minutes
Le statut SLO serait calculé comme suit :
- Statut SLO = 100 % x (nombre total de minutes dans la fenêtre temporelle - nombre de minutes incorrectes dans la fenêtre temporelle) / nombre total de minutes dans la fenêtre temporelle
- 100 % x (4 320 minutes totales - 200 minutes incorrectes) / 4 320 minutes totales = 95.37 %
Exemple 8 : SLO d'infrastructure avec modèle de saturation basé sur le temps (CPU)
Objectif : Veiller à ce que l'utilisation du processeur sur les hôtes de production reste inférieure à 75 % pendant 99 % du temps sur une période glissante de 7 jours.
- Entité : Infrastructure
- Type d'infrastructure : Hôte
- Expression du filtre de balise :
availabilityZone = "us-east-1"
- Indicateur :
- Plan directeur : Saturation
- Type : Temps
- Métrique :
cpu.used - Agrégation : Moyenne
- Opérateur : >=
- Seuil : 75 %
- Objectif :
- Objectif SLO : 99 %
- Type de fenêtre temporelle : glissante
- Durée de la fenêtre temporelle : 7 jours
- Minutes dans la période x (1 - pourcentage cible SLO)
- Nombre total de minutes dans la fenêtre temporelle : 24 × 60 × 7 minutes en 1 semaine = 10 080 minutes
- Pourcentage cible SLO : 99 % ( 0.99 )
- Budget d'erreur : 10080 x (1 - 0.99 ) = 101 minutes
- Statut SLO = 100 % x (nombre total de minutes dans la fenêtre temporelle - nombre de minutes incorrectes dans la fenêtre temporelle) / nombre total de minutes dans la fenêtre temporelle
- 100 % x (10 080 minutes totales - 25 minutes mauvaises) / 10 080 minutes totales = 99.75 %
Exemple 9 : SLO d'infrastructure avec modèle de saturation basé sur les événements (mémoire)
Objectif : garantir que l'utilisation de la mémoire sur les serveurs de base de données reste inférieure à 85 % pour 99.9 % des instantanés métriques sur une période glissante d'un jour.
- Entité : Infrastructure
- Type d'infrastructure : Hôte
- Expression du filtre de balise :
host.fqdn contains "company-name" AND availabilityZone = "us-east-1"
- Indicateur :
- Plan directeur : Saturation
- Type : Nombre d'événements (nombre total de captures d'écran métriques correctes par rapport au nombre de captures d'écran métriques incorrectes)
- Métrique :
memory.used - Opérateur : >=
- Seuil : 85 %
- Objectif :
- Objectif SLO : 99.9 %
- Type de fenêtre temporelle : glissante
- Durée de la fenêtre temporelle : 1 jour
- Evénement :
- Nombre d'événements positifs : 8 640 instantanés
- Nombre d'événements négatifs : 5 instantanés
- Nombre total d'événements : 8 640 + 5 = 8 645 instantanés
- Pourcentage cible SLO : 99.9 % ( 0.999 )
- Budget d'erreur : 8 645 x (1 - 0.999 ) = 8.65 instantanés (arrondi à 9)
- Budget d'erreurs restant : 9 - 5 = 4 instantanés
- Pourcentage restant du budget d'erreur : 100 % * (9 - 5) / 9 = 44.44 %
- Statut SLO = 100 % x nombre total d'événements positifs dans la fenêtre temporelle / nombre total d'événements dans la fenêtre temporelle
- 100 % x 8 640 instantanés / 8 645 instantanés = 99.94 %
Exemple 10 : SLO d'infrastructure avec un modèle personnalisé pour un cluster d' Kubernetes
Objectif : Veiller à ce que le cluster d' Kubernetes s de production maintienne au moins 6 nœuds disponibles pour 99.9 % du temps sur une période glissante de 7 jours.
- Entité : Infrastructure
- Type d'infrastructure : cluster Kubernetes
- Expression du filtre de balise :
kubernetes.cluster.name = "prod-cluster"
- Indicateur :
- Plan : Personnalisé
- Type : Nombre d'événements (nombre total de captures d'écran métriques correctes par rapport au nombre de captures d'écran métriques incorrectes)
- Événements positifs : nodes.count >= 6
- Événements négatifs : nodes.count < 6
- Objectif :
- Objectif SLO : 99.9 %
- Type de fenêtre temporelle : glissante
- Durée de la fenêtre temporelle : 7 jours
- Evénement :
- Nombre d'événements positifs : 60 400 instantanés
- Nombre d'événements négatifs : 80 instantanés
- Nombre total d'événements : 60 400 + 80 = 60 480 instantanés
- Pourcentage cible SLO : 99.9 % ( 0.999 )
- Budget d'erreur : 60 480 x (1 - 0.999 ) = 60.48 instantanés (arrondi à 60)
- Budget d'erreurs restant : 60 - 80 = -20 instantanés (dépassé)
- Pourcentage restant du budget d'erreur : 100 % x (-20 / 60) = -33.33 % (dépassement)
- Statut SLO = 100 % x nombre total d'événements positifs dans la fenêtre temporelle / nombre total d'événements dans la fenêtre temporelle
- 100 % x 60 400 instantanés / 60 480 instantanés = 99.87 %
Exemple 11 : Comportement des SLO avec liaison au fuseau horaire
Objectif : s'assurer que la plage horaire SLO correspond à l'heure civile et reste inchangée chaque jour, même lors des changements d'heure liés à l'heure d'été, afin de garantir la précision et la cohérence des rapports. Assurez-vous que le calcul du SLO est lié à un fuseau horaire spécifique, car le passage à l'heure d'été a une incidence sur la fenêtre temporelle en fonction du fuseau horaire configuré.
- Entité : Application Robot-shop
- Portée :
- Limite : tous les services
- Inclure les appels internes : faux
- Inclure les appels synthétiques : faux
- Service : Tous les services
- Point final : Tous les points finaux
- Portée :
- Indicateur :
- Plan directeur : Latence
- Type : Temps
- Agrégation : moyenne
- Seuil : 100 ms
- Objectif :
- Objectif SLO : 90 %
- Type de fenêtre temporelle : Fixe
- Durée de la fenêtre temporelle : 3 jours
- Ficher le fuseau horaire : Activer
- Fuseau horaire : Europe/Berlin
Exemple 12 : SLO associé à une équipe
Objectif : attribuer l'objectif d'apprentissage (SLO) à une ou plusieurs équipes associées à l'utilisateur. Ces associations d'équipes sont ensuite utilisées pour appliquer les restrictions d'accès.
Entité : Application Robot-shop
- Portée :
- Limite : tous les services
- Inclure les appels internes : faux
- Inclure les appels synthétiques : faux
- Service : Tous les services
- Point final : Tous les points finaux
- Portée :
Indicateur :
- Plan directeur : Latence
- Type : Temps
- Agrégation : moyenne
- Seuil : 100 ms
Objectif :
- Objectif SLO : 90 %
- Type de fenêtre temporelle : glissante
- Durée de la fenêtre temporelle : 1 semaine
Détails :
- Nom : Exemple SLO
- Balises (facultatif) : Exemple de balise
- Équipes : Équipe 1, Équipe 2
Exemple 13 : SLO mensuel créé en cours de mois
Objectif : garantir que 99 % des appels vers l'application « Service de paiement » aient une latence moyenne inférieure à 200 ms sur des périodes d'un mois civil, avec le SLO créé le 15 janvier.
La configuration du SLO serait la suivante :
- Entité : Application de service de paiement
- Portée :
- Limite : appels entrants
- Inclure les appels internes : faux
- Inclure les appels synthétiques : faux
- Service : Tous les services
- Point final : Tous les points finaux
- Portée :
- Indicateur :
- Plan directeur : Latence
- Type : Temps
- Agrégation : moyenne
- Seuil : 200 ms
- Objectif :
- Objectif SLO : 99 %
- Type de fenêtre temporelle : Fixe
- Durée de la fenêtre temporelle : 1 mois civil
- Ficher le fuseau horaire : Activer
- Fuseau horaire : Amérique/New_York
- Début : 15 janvier 2025 à minuit
Scénario : Le SLO est créé le 15 janvier 2025. Les SLO mensuels correspondent aux limites mensuelles, créant ainsi une première période partielle lorsqu'ils sont créés au milieu du mois.
- Durée : 17 jours (du 15 janvier au 31 janvier)
- Total en minutes : 17 × 24 × 60 = 24 480 minutes
- Budget d'erreur : 24 480 × (1 - 0.99 ) = 245 minutes
- Mauvaises minutes enregistrées : 30 minutes
- Statut SLO : 100 % × (24 480 - 30) / 24 480 = 99.88 %
- Budget d'erreur restant : 245 - 30 = 215 minutes
- Durée : 28 jours (mois civil complet)
- Total en minutes : 28 × 24 × 60 = 40 320 minutes
- Budget d'erreur : 40 320 × (1 - 0.99 ) = 403 minutes
- Mauvaises minutes enregistrées : 50 minutes
- Statut SLO : 100 % × (40 320 - 50) / 40 320 = 99.88 %
- Budget d'erreurs restant : 403 - 50 = 353 minutes
- Durée : 31 jours (mois civil complet)
- Total en minutes : 31 × 24 × 60 = 44 640 minutes
- Budget d'erreur : 44 640 × (1 - 0.99 ) = 446 minutes
Exemple 14 : SLO mensuel créé le premier jour du mois
Objectif : garantir que 95 % des demandes d' HTTP s vers le « site Web de commerce électronique » soient disponibles sur des périodes d'un mois civil, avec un SLO créé le 1er mars.
La configuration du SLO serait la suivante :
- Entité : Site web de commerce électronique
- Beacon : requêtes HTTP
- Filtre personnalisé : Aucun
- Indicateur :
- Plan directeur : Disponibilité
- Type : Temps
- Seuil de taux d'erreur : 5 %
- Objectif :
- Objectif SLO : 95 %
- Type de fenêtre temporelle : Fixe
- Durée de la fenêtre temporelle : 1 mois civil
- Ficher le fuseau horaire : Activer
- Fuseau horaire : UTC
- Début : 01/03/2025 à 00h00
Scénario : Le SLO est créé le 1er mars 2025 (le premier jour du mois). Toutes les périodes de mesure correspondent à des mois civils complets.
- Durée : 31 jours (mois civil complet)
- Total en minutes : 31 × 24 × 60 = 44 640 minutes
- Budget d'erreur : 44 640 × (1 - 0.95 ) = 2 232 minutes
- Minutes négatives enregistrées : 400 minutes
- Statut SLO : 100 % × (44 640 - 400) / 44 640 = 99.10 %
- Budget d'erreur restant : 2 232 - 400 = 1 832 minutes
- Durée : 30 jours (mois civil complet)
- Total en minutes : 30 × 24 × 60 = 43 200 minutes
- Budget d'erreur : 43 200 × (1 - 0.95 ) = 2 160 minutes
- Mauvaises minutes enregistrées : 350 minutes
- Statut SLO : 100 % × (43 200 - 350) / 43 200 = 99.19 %
- Budget d'erreur restant : 2 160 - 350 = 1 810 minutes
Exemples de configuration des alertes intelligentes pour les niveaux de service
Exemple 1 : Alerte intelligente relative aux niveaux de service pour surveiller l'état d'un SLO
Objectif : alerter et signaler un problème si le statut de la configuration SLO de fiabilité du distributeur automatique est inférieur à 90 %.
La configuration de l'alerte intelligente relative aux niveaux de service serait la suivante :
Rule:
Alert Type: Service Levels Objective
Metric: Status
Threshold:
Operator: <
value: 0.90
SLOs: Vending Machine Reliability
Time Threshold:
Expiry: 5 Minutes
Time window: 10 Minutes
Une fois la configuration de Smart Alert effectuée, le système commencera à surveiller l'état de la configuration du SLO de fiabilité des distributeurs automatiques.
Scénario : Surveillance et déclenchement d'événements
Le SLO passe sous le seuil
- Supposons que le SLO de fiabilité du distributeur automatique tombe à 89 %, soit en dessous du seuil défini de 90 %.
- Avec le délai fixé à 10 minutes, le système attendra la fin de la période de 10 minutes avant de prendre une décision.
- Si le SLO reste inférieur à 90 % après 10 minutes, le système déclenche un événement, signalant un problème.
SLO revient au-dessus du seuil
- Si, après un certain temps, le statut SLO se rétablit et dépasse 90 %, le système continuera à surveiller.
- Toutefois, si le statut reste supérieur à 90 %, le système attendra le délai d'expiration de 5 minutes.
- Si le SLO reste supérieur à 90 % pendant les 5 minutes complètes, l'événement sera automatiquement clôturé.
Exemple 2 : Alerte intelligente relative aux niveaux de service pour surveiller le budget d'erreurs d'un SLO
Objectif : alerter et signaler un problème si le pourcentage de consommation du budget d'erreurs de la configuration SLO de fiabilité du distributeur automatique est supérieur à 50 %.
La configuration de l'alerte intelligente relative aux niveaux de service est la suivante :
Rule:
Alert Type: Error Budget
Metric: Burned Percentage
Threshold:
Operator: >
value: 0.50
SLOs: Vending Machine Reliability
Time Threshold:
Expiry: 5 Minutes
Time window: 10 Minutes
Une fois la configuration des alertes intelligentes mise en place, le système commencera à surveiller le pourcentage d'utilisation du budget d'erreurs défini dans la configuration du SLO de fiabilité des distributeurs automatiques.
Scénario : Surveillance et déclenchement d'événements
La consommation du budget d'erreurs dépasse 50 %
- Supposons que la consommation du budget d'erreurs dépasse 50 %.
- Avec le délai fixé à 10 minutes, le système attendra la fin de la période de 10 minutes avant de prendre une décision.
- Si la consommation du budget d'erreurs reste supérieure à 50 % après 10 minutes, le système déclenche un événement, soulevant un problème.
La consommation du budget d'erreurs tombe en dessous de 50 %
- Si, après un certain temps, la consommation du budget d'erreurs repasse sous la barre des 50 %, le système continuera à surveiller.
- Si la consommation du budget d'erreurs reste inférieure à 50 %, le système attendra l'expiration du délai de 5 minutes.
- Si la consommation du budget d'erreurs reste inférieure à 50 % pendant les 5 minutes complètes, l'événement sera automatiquement clôturé.
Calcul des alertes intelligentes sur le taux d'épuisement des niveaux de service
Le taux de consommation est calculé à l'aide de la formule suivante :
Taux de consommation = (budget d'erreurs consommé * fenêtre temporelle SLO) / fenêtre d'alerte
- Par exemple :
- Supposons que le budget d'erreur consommé au cours des 12 dernières heures soit de 70 % et que la fenêtre temporelle SLO pour le SLO de fiabilité des distributeurs automatiques soit de 1 jour (24 heures).
- Le taux de consommation pour les 12 dernières heures serait : ( 0.70 * 24) / 12 = 1.4
- De même, si le budget d'erreur consommé au cours des deux dernières heures est de 20 %
- Le taux de consommation pour les deux dernières heures serait : ( 0.20 * 24) / 2 = 2.4
Exemple 3 - Alerte intelligente pour surveiller le taux d'épuisement d'un SLO avec une seule fenêtre d'alerte et un seul seuil
Objectif : alerter et signaler un problème si le taux de défaillance de la configuration SLO de fiabilité des distributeurs automatiques est supérieur à 1 au cours des 12 dernières heures.
La configuration de l'alerte intelligente relative aux niveaux de service doit être la suivante :
Rule:
Alert Type: Error Budget
Metric: Burn Rate V2
Burn Rate Config:
[
Alert Window Type: SINGLE
Duration: 12 Hours
Duration Unit Type: Hour
Threshold:
Operator: >
Value: 1
]
SLOs: Vending Machine Reliability
Time Threshold:
Expiry: 5 Minutes
Time window: 10 Minutes
Une fois la configuration de Smart Alert mise en place, le système commence à surveiller le taux d'épuisement défini dans la configuration du SLO de fiabilité des distributeurs automatiques pour la fenêtre d'alerte spécifiée.
Scénario : Surveillance et déclenchement d'événements
Le taux de consommation dépasse 1 pour la fenêtre d'alerte (12 dernières heures)
- Supposons que le taux de consommation calculé pour les 12 dernières heures commence à dépasser 1.
- Avec le délai fixé à 10 minutes, le système attend la fin de la période de 10 minutes avant de prendre une décision.
- Si le taux de consommation reste supérieur à 1 après 10 minutes, le système déclenche une alerte et signale un problème.
Le taux de consommation tombe en dessous de 1 pour la fenêtre d'alerte (12 dernières heures)
- Si, après un certain temps, le taux de consommation de la fenêtre d'alerte tombe en dessous de 1, le système continue la surveillance.
- Si le taux de consommation reste inférieur à 1, le système attendra le délai d'expiration de 5 minutes.
- Si le taux de consommation reste inférieur à 1 pendant les 5 minutes, l'événement sera automatiquement clôturé.
Exemple 4 - Alerte intelligente pour surveiller le taux de consommation d'un SLO avec plusieurs fenêtres d'alerte et des seuils respectifs
Objectif : alerter et signaler un problème si le taux de défaillance de la configuration SLO de fiabilité des distributeurs automatiques est supérieur à 1 au cours des dernières 24 heures et supérieur à 4 au cours des dernières 2 heures.
La configuration de l'alerte intelligente relative aux niveaux de service doit être la suivante :
Rule:
Alert Type: Error Budget
Metric: Burn Rate V2
Burn Rate Config:
[
Alert Window Type: LONG
Duration: 24 Hours
Duration Unit Type: Hour
Threshold:
Operator: >
Value: 1
,
Alert Window Type: SHORT
Duration: 2 Hours
Duration Unit Type: Hour
Threshold:
Operator: >
Value: 4
]
SLOs: Vending Machine Reliability
Time Threshold:
Expiry: 5 Minutes
Time window: 10 Minutes
Une fois la configuration de Smart Alert mise en place, le système commence à surveiller le taux d'épuisement de la configuration SLO de fiabilité des distributeurs automatiques, tant pour les fenêtres d'alerte longues que courtes.
Scénario : Surveillance et déclenchement d'événements
Le taux de consommation dépasse 1 pour les fenêtres d'alerte longues et courtes (dernières 24 heures et 2 heures)
- Supposons que le taux de consommation calculé pour les dernières 24 heures commence à dépasser 1 et que celui des deux dernières heures commence à dépasser 4.
- Avec le délai fixé à 10 minutes, le système attend la fin de la période de 10 minutes avant de prendre une décision.
- Si le taux de consommation des deux fenêtres d'alerte dépasse toujours les seuils après 10 minutes, le système déclenche un événement d'alerte, soulevant ainsi un problème.
Le taux de consommation tombe en dessous de 1 pour la fenêtre d'alerte longue, mais reste supérieur à 4 pour la fenêtre d'alerte courte
- Si, après un certain temps, le taux de consommation pour la fenêtre d'alerte longue tombe en dessous de 1, mais que le taux de consommation pour la fenêtre d'alerte courte reste supérieur à 4, le système continue la surveillance.
- Si le taux de consommation reste inférieur à 1 pendant la fenêtre d'alerte longue, le système attend le délai d'expiration de 5 minutes.
- Si le taux de consommation reste inférieur à 1 pendant toute la durée de la fenêtre d'alerte longue, soit 5 minutes, quelle que soit la valeur de la fenêtre d'alerte courte, l'événement est automatiquement clos, car les deux seuils doivent être dépassés pour qu'une alerte soit envoyée. Il en va de même dans le sens inverse : même lorsque la fenêtre d'alerte courte dépasse le seuil, mais que la fenêtre d'alerte longue ne le dépasse pas.
Le taux de consommation tombe en dessous de 1 pour la fenêtre d'alerte longue et en dessous de 4 pour la fenêtre d'alerte courte
- Si, après un certain temps, le taux de consommation pour les deux fenêtres d'alerte tombe en dessous de leurs seuils respectifs, le système continue la surveillance.
- Si le taux de consommation reste inférieur aux seuils, le système attend l'expiration du délai de 5 minutes.
- Si le taux de combustion reste inférieur aux seuils pendant les 5 minutes complètes, l'événement est automatiquement clôturé.
Traitement des incidents
Voici quelques suggestions pour résoudre les problèmes courants liés aux SLO de configuration.
Problème : aucun budget d'erreurs n'est consommé, le statut SLO est toujours de 100 %.
- Solution : utilisez le graphique des indicateurs du tableau de bord SLO pour vérifier si l'indicateur ne dépasse jamais le seuil pendant la période SLO, ce qui évite toute consommation du budget d'erreurs. Vous pouvez envisager de modifier le seuil en conséquence.
Problème : aucun budget d'erreurs n'est consommé, le statut SLO est toujours de 100 %.
- Solution : utilisez le graphique du trafic sur le tableau de bord SLO pour vérifier que l'entité reçoit du trafic pendant la fenêtre temporelle SLO. Sinon, le budget d'erreurs et le statut SLO ne seront pas affectés.
Problème : le budget d'erreurs est systématiquement consommé rapidement, le statut SLO reste négatif.
- Solution : utilisez le graphique des indicateurs du tableau de bord SLO pour vérifier si l'indicateur dépasse systématiquement le seuil pendant la période SLO, ce qui entraîne une consommation rapide du budget d'erreurs. Vous pouvez envisager de modifier le seuil en conséquence.
Problème : l'alerte de taux de consommation n'est pas déclenchée en raison d'un décalage dans la fenêtre temporelle.
- Solution :
- Fenêtre temporelle fixe SLO : si le SLO est configuré avec une fenêtre temporelle fixe, l'alerte peut ne pas se déclencher si le calcul du taux de consommation est basé sur une fenêtre d'alerte plus longue que le temps écoulé réel dans la période SLO. Par exemple, si la fenêtre d'alerte nécessite des données sur une période de 12 heures, mais que la fenêtre temporelle SLO vient de commencer, il se peut qu'il n'y ait pas assez de temps pour que le taux de consommation dépasse le seuil. Par conséquent, aucune alerte n'est déclenchée même si le taux de consommation est élevé pendant la durée écoulée.
- Fenêtre temporelle glissante SLO : si le SLO est défini sur une fenêtre temporelle glissante, le calcul du taux de consommation peut ne pas déclencher d'alerte si la fenêtre d'alerte s'étend au-delà de l'heure de création du SLO. Par exemple, si la fenêtre d'alerte dépasse la période pendant laquelle le SLO a été créé ou était actif, le taux de consommation ne peut pas être calculé correctement, car les données ne sont pas disponibles pour l'ensemble de la fenêtre d'alerte.
- Solution :