Sentry ou Datadog : coût et portée du suivi des erreurs

Choisissez Sentry si votre priorité est de regrouper les exceptions, retrouver le code en cause et suivre leur résolution. Choisissez Datadog si une erreur doit être replacée dans une requête, une session utilisateur ou l’état de l’infrastructure. La comparaison de Scout Monitoring, concurrent des deux services, décrit Sentry comme un outil d’abord centré sur les erreurs et Datadog comme une plateforme d’observabilité plus large.

Le choix dépend aussi de ce qui est déjà collecté. Pour une équipe qui utilise APM ou RUM chez Datadog, les erreurs provenant de ces données entrent dans Error Tracking sans supplément propre à cette fonction. Cela ne paie ni la collecte des traces et des sessions, ni celle des journaux. Ajouter Sentry peut améliorer le travail sur les exceptions, mais crée alors un second flux de données à financer et à administrer.

Une exception et un incident ne demandent pas les mêmes signaux

Face à une exception répétée, les développeurs cherchent généralement sa pile d’appels, les actions qui l’ont précédée, la version concernée et les occurrences semblables. Le regroupement en problèmes rend ce parcours lisible dans Sentry : il évite de traiter chaque événement comme un nouveau défaut du code. Des traces et des replays peuvent apporter davantage de contexte si l’application les envoie également. Leur présence doit toutefois être distinguée de la simple collecte des erreurs.

Une dégradation ressentie par un utilisateur pose parfois une autre question : quel service a ralenti la requête, quels journaux éclairent l’échec et la session montre-t-elle le même problème ? Datadog peut rapprocher ces signaux lorsque ses produits correspondants sont activés et que les données utiles sont conservées. Son Error Tracking regroupe lui aussi des erreurs en problèmes ; la différence décisive tient alors au parcours d’enquête disponible autour de chaque problème, et non à la seule existence d’une liste d’exceptions.

Cette distinction évite de comparer des fonctions sous un même nom sans regarder leurs entrées. Une pile d’appels aide à localiser l’endroit où le programme échoue. Une trace distribuée suit la requête entre services ; un journal peut apporter un détail d’exécution ; RUM renseigne sur la session réellement vécue. Selon la cause recherchée, l’un de ces éléments peut être indispensable ou superflu.

Trois architectures et leurs parcours de diagnostic

Une exception regroupée dans Sentry face au parcours plus large reliant trace applicative et session utilisateur dans Datadog.

Sentry seul concentre le travail sur les erreurs applicatives. L’application envoie des occurrences, que l’équipe examine par problème, pile d’appels et version avant de suivre la correction. Si elle active aussi les traces, les replays ou les journaux, elle ajoute des données et des quotas à cette architecture. Recevoir des exceptions dans Sentry ne fournit pas automatiquement les métriques d’hôtes ni les journaux d’exploitation que personne ne lui a transmis.

Datadog seul convient lorsque APM, RUM ou Log Management portent déjà les enquêtes de production. Une erreur présente dans une trace APM ou une session RUM peut rejoindre Error Tracking, puis conduire vers les autres signaux effectivement disponibles. Les journaux restent un flux distinct, soumis à leur collecte et à leur indexation. Cette architecture évite un fournisseur supplémentaire, mais sa portée dépend de l’instrumentation, des produits souscrits et des règles de conservation.

La combinaison devient utile si l’équipe tire une valeur propre du regroupement et du suivi des problèmes dans Sentry, tout en gardant Datadog pour les traces, les sessions et l’exploitation. Une même défaillance peut alors produire une occurrence chez Sentry et apparaître dans des données déjà collectées chez Datadog. Elle ne représente pas nécessairement deux suppléments Error Tracking, mais elle traverse deux systèmes de collecte et peut consommer des quotas dans chacun. Désigner celui qui porte l’alerte et la clôture du problème évite deux suivis parallèles.

Le parcours attendu permet de départager ces montages. Si la pile d’appels et la version suffisent généralement à corriger le défaut, Sentry peut répondre au besoin avec moins de produits activés. Si la cause se trouve souvent dans une dépendance ou dans le trajet entre navigateur et services, les traces et les sessions deviennent centrales. La combinaison se justifie quand ces deux parcours servent réellement à des personnes ou à des étapes différentes de l’enquête.

Ce que facture réellement le volume d’erreurs

Une même exception suivie dans Sentry et Datadog, avec les erreurs autonomes distinguées de celles issues d’APM ou de RUM.

Chez Datadog, la grille d’Error Tracking inclut sans supplément les erreurs collectées dans les traces APM et les sessions RUM, mais facture les erreurs autonomes et celles issues de journaux éligibles. Elle affiche 25 dollars par mois avec facturation annuelle pour un volume facturable inférieur à 50 000 erreurs mensuelles ; l’usage des erreurs provenant des journaux exige aussi Log Management avec indexation. Les produits APM et RUM conservent leurs propres coûts.

Prenons un exemple purement hypothétique de 100 000 occurrences mensuelles sans chevauchement : 60 000 passent par APM, 20 000 par RUM et 20 000 sont envoyées de façon autonome. Dans ce cas, seules les 20 000 dernières alimentent le volume autonome d’Error Tracking ; le forfait correspondant ne résume pas la facture, puisqu’il faut encore compter APM et RUM. Si des erreurs proviennent aussi de journaux, leur traitement et leur indexation doivent entrer séparément dans le calcul.

Pour Sentry, le nombre de problèmes affichés ne remplace pas le volume d’événements envoyés : plusieurs occurrences d’une même exception peuvent appartenir à un seul problème. Il faut donc estimer les erreurs reçues, puis les autres catégories activées, notamment les traces et les replays. L’aide tarifaire de Sentry oriente les estimations des forfaits en libre-service vers sa page de prix et les besoins de volume négocié vers son équipe commerciale. Une ancienne grille reprise dans un comparatif ne suffit pas à chiffrer ce second flux.

Le coût marginal est la bonne unité de décision lorsque Datadog est déjà déployé : quelles données supplémentaires faudra-t-il envoyer à Sentry pour obtenir un meilleur parcours de correction ? À l’inverse, acheter plusieurs produits Datadog uniquement pour enrichir des exceptions peut coûter davantage qu’un suivi ciblé. Dans les deux cas, un prix par erreur isolé masque les hôtes, les traces, les sessions, les journaux et les éventuels dépassements qui composent la dépense réelle.

La rétention décide de ce qui reste explicable

Une erreur encore comptabilisée n’est pas toujours consultable dans son détail. L’aide Sentry sur les événements conservés indique une rétention des erreurs de 30 jours pour Developer et de 90 jours pour Team, Business et Enterprise. Le total historique d’un problème peut rester visible après la disparition des anciennes occurrences, alors que filtres et période sélectionnée modifient aussi la liste consultée.

Dans Datadog, conserver une session RUM ne garantit pas que sa trace APM associée reste accessible. Les filtres de rétention croisée de Datadog peuvent maintenir ensemble une session retenue et les traces backend ingérées qui lui correspondent ; leur configuration détermine la part des sessions concernées. Pour une équipe qui enquête plusieurs semaines après un signalement, la durée utile de chaque donnée compte donc autant que sa présence au moment de l’erreur. Dans une architecture combinée, conserver l’occurrence chez Sentry ne prolonge pas à elle seule la trace ou la session chez Datadog.