Documentation

Suivi des erreurs

Capturez les exceptions que lance votre application, regroupées en issues, sur tous les forfaits y compris le gratuit. Le service parle le protocole de Sentry : vous gardez le SDK que vous avez déjà et changez une ligne de configuration.

Mise en place

Créez un projet dans le tableau de bord et copiez son DSN. Pointez ensuite votre SDK existant vers celui-ci :

Sentry.init({
  dsn: "https://<key>@vitrinaengine.com/ingest/<project>",
});

C’est toute l’intégration. N’importe quel SDK Sentry fonctionne — JavaScript, Python, Ruby, Go, PHP, .NET — parce qu’il s’agit de leur protocole réseau et non de quelque chose qui y ressemble.

La clé d’un DSN n’est pas un secret. Un SDK navigateur l’expédie dans le bundle de la page : elle identifie un projet et n’autorise rien d’autre. Ne construisez rien qui suppose qu’elle est privée.

Comment les erreurs deviennent des issues

Les événements qui sont le même problème sont regroupés en une issue. Le regroupement utilise le type d’exception, le message et la forme de la pile — jamais les numéros de ligne, car ajouter un import en haut d’un fichier scinderait sinon une issue en deux et ferait passer un bogue ancien pour nouveau.

Une issue que vous aviez résolue et qui se reproduit est rouverte en tant que régression et vous alerte, au lieu d’ajouter discrètement une occurrence de plus à une issue fermée.

Source maps

Téléversez les maps d’une version et une pile de navigateur minifiée devient lisible. Téléversez-les depuis votre build via l’API — voir la référence de l’API.

Les maps sont associées d’abord par debug_id, puis par version et nom de fichier. Elles sont appliquées à la lecture d’une issue, pas à l’arrivée de l’événement, ce qui a une conséquence utile : une map téléversée après les erreurs leur est quand même appliquée. C’est en général l’ordre dans lequel les choses se passent.

Erreurs rattachées à un incident

Lorsque la surveillance ouvre un incident, elle rassemble les erreurs que votre application a lancées pendant que cette panne était confirmée et rattache un résumé à l’incident lui-même.

Il vaut la peine de savoir pourquoi c’est plus utile qu’une recherche après coup : la fenêtre cesse d’exister dès que l’incident existe, et les événements sont soumis à une durée de conservation qui expire bien avant l’incident. Le résumé est donc capturé au moment où c’est possible, puis conservé avec l’incident.

Dans un compte d’agence, le résumé est limité à l’espace de travail, afin que l’incident d’un client n’emporte pas les traces d’un autre dans un e-mail.

Journaux de vos serveurs et de votre réseau

À partir de Business, un projet accepte aussi les journaux que vos machines écrivent déjà : syslog sous Linux et depuis les équipements Cisco et Juniper, le journal d’événements Windows et le journal unifié de macOS. Dirigez un collecteur que vous utilisez déjà vers le point de terminaison de journaux de votre projet, indiqué sur la page du projet à côté du DSN. Il n’y a rien à installer sur les machines.

Seules les erreurs sont conservées. Les niveaux syslog inférieurs à err, les niveaux Windows inférieurs à Error et tout ce que le journal macOS appelleDefault ou moins sont écartés avant d’être comptés ou facturés — un hôte en bonne santé ne vous coûte donc rien, et les avertissements pour lesquels personne ne serait alerté n’encombrent pas votre liste d’incidents.

Les journaux sont regroupés comme les exceptions : selon le programme émetteur et le message, et non selon l’hôte. Un déploiement défectueux sur vingt serveurs web est un incident vu vingt fois, et non vingt incidents. Lorsqu’un équipement nomme lui-même ses messages, nous regroupons sur ce nom : une interface tombée est un seul incident, quel que soit le port.

Comme une ligne de journal se répète bien plus qu’une exception, nous conservons un exemple de chaque incident par heure et comptons le reste. Le nombre d’occurrences et le graphique sont exacts ; ce que vous n’avez pas, c’est une copie distincte de la centième ligne identique.

Quotas

Chaque forfait dispose d’un quota mensuel d’événements — 5 000 sur Free, 50 000 sur Starter, 250 000 sur Pro, 1 000 000 sur Business. L’ingestion est en outre limitée en débit par projet, ce qui correspond au cas qui se produit réellement : une exception dans une boucle de réessai peut sinon consommer un mois de quota en quelques minutes.

Les événements individuels sont conservés selon la rétention d’erreurs de votre forfait — sept jours sur Free, trente sur Starter, soixante sur Pro, quatre-vingt-dix sur Business. Les issues qui en sont issues survivent aux événements : leurs compteurs et leurs première et dernière occurrences restent aussi longtemps que la rétention d’historique de votre forfait.

Ce que nous ne faisons pas

Pas de relecture de session, pas de traçage de performance, pas de profilage. Ceci est du suivi d’exceptions qui se trouve à côté de votre surveillance de disponibilité, pour que « le site est en ligne et lance cinq cents erreurs par minute » soit un seul écran plutôt que deux produits.