SMF·SENTRY
Un prompt peut-il remplacer Sentry ?
Supervision et observabilité — error tracking
Bordereau de suivi des pièces
Verdict
Le point d’entrée qui reçoit une erreur, c’est un après-midi. Le produit, c’est le regroupement : transformer cent mille événements en une poignée de tickets, garder le même bug dans le même ticket à travers les releases, et remarquer quand un bug corrigé revient. C’est un week-end pour construire ça passablement et longtemps pour le construire aussi bien que Sentry, ce qui en fait un « en partie » plutôt qu’un « oui » — et il existe un serveur open source compatible si tu préfères déployer plutôt que construire.
Pièce A — Le prompt
Reçu le31.07.2026Construis un tracker d’erreurs où le regroupement est la fonctionnalité et l’empreinte est lisible.
Stack : ton choix, Postgres, Docker Compose, un domaine avec TLS.
Ingestion : un point d’entrée HTTP par projet avec une clé, acceptant une charge utile de type d’exception, message, frames de stack, release, environnement, et des tags et contexte arbitraires. Limite le débit par projet et laisse tomber avec un compteur plutôt que de mettre en file sans limite.
Empreinte, le cœur du projet, et elle doit être inspectable :
1. Normalise la stack — retire les chemins absolus vers une forme relative au dépôt, retire les numéros de ligne des frames hors de ton propre code, replie les frames consécutives d’un même paquet tiers en une seule.
2. Prends les N meilleures frames dans-l’application, dans l’ordre.
3. Hache ces frames plus le type d’exception. Pas le message : les messages contiennent des identifiants, des valeurs et des horodatages, et les hacher crée un ticket par occurrence, l’erreur classique.
4. Montre les frames exactes qui ont produit l’empreinte sur la page du ticket, et permets un remplacement manuel — fusionner deux tickets, ou en scinder un par une clé additionnelle — enregistré et réversible.
Releases : chaque événement porte une release. Un ticket enregistre la release de première apparition et la release de dernière apparition. Marquer un ticket comme résolu enregistre la release où il a été résolu, et un événement arrivant d’une release plus tardive le rouvre comme une régression, signalée distinctement d’un nouveau ticket. Ce signal de régression est de loin la chose la plus précieuse qu’un tracker d’erreurs produit, et il a besoin de la plomberie de releases pour fonctionner tout court.
Page de ticket : compte dans le temps, utilisateurs affectés, distributions de tags (navigateur, version, environnement) avec la plus déséquilibrée mise en évidence, la stack complète du dernier événement avec résolution de source map ou de symboles appliquée à l’ingestion, et le fil d’Ariane si le client en a envoyé un.
Alertes : un nouveau ticket, ou un ticket qui dépasse un seuil de taux, ou une régression. Livre vers un webhook. N’alerte pas sur chaque événement.
Rétention avec suppression réelle, et un quota par projet qui laisse tomber et compte.
Écris des tests pour la stabilité d’empreinte à travers une release qui déplace les numéros de ligne, pour le contenu du message qui n’affecte jamais l’empreinte, pour la détection de régression à travers l’ordre des releases, et pour la fusion et la scission qui sont réversibles.
Ne construis ni replay de session, ni traçage, ni SDK pour plus d’un langage.L’ouverture pré-remplit le prompt — il ne reste qu’à appuyer sur entrée.
Pièce B — Ce que tu perds
- B.1 des SDK pour des dizaines de langages et frameworks, maintenus
- B.2 une qualité de regroupement réglée sur un corpus énorme de vraies stacks
- B.3 le replay de session, le traçage et le profilage sur les mêmes événements
- B.4 une ingestion qui reste en ligne pendant ton propre incident
- B.5 les intégrations qui ouvrent un ticket et lient le commit
Alternatives existantes
Pièce C — Pourquoi certains continuent de payer : grouping quality and SDK breadth
Parce qu’un mauvais regroupement rend un tracker d’erreurs inutile — un bug éparpillé sur quarante tickets, ou quarante bugs réduits à un seul — et le regroupement est la partie difficile à bien faire et invisible quand ça marche.
Questions
Pourquoi exclure le message de l’empreinte ?
Parce que les messages intègrent des identifiants d’enregistrement, des valeurs et des horodatages, donc les hacher produit un ticket par occurrence et le tracker devient une visionneuse de logs. Type plus frames normalisées, c’est ce qui transforme dix mille événements en quatre bugs.
Pourquoi la détection de régression a-t-elle besoin du suivi de releases ?
« Résolu » ne signifie quelque chose que relativement à une version. Sans releases, un vieil événement qui arrive au compte-gouttes rouvre le ticket et tout le monde apprend à ignorer le signal ; avec elles, une réouverture signifie que le correctif a vraiment cassé.
Ne devrais-je pas simplement déployer un tracker d’erreurs existant ?
Pour la plupart des gens, oui — un serveur open source compatible Sentry existe et accepte les SDK officiels, ce qui est une grosse avance. Construis celui-ci si tu veux que le regroupement soit quelque chose que tu peux lire et changer.
Comment fonctionne le tarif de Sentry ?
Un prix de plan plus un volume compté : erreurs, replays de session, spans de traçage et moniteurs cron sont chacun comptés séparément contre un quota prépayé, avec le dépassement facturé en plus. Le prix du plan, c’est le plancher, pas la facture.
Outils proches
Récépissé