.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. Både loggning och spårning kapslar in den här tekniken. .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.

Termerna "loggning" och "spårning" är ofta synonyma. Skillnaden är att loggningsutdata förväntas samlas in hela tiden, och därför bör det ha en låg omkostnad. Spårning är vanligtvis mer invasivt och samlar in mer information från djupare delar av programmet och .NET-körning. Den används antingen när du diagnostiserar specifika problem eller automatiskt under korta tidsperioder som en del av djupare prestandaanalyssystem.

En annan pivot på spårningstermen är distribuerad spårning. Distribuerad spårning samlar in aktivitets- och tidsdata på hög nivå för begärandebaserade system och korrelerar begäranden mellan tjänster för att ge en bild av hur varje begäran bearbetas av hela systemet.

Viktiga skillnader i loggnings-API:er

Strukturerad loggning

Loggnings-API:er kan antingen vara strukturerade eller ostrukturerade:

• Ostrukturerad: Loggposter har textinnehåll i fritt format som är avsett att visas av människor.
• 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.

API:er som stöder strukturerad loggning är att föredra för icke-trivial användning. De erbjuder mer funktionalitet, flexibilitet och prestanda med liten skillnad i användbarhet.

Konfiguration

För enkla användningsfall kanske du vill använda API:er som direkt skriver meddelanden till konsolen eller en fil. Men de flesta programvaruprojekt är användbara för att konfigurera vilka logghändelser som registreras och hur de sparas. När du till exempel kör i en lokal utvecklingsmiljö kanske du vill mata ut oformaterad text till konsolen för enkel läsbarhet. När programmet sedan distribueras till en produktionsmiljö kan du växla till att ha loggarna lagrade i en dedikerad databas eller en uppsättning rullande filer. API:er med bra konfigurationsalternativ gör dessa övergångar enkla, medan mindre konfigurerbara alternativ skulle kräva att instrumentationskoden uppdateras överallt för att göra ändringar.

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.

.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 spårnings-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.

Eventlog

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.