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. La journalisation et le suivi encapsulent cette technique. .NET a accumulé plusieurs API de journalisation différentes depuis ses débuts et cet article vous aidera à comprendre les options disponibles.

Les termes « journalisation » et « traçage » sont généralement synonymes. La distinction est que la sortie de journalisation est censée être collectée tout le temps, et qu’elle doit donc avoir une faible surcharge. Le suivi est généralement plus invasif et collecte plus d’informations à partir des parties plus profondes de l’application et du runtime .NET. Il est soit utilisé lors du diagnostic de problèmes spécifiques, soit automatiquement pendant de courtes périodes dans le cadre de systèmes d’analyse des performances plus approfondis.

Une autre variante du terme de suivi est le Suivi distribué. Le suivi distribué collecte des données d’activité et de minutage de haut niveau pour les systèmes basés sur les requêtes et met en corrélation les requêtes entre les services pour donner une vue d’ensemble de la façon dont chaque requête est traitée par le système complet.

Distinctions clés dans les API de journalisation

Journalisation structurée

Les API de journalisation peuvent être structurées ou non structurées :

• Non structurées : les entrées de journal ont du contenu texte de forme libre qui est destiné à être consulté par les utilisateurs.
• 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.

Les API qui prennent en charge la journalisation structurée sont préférables pour une utilisation non triviale. Elles offrent plus de fonctionnalités, de flexibilité et de performances avec peu de différence d’utilisation.

Configuration

Pour les cas d’usage simples, vous pouvez utiliser des API qui écrivent directement des messages dans la console ou dans un fichier. Toutefois, la plupart des projets logiciels trouveront utile de configurer les événements de journal enregistrés et la façon dont ils sont conservés. Par exemple, lors de l’exécution dans un environnement de développement local, vous pouvez générer du texte brut dans la console pour faciliter la lisibilité. Ensuite, lorsque l’application est déployée dans un environnement de production, vous pouvez faire en sorte que les journaux soient stockés dans une base de données dédiée ou un ensemble de fichiers propagés. Les API avec de bonnes options de configuration facilitent ces transitions, tandis que les options moins configurables nécessitent la mise à jour du code d’instrumentation partout pour apporter des modifications.

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.

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 une journalisation structurée rapide, une configuration flexible et une collection de récepteurs courants, y compris la console, qui est ce que vous voyez lors de l’exécution d’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 de suivi hautes performances plus ancienne avec 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 a relativement peu de récepteurs de journalisation prédéfinis et il n’existe aucune prise en charge intégrée pour configurer via des fichiers de configuration distincts. 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.