Surveillance et logging C# : du chaos à l'ordre

Pourquoi votre application C# crie-t-elle sans que vous l'entendiez ?

Imaginez : vous déployez une nouvelle version de votre microservice C# à minuit. Tout fonctionne parfaitement... les 10 premières minutes. Puis soudain, les utilisateurs se plaignent de ralentissements, et vous êtes là, devant un fichier de log de 2 Go, à chercher une aiguille dans une botte de foin. Cela vous parle ? Si ce n'est pas le cas, vous êtes soit un génie, soit vous n'avez jamais vraiment fait de surveillance.

Dans cet article, nous allons voir comment transformer le chaos des logs en un système structuré. Vous apprendrez à configurer le logging C# pour ne pas perdre la tête lors des déploiements, et à mettre en place une surveillance d'applications qui vous aide réellement, au lieu de simplement afficher de beaux graphiques.

Par où commencer : la philosophie d'un bon logging

Beaucoup de développeurs pensent : « Je vais mettre un Console.WriteLine et ça ira ». Spoiler : non, ça n'ira pas. Le vrai logging en C#, c'est le structured logging (logging structuré). Au lieu d'écrire :

Log.Info("User " + userId + " bought item " + itemId);

Vous écrivez :

Log.Information("User {UserId} bought item {ItemId}", userId, itemId);

La différence est énorme. Dans le second cas, vous pouvez filtrer les logs par UserId, créer des tableaux de bord et trouver rapidement les problèmes. C'est la base du diagnostic d'erreurs C# en production.

Choisir sa bibliothèque : Serilog vs NLog vs log4net

Sur le marché .NET, trois acteurs principaux se démarquent. Comparons-les selon des critères importants pour un projet réel :

\n
• Serilog — le favori du .NET moderne. Idéal pour le structured logging, facile à configurer, supporte les sinks (sortie vers fichier, base de données, Elasticsearch). Je le recommande pour les nouveaux projets.
\n
• NLog — un vétéran avec une configuration flexible via XML/JSON. Parfait pour les systèmes legacy où il est déjà utilisé.
\n
• log4net — l'ancien, à éviter sauf en cas d'absolue nécessité. Le support est limité, et le structured logging est bancal.
\n

Pour le traçage .NET dans les applications modernes, Serilog est le choix numéro 1. Configurons-le en 5 minutes.

Configuration de Serilog en C# : guide pas à pas

Installez les packages via NuGet :

dotnet add package Serilog\ndotnet add package Serilog.Sinks.Console\ndotnet add package Serilog.Sinks.File\ndotnet add package Serilog.Sinks.Seq

Voici une configuration minimale dans Program.cs pour ASP.NET Core :

using Serilog;\n\nLog.Logger = new LoggerConfiguration()\n    .MinimumLevel.Information()\n    .WriteTo.Console()\n    .WriteTo.File("logs/app-.log", rollingInterval: RollingInterval.Day)\n    .WriteTo.Seq("http://localhost:5341") // pour une surveillance avancée\n    .CreateLogger();\n\ntry\n{\n    Log.Information("Starting web application");\n    var builder = WebApplication.CreateBuilder(args);\n    builder.Host.UseSerilog(); // intégration avec le host\n    // ... reste de la configuration\n    var app = builder.Build();\n    app.Run();\n}\ncatch (Exception ex)\n{\n    Log.Fatal(ex, "Application terminated unexpectedly");\n}\nfinally\n{\n    Log.CloseAndFlush();\n}

Notez le rollingInterval : les logs seront automatiquement archivés chaque jour, évitant ainsi une croissance infinie. C'est la base du logging asynchrone en production.

Logs structurés : comment en tirer le maximum

Prenons un exemple : une méthode de traitement de commande. Sans structuration, vous écririez :

logger.LogInformation("Processing order {OrderId} for user {UserId}", order.Id, user.Id);

Avec Serilog, cela devient un objet JSON facilement analysable. Et si vous ajoutez du contexte via ILogger<T> :

public class OrderService\n{\n    private readonly ILogger<OrderService> _logger;\n\n    public OrderService(ILogger<OrderService> logger)\n    {\n        _logger = logger;