Spårning (programvara)

Inom mjukvaruteknik innebär spårning en specialiserad användning av loggning för att registrera information om ett programs exekvering . Denna information används vanligtvis av programmerare för felsökningsändamål , och dessutom, beroende på typen och detaljinformationen som finns i en spårningslogg, av erfarna systemadministratörer eller teknisk supportpersonal och av programvaruövervakningsverktyg för att diagnostisera vanliga problem med programvara. Spårning är ett övergripande problem .

Det finns inte alltid en tydlig skillnad mellan spårning och andra former av loggning , förutom att termen spårning nästan aldrig tillämpas på loggning som är ett funktionskrav för ett program (därför utesluter loggning av data från en extern källa, såsom datainsamling i ett högenergifysikexperiment och förutskrivningsloggning) . Loggar som registrerar programanvändning (som en serverlogg ) eller operativsystemhändelser som främst är av intresse för en systemadministratör (se till exempel Event Viewer ) faller in i ett terminologiskt gråområde.

Den här artikeln handlar främst om spårning för felsökning eller diagnostiska ändamål.

Händelseloggning kontra spårning

Svårigheter att göra en tydlig åtskillnad mellan händelseloggning och mjukvaruspårning beror på att vissa av samma teknologier används för båda, och vidare på grund av att många av kriterierna som skiljer mellan de två är kontinuerliga snarare än diskreta. Följande tabell listar några viktiga, men inte alls exakta eller universella, distinktioner som används av utvecklare för att välja teknik för varje ändamål, och som styr den separata utvecklingen av ny teknik inom varje område:

Händelseloggning	Spårning av programvara
Konsumeras främst av systemadministratörer	Konsumeras främst av utvecklare
Loggar information på "hög nivå" (t.ex. misslyckad installation av ett program)	Loggar "lågnivå"-information (t.ex. ett slängt undantag )
Får inte vara för "bullrig" (innehåller många dubbletter av händelser eller information som inte är till hjälp för den avsedda publiken)	Kan vara bullriga
Ett standardbaserat utdataformat är ofta önskvärt, ibland till och med nödvändigt	Få begränsningar för utdataformat
Händelseloggmeddelanden är ofta lokaliserade	Lokalisering är sällan ett problem
Tillägg av nya typer av händelser, såväl som nya händelsemeddelanden, behöver inte vara smidigt	Tillägg av nya spårningsmeddelanden måste vara smidigt

Händelseloggning

Händelseloggning ger systemadministratörer användbar information för diagnostik och granskning . De olika klasserna av händelser som kommer att loggas, samt vilka detaljer som kommer att visas i händelsemeddelandena, övervägs ofta tidigt i utvecklingscykeln. Många händelseloggningsteknologier tillåter eller kräver till och med att varje klass av händelse tilldelas en unik "kod", som används av händelseloggningsmjukvaran eller en separat tittare (t.ex. Event Viewer) för att formatera och mata ut ett meddelande som kan läsas av människor. Detta underlättar lokalisering och gör att systemadministratörer lättare kan få information om problem som uppstår.

Eftersom händelseloggning används för att logga information på hög nivå (ofta felinformation), är prestandan för loggningsimplementeringen ofta mindre viktig.

Ett särskilt problem, att förhindra att dubbletter av händelser registreras "för ofta" tas om hand genom händelsestrypning.

Spårning av programvara

Programspårning ger utvecklare information som är användbar för felsökning. Denna information används både under utvecklingscykler och efter lanseringen av programvaran. Till skillnad från händelseloggning har mjukvaruspårning vanligtvis inte konceptet av en "klass" av händelse eller en "händelsekod". Andra anledningar till varför händelseloggningslösningar baserade på händelsekoder är olämpliga för mjukvaruspårning inkluderar:

Eftersom mjukvaruspårning är på låg nivå finns det ofta många fler typer av meddelanden som skulle behöva definieras, av vilka många bara skulle användas på ett ställe i koden. Händelsekodparadigmet introducerar betydande utvecklingskostnader för dessa "one-shot"-meddelanden.
De typer av meddelanden som loggas är ofta mindre stabila under utvecklingscykeln än för händelseloggning.
Eftersom spårningsutgången är avsedd att konsumeras av utvecklaren behöver meddelandena inte lokaliseras. Att hålla spårningsmeddelanden åtskilda från andra resurser som behöver lokaliseras (som händelsemeddelanden) är därför viktigt.
Det finns meddelanden som aldrig bör ses .
Spårningsmeddelanden bör behållas i koden, eftersom de kan öka kodens läsbarhet. Detta är inte alltid möjligt eller genomförbart med händelseloggningslösningar.

En annan viktig faktor för spårning av programvara är prestanda. Eftersom mjukvaruspårning är på låg nivå är den möjliga volymen spårningsmeddelanden mycket högre. För att ta itu med prestandaproblem måste det ofta vara möjligt att stänga av mjukvaruspårning, antingen vid kompilering eller körning.

Andra speciella problem:

I proprietär programvara kan spårningsdata innehålla känslig information om produktens källkod .
Om spårning är aktiverat eller inaktiverat under körning kräver många spårningsmetoder inkludering av en betydande mängd ytterligare data i binären, vilket indirekt kan skada prestandan även när spårning är inaktiverat.
Om spårning är aktiverat eller inaktiverat vid kompilering, beror att få spårningsdata för ett problem på en kunddator på att kunden är villig och kan installera en speciell, spårningsaktiverad version av programvaran och sedan duplicera problemet.
Många användningar av spårning har mycket stränga krav på robusthet . Detta beror både på robustheten hos spårningsutgången men också i att användningsfallet som spåras inte ska störas.
I operativsystem är spårning ibland användbart i situationer (som uppstart ) där vissa av teknikerna som används för att tillhandahålla händelseloggning kanske inte är tillgängliga.
i inbäddad programvara kräver spårning speciella tekniker.

Tekniker

Programspårning:

Spårande makron
Utdata till debugger
Aspektorienterad programmering och relaterade instrumenteringstekniker
Windows-programspårningsförprocessor (alias WPP)
FreeBSD och SmartOS-spårning med DTrace - spårar kärnan och användarlandet
Linux-kärnspårning med ftrace
Spårning på Linux-systemnivå och användarnivå med kärnmarkörer och LTTng
Spårning av Linux-applikationer med UST - en del av samma projekt som LTTng
Linux C/C++ programspårning med cwrap
Spåra med GNU Debuggers spårningskommando

Händelseloggning:

syslog (se artikel för specifika implementeringar)

Lämpligt för båda:

Instruktionsset simulering

Se även