Problèmes et regroupement

1Comment l'empreinte est calculée

Si le SDK envoie un tableau fingerprint, il l'emporte. Sinon, Blipit hache le type d'exception plus les cinq dernières frames applicatives de la stack trace (nom de fichier et fonction). Sans frames applicatives, il utilise le type d'exception et le message avec les nombres, adresses hexadécimales et UUID remplacés, de sorte que « order 4821 not found » et « order 9 not found » sont regroupés. Les événements sans exception sont regroupés par message normalisé.

2Modifier le regroupement avec des règles

Ouvrez la page du projet et ajoutez une règle de regroupement. Les règles s'exécutent dans l'ordre et la première correspondance l'emporte. Une règle porte sur : type d'exception égal à, regex sur le message, nom de fichier ou fonction de la frame contenant, ou tag égal à. Regrouper met chaque événement correspondant dans un seul problème ; Ignorer écarte l'événement avant stockage. Les règles prennent jusqu'à une minute pour s'appliquer. Les regex sont limitées à 200 caractères, doivent compiler, et ne peuvent utiliser ni références arrière, ni lookarounds, ni répétitions imbriquées comme (a+)+.

3Résoudre, ignorer, rouvrir

Un problème est non résolu, résolu ou ignoré. Résolvez-le quand vous livrez un correctif : si l'erreur revient, le problème se rouvre en régression et vous êtes alerté. Le problème indique s'il est revenu dans la même release (le correctif n'a jamais été livré) ou dans une release ultérieure (quelque chose l'a réintroduit). Ignorer continue de compter les événements mais arrête les alertes. Rouvrir le remet en non résolu. La liste Problèmes propose des actions groupées, et les e-mails d'alerte contiennent des liens Résoudre et Ignorer qui demandent confirmation et fonctionnent une fois.

4Mettre en pause

Depuis la page du problème, mettez en pause pour 1 heure, 24 heures, 7 jours, ou les 100 ou 1 000 prochaines occurrences. Les événements sont toujours enregistrés et comptés ; les alertes de nouveau problème et de régression sont ignorées jusqu'à la fin de la pause. Les alertes de sécurité ne sont pas affectées.

Bon à savoir

• Blipit conserve la charge utile complète du premier événement d'un problème, de chaque régression, de chaque événement de sécurité et des 20 premiers événements de chaque heure UTC. Les autres événements stockent un résumé (id, heure, plateforme, niveau, release, environnement, tags, id utilisateur, SDK). La page du problème indique « Détails complets affichés pour N des M événements » ; la stack trace, les breadcrumbs et la correction par IA lisent la dernière charge utile complète.
• Au-delà du plafond mensuel d'événements de votre plan, 1 événement sur 10 est conservé et les autres sont comptés comme échantillonnés ; rien n'est facturé. La page Consommation affiche le nombre échantillonné.
• Les alertes sont plafonnées à 30 alertes de nouveau problème ou de régression par projet et par heure, pour qu'une tempête d'erreurs ne puisse pas inonder votre boîte mail.