Chapitre 1 · 3 h
Observabilité
Métriques, journaux et traces ; Prometheus et Grafana ; centralisation des journaux ; alertes utiles contre bruit d'alertes ; SLI, SLO et budget d'erreur.
Le chapitre 6 a construit un déploiement canari : router 5 % du trafic, mesurer, décider. Le chapitre 9 a montré Kubernetes retirer des pods du service et arrêter un déploiement.
Deux mécanismes remarquables, et tous deux inutilisables tels quels — parce qu'il manque la partie qui regarde. Un canari sans mesure expose 5 % des utilisateurs et attend qu'ils se plaignent ; un orchestrateur qui redémarre en boucle sans que rien ne le signale produit une panne silencieuse.
L'observabilité est cette partie manquante. Sa question n'est pas « le serveur répond-il ? » mais « que fait mon système, et pourquoi ? ».
Trois piliers, trois questions
| Pilier | Nature | Répond à | Coût |
|---|---|---|---|
| Métriques | nombres agrégés dans le temps | que quelque chose va mal | faible |
| Journaux | événements discrets, horodatés | quoi exactement | moyen à élevé |
| Traces | trajet d'une requête entre services | où, dans la chaîne | élevé |
L'ordre n'est pas arbitraire : c'est celui du diagnostic. Une métrique alerte — le taux d'erreur est passé de 0,1 % à 4 %. Les journaux disent de quoi il s'agit — telle requête échoue avec tel message. Une trace dit où le temps est passé quand cinq services sont impliqués et qu'aucun ne semble fautif.
Les trois ne se remplacent pas. Beaucoup d'équipes n'ont que des journaux et cherchent une tendance en les lisant, ce qui ne marche pas : un journal répond mal à « combien » et « depuis quand ».
Métriques
Prometheus interroge périodiquement les applications, qui exposent leurs compteurs sur une adresse dédiée. Ce modèle par interrogation a une conséquence utile : l'absence de réponse est elle-même une information — un service qui ne répond plus est immédiatement visible.
Chaque métrique porte des étiquettes qui la découpent : par code HTTP, par point d'entrée, par version. C'est ce qui permet de comparer la version 1.4 et la version 1.5 pendant un canari, et donc de décider.
Quatre indicateurs suffisent à surveiller un service, et ils portent le nom de signaux dorés : la latence, le trafic, les erreurs, la saturation — c'est-à-dire à quel point les ressources sont pleines.
Un point de méthode sur la latence, souvent manqué : on ne surveille jamais une moyenne. Une latence moyenne de 200 ms peut cacher 95 % des requêtes à 50 ms et 5 % à plusieurs secondes. On regarde des centiles — le 95e, le 99e — parce que ce sont eux que les utilisateurs subissent, et parce qu'ils bougent bien avant la moyenne.
Journaux
Deux règles, et la première a une raison précise.
Les journaux quittent la machine. Une machine qui tombe emporte ses fichiers, et un conteneur détruit emporte les siens — le chapitre 3 l'a dit. Sur vingt exemplaires, chercher dans vingt endroits est impraticable. On les envoie donc vers un système central.
Les journaux sont structurés. Une ligne de texte libre se cherche mal ; un enregistrement avec des champs se filtre.
2026-03-14 10:22:31 ERROR échec de la commande 4471 pour l'utilisateur 88{"ts":"2026-03-14T10:22:31Z","niveau":"error","message":"échec de commande", "commande":4471,"utilisateur":88,"trace":"a3f9c1","service":"paiement"}Le champ trace est ce qui relie les enregistrements d'une même requête à travers les services.
Sans lui, un incident dans une architecture distribuée demande de recouper des horodatages à la
main — c'est faisable sur deux services, impossible sur dix.
Deux mises en garde. Les journaux coûtent : en stockage, en indexation, en bande passante,
et le niveau debug en production peut coûter plus cher que le service lui-même. Et ils
contiennent des données personnelles — journaliser un corps de requête revient souvent à
journaliser une adresse ou un moyen de paiement, ce qui a des conséquences réglementaires.
Alertes utiles, et bruit d'alertes
C'est la partie la plus importante du chapitre, et la plus mal faite en pratique.
Le mécanisme de dégradation est connu. On ajoute des alertes « au cas où ». Certaines se déclenchent sans qu'il y ait rien à faire. L'équipe apprend à les ignorer, met en sourdine celles qui reviennent le plus, et le jour où une vraie alerte part, elle est traitée comme les autres. C'est exactement le sort du test instable du chapitre 5.
Trois règles l'évitent.
Alerter sur les symptômes, pas sur les causes. « Le taux d'erreur dépasse 2 % » concerne les utilisateurs. « L'usage processeur dépasse 80 % » ne concerne personne : si le service répond correctement, il n'y a rien à faire. La cause s'investigue dans les tableaux de bord, une fois alerté par le symptôme.
Toute alerte doit être actionnable. La question à poser pour chaque alerte est : « que fait la personne réveillée ? » Sans réponse précise, l'alerte devient un tableau de bord, pas une alerte.
Distinguer ce qui réveille de ce qui attend. Une dégradation qui menace le service justifie une notification immédiate ; un disque à 70 % justifie un ticket. Mélanger les deux détruit la première catégorie.
SLI, SLO et budget d'erreur
Ces trois notions donnent au chapitre son cadre, et elles règlent un débat vieux comme le chapitre 1.
Un SLI est un indicateur de service : la part des requêtes servies en moins de 300 ms, par exemple. Un SLO est l'objectif qu'on se donne dessus : « 99,9 % des requêtes en moins de 300 ms, sur trente jours ».
Le budget d'erreur est le complément : . Sur trente jours, cela représente 43 minutes d'indisponibilité autorisées.
Le renversement est là. Ce budget n'est pas une tolérance honteuse : c'est une ressource à dépenser. Tant qu'il reste du budget, l'équipe peut déployer vite et prendre des risques — le canari du chapitre 6, une refonte, une migration. Quand il est épuisé, on gèle les changements risqués et l'on consacre l'effort à la fiabilité.
Cette mécanique transforme une dispute en arithmétique. « Faut-il livrer vite ou être stable ? » n'est plus une question d'opinion entre deux équipes aux objectifs opposés : c'est un budget, mesuré, que tout le monde regarde. Et un SLO à 100 % est un mauvais SLO — il interdit tout changement, et il coûte un ordre de grandeur de plus que 99,9 % pour un bénéfice que personne ne perçoit.
Quiz · 1 question
Une équipe reçoit soixante alertes par jour, dont deux ou trois exigent une action. Quel est le vrai risque ?
- Le coût du système de supervision, qui traite trop de données — coût technique
- L'équipe apprend à ignorer les alertes : le jour où une vraie part, elle est traitée comme les autres. Le bruit ne fait pas perdre du temps, il DÉTRUIT LE SIGNAL — destruction du signal
- Aucun : mieux vaut trop d'alertes que pas assez, tant qu'elles sont archivées — aucun risque
Réponse : C'est exactement le mécanisme du test instable du chapitre 5, transposé à l'exploitation. Une alerte qui se déclenche sans qu'il y ait rien à faire enseigne à l'équipe que « rouge » ne veut rien dire ; on met en sourdine celles qui reviennent, on regarde les autres distraitement, et le jour où le taux d'erreur explose réellement, l'alerte est noyée dans les cinquante-sept autres. Trois règles l'évitent. ALERTER SUR LES SYMPTÔMES, pas sur les causes : « le taux d'erreur dépasse 2 % » concerne les utilisateurs, « le processeur est à 80 % » ne concerne personne si le service répond. TOUTE ALERTE DOIT ÊTRE ACTIONNABLE : que fait la personne réveillée ? Sans réponse précise, c'est un tableau de bord, pas une alerte. Et DISTINGUER ce qui réveille de ce qui attend un ticket — mélanger les deux détruit la première catégorie.
Quiz · 1 question
Un SLO fixe 99,9 % de disponibilité sur trente jours. L'équipe a consommé 10 minutes de son budget d'erreur. Que peut-elle en faire ?
- Rien : tout incident est un échec, et il faut geler les déploiements jusqu'à la fin du mois — tout incident est un échec
- Il reste 33 minutes sur les 43 autorisées : le budget est une RESSOURCE À DÉPENSER — tant qu'il en reste, on peut déployer vite et prendre des risques ; quand il est épuisé, on gèle les changements risqués — une ressource à dépenser
- Relever le SLO à 99,99 % pour se donner plus de marge — relever le SLO
Réponse : Le budget d'erreur est le complément du SLO : 100 % − 99,9 % = 0,1 %, soit 43 minutes sur trente jours. Le renversement conceptuel est de le voir comme une RESSOURCE plutôt que comme une tolérance honteuse. Tant qu'il en reste, l'équipe est autorisée à déployer vite, à tenter une migration, à lancer un canari — les incidents qui en découlent sont budgétés. Quand il est épuisé, on gèle les changements risqués et l'on consacre l'effort à la fiabilité. Cette mécanique transforme la dispute du chapitre 1 — livrer vite ou être stable ? — en arithmétique que les deux camps regardent ensemble. Relever le SLO à 99,99 % ferait l'inverse : il ne resterait que 4 minutes par mois, ce qui interdit presque tout changement et coûte un ordre de grandeur de plus, pour un bénéfice qu'aucun utilisateur ne perçoit. Un SLO à 100 % est un mauvais SLO.
La séance qui compte : casser la production
Tout ce chapitre s'apprend en une séance, et elle mérite d'être décrite parce qu'elle transforme une liste d'outils en réflexe.
On déploie volontairement une version défaillante. On laisse l'alerte se déclencher — et l'on mesure combien de temps elle a mis. On diagnostique par les journaux et les tableaux de bord, sans regarder le code fautif. On exécute le retour arrière du chapitre 6. Et l'on écrit un post-mortem, avec les cinq parties du chapitre 1.
Ce que la séance apprend et qu'aucun cours ne transmet : le temps réel entre la panne et l'alerte, celui entre l'alerte et le diagnostic, la sensation de chercher dans les journaux sous pression, et le soulagement d'avoir un retour arrière qui a déjà été testé.
C'est aussi la seule façon de vérifier que le dispositif fonctionne. Une alerte jamais déclenchée, un retour arrière jamais exécuté et un tableau de bord jamais consulté en incident ne sont pas des garanties : ce sont des hypothèses.
À vous
L'exercice calcule ce qui se discute habituellement à l'estime.
D'abord le budget d'erreur : à partir d'un journal d'incidents, vous calculerez la disponibilité réalisée, le budget consommé et ce qu'il reste — puis vous verrez ce que change un SLO à 99,99 % au lieu de 99,9 %.
Ensuite la qualité des alertes. Vous disposez d'un mois d'alertes, chacune étiquetée « vraie » ou « fausse », et vous mesurerez la précision — quelle part des alertes méritait une action — et le rappel — quelle part des vrais incidents a été détectée. Vous ajusterez le seuil et vous constaterez qu'on ne peut pas améliorer les deux à la fois.
Enfin, la chronologie d'un incident : détection, diagnostic, rétablissement. Vous calculerez le temps de rétablissement du chapitre 1, et vous verrez lequel des trois segments dominait — ce qui dit sur quoi travailler.
Exercice de code
Calculez un budget d'erreur, réglez un seuil d'alerte, puis trouvez le segment qui domine un incident.
Point de départ
// ── 1. Budget d'erreur ────────────────────────────────────────────────────
const MOIS_MINUTES = 30 * 24 * 60; // 43 200
const INCIDENTS = [
{ jour: 3, minutes: 4, cause: "déploiement défaillant, retour arrière" },
{ jour: 11, minutes: 2, cause: "sonde mal réglée, redémarrages" },
{ jour: 18, minutes: 22, cause: "panne du fournisseur de base" },
{ jour: 26, minutes: 6, cause: "migration bloquante" },
];
function budget(slo, incidents) {
const autorise = 0; // ← à écrire : (1 − slo) × minutes du mois
const consomme = 0; // ← à écrire
return { autorise, consomme, restant: autorise - consomme,
realise: 0 }; // ← disponibilité réellement atteinte
}
// ── 2. Qualité des alertes ────────────────────────────────────────────────
// Chaque alerte : la valeur mesurée, et s'il y avait VRAIMENT un problème.
const ALERTES = [
{ valeur: 2.4, vraiProbleme: true }, { valeur: 0.9, vraiProbleme: false },
{ valeur: 5.1, vraiProbleme: true }, { valeur: 1.2, vraiProbleme: false },
{ valeur: 3.8, vraiProbleme: true }, { valeur: 0.6, vraiProbleme: false },
{ valeur: 1.8, vraiProbleme: false }, { valeur: 4.2, vraiProbleme: true },
{ valeur: 1.1, vraiProbleme: true }, { valeur: 0.8, vraiProbleme: false },
{ valeur: 2.9, vraiProbleme: false }, { valeur: 6.0, vraiProbleme: true },
];
function qualite(seuil, alertes) {
// ← à écrire : précision = part des alertes qui méritaient une action ;
// rappel = part des vrais problèmes détectés.
return { declenchees: 0, precision: 0, rappel: 0 };
}
// ── 3. Chronologie d'un incident ──────────────────────────────────────────
const CHRONOLOGIE = {
panne: "10:04", // le déploiement défaillant part
alerte: "10:31", // quelqu'un est prévenu
diagnostic: "10:44", // la cause est comprise
retabli: "10:46", // le retour arrière est terminé
};
// ── À VOUS ────────────────────────────────────────────────────────────────
// 1. Écrivez budget(). Que reste-t-il à 99,9 % ? Et à 99,99 % ?
// 2. Écrivez qualite() et faites varier le seuil de 0,5 à 5. Peut-on
// améliorer précision ET rappel en même temps ?
// 3. Découpez la chronologie en trois segments. Lequel domine, et sur quoi
// faut-il donc travailler en priorité ?
console.log(JSON.stringify(budget(0.999, INCIDENTS)));
Solution
const MOIS_MINUTES = 30 * 24 * 60;
const INCIDENTS = [
{ jour: 3, minutes: 4, cause: "déploiement défaillant, retour arrière" },
{ jour: 11, minutes: 2, cause: "sonde mal réglée, redémarrages" },
{ jour: 18, minutes: 22, cause: "panne du fournisseur de base" },
{ jour: 26, minutes: 6, cause: "migration bloquante" },
];
function budget(slo, incidents) {
const autorise = (1 - slo) * MOIS_MINUTES;
const consomme = incidents.reduce((s, i) => s + i.minutes, 0);
return { autorise, consomme, restant: autorise - consomme,
realise: 1 - consomme / MOIS_MINUTES };
}
console.log("— 1. budget d'erreur —");
for (const slo of [0.99, 0.999, 0.9999]) {
const b = budget(slo, INCIDENTS);
console.log(" SLO " + (slo * 100).toFixed(2).padStart(6) + " % : " +
"budget " + b.autorise.toFixed(0).padStart(4) + " min | consommé " +
b.consomme + " min | restant " + b.restant.toFixed(0).padStart(5) + " min" +
(b.restant < 0 ? " BUDGET ÉPUISÉ : gel des changements risqués" : " on peut déployer"));
}
console.log(" disponibilité réellement atteinte : " +
(budget(0.999, INCIDENTS).realise * 100).toFixed(3) + " %");
console.log(" À 99,9 % il reste " + budget(0.999, INCIDENTS).restant.toFixed(0) +
" minutes : l'équipe est autorisée à prendre des risques.");
console.log(" À 99,99 % le budget est dépassé dès le premier incident : ce SLO");
console.log(" interdirait presque tout changement, pour un bénéfice qu'aucun");
console.log(" utilisateur ne perçoit. Un SLO trop élevé coûte plus qu'il ne rapporte.");
console.log("");
console.log("— 2. précision et rappel des alertes —");
const ALERTES = [
{ valeur: 2.4, vraiProbleme: true }, { valeur: 0.9, vraiProbleme: false },
{ valeur: 5.1, vraiProbleme: true }, { valeur: 1.2, vraiProbleme: false },
{ valeur: 3.8, vraiProbleme: true }, { valeur: 0.6, vraiProbleme: false },
{ valeur: 1.8, vraiProbleme: false }, { valeur: 4.2, vraiProbleme: true },
{ valeur: 1.1, vraiProbleme: true }, { valeur: 0.8, vraiProbleme: false },
{ valeur: 2.9, vraiProbleme: false }, { valeur: 6.0, vraiProbleme: true },
];
function qualite(seuil, alertes) {
const declenchees = alertes.filter((a) => a.valeur >= seuil);
const vraisPositifs = declenchees.filter((a) => a.vraiProbleme).length;
const totalVrais = alertes.filter((a) => a.vraiProbleme).length;
return {
declenchees: declenchees.length,
// Précision : parmi ce qui a sonné, quelle part méritait une action ?
precision: declenchees.length ? vraisPositifs / declenchees.length : 1,
// Rappel : parmi les vrais problèmes, quelle part a sonné ?
rappel: vraisPositifs / totalVrais,
};
}
console.log(" seuil | alertes | précision | rappel | lecture");
for (const seuil of [0.5, 1.0, 1.5, 2.0, 3.0, 4.0, 5.0]) {
const q = qualite(seuil, ALERTES);
const lecture = q.precision < 0.6 ? "bruyant : on apprend à ignorer"
: q.rappel < 0.6 ? "silencieux : des incidents passent"
: "acceptable";
console.log(" " + seuil.toFixed(1).padStart(5) + " | " + String(q.declenchees).padStart(7) +
" | " + (q.precision * 100).toFixed(0).padStart(8) + " %" +
" | " + (q.rappel * 100).toFixed(0).padStart(5) + " %" + " | " + lecture);
}
console.log(" Les deux ne s'améliorent pas ensemble : abaisser le seuil détecte");
console.log(" plus d'incidents ET plus de faux positifs. Un seuil trop bas produit");
console.log(" le bruit qui détruit le signal ; trop haut, il laisse passer. Le");
console.log(" réglage est une décision, pas un réglage par défaut.");
console.log("");
console.log("— 3. anatomie d'un incident —");
const minutes = (h) => { const [a, b] = h.split(":").map(Number); return a * 60 + b; };
const C = { panne: "10:04", alerte: "10:31", diagnostic: "10:44", retabli: "10:46" };
const segments = [
{ nom: "panne → alerte (détection)", d: minutes(C.alerte) - minutes(C.panne) },
{ nom: "alerte → diagnostic", d: minutes(C.diagnostic) - minutes(C.alerte) },
{ nom: "diagnostic → rétabli (action)", d: minutes(C.retabli) - minutes(C.diagnostic) },
];
const total = segments.reduce((s, x) => s + x.d, 0);
for (const s of segments) {
console.log(" " + s.nom.padEnd(32) + String(s.d).padStart(3) + " min " +
"█".repeat(s.d) + " " + Math.round((s.d / total) * 100) + " %");
}
console.log(" temps de rétablissement : " + total + " min");
const pire = segments.reduce((a, b) => (b.d > a.d ? b : a));
console.log(" Le segment dominant est « " + pire.nom + " » : c'est là qu'il faut");
console.log(" travailler. Améliorer le retour arrière — déjà à 2 minutes — ne");
console.log(" gagnerait presque rien ; abaisser le délai de DÉTECTION diviserait");
console.log(" le temps de rétablissement par deux. C'est exactement ce que le");
console.log(" canari du chapitre 6 attendait de ce chapitre.");
En travaux pratiques
Travaux pratiques 10 · 2 h
Casser la production
La séance qui transforme une liste d'outils en réflexe : instrumenter, déployer une version défaillante, laisser l'alerte partir, diagnostiquer, revenir en arrière, et écrire le compte rendu.
Avant de commencer
- Le déploiement du TP 9, qui tourne
- Prometheus et Grafana dans le cluster, ou en Compose à côté
- Une charge continue sur l'application (une boucle curl suffit)
Énoncé
- Exposer les métriques — Faites exposer par l'application un compteur de requêtes étiqueté par code de réponse, et un histogramme de latence. Vérifiez que Prometheus les récupère. Indice : Un compteur par code permet de calculer un TAUX d'erreur ; un compteur global ne le permet pas.
- Construire le tableau de bord minimal — Affichez les quatre signaux dorés : latence au 95e centile, trafic, taux d'erreur, saturation. Rien d'autre. Indice : Une moyenne de latence cache exactement ce qu'on cherche : surveillez des centiles.
- Fixer un SLO et calculer le budget — Choisissez un objectif de disponibilité sur trente jours, calculez le budget d'erreur correspondant en minutes, et affichez la part déjà consommée.
- Écrire une seule alerte — Une alerte, sur un symptôme, avec un seuil et une durée. Écrivez à côté, en une phrase, ce que fait la personne réveillée — si vous ne savez pas l'écrire, l'alerte n'est pas la bonne.
- Casser la production — Sans prévenir vos camarades, déployez une version qui échoue sur une part des requêtes. Notez l'heure exacte.
- Diagnostiquer — L'équipe d'astreinte — vos camarades — travaille SANS regarder le code déployé. Ils partent de l'alerte, passent au tableau de bord, puis aux journaux. Notez l'heure de l'alerte et celle du diagnostic.
- Revenir en arrière — Exécutez le retour arrière et notez l'heure de rétablissement. Vérifiez sur le tableau de bord que le taux d'erreur redescend.
- Écrire le post-mortem — Cinq parties, comme au TP 1. Calculez les trois segments — détection, diagnostic, action — et dites lequel domine votre temps de rétablissement. C'est celui-là qu'il faudra travailler.
C'est réussi quand
- L'alerte est partie sans intervention humaine
- Le diagnostic a été fait sans lire le code fautif
- Vous avez trois durées chiffrées, et vous savez laquelle réduire en priorité
- Le post-mortem ne nomme personne et ses actions ont une échéance
Correction
const requetes = new client.Counter({
name: "http_requetes_total",
help: "requêtes servies",
labelNames: ["route", "code"], // l'étiquette rend le taux calculable
});
const duree = new client.Histogram({
name: "http_duree_secondes",
help: "latence",
buckets: [0.05, 0.1, 0.3, 1, 3],
});Sans l'étiquette « code », on connaît le nombre de requêtes mais pas la part qui échoue — et c'est précisément ce dont l'alerte a besoin. Un histogramme, lui, permet de calculer des centiles ; une simple moyenne ne le permet pas.
SLO 99,9 % sur 30 jours budget = 0,1 % × 43 200 min = 43,2 min incident de ce TP : 42 min d'erreurs à 30 % consommation ≈ 42 × 0,30 = 12,6 min → 29 % du budget mensuel
Le budget se raisonne en minutes d'indisponibilité ÉQUIVALENTES, pondérées par la part du trafic touchée. Un incident qui consomme un tiers du budget mensuel n'interdit rien ; trois de suite gèlent les changements risqués. C'est ce qui transforme la dispute « vite ou stable » en arithmétique.
- alert: TauxErreurEleve
expr: |
sum(rate(http_requetes_total{code=~"5.."}[5m]))
/ sum(rate(http_requetes_total[5m])) > 0.02
for: 2m
annotations:
resume: "taux d'erreur au-dessus de 2 % depuis 2 minutes"
action: |
1. tableau de bord : la hausse suit-elle un déploiement ?
2. si oui : kubectl rollout undo deployment/tickets
3. sinon : journaux du service, filtrer sur code 5xxTrois choses en font une bonne alerte. Elle porte sur un SYMPTÔME que les utilisateurs subissent, pas sur une cause comme l'usage processeur. Elle a une DURÉE (for: 2m), qui évite de réveiller quelqu'un pour un pic de dix secondes. Et elle est ACTIONNABLE : l'annotation dit quoi faire. Une alerte dont on ne sait pas écrire l'action est un graphique, pas une alerte.
10:04 déploiement de la version fautive
10:31 alerte reçue → détection 27 min
10:44 cause identifiée → diagnostic 13 min
10:46 retour arrière fini → action 2 min
total 42 minLa DÉTECTION domine largement, et c'est le cas le plus fréquent en TP comme en production. Améliorer le retour arrière — déjà à deux minutes — ne gagnerait rien ; abaisser le seuil et la durée de l'alerte, ou surveiller pendant le déploiement, diviserait le total par deux. C'est aussi ce qui manquait au canari du TP 6 pour décider tout seul.
Le temps réel entre la panne et l'alerte. La sensation de chercher dans des journaux sous pression. Et le soulagement d'exécuter un retour arrière qui a DÉJÀ été testé. C'est aussi la seule façon de vérifier que le dispositif fonctionne : une alerte jamais déclenchée, un retour arrière jamais exécuté et un tableau de bord jamais consulté en incident ne sont pas des garanties, ce sont des hypothèses.
Ce que la suite en fait
Le chapitre 11 clôt le semestre en ajoutant la sécurité au flux plutôt qu'à sa fin. La logique sera la même que dans ce chapitre : mesurer, alerter sur ce qui compte, et éviter le bruit — un analyseur de vulnérabilités qui signale trois cents alertes non exploitables sera désactivé exactement comme une alerte trop bavarde.
À retenir
Flashcards · 5 cartes
- Quels sont les trois piliers, et à quelle question répond chacun ?
- MÉTRIQUES : nombres agrégés, faible coût, disent QUE quelque chose va mal — elles alertent. JOURNAUX : événements discrets horodatés, disent QUOI exactement. TRACES : trajet d'une requête entre services, disent OÙ dans la chaîne. L'ordre est celui du diagnostic, et les trois ne se remplacent pas : chercher une tendance en lisant des journaux ne marche pas, un journal répond mal à « combien » et « depuis quand ».
- Quels sont les quatre signaux dorés, et pourquoi ne surveille-t-on pas une moyenne de latence ?
- LATENCE, TRAFIC, ERREURS, SATURATION. Une latence MOYENNE de 200 ms peut cacher 95 % des requêtes à 50 ms et 5 % à plusieurs secondes : on surveille des CENTILES — 95e, 99e — parce que ce sont eux que les utilisateurs subissent, et parce qu'ils bougent bien avant la moyenne. À noter aussi : le modèle par interrogation de Prometheus rend l'ABSENCE de réponse informative.
- Quelles sont les deux règles sur les journaux, et les deux mises en garde ?
- 1) ILS QUITTENT LA MACHINE : une machine qui tombe emporte ses fichiers, un conteneur détruit aussi, et chercher dans vingt endroits est impraticable. 2) ILS SONT STRUCTURÉS : des champs se filtrent, une ligne libre se cherche mal — et un identifiant de trace relie les enregistrements d'une même requête à travers les services. MISES EN GARDE : ils COÛTENT (stockage, indexation, bande passante — le niveau debug en production peut coûter plus que le service), et ils contiennent des DONNÉES PERSONNELLES.
- Quelles sont les trois règles d'une bonne alerte ?
- 1) ALERTER SUR LES SYMPTÔMES, pas les causes : « le taux d'erreur dépasse 2 % » concerne les utilisateurs, « le processeur est à 80 % » ne concerne personne si le service répond. 2) TOUTE ALERTE DOIT ÊTRE ACTIONNABLE : que fait la personne réveillée ? Sans réponse précise, c'est un tableau de bord. 3) DISTINGUER ce qui réveille de ce qui attend un ticket. Sinon l'équipe apprend à ignorer les alertes, et le bruit ne fait pas perdre du temps : il DÉTRUIT LE SIGNAL.
- Qu'est-ce qu'un budget d'erreur, et quel débat règle-t-il ?
- Le complément du SLO : 100 % − 99,9 % = 0,1 %, soit 43 minutes sur trente jours. C'est une RESSOURCE À DÉPENSER, pas une tolérance honteuse : tant qu'il en reste, on déploie vite et l'on prend des risques ; épuisé, on gèle les changements risqués pour travailler la fiabilité. Il transforme la dispute « vite ou stable ? » en arithmétique que les deux camps regardent ensemble. Et un SLO à 100 % est un mauvais SLO : il interdit tout changement pour un bénéfice imperceptible.