Aller au contenu principal
sfiSuperviser un système : lois continues et détection d'anomalies

Superviser un système : lois continues et détection d'anomalies

Ce que ce chapitre apporte

  • Rappeler comment un système d'exploitation gère les processus et la mémoire.
  • Interpréter les métriques classiques de supervision et leur mode d'échantillonnage.
  • Reconnaître les lois continues usuelles : normale, log-normale, exponentielle, Weibull.
  • Vérifier graphiquement et par un test qu'une série suit une loi donnée.
  • Détecter des anomalies par z-score, écart interquartile et statistiques robustes.
  • Choisir un seuil de vigilance en connaissant son taux de fausses alertes.
Où on va
Emma commence son stage chez OPTIMAL. On lui confie un fichier : une semaine de mesures relevées chaque minute sur des serveurs, charge processeur, mémoire, trafic réseau, température. Sa mission n'est pas de calculer une moyenne, c'est de déclencher la bonne alerte au bon moment. Ce chapitre suit ce trajet : comprendre ce que mesurent ces métriques, reconnaître la loi que suit chacune, et poser des seuils qui ne noient pas l'équipe sous les fausses alertes.

Ce que mesure la supervision

Superviser, c'est observer un système en fonctionnement pour décider s'il faut intervenir. Encore faut-il savoir ce que les chiffres décrivent.

Processus et ordonnancement

Le système d'exploitation gère le matériel et arbitre entre les programmes. Un processus est un programme en cours d'exécution, avec sa mémoire propre et son état ; l'ordonnanceur (scheduler) répartit le temps de processeur entre les processus prêts, en leur accordant des tranches de quelques millisecondes.

Ce que « 100 % de CPU » veut dire

La charge processeur est la proportion de temps pendant laquelle le processeur n'était pas inactif, sur l'intervalle de mesure. À 100 % il travaille sans interruption : ce n'est pas une panne, c'est un processeur utilisé. Le signal d'alerte est ailleurs : dans la file d'attente des processus prêts, qui dit combien de tâches attendent leur tour.

Une moyenne de charge cache le régime
Un processeur à 50 % en moyenne sur une minute peut avoir passé trente secondes à 100 % et trente à 0 %. Pour un utilisateur, ces deux situations n'ont rien à voir : la seconde donne des à-coups perceptibles. C'est pourquoi on relève une mesure par minute, et pas une moyenne horaire.

Mémoire

La mémoire physique (RAM) est découpée en pages de taille fixe. Chaque processus voit un espace d'adressage virtuel continu, que la table des pages traduit en adresses physiques : c'est ce qui permet l'isolation entre processus et l'illusion d'une mémoire plus grande que la RAM.

Quand la RAM manque, le système écrit des pages inutilisées sur disque, le swap. Un accès disque étant des milliers de fois plus lent qu'un accès RAM, un système qui swappe activement s'effondre en performance.

La métrique mémoire à surveiller n'est pas celle qu'on croit
Une mémoire « utilisée à 95 % » est normale : le système garde en cache tout ce qu'il peut, et libère à la demande. Ce qui compte, c'est la mémoire disponible, et surtout l'activité de swap. Un serveur en swap soutenu est en train de mourir, même si sa charge CPU paraît saine.

Une série temporelle

Chaque métrique relevée à intervalle régulier forme une série temporelle. Elle se distingue d'une série statistique ordinaire sur deux points : les observations sont ordonnées, et elles ne sont pas indépendantes, la charge de cette minute ressemble à celle de la précédente.

La conséquence, immédiate
Tous les indicateurs du chapitre 3 restent calculables, mais ils ignorent le temps. Une moyenne journalière écrase la différence entre le jour et la nuit ; un histogramme de la charge sur 24 heures mélange deux régimes distincts. Trace la série dans le temps avant de la résumer : c'est le même réflexe que le nuage de points, appliqué à un axe différent.

Variables aléatoires continues

Quand la grandeur mesurée peut prendre n'importe quelle valeur d'un intervalle (une température, une durée, un débit) on ne peut plus lister les P(X=x)P(X = x) : elles valent toutes zéro.

Définition

Une variable aléatoire continue est décrite par sa densité de probabilité ff, une fonction positive d'aire totale 1. La probabilité se lit comme une aire :

P(a ≤ X ≤ b) = ∫ₐᵇ f(x) dx

La fonction de répartition F(x)=P(Xx)F(x) = P(X \leq x) est la primitive de la densité qui s'annule en -\infty.

Une densité n'est pas une probabilité
C'est le contresens le plus fréquent du passage au continu. La valeur $f(x)$ n'est pas la probabilité d'obtenir $x$ : cette probabilité vaut zéro, puisqu'il y a une infinité de valeurs possibles.
Conséquence qui déroute : $f(x)$ peut dépasser 1 sans rien casser. Une loi uniforme sur $[0 ; 0{,}1]$ a une densité constante égale à 10, et c'est parfaitement correct : ce qui doit valoir 1, c'est l'aire sous la courbe, pas sa hauteur.
Ce qui a un sens, c'est toujours une probabilité d'intervalle : $P(a < X < b)$, l'aire entre $a$ et $b$. D'où l'usage de la fonction de répartition $F$, qui donne directement $P(X \leq x)$, et le calcul $P(a < X < b) = F(b) - F(a)$.

Les quatre lois continues à connaître

Loi normale N(μ,σ2)N(\mu , \sigma ^2)

La courbe en cloche, symétrique autour de μ\mu. Elle apparaît dès qu'une grandeur est la somme de nombreux petits effets indépendants, c'est le théorème central limite. Une température de salle machine, un bruit de mesure : normal.

La règle des trois sigmas
68 % des valeurs dans [μ − σ, μ + σ], 95 % dans [μ − 2σ, μ + 2σ], 99,7 % dans [μ − 3σ, μ + 3σ]. C'est de là que sortent tous les seuils « à 3 sigmas » de la supervision, et c'est valable uniquement si la série est normale.

Loi log-normale

XX est log-normale si ln(X)\ln(X) est normale. Densité asymétrique, étalée à droite, définie sur les valeurs positives. Elle apparaît quand une grandeur est le produit de nombreux facteurs : temps de réponse, taille de fichiers, durée d'une requête qui traverse plusieurs couches.

C'est la loi des temps de réponse, et ça change tout
Sur une série log-normale, moyenne et médiane diffèrent nettement, et un seuil « moyenne + 3σ » place la limite bien au-delà du maximum observé : il ne se déclenchera jamais. C'est l'erreur la plus courante de la supervision, appliquer une règle normale à une grandeur qui ne l'est pas.

Loi exponentielle E(λ)E(\lambda )

Densité f(x)=λe(λx)f(x) = \lambda e^(-\lambda x) sur les réels positifs, d'espérance 1/λ1/\lambda. C'est la loi des durées entre deux événements quand ces événements arrivent au hasard à taux constant, le pendant continu de la loi de Poisson.

Sa propriété caractéristique est l'absence de mémoire : P(X>s+tX>s)=P(X>t)P(X > s + t | X > s) = P(X > t). Un composant qui a déjà tenu mille heures n'est ni plus ni moins susceptible de tomber en panne dans l'heure suivante qu'un composant neuf. C'est un modèle de panne accidentelle, pas d'usure.

Loi de Weibull

Elle généralise l'exponentielle en ajoutant un paramètre de forme kk, ce qui lui permet de représenter l'usure :

  • k<1k < 1 : taux de panne décroissant, mortalité infantile, les défauts de fabrication se révèlent tôt ;
  • k=1k = 1 : taux constant, c'est exactement l'exponentielle ;
  • k>1k > 1 : taux croissant, usure, la panne devient plus probable avec l'âge.

C'est la loi de référence en fiabilité, et celle qui décrit correctement la durée de vie d'un disque dur.

Reconnaître la loi d'après la question
Somme de petits effets → normale. Produit de facteurs, série étalée à droite → log-normale. Durée entre événements à taux constant → exponentielle. Durée de vie avec usure → Weibull.

Vérifier la loi d'une série

Supposer une loi sans la vérifier est la fausse piste la plus coûteuse : tout ce qui suit en dépend. La vérification se fait en trois temps, du moins au plus formel.

L'histogramme avec la densité théorique superposée : c'est grossier mais cela élimine les erreurs grossières, qui sont les plus fréquentes.

Le diagramme quantile-quantile (QQ-plot) : on trace les quantiles observés contre les quantiles théoriques. Si la loi est la bonne, les points s'alignent sur la première bissectrice. Les écarts aux extrémités se lisent immédiatement, et ce sont justement les extrémités qui décident des seuils d'alerte.

Le test de Kolmogorov-Smirnov : il mesure l'écart maximal entre la fonction de répartition empirique et la théorique, et en tire une pp-valeur. Une pp-valeur inférieure à 0,05 conduit à rejeter l'hypothèse que la série suit la loi testée.

Le test de Kolmogorov-Smirnov a deux limites qu'on tait souvent
1. Si tu estimes μ et σ sur les données mêmes, la p-valeur du test est faussée dans le sens optimiste : le test accepte trop facilement. La correction s'appelle le test de Lilliefors.
2. Sur un grand échantillon, le test rejette tout. Avec 10 000 points, le moindre écart devient significatif, or aucune série réelle ne suit exactement une loi théorique. Une p-valeur minuscule sur 10 000 mesures ne dit pas que le modèle est inutilisable, elle dit que l'échantillon est grand.

Le code ci-dessous fabrique une journée de supervision (1 440 mesures à la minute) et confronte deux métriques à la loi normale.

main.py
Sortie
>_ Prêt à exécuter…

L'asymétrie (skewness) est le premier signal : proche de 0 pour la température, franchement positive pour la latence. Voici les mêmes séries en images.

main.py
Sortie
>_ Prêt à exécuter…

Le QQ-plot de la température suit la droite ; celui de la latence s'en écarte nettement dans le haut. C'est exactement la zone qui décide des alertes.

Vérification rapidesans note, on peut se reprendre

1.Le z-score classique repose sur la moyenne et l'écart-type. Son défaut ?

2.Avant d'appliquer une règle à trois sigmas, il faut…

3.Un temps de réponse est souvent mieux décrit par…

Détecter une anomalie

Une anomalie est une observation qui s'écarte assez du comportement habituel pour mériter un regard. Le bloc s'en tient à des méthodes fondées sur des statistiques classiques (pas d'apprentissage automatique) et c'est amplement suffisant.

Le z-score

Définition

z=(xxˉ)/σz = (x - \bar{x}) / \sigma mesure l'écart d'une valeur à la moyenne, en nombre d'écarts-types. On signale généralement z>3|z| > 3.

Le z-score se sabote lui-même
Deux défauts, et ils vont ensemble. D'abord il suppose la normalité : sur une série log-normale, le seuil « moyenne + 3σ » peut dépasser le maximum observé, et l'alerte ne part jamais.
Ensuite, moyenne et écart-type sont calculés en incluant les anomalies. Une valeur extrême gonfle σ, donc réduit son propre z-score : c'est l'effet de masquage. Plus l'anomalie est grosse, moins elle est détectable.

L'écart interquartile

On signale les valeurs hors de [Q₁ − 1,5 IQR ; Q₃ + 1,5 IQR], la règle de la boîte à moustaches. Quartiles et IQR étant robustes, quelques valeurs extrêmes ne les déplacent pas : pas d'effet de masquage. Et la méthode ne suppose aucune loi.

Le z-score robuste

On remplace moyenne et écart-type par leurs équivalents robustes. L'écart absolu médian est MAD = médiane(|xᵢ − médiane(x)|), et :

z_robuste = 0,6745 × (x − médiane) / MAD

Le facteur 0,6745 ramène l'échelle du MAD à celle d'un écart-type sur une loi normale, de sorte que le seuil de 3 garde le même sens qu'avec le z-score classique.

Le pourcentage du maximum

« Alerte au-delà de 90 % du maximum observé » : simple, immédiat, et sans aucune propriété. Le maximum est la statistique la moins robuste qui soit, il est déterminé par une seule valeur, souvent celle dont on doute le plus. À citer, à ne pas utiliser seul.

main.py
Sortie
>_ Prêt à exécuter…
Ce que la comparaison montre
Les trois incidents sont réels et massifs, et pourtant les seuils diffèrent de plusieurs points de charge. Le z-score classique place sa limite le plus haut, parce que les incidents ont eux-mêmes gonflé l'écart-type. Les méthodes robustes, qui les ignorent dans le calcul du seuil, les repèrent plus franchement, au prix de quelques signalements supplémentaires.
Il n'y a pas de méthode gagnante dans l'absolu : il y a un arbitrage entre incidents manqués et fausses alertes, et c'est à l'exploitant de le trancher.

Régler un seuil de vigilance

Un seuil produit deux types d'erreurs : les faux négatifs (incidents manqués) et les faux positifs (fausses alertes). Les baisser tous les deux en même temps est impossible : durcir le seuil réduit les fausses alertes et augmente les incidents manqués.

Le calcul que personne ne fait, et qui décide de tout
Un seuil à 3 sigmas sur une série normale laisse passer 0,3 % des mesures normales. Sur un relevé à la minute, cela fait 0,003 × 1440 ≈ 4 fausses alertes par jour et par métrique. Avec quatre métriques et vingt serveurs, on atteint 350 alertes quotidiennes, dont presque aucune ne correspond à un incident.
C'est le résultat de Bayes du chapitre 2, sous sa forme opérationnelle : une équipe noyée sous les fausses alertes finit par toutes les ignorer, y compris la vraie.

Trois leviers, dans l'ordre où on les emploie :

  1. Exiger une persistance : alerter seulement si le seuil est dépassé pendant kk minutes consécutives. Un pic isolé disparaît, une dérive réelle passe. C'est le levier le plus efficace et le moins coûteux.
  2. Corréler plusieurs métriques : CPU et latence simultanément. La probabilité que deux signaux indépendants se déclenchent à tort en même temps est le produit des deux, bien plus petite.
  3. Choisir le seuil selon le coût : manquer une surchauffe coûte un serveur, manquer un pic de trafic coûte quelques secondes de lenteur. Les deux ne méritent pas le même réglage.
main.py
Sortie
>_ Prêt à exécuter…
Le seuil calculé sur 24 heures rate un tiers de l'incident
La journée mélange deux régimes, une nuit à 30 % et un plateau diurne à 57 %. Ce mélange gonfle l'écart interquartile, donc pousse le seuil à 86 % : seules les dix minutes les plus violentes de l'incident sont vues. Le même calcul mené sur les seules heures ouvrées descend le seuil à 75 % et détecte les quinze minutes.
Même série, même méthode, même règle. Ce qui change, c'est qu'on a d'abord séparé les régimes. C'est le conseil qui paraissait théorique au début du chapitre, et qui coûte ici cinq minutes d'incident non vues.

Exercices type

Une série de latences a pour moyenne 45 ms et pour médiane 28 ms. Que peut-on en déduire ?

La moyenne est très supérieure à la médiane : la distribution est fortement asymétrique à droite. Quelques requêtes très lentes tirent la moyenne, tandis que la majorité se situe autour de 28 ms.

C'est la signature d'une loi log-normale, typique des temps de réponse.

Conséquence pratique : n'utilise pas de z-score sur cette série. Travaille sur ln(latence), ou passe par des quantiles, c'est la raison d'être des p95p95 et p99p99 en supervision applicative.

Sur 1 440 mesures normales par jour, combien de fausses alertes produit un seuil à 2 sigmas ? à 3 sigmas ?

À 2 sigmas : 4,6 % des mesures sortent de l'intervalle, soit 0,046×14400{,}046 \times 1440 \approx 66 fausses alertes par jour. Inexploitable.

À 3 sigmas : 0,27 %, soit 0,0027×14400{,}0027 \times 1440 \approx 4 par jour. Acceptable pour une métrique, déjà lourd pour dix.

Et ce calcul suppose la série normale et les mesures indépendantes, deux hypothèses fausses sur une série temporelle, où les valeurs successives se ressemblent. En pratique, les fausses alertes arrivent groupées, ce qui est à la fois plus visible et plus facile à filtrer par une règle de persistance.

Pourquoi le z-score détecte-t-il mal une anomalie très grande ?

Parce que la valeur extrême entre dans le calcul de la moyenne et de l'écart-type qui servent à la juger, c'est l'effet de masquage.

Une seule valeur énorme fait exploser σ\sigma, ce qui abaisse mécaniquement son propre z-score, et peut le ramener sous le seuil de 3. Plus l'anomalie est grosse, moins elle est détectable : exactement le contraire de ce qu'on veut.

Les méthodes robustes (IQR, MAD) n'ont pas ce défaut : médiane et quartiles ne bougent pas quand quelques points s'envolent.

Un disque a une durée de vie suivant une loi de Weibull de paramètre $k = 2{,}5$. Que faut-il en conclure pour la maintenance ?

k>1k > 1 signifie un taux de panne croissant avec l'âge : c'est un phénomène d'usure, pas d'accident.

Conséquence directe : la maintenance préventive a du sens. Remplacer les disques au-delà d'un certain âge réduit réellement le taux de panne, et l'âge est un bon prédicteur.

Contraste utile : si k=1k = 1 (exponentielle, sans mémoire), remplacer un composant ancien par un neuf ne changerait rien au risque de panne du mois suivant. La politique de maintenance découle directement de la forme de la loi.

Le test de Kolmogorov-Smirnov donne $p = 0{,}001$ sur 10 000 mesures de température. Faut-il abandonner le modèle normal ?

Pas nécessairement. Sur un échantillon de cette taille, le test détecte des écarts infimes : aucune série physique réelle ne suit exactement une loi théorique, et le test finit toujours par le voir.

La question utile n'est pas « la loi est-elle exacte ? » mais « l'écart est-il gênant pour ce que j'en fais ? ». Si tu poses un seuil à 3 sigmas, ce qui compte est la qualité de l'ajustement dans la queue de distribution, et cela se lit sur un QQ-plot, pas sur une pp-valeur.

Regarde donc l'ampleur de l'écart (la statistique DD du test) plutôt que sa significativité.

Deux serveurs ont la même charge CPU moyenne de 55 %. Comment savoir lequel est en difficulté ?

La moyenne ne peut pas répondre. Il faut :

  1. La dispersion : un serveur régulier à 55 % et un autre alternant 10 % et 100 % n'ont pas le même comportement. Écart-type et IQR les séparent.
  2. La série temporelle : le second est-il saturé pendant les heures ouvrées et inactif la nuit (auquel cas c'est normal) ou ses pics sont-ils erratiques ?
  3. Les quantiles hauts : p95p95 et p99p99 disent la charge dans les pires moments, qui est ce que ressentent les utilisateurs.
  4. Les métriques corrélées : mémoire, activité de swap, latence. Un CPU à 55 % avec du swap soutenu est un serveur en difficulté ; à 55 % sans swap, c'est un serveur qui travaille.

La méthode

  1. Trace la série dans le temps avant tout. Les régimes jour/nuit et les incidents s'y voient à l'œil nu.
  2. Sépare les régimes s'il y en a plusieurs. Un indicateur global sur deux populations mélangées ne décrit ni l'une ni l'autre.
  3. Identifie la loi : histogramme, puis QQ-plot, puis test, dans cet ordre, du plus parlant au plus formel.
  4. N'applique jamais un raisonnement en sigmas à une série que tu n'as pas vérifiée normale.
  5. Compare au moins deux méthodes de détection, et donne les seuils qu'elles produisent.
  6. Chiffre le taux de fausses alertes attendu par jour. C'est ce nombre qui rend un seuil acceptable ou non.
  7. Ajoute une règle de persistance avant de durcir un seuil : c'est plus efficace et cela ne coûte pas de sensibilité.
  8. Conclus par une recommandation actionnable : quel seuil, sur quelle métrique, avec quelle durée, et pourquoi.

En résumé

  • La charge CPU est une proportion de temps ; ce qui alerte, c'est la file d'attente. La mémoire s'apprécie par le disponible et le swap, pas par l'utilisé.
  • Une série temporelle est ordonnée et auto-corrélée : trace-la avant de la résumer.
  • Une loi continue se décrit par sa densité ; la probabilité est une aire.
  • Normale = somme d'effets. Log-normale = produit d'effets, temps de réponse. Exponentielle = durées entre événements, sans mémoire. Weibull = durées de vie, k>1k > 1 pour l'usure.
  • Règle des trois sigmas : 68/95/99,768 / 95 / 99{,}7 %, valable uniquement sur une série normale.
  • Vérifier la loi : histogramme → QQ-plot → Kolmogorov-Smirnov. Le test rejette tout sur un grand échantillon.
  • z-score : simple, suppose la normalité, souffre de l'effet de masquage.
  • IQR et z robuste (MAD) : sans hypothèse de loi, insensibles aux valeurs extrêmes.
  • Le pourcentage du maximum n'a aucune propriété : à citer, pas à utiliser.
  • Un seuil à 3 sigmas produit ~4 fausses alertes par jour et par métrique sur un relevé à la minute.
  • Persistance puis corrélation de métriques avant de durcir un seuil.

Et ensuite ? On vient de superviser un système existant. Le chapitre suivant change d'échelle et regarde le logiciel lui-même : les grandes façons de le structurer, avec les paradigmes de programmation.

Superviser un système : lois continues et détection d'anomalies | Plateforme ETS