PathruleVérification et cycle de vie
Comment Pathrule Signals regroupe les événements, ce que signifient chaque statut de groupe et chaque état de vérification, les preuves qu'exige un correctif pour être vérifié, et la durée de conservation des groupes en local.
Sur cette page
Signals distingue deux questions : ce qui se reproduit, et si un correctif a réellement tenu. Le regroupement répond à la première, la vérification à la seconde, et seules des preuves issues de l'exécution peuvent répondre à la seconde.
Groupes
Chaque événement appartient à un groupe, défini par environnement, type (error ou event) et empreinte. L'empreinte est calculée à partir du libellé, du flux et du chemin de code de l'événement : une même défaillance au même endroit forme donc un seul groupe, quelle que soit sa fréquence, tandis qu'une même erreur en production et en preview reste séparée. Chaque enveloppe porte un identifiant qui reste identique à chaque nouvel envoi, si bien qu'une enveloppe renvoyée n'est stockée qu'une fois.
Statut et vérification
Un groupe a un statut :
active: il se produit, ou il est revenu.declared: un point d'instrumentation a été annoncé, mais rien n'a encore été remonté.resolved: la vérification a prouvé que le correctif a tenu.archived: il est devenu silencieux et a été clos. Archivé ne veut pas dire résolu.
Et un état de vérification :
| État | Signification |
|---|---|
unobserved | Aucun correctif enregistré, ou aucune version plus récente observée pour l'instant. |
observing | Une version plus récente est en cours d'exécution et des preuves sont en cours de collecte. |
quiet | 24 heures et au moins 3 enveloppes de la version plus récente sans récurrence. C'est le meilleur état que puisse atteindre un groupe sans flux. |
verified | Le correctif a tenu : les preuves décrites ci-dessous sont réunies. Le groupe passe à resolved. |
recurred | Il s'est reproduit dans une version plus récente. Le groupe est de nouveau active. |
Ce qui compte comme preuve
Un correctif est vérifié lorsque les trois conditions suivantes sont remplies pour une version plus récente que celle sur laquelle le correctif a été enregistré :
- au moins 60 minutes d'observation,
- au moins 3 enveloppes provenant de cette version plus récente,
- au moins 3 succès du flux propre au groupe, remontés avec
meta.outcome: "success".
Certains éléments ne comptent jamais : la version de référence, les événements sans identité de version, et tout ce qui a été observé avant l'enregistrement du correctif. Une version plus récente fait repartir l'observation de zéro. Si la version plus récente reste silencieuse pendant 45 minutes, un état quiet devient obsolète. Sans identité de version, la vérification est bloquée et le SDK remonte no_release.
Enregistrer un correctif
Lorsque vous ou votre agent corrigez quelque chose, le correctif est enregistré sur le groupe (voir l'intégration avec les agents). L'enregistrement est une affirmation, pas une preuve : à lui seul, il ne fait rien passer à resolved. Seule la vérification le fait. Il n'existe pas de résolution manuelle, et toute occurrence dans une version plus récente, même après verified, fait passer le groupe à recurred et le remet à active.
Conservation dans Pathrule Local
- Jusqu'à 5 000 groupes par espace de travail.
- Un groupe non résolu expire après 14 jours sans occurrence en production, 7 jours en développement ou en preview, et 30 jours pour une déclaration.
- Les groupes résolus et leur historique sont conservés 90 jours.
- Les identifiants d'enveloppe sont mémorisés pendant 2 jours, ce qui permet de renvoyer des enveloppes sans risque.
La conservation dans le Cloud est décrite sur la page Cloud Signals.