Triez un incident de production frais en 5 minutes
Quand l'utiliser : PagerDuty vient de vous réveiller. Sentry dit que les erreurs augmentent. Vous devez savoir quoi, pourquoi, et s'il faut revenir en arrière — rapidement.
Prérequis
- Slug org Sentry + slug projet — Regardez n'importe quelle URL Sentry : sentry.io/organizations/<ORG>/issues/?project=<ID>
- Token d'authentification utilisateur Sentry avec
event:readetproject:read— sentry.io/settings/account/api/auth-tokens/
Déroulement
-
Trouvez le problème NOUVEAU le plus important de la dernière heureQuel est le problème nouveau le plus important de notre projet
web-prodde la dernière heure, classé par nombre d'événements ?✓ Copié→ Un seul issue avec titre, nombre d'événements, utilisateurs affectés, timestamp d'apparition -
Récupérez l'événement le plus récent avec stacktrace complète + breadcrumbsObtenez l'événement le plus récent pour ce problème. Montrez-moi la stacktrace, la release, et les 5 derniers breadcrumbs avant le crash.✓ Copié→ File:line de la fonction qui lance l'exception + séquence des actions utilisateur avant l'erreur
-
Identifiez la release qui a introduit le problèmeCe problème a-t-il été vu pour la première fois dans la même release qu'il est apparu, ou a-t-il été reporté ? Comparez le tag de release.✓ Copié→ Oui/non avec confiance — oriente la décision de revert
Résultat : Un résumé d'incident en 3 lignes que vous pouvez coller dans Slack : qu'est-ce qui est cassé, qui est affecté, quelle release l'a causé, action recommandée.
Pièges
- Si vos tags de release ne sont pas configurés, vous ne pouvez pas savoir quel déploiement a introduit le bug — Configurez
sentry-cli releasesdans votre CI avant de vous fier à cela — sans cela, vous devinez - La stacktrace est en JS minifié et illisible — Vérifiez que les sourcemaps sont téléchargées —
sentry-cli sourcemaps uploaddevrait être dans votre pipeline de construction