Journalisation dans les applications C# : meilleures pratiques .NET

Journalisation dans les applications C# : meilleures pratiques et outils (.NET)

La journalisation ne consiste pas simplement à écrire des messages dans un fichier. C'est un composant essentiel de toute application de production en C#. Sans un système de journalisation de qualité, vous travaillez à l'aveugle : les erreurs passent inaperçues, les performances sont difficiles à analyser, et le débogage devient un jeu de devinettes. Dans cet article, nous allons passer en revue les meilleures pratiques de journalisation dans l'écosystème .NET, examiner les bibliothèques populaires (Serilog, NLog), les niveaux de journalisation appropriés et une approche structurée de la collecte de données.

1. Choix d'une bibliothèque de journalisation : Serilog vs NLog

Dans le monde .NET, il existe plusieurs solutions matures. Les deux plus populaires sont Serilog et NLog. Tous deux prennent en charge la journalisation asynchrone, de multiples sinks (destinations de sortie) et l'intégration avec .NET Core/5+ via ILogger.

Serilog

Serilog est connu pour sa philosophie de journalisation structurée. Au lieu de simples chaînes de caractères, vous transmettez des objets, et Serilog les sérialise en JSON. C'est idéal pour des systèmes comme Elasticsearch, Seq ou Datadog.

// Exemple Serilogusing Serilog;

Log.Logger = new LoggerConfiguration()    .MinimumLevel.Information()    .WriteTo.Console()    .WriteTo.File("logs/app-.log", rollingInterval: RollingInterval.Day)    .CreateLogger();

Log.Information("Utilisateur {UserId} connecté à {Time}", userId, DateTime.UtcNow);

NLog

NLog est un outil plus traditionnel, mais non moins puissant. Il est parfait pour les projets nécessitant une configuration flexible via XML ou code. Il prend en charge la rotation des fichiers, l'envoi par email et l'intégration avec les bases de données.

// Exemple NLogusing NLog;

private static readonly Logger Logger = LogManager.GetCurrentClassLogger();

Logger.Info("Utilisateur {UserId} a effectué une action", userId);

Quand choisir quoi ? Si vous construisez des microservices ou utilisez la stack ELK — choisissez Serilog. Si vous avez besoin d'une configuration simple dans des projets legacy — NLog. Dans tous les cas, les deux prennent en charge le ILogger standard de Microsoft.Extensions.Logging.

2. Niveaux de journalisation : quand et quoi écrire

L'une des erreurs les plus fréquentes est de tout écrire au niveau Information ou, à l'inverse, de mettre Debug partout. Utilisez les niveaux appropriés :

• Trace (0) — informations extrêmement détaillées : entrée/sortie des méthodes, valeurs des variables. Utilisé uniquement lors du débogage.
• Debug (1) — messages de débogage utiles au développeur, mais pas à l'opérateur.
• Information (2) — événements métier : "commande créée", "utilisateur enregistré". C'est le niveau de travail principal.
• Warning (3) — situation anormale qui ne casse pas l'application : timeout de requête, nouvelle tentative de connexion.
• Error (4) — exceptions gérées, erreurs de logique métier, défaillances d'un module.
• Critical (5) — erreurs fatales : perte de connexion à la base de données, manque de mémoire, plantage de l'application entière.

// Exemple d'utilisation correcte des niveauxpublic async Task<Order> CreateOrderAsync(CreateOrderRequest request){    Log.Debug("Début de la création de commande pour l'utilisateur {UserId}", request.UserId);

    try    {        var order = new Order(request);        await _repository.SaveAsync(order);                Log.Information("Commande {OrderId} créée par l'utilisateur {UserId}", order.Id, request.UserId);        return order;    }    catch (DbException ex)    {        Log.Error(ex, "Erreur BDD lors de la création de commande pour l'utilisateur {UserId}", request.UserId);        throw; // On remonte l'exception    }}

3. Journalisation structurée : pourquoi est-ce important ?

La journalisation traditionnelle via