Aller au contenu
Antoine Boucher

Options

Profils

← Tous les articles
Présentation du projet

Serilog.Sinks.SentrySDK : relier les logs structurés au suivi d’erreurs

2 min de lecture

Écouter en version balado

D'une ligne de log à une erreur exploitable · 2:07 · voix synthétiques, script rédigé avec l’IA

Transcription

Sylvie : Une ligne de log dit qu'il s'est passé quelque chose. Elle en dit rarement assez pour corriger le problème.

Thierry : Oui, on reçoit un message à trois heures du matin, sans savoir de quelle version ni de quel environnement il vient.

Sylvie : C'est ce trou que comble Serilog point Sinks point SentrySDK. C'est une bibliothèque dot NET d'Antoine qui relie les logs Serilog aux événements d'erreur de Sentry, pour qu'une erreur arrive avec son exception, sa version, son environnement et le contexte de la requête.

Thierry : Il est parti de zéro ?

Sylvie : Non, le projet s'inspire d'un projet communautaire existant, serilog-sinks-sentry. Et Antoine précise que les étoiles GitHub mesurent l'intérêt pour ce dépôt, pas l'adoption globale de Serilog ou de Sentry.

Thierry : Comment ça marche à l'intérieur ?

Sylvie : Un sink reçoit chaque événement Serilog et le passe à un petit adaptateur autour du SDK officiel de Sentry. Cet adaptateur gère les messages, les exceptions et les transactions, et il rend le SDK facile à remplacer dans les tests.

Thierry : Un piège pour ceux qui l'adoptent ?

Sylvie : L'initialisation. Le sink configure Sentry lui-même, et le README déconseille d'appeler l'init de Sentry une deuxième fois dans le même processus. Dans une application web qui initialise déjà son monitoring, il faut décider qui en est responsable.

Thierry : Et les données de requête ? Ça peut être sensible.

Sylvie : Oui. Un paquet ASP.NET Core complémentaire ajoute le contexte de requête, mais l'article insiste : choisir ce qui quitte l'application, et vérifier les réglages de données personnelles et le filtrage. Il y a aussi un callback avant envoi pour filtrer ou enrichir les événements.

Thierry : Et côté qualité ?

Sylvie : Le README documente des tests unitaires, la couverture et des contrôles de formatage. Antoine ne prétend pas les avoir relancés et n'invente aucun pourcentage. Les paquets ciblent net six et net dix.

Thierry : L'installation tient en une commande ?

Sylvie : Un dotnet add package, oui. L'article complet a le schéma d'architecture et les liens vers les exemples.

Visuel du package Serilog Sentry SDK provenant du dossier src/assets
Table des matières

Un log indique qu’un événement a eu lieu. Pour enquêter sur une erreur, il faut aussi l’exception, la version, l’environnement et parfois le contexte de la requête. Serilog.Sinks.SentrySDK relie ces deux vues.

Le projet est basé sur serilog-contrib/serilog-sinks-sentry. Ses étoiles GitHub concernent ce dépôt, pas l’adoption totale de Serilog ou de Sentry.

1. Le rôle de l’adaptateur

flowchart TD
  A["Application"] --> L["LogEvent Serilog"]
  L --> S["SentrySink"]
  S --> W["ISentrySdkWrapper"]
  W --> SDK["SDK Sentry .NET"]
  SDK --> E["Suivi des événements Sentry"]
  C["Middleware de contexte ASP.NET Core"] -. contexte .-> S

SentrySink.cs[1] implémente ILogEventSink et IDisposable. L’interface ISentrySdkWrapper abstrait la capture de messages, d’exceptions et la création de transactions. Cette frontière facilite aussi les tests.

2. Une seule initialisation

Le sink configure Sentry lui-même. Son constructeur refuse un DSN vide, prépare les options et conserve le handle d’initialisation. Le README déconseille une deuxième initialisation indépendante avec SentrySdk.Init dans le même processus.

C’est particulièrement facile à oublier dans une application web qui initialise déjà son monitoring. Il faut choisir le propriétaire de cette initialisation avant d’ajouter le sink.

dotnet add package Serilog.Sinks.SentrySDK

Les exemples console et ASP.NET Core du dépôt donnent les configurations à suivre pour la version installée.

3. Choisir le contexte transmis

Le projet ASP.NET Core comprend un adaptateur de requête, une politique de déstructuration, des extensions d’exception et un middleware de contexte. Ces informations aident au diagnostic, mais il faut choisir ce qui doit quitter l’application.

Le sink expose des options avancées et un callback beforeSend. Le code documente son ordre d’exécution par rapport au mapping EventId. C’est utile pour filtrer ou enrichir les événements sans effacer le travail du sink.

4. Packages et statistiques

Le README décrit deux packages principaux ciblant net6.0 et net10.0, plus des variantes .6 et .10. Il s’agit des cibles des packages, pas d’un avis sur le cycle de support des runtimes.

Téléchargements NuGet de Serilog.Sinks.SentrySDK[4]

Ce badge montre le compteur courant de ce package. Il n’additionne pas les variantes, et un téléchargement ne correspond pas forcément à une installation active. Les statistiques GitHub datées restent distinctes.

5. Ce que les vérifications démontrent

Le dépôt documente les tests xUnit, la couverture et les contrôles de formatage. Les liens CI permettent de consulter leurs résultats. Cet article ne prétend pas avoir relancé ces tests et n’invente aucun pourcentage de couverture.

6. Sources

Références

  1. antoinebou12. (). SentrySink.cs. [Source file or documentation] github.com.
  2. antoinebou12. (). Serilog.Sinks.SentrySDK. [Software repository] github.com.
  3. antoinebou12. (). Exemples console et web. [Source file or documentation] github.com.
  4. Statistiques NuGet. (). [Web page] www.nuget.org.

Les références utilisent la date de publication de cet article.