.net - Hvor skal du skrive log til Windows app

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg har et .NET Windows-program, der er implementeret via ClickOnce til en webserver. Der er ca. 100 brugere på et givet tidspunkt, alle centralt beliggende. Jeg bruger log4net til at logge ind i applikationen, men jeg har problemer med at komme til det bedste sted at sætte loggen.


Jeg har forsøgt at få dem til at skrive til en delt netværksplacering, men nogle brugere har oplevet dårlige I/O med denne tilgang. Jeg har prøvet at logge på brugerens tempmappe, men det gør det sværere at hente logfilerne. Haven har ikke prøvet hændelsesloggen, fordi jeg sandsynligvis skal springe igennem nogle hoops for at få det til at fungere, og jeg er ikke sikker på om det er det værd. Jeg har aldrig prøvet database logning, men jeg har altid antaget, at det ville være relativt langsomt.


Har nogen erfaring med at logge ind i et Windows-program, der er implementeret i et corporate miljø? Eventuelle forslag til hvor jeg kan lægge loggen, så den bliver (1) hurtig, (2) pålidelig og (3) tilgængelig?

Bedste reference


Problemet med Database logging er ikke hastigheden: det er pålideligheden. Du logger på, når tingene går galt, og hvis noget går galt, er oddsene for en utilgængelig DB ikke i din favør.


Generelt vil du skrive til en lokal tekstfil og et andet sted som en netværksdel eller DB. Hvis du har problemer med IO/hastighed, kan du bruge tekstfilen som buffer og skrive logger til den anfægtede ressource i partier. Derefter spoles du de lokale 'backup' -logfiler.

Andre referencer 1


Jeg har brugt log4net med ms sql databaser. Jeg sætter dem generelt en dedikeret db på en anden server, hvis det er muligt. På den måde, hvis der er problemer med applikationsserveren eller db, mister jeg ikke min logning.


Hastighed var aldrig et problem.

Andre referencer 2


log4net understøtter databaseappendører for nogle store databaser. Dette kan være et bedre alternativ, hvis du har en passende database til rådighed. Fremgangsmåde med forsigtighed, fordi det kunne reducere pålideligheden af ​​din ansøgning, hvis det ikke lykkes korrekt. [4]


Du kan bruge det i forbindelse med lokal fillogning ved at bruge en BufferingForwardingAppender til at batch din netværkslogging og sende kun, når du får en besked, der overstiger en bestemt tærskelværdi. På den måde kan du have tilstrækkelig kontekst til at spore fejl, men kun når der opstår fejl.


<appender name="BufferingForwardingAppender" type="log4net.Appender.BufferingForwardingAppender">
<bufferSize value="1024" />
<lossy value="true" />
<evaluator type="log4net.Core.LevelEvaluator">
  <threshold value="ERROR"/>
</evaluator>
<appender-ref ref="DatabaseAppender" />




Andre referencer 3


Hvad med mappen ApplicationData? På Vista ville det være sådan noget:


C: \ Brugere \ Ray \ AppData \ Local \ MyCompanyName


Hvis du vil have en central placering, ville jeg gå med databasens logning. Men som Joel sagde, vil du have både et lokalt sted, der altid fungerer (eller så tæt på det) og et centralt sted at samle logs til, når tingene virker normalt.

Andre referencer 4


Du kan bruge en kombination af lokal logning, og du kan synkronisere logfilerne til en central database ved vellykket log af.


Det afhænger af, hvilken slags logning du vil gøre, og hvordan din ansøgning kører. Hvis applikationen, der gør loggen, er et klientsideprogram, så er det måske ikke nyttigt, hvis du skriver til hændelsesloggene.


Hvis du vil skrive til hændelseslogfilerne, er det ret lige fremad:


http://support.microsoft.com/kb/307024[5]


Endnu en ting, hvis du leder efter et sted, som du ved, brugeren har adgang til, kan du bruge isoleret lagring, men det faktum at du forsøgte at skrive til en delt mappe gør mig ting, du vil have en central placering til dine logfiler, i hvilket tilfælde en DB sandsynligvis er din bedste indsats, og mit topforslag kan være bedst for dig.

Andre referencer 5


Hvis appen er et typisk to-tier-job, er det sandsynligvis passende at logge på databasen med AdoNetAppender. AdoNetAppender batcher log-meddelelser i stykker på op til 100, selvom du sandsynligvis vil konfigurere den til at skrive gennem mindst WARN alvorlighedsbegivenheder.


Du kan også overveje at logge på All Users Application Data Directory, selvom det kan gøre det lige så uhåndterligt at hente logfiler. Måske overveje at tilføje en genvej et sted?


Endelig, hvis log tilgængelighed spørgsmål er et fælles tema i din organisation, kan du overveje at overveje en log indsamlings app som Splunk. [6]

Andre referencer 6


Du kan prøve et sted under CommonAppData-mappen - dvs. CommonAppData \ YourAppName \ Logs - forudsat at du sikrer størrelsesgrænser og/eller periodiske oprydning. Folk bruges til periodisk at rydde op i tempmapperne, men er forsigtige med at starte med at grave rundt CommonAppData, AppData eller LocalAppData.


At skrive andetsteds men her eller ind i Temp vil før eller senere få dig i problemer på Vista og højere.


Hvis logfilerne ikke er vigtige, dvs. hvis uerstattelige data ikke bliver tabt, hvis nogen sletter loggen, ville jeg helt sikkert gå til en undermappe i Temp og have en separat opgaveplanlægger job upload dem. Det er det mindst smertefulde sted.

Andre referencer 7


I vores applikationer logger vi og bruger en fælles logfil til alle vores brugere i CommonAppData-mappen (C: \ Documents and Settings \ All Users \ Application Data \ Company \ Product). I dette tilfælde skal vores installatør manuelt indstille filtilladelser for mappen og logfilen, så alle brugere kan få adgang til det. Standard tilladelser er kun for brugeren, der installerer programmet.


Vi logger også uhåndterede undtagelser (når vi kan) til hændelsesloggen ved hjælp af en undtagelseshandler på øverste niveau (ved hjælp af en implementering som ligner: http://www.wintellect.com/cs/blogs/jclark/archive/2005/03/30/simple-main.aspx). Vi bruger hændelsesloggen, da alle væddemål er slukket om tilstanden for de filstrømme, der åbnes. Igen skal vores installatør oprette begivenhedslogkilden i applikationshændelsesloggen. [7]


Hvis du bruger logfilen, skal du sørge for, at din logning er ret minimal. Hvis du logger mange hændelser, da hændelsesloggen kan blive fyldt op ret hurtigt, og standardpolicyen for XP er, at hændelsesloggen skal begynde at tabe hændelser, hvis loggen er fuld, og standardstørrelsen er forholdsvis lille (512 KB, og overskriv kun begivenheder, der er ældre end 7 dage).