Avant d'écrire une seule règle Prometheus, il faut comprendre ce qu'on mesure et pourquoi. SLI et SLO sont deux concepts liés mais distincts — les confondre est la première source d'erreurs dans un programme de fiabilité.
Qu'est-ce qu'un SLI ?
Un Service Level Indicator est une mesure quantitative d'un aspect du comportement de votre service. Ce n'est pas une alerte. Ce n'est pas un tableau de bord. C'est un ratio : événements bons / événements totaux, exprimé en pourcentage. 99,3 % des requêtes HTTP ont retourné un code de succès. 97,2 % des requêtes ont été servies en moins de 200 ms. Ce sont des SLI. L'uptime d'un serveur, la taille d'une file d'attente ou le CPU ne le sont pas — ce sont des signaux internes, pas des mesures de service rendu.
Qu'est-ce qu'un SLO ?
Un Service Level Objective est une cible fixée sur un SLI, mesurée sur une fenêtre temporelle définie. « 99,9 % des requêtes HTTP retournent un code de succès sur les 28 derniers jours » est un SLO complet. Il contient trois éléments indissociables : le SLI (ratio de succès), la cible (99,9 %), et la fenêtre (28 jours). Retirez n'importe lequel des trois et vous n'avez plus un SLO — vous avez une intention vague.
Le lien entre les deux
Le SLI mesure. Le SLO décide. Votre SLI vous dit où vous en êtes. Votre SLO vous dit si c'est acceptable. Sans cible, une mesure ne sert à rien. Sans mesure, une cible est du vent. Ce qui les relie dans la pratique, c'est l'error budget — la marge d'erreur que votre SLO vous autorise. Un SLO à 99,9 % sur 30 jours signifie que vous pouvez vous permettre 43,2 minutes d'indisponibilité complète ce mois-ci. Ni plus, ni moins.
Comment choisir un bon SLI ?
Un bon SLI mesure quelque chose que votre utilisateur ressent directement. La latence d'une requête SQL interne n'est pas un SLI — c'est un symptôme. Le ratio de réponses 2xx sur votre API en est un. La règle est simple : si l'utilisateur ne peut pas faire la différence entre 100 % et 99 % sur cette métrique, ce n'est pas le bon SLI. Pour les services HTTP, commencez par la disponibilité (taux de succès) ou la latence (ratio de requêtes sous seuil). Pour les pipelines de données, la fraîcheur ou la couverture sont souvent plus pertinentes.
Comment fixer un SLO réaliste ?
Commencez par mesurer. Regardez ce que votre service délivre réellement sur les 30 derniers jours — c'est votre ligne de base. Visez légèrement en dessous. Un SLO à 99,9 % pour un service qui délivre 98,5 % est une promesse intenable. Un SLO à 98 % pour ce même service est honnête et tenable. On resserre une fois qu'on a amélioré. L'ordre compte : mesure d'abord, cible ensuite. Jamais l'inverse.
Trois erreurs fréquentes
- ! Viser 100 % — ça rend l'error budget nul et le SLO sans objet. Le générateur rejette explicitement cette valeur.
- ! Confondre SLO et SLA — le SLO est un objectif interne. Le SLA est un engagement contractuel avec pénalités. Le SLO doit toujours être plus strict que le SLA, sinon votre contrat vous oblige à pager avant que vous ayez eu le temps de réagir.
- ! Mesurer trop de choses à la fois — commencez par un seul SLI par service. Deux SLO qui se contredisent valent moins qu'un seul bien calibré.
Articles liés
Essayer le simulateur →
SLO Simulator →