Les incidents : remonter à ce qui a commencé
Mis à jour le
Ce qu’un incident raconte
La boîte de réception liste des faits. Un incident raconte une histoire : ce qui s’est ouvert, dans quel ordre, sur quelles cibles, et ce qui, très probablement, a tout déclenché.
Deux questions reviennent quand une alerte tombe :
- « Laquelle a commencé ? » Un disque qui sature rend un conteneur malade, qui fait échouer une sonde, qui remplit les journaux d’erreurs. Quatre alertes, un seul incident.
- « Ce plantage, c’est qui ? » Un crash ne frappe presque jamais tout le monde : il se concentre sur une version d’OS, un modèle d’appareil, une version de l’application.
Trois façons de constituer un incident
| Type | Ce qui est regroupé |
|---|---|
| Grappe serveur | Des anomalies de la même machine, proches dans le temps, portant sur le même service ou le même conteneur. |
| Faisceau de plantages | Des erreurs aux symptômes proches qui touchent la même population d’appareils. |
| Entre cibles | Un symptôme dans une application et une anomalie du serveur dont elle dépend, quand les deux se recouvrent dans le temps. |
Le troisième cas n’existe que si vous avez déclaré le lien entre les deux cibles (« hébergé sur », « dépend de »). Sans ce lien, le cockpit ne suppose rien.
La chronologie et la racine
Le détail d’un incident s’ouvre sur la chronologie. La première ligne porte la mention Racine : c’est le fait le plus ancien que rien n’explique dans la grappe. Les suivants indiquent en toutes lettres de quoi ils sont la conséquence probable.
La pastille de confiance dit ce que vaut cette désignation :
- Racine probable — un seul point de départ possible ;
- Racine plausible — deux candidates, l’ordre tranche ;
- À arbitrer — plusieurs départs possibles, votre jugement compte plus que le calcul.
Les faisceaux d’indices
Le tableau compare, pour chaque valeur remarquable, sa part dans l’incident à sa part dans une population de référence, et affiche l’écart en toutes lettres (« six fois plus »).
La population de référence n’est pas la même partout, et la colonne le dit :
- pour une version de l’application, ce sont les sessions mesurées — combien de sessions ont réellement tourné sur cette version ;
- pour les autres dimensions (modèle, version d’OS), c’est la distribution des plantages de la même cible, l’issue observée exclue. Cela répond à « ce plantage-là frappe-t-il Android 13 plus que les autres plantages de mon app ? », pas à « quelle part de mon parc est en Android 13 ? ».
Un effectif minimal est exigé avant toute affirmation : deux événements sur un modèle rare ne font pas un faisceau.
Vos trois gestes
- Confirmer la racine — vous avez vérifié sur la machine.
- Infirmer la racine — le calcul s’est trompé.
- Détacher un fait — ce lien-là n’a rien à faire dans cette histoire.
Ces gestes sont conservés. Le recalcul, qui tourne toutes les vingt minutes, met à jour la preuve et jamais votre verdict ; un fait détaché ne revient pas tout seul.
« Racines seulement »
Sur l’écran des anomalies, la case Racines seulement masque ce qu’une incident explique déjà comme conséquence. Une liste de quarante symptômes y devient trois incidents. Une anomalie qu’aucun incident ne couvre reste affichée : le filtre ne cache jamais ce qu’il ne comprend pas.
Depuis une alerte
Le bouton Incidentr, sur une anomalie de la boîte de réception, lance la recherche à la demande et ouvre l’incident correspondante. Si rien ne relie cette anomalie à d’autres faits, le cockpit le dit plutôt que d’ouvrir un écran vide.