Journalisation et suivi .NET

Le code peut être instrumenté pour produire un journal, qui sert d’enregistrement d’événements intéressants qui se sont produits pendant l’exécution du programme. Pour comprendre le comportement de l’application, les journaux peuvent être examinés. .NET a accumulé plusieurs API de journalisation différentes depuis ses débuts et cet article vous aidera à comprendre les options disponibles.

Remarque

Parfois, la journalisation est également appelée « traçage », y compris dans certaines des anciennes API Windows et .NET. Ces dernières années, le « traçage » est plus couramment utilisé comme une abréviation pour le traçage distribué, mais ce n’est pas le sens utilisé dans cet article.

API de journalisation .NET

ILogger

Dans la plupart des cas, si vous ajoutez la journalisation à un projet existant ou créez un projet, l’infrastructure ILogger est un bon choix par défaut. ILogger prend en charge la journalisation structurée rapide, une configuration flexible, et une collection de récepteurs communs incluant la console, qui est ce que vous voyez lorsque vous exécutez une application ASP.NET. En outre, l’interface ILogger peut également servir de façade sur de nombreuses implémentations de journalisation tierces qui offrent plus de fonctionnalités et d’extensibilité.

ILogger fournit le récit de journalisation de l’implémentation OpenTelemetry pour .NET, qui permet la sortie des journaux de votre application vers divers systèmes APM pour une analyse plus approfondie.

EventSource

EventSource est une API plus ancienne et performante avec de la journalisation structurée. Elle a été initialement conçue pour s’intégrer correctement à Event Tracing pour Windows (ETW),mais a été étendue ultérieurement pour prendre en charge le suivi multiplateforme EventPipe et EventListener pour les récepteurs personnalisés. En comparaison avec ILogger, EventSource dispose de relativement peu de récepteurs de journalisation prémontés et il n’y a pas de prise en charge intégrée pour une configuration via des fichiers de configuration séparés. EventSource est excellente si vous souhaitez un contrôle plus étroit sur l’intégration ETW ou EventPipe, mais pour la journalisation à usage général, ILogger est plus flexible et plus facile à utiliser.

Trace

System.Diagnostics.Trace et System.Diagnostics.Debug sont les API de journalisation les plus anciennes de NET. Ces classes ont des API de configuration flexibles et un vaste écosystème de récepteurs, mais prennent uniquement en charge la journalisation non structurée. Sur .NET Framework, elles peuvent être configurées via un fichier app.config, mais dans .NET Core, il n’existe aucun mécanisme de configuration intégré basé sur les fichiers. Ils sont généralement utilisés pour produire des diagnostics de sortie pour le développeur lors de l’exécution sous le débogueur. L’équipe .NET continue de prendre en charge ces API à des fins de compatibilité descendante, mais aucune nouvelle fonctionnalité ne sera ajoutée. Ces API constituent un bon choix pour les applications qui les utilisent déjà. Pour les applications plus récentes qui n’ont pas encore été associées à une API de journalisation, ILogger peut offrir de meilleures fonctionnalités.

API de journalisation spécialisées

Console

La classe System.Console a les méthodes Write et WriteLine qui peuvent être utilisées dans des scénarios de journalisation simples. Ces API sont très faciles à utiliser, mais la solution ne sera pas aussi flexible qu’une API de journalisation à usage général. La console autorise uniquement la journalisation non structurée et aucune prise en charge de la configuration ne permet de sélectionner les messages de journal activés ou de recibler vers un autre récepteur. L’utilisation des API ILogger ou Trace avec un récepteur de console ne demande pas beaucoup d’efforts supplémentaires et la journalisation reste configurable.

DiagnosticSource

System.Diagnostics.DiagnosticSource est destinée à la journalisation où les messages de journal seront analysés de manière synchrone In-process au lieu d’être sérialisés dans un stockage. Cela permet à la source et à l’écouteur d’échanger des objets .NET arbitraires en tant que messages, tandis que la plupart des API de journalisation nécessitent que l’événement de journalisation soit sérialisable. Cette technique peut également être extrêmement rapide, gérant les événements de journal en dizaines de nanosecondes si l’écouteur est implémenté efficacement. Les outils qui utilisent ces API agissent souvent plus comme des profils in-process, bien que l’API n’impose aucune contrainte ici.

EventLog

System.Diagnostics.EventLog est une API Windows uniquement qui écrit des messages dans le Journal des événements Windows. Dans de nombreux cas, l’utilisation d’ILogger avec un récepteur EventLog facultatif lors de l’exécution sur Windows peut donner des fonctionnalités similaires sans couplage étroit de l’application au système d’exploitation Windows.

Terminologie de la journalisation

Journalisation structurée et non structurée

La journalisation peut être soit structurée, soit non structurée :

• Non structurée : les entrées de journal sont encodées en tant que texte de forme libre que les humains peuvent lire, mais il est difficile d’analyser et de interroger par programmation.
• Structurées : les entrées de journal ont un schéma bien défini et peuvent être encodées dans différents formats binaires et textuels. Ces journaux d’activité sont conçus pour être traduits par ordinateur et interrogeables afin que les utilisateurs et les systèmes automatisés puissent travailler facilement avec eux.

De bonnes API de journalisation structurée peuvent offrir plus de fonctionnalités et de performances avec seulement une légère augmentation de la complexité d’utilisation.

Récepteurs

La plupart des API de journalisation permettent d’envoyer des messages de journal à différentes destinations appelées récepteurs. Certaines API ont un grand nombre de récepteurs prédéfinis, tandis que d’autres n’en ont que quelques-uns. Si aucun récepteur prédéfini n’existe, il existe généralement une API d’extensibilité qui vous permettra de créer un récepteur personnalisé, bien que cela nécessite l’écriture d’un peu plus de code.