.NET-loggning och spårning

Kod kan instrumenteras för att skapa en logg som fungerar som en post med intressanta händelser som inträffade när programmet kördes. För att förstå programmets beteende kan loggar granskas. .NET har samlat flera olika loggnings-API:er över sin historik och den här artikeln hjälper dig att förstå vilka alternativ som är tillgängliga.

Kommentar

Ibland kallas loggning även för "spårning", inklusive i några av de äldre Windows- och .NET-API:erna. Under de senaste åren används "spårning" oftare som en förkortning för distribuerad spårning, men det är inte innebörden i den här artikeln.

.NET-loggnings-API:er

ILogger

I de flesta fall, oavsett om du lägger till loggning i ett befintligt projekt eller skapar ett nytt projekt, är ILogger-infrastrukturen ett bra standardval. ILogger stöder snabb strukturerad loggning, flexibel konfiguration och en samling vanliga mottagare , inklusive konsolen, vilket är vad du ser när du kör en ASP.NET app. Dessutom ILogger kan gränssnittet även fungera som en fasad över många implementeringar av loggning från tredje part som erbjuder omfattande funktioner och utökningsbarhet.

ILogger innehåller loggningsberättelsen för OpenTelemetry-implementeringen för .NET, som möjliggör utgående loggar från ditt program till en mängd olika APM-system för ytterligare analys.

EventSource

EventSource är ett äldre API med höga prestanda med strukturerad loggning. Den utformades ursprungligen för att integreras väl med Händelsespårning för Windows (ETW), men utökades senare för att stödja EventPipe-spårning mellan plattformar och EventListener för anpassade mottagare. I jämförelse med ILoggerhar har EventSource relativt få fördefinierade loggningsmottagare och det finns inget inbyggt stöd för att konfigurera via separata konfigurationsfiler. EventSource är utmärkt om du vill ha bättre kontroll över ETW - eller EventPipe-integrering , men för generell loggning ILogger är det mer flexibelt och enklare att använda.

Spårning

System.Diagnostics.Trace och System.Diagnostics.Debug är . NET:s äldsta loggnings-API:er. De här klasserna har flexibla konfigurations-API:er och ett stort ekosystem med mottagare, men stöder bara ostrukturerad loggning. I .NET Framework kan de konfigureras via en app.config-fil, men i .NET Core finns det ingen inbyggd, filbaserad konfigurationsmekanism. De används vanligtvis för att producera diagnostikutdata för utvecklaren när de körs under felsökningsprogrammet. .NET-teamet fortsätter att stödja dessa API:er i bakåtkompatibilitetssyfte, men inga nya funktioner kommer att läggas till. Dessa API:er är ett bra val för program som redan använder dem. För nyare appar som inte redan har checkat in till ett loggnings-API ILogger kan det erbjuda bättre funktioner.

Specialiserade loggnings-API:er

Konsol

Klassen System.Console har metoderna Write och WriteLine som kan användas i enkla loggningsscenarier. Dessa API:er är mycket enkla att komma igång med, men lösningen blir inte lika flexibel som ett allmänt loggnings-API. Konsolen tillåter endast ostrukturerad loggning och det finns inget konfigurationsstöd för att välja vilka loggmeddelanden som är aktiverade eller att ommåla till en annan mottagare. Att använda ILogger- eller Trace-API:er med en konsolmottagare kräver inte mycket ytterligare arbete och håller loggningen konfigurerbar.

DiagnosticSource

System.Diagnostics.DiagnosticSource är avsedd för loggning där loggmeddelandena analyseras synkront i processen i stället för att serialiseras till någon lagring. På så sätt kan källan och lyssnaren utbyta godtyckliga .NET-objekt som meddelanden, medan de flesta loggnings-API:er kräver att logghändelsen är serialiserbar. Den här tekniken kan också vara extremt snabb och hantera logghändelser på tiotals nanosekunder om lyssnaren implementeras effektivt. Verktyg som använder dessa API:er fungerar ofta mer som processprofilerare, även om API:et inte har några begränsningar här.

Händelselogg

System.Diagnostics.EventLog är ett API för endast Windows som skriver meddelanden till Windows EventLog. I många fall kan användning av ILogger med en valfri EventLog-mottagare när du kör på Windows ge liknande funktioner utan att koppla appen tätt till Windows-operativsystemet.

Loggningsterminologi

Strukturerad och ostrukturerad loggning

Loggning kan antingen vara strukturerad eller ostrukturerad:

• Ostrukturerad: Loggposter kodas som friformstext som människor kan läsa, men det är svårt att programmatiskt parsa och fråga.
• Strukturerade: Loggposter har ett väldefinierat schema och kan kodas i olika binära och textbaserade format. Dessa loggar är utformade för att vara maskintranslaterbara och frågebara så att både människor och automatiserade system enkelt kan arbeta med dem.

Bra strukturerade loggnings-API:er kan erbjuda fler funktioner och prestanda med bara en liten ökning av användningskomplexiteten.

Sjunker

De flesta loggnings-API:er tillåter att loggmeddelanden skickas till olika mål som kallas mottagare. Vissa API:er har ett stort antal färdiga mottagare, medan andra bara har några få. Om det inte finns någon fördefinierad mottagare finns det vanligtvis ett utöknings-API som gör att du kan skapa en anpassad mottagare, även om detta kräver att du skriver lite mer kod.