En guide til rullende filtilhængere
1. Oversigt
Mens logfiler ofte formidler nyttige oplysninger, vokser de naturligvis større over tid, og hvis de får lov til at vokse på ubestemt tid, kan deres størrelse blive et problem.
Logbiblioteker løser dette problem ved hjælp af rullende fil-appenders, som automatisk "ruller" eller arkiverer den aktuelle logfil og genoptager logning i en ny fil når visse foruddefinerede forhold opstår og derved forhindrer uønsket nedetid.
I denne artikel vil vi undersøge, hvordan du konfigurerer rullende filappendere i nogle af de mest anvendte logbiblioteker - Log4j, Log4j2 og Slf4j.
Vi viser, hvordan man ruller logfiler baseret på størrelse, dato / tid og en kombination af størrelse og dato / tid. Vi vil også demonstrere, hvordan man konfigurerer hvert bibliotek til automatisk at komprimere og senere slette de gamle logfiler, hvilket sparer os for at skrive kedelig husholdningskode.
2. Vores prøveansøgning
Lad os starte med et eksempel på et program, der logger nogle meddelelser. Denne kode er baseret på Log4j, men den kan let ændres til at arbejde med Log4j2 eller Slf4j:
import org.apache.log4j.Logger; offentlig klasse Log4jRollingExample {privat statisk loggerlogger = Logger.getLogger (Log4jRollingExample.class); offentlig statisk ugyldig hoved (String [] args) kaster InterruptedException {for (int i = 0; i <2000; i ++) {logger.info ("Dette er" + i + "gangen jeg siger 'Hello World'.") ; Tråd. Søvn (100); }}}Applikationen er ret naiv - den skriver nogle meddelelser i en løkke med en kort forsinkelse mellem gentagelser. Med 2.000 sløjfer at køre og en pause på 100 ms i hver sløjfe, skal applikationen tage lidt mere end tre minutter at gennemføre.
Vi bruger denne prøve til at demonstrere flere funktioner i forskellige slags rullende filappendere.
3. Rolling File Appenders i Log4j
3.1. Maven afhængigheder
Først og fremmest skal du bruge Log4j i din applikation ved at tilføje denne afhængighed til dit projekts pom.xml fil:
log4j log4j 1.2.17 At bruge de ekstra appenders, der leveres af apache-log-ekstra som vi vil bruge i de næste eksempler, tilføje følgende afhængighed og være sikker på at bruge den samme version, som vi erklærede for Log4j for at sikre fuld kompatibilitet:
log4j apache-log4j-ekstra 1.2.17 Du kan finde den nyeste version af Log4j og Apache Log4j Extras på Maven Central.
3.2. Rulende baseret på filstørrelse
I Log4j, som i de andre logningsbiblioteker, delegeres filrulning til appenderen. Lad os se på konfigurationen for en rullende filappender i Log4j, der ruller baseret på filstørrelse:
Her konfigurerede vi Log4j til at rulle logfilen, når dens størrelse når 5 KB ved hjælp af MaxFileSize parameter. Vi instruerede også Log4j om at opbevare maksimalt to rullede logfiler ved hjælp af MaxBackupIndex parameter.
Da vi kørte vores prøveansøgning, opnåede vi følgende filer:
27/11/2016 10:28 138 app.log 27/11/2016 10:28 5.281 app.log.1 27/11/2016 10:28 5.281 app.log.2 Hvad skete der? Log4j begyndte at skrive til app.log fil. Når filstørrelsen overskred 5KB-grænsen, flyttede Log4j app.log til app.log.1, skabte en helt ny, tom app.log, og fortsatte med at skrive nye logbeskeder til app.log.
Så efter det nye app.log overskred grænsen på 5 KB, blev denne rullende proces gentaget. Denne gang, app.log.1 blev flyttet til app.log.2, at give plads til endnu et nyt, tomt app.log.
Rulleprocessen blev gentaget flere gange under kørslen, men da vi konfigurerede vores appender til at holde højst to rullede filer, er der ikke nogen fil, der hedder app.log.3.
Så vi har løst et af de originale problemer, fordi vi nu er i stand til at sætte en grænse for størrelsen på de producerede logfiler.
På den anden side, da vi tjekkede den første linje i app.log.2, det indeholdt meddelelsen relateret til den 700. iteration, hvilket betyder at alle tidligere logmeddelelser var gået tabt:
2016-11-27 10:28:34 INFO Dette er 700 gang, jeg siger 'Hello World'. Lad os se, om vi kan komme med en opsætning, der er bedre egnet til et produktionsmiljø, hvor tab af logbeskeder ikke kan betragtes som den bedste tilgang.
For at gøre det skal vi bruge andre mere kraftfulde, fleksible og konfigurerbare Log4j appenders, der sendes i en dedikeret pakke kaldet apache-log4j-ekstra.
Appenderne indeholdt i denne artefakt tilbyder masser af muligheder for at finjustere træstammen, og de introducerer de forskellige begreber udløsende politik og rullende politik. Det udløsende politik beskriver, hvornår en rulle skal forekomme, mens rullende politik beskriver, hvordan valsningen skal udføres. Disse to koncepter er nøglen til rullende logfiler og bruges mere eller mindre eksplicit af andre biblioteker, som vi snart vil se.
3.3. Rullende med automatisk kompression
Lad os gå tilbage til Log4j-eksemplet og forbedre vores opsætning ved at tilføje den automatiske komprimering af de rullede filer for at spare plads:
Med udløsende politik element, sagde vi, at rullen skulle forekomme, når loggen overstiger størrelsen på 5.120 bytes.
Indenfor rullende politik tag, det ActiveFileName parameter angiver stien til de vigtigste logfiler, der indeholder de seneste meddelelser og FileNamePattern parameter specificerer en skabelon, der beskriver, hvilken sti de rullede filer skal have. Lad os bemærke, at dette virkelig er et mønster, fordi den specielle pladsholder %jeg erstattes med indekset for den rullede fil.
Lad os også bemærke det FileNamePattern ender med en “.gz ” udvidelse. Når vi bruger en udvidelse tilknyttet et understøttet komprimeret format, vil vi få de gamle rullede filer komprimeret uden nogen ekstra indsats fra vores side.
Nu når vi kører applikationen, får vi et andet sæt logfiler:
03/12/2016 19:24 88 app.1.log.gz ... 03/12/2016 19:26 88 app.2.log.gz 03/12/2016 19:26 88 app.3.log. gz 03/12/2016 19:27 70 app.current.log Filen app.current.log er, hvor de sidste logfiler opstod. Tidligere logfiler er rullet og komprimeret, når deres størrelse nåede den indstillede grænse.
3.4. Rulende baseret på dato og klokkeslæt
I andre scenarier vil du muligvis konfigurere Log4j til at rulle filerne baseret på dato og klokkeslæt for logmeddelelserne i stedet for filens størrelse. I en webapplikation kan du for eksempel have alle logbeskeder udstedt på en dag i den samme logfil.
For at gøre det kan du bruge TimeBasedRollingPolicy. Med denne politik er det obligatorisk at specificere en skabelon til stien til logfilen, der indeholder en tidsrelateret pladsholder. Hver gang der udstedes en logmeddelelse, verificerer appenderen, hvad den resulterende logsti ville være, og hvis den adskiller sig fra den sidst anvendte sti, vil der opstå en rulle. Her er et hurtigt eksempel, der konfigurerer en sådan appender:
3.5. Rulende baseret på størrelse og tid
Kombinerer SizeBasedTriggeringPolicy og Tidsbaseret rullende politik, du kan få en appender, der ruller baseret på dato / tid, og når filstørrelsen når den indstillede grænse, ruller den også ud fra størrelse:
Da vi kørte vores applikation med denne opsætning, opnåede vi følgende logfiler:
03/12/2016 19:25 234 app.19-25.1481393432120.log.gz 03/12/2016 19:25 234 app.19-25.1481393438939.log.gz 03/12/2016 19:26 244 app.19-26.1481393441940 .log.gz 03/12/2016 19:26 240 app.19-26.1481393449152.log.gz 03/12/2016 19:26 3.528 app.19-26.1481393470902.logFilen app.19-26.1481393470902.log er, hvor den aktuelle logning finder sted. Som du kan se, gemmes alle logfiler i intervallet mellem 19:25 og 19:26 i flere komprimerede logfiler med navne, der starter med “ca. 19-25 ″. Det "%jeg" pladsholder erstattes af et stadigt stigende antal.
4. Rullende filappendere i Log4j2
4.1. Maven afhængigheder
For at bruge Log4j2 som vores foretrukne logbibliotek er vi nødt til at opdatere vores projekts POM med følgende afhængighed:
org.apache.logging.log4j log4j-kerne 2.7 Som sædvanlig kan du finde den nyeste version på Maven Central.
4.2. Rulende baseret på filstørrelse
Lad os ændre vores eksempelapplikation til at bruge Log4j2-logbibliotekerne, og lad os nu undersøge, hvordan vi kan konfigurere filrulling baseret på størrelsen på logfilen i log4j2.xml konfigurationsfil:
% d {åååå-MM-dd HH: mm: ss}% p% m% n I Politikker tag, vi specificerede alle de udløsende politikker, vi vil anvende. OnStartupTriggeringPolicy udløser en rulle hver gang applikationen starter, hvilket kan være nyttigt for enkeltstående applikationer. Vi specificerede derefter en SizeBasedTriggeringPolicy om, at en rulle skal forekomme, når logfilen når 5KB.
4.3. Rulende baseret på dato og klokkeslæt
Brug de politikker, der tilbydes af Log4j2, lad os oprette en appender til at rulle og komprimere logfilen baseret på tid:
% d {åååå-MM-dd HH: mm: ss}% p% m% n Her er nøglen brugen af TimeBasedTriggeringPolicy der giver os mulighed for at bruge tidsrelaterede pladsholdere i skabelonen til de rullede filnavne. Bemærk, at da vi kun havde brug for en enkelt udløsende politik, behøver vi ikke bruge Politikker tag som vi gjorde i det foregående eksempel.
4.4. Rulende baseret på størrelse og tid
Som tidligere beskrevet er et mere overbevisende scenario at rulle og komprimere logfiler baseret på både tid og størrelse. Her er et eksempel på, hvordan vi kan konfigurere Log4j2 til denne opgave:
% d {åååå-MM-dd HH: mm: ss}% p% m% n Med denne konfiguration sagde vi, at en rulle skulle forekomme baseret på tid og størrelse. Appenderen er i stand til at forstå, hvilket tidsinterval vi henviser til på grund af det mønster, der bruges til filnavnet, “app.% d {MM-dd-åååå-HH-mm}.% i.log.gz ”, som implicit indstiller en rulle, der skal forekomme hvert minut og komprimerer den rullede fil.
Vi tilføjede også en StandardRolloverStrategy for at slette gamle rullede filer, der matcher bestemte kriterier. Vi konfigurerer vores til at slette filer, der matcher det givne mønster, når de er ældre end 20 dage.
4.5. Maven afhængigheder
For at bruge Log4j2 som vores foretrukne logbibliotek er vi nødt til at opdatere vores projekts POM med følgende afhængighed:
org.apache.logging.log4j log4j-kerne 2.7 Som sædvanlig kan du finde den nyeste version på Maven Central.
5. Rolling File Appenders i Slf4j
5.1. Maven afhængigheder
Når du vil bruge Slf4j2 med en Logback-backend som logbiblioteker, skal du tilføje denne afhængighed til din pom.xml:
ch.qos.logback logback-classic 1.1.7 Som sædvanlig kan du finde den nyeste version på Maven Central.
5.2. Rulende baseret på filstørrelse
Lad os nu se, hvordan man bruger Slf4j i stedet med sin standard back-end Logback. Lad os undersøge, hvordan vi kan konfigurere filruller i konfigurationsfilen logback.xml, som er placeret i programmets klassesti:
target / slf4j / roll-by-size / app.log target / slf4j / roll-by-size / app.% i.log.zip 1 3 1MB 5KB% -4relativ [% thread]% -5level% logger {35} -% msg% n Igen støder vi på begrebet rullende politik. Den grundlæggende mekanisme er den samme som den, der bruges af Log4j og Log4j2. Det FixedWindowRollingPolicy giver os mulighed for at bruge en indekspladsholder i navnet på den rullede fil.
Når størrelsen på logfilen vokser over den konfigurerede grænse, tildeles en ny fil, og det gamle indhold gemmes som den første fil på listen, hvor de eksisterende flyttes et sted længere.
5.3. Rulende baseret på tid
I Slf4j kan vi rulle en logfil baseret på tid ved hjælp af den medfølgende TimeBasedRollingPolicy. Denne politik giver os mulighed for at specificere skabelonnavnet på den rullende fil ved hjælp af tids- og datorelaterede pladsholdere:
target / slf4j / roll-by-time / app.log target / slf4j / roll-by-time / app.% d {åååå-MM-dd-HH-mm} .log.zip 20 1MB% d {åååå-MM -dd HH: mm: ss}% p% m% n 5.4. Rulende baseret på størrelse og tid
Hvis du har brug for at rulle en fil både baseret på både tid og størrelse, kan du bruge den medfølgende SizeAndTimeBasedRollingPolicy. Når du bruger denne politik, skal du angive både en tidsrelateret pladsholder og en indekspladsholder.
Hver gang størrelsen af logfilen i et bestemt tidsinterval vokser ud over den konfigurerede størrelsesgrænse, oprettes en anden logfil med den samme værdi for den tidsrelaterede pladsholder, men med et inkrementeret indeks:
target / slf4j / roll-by-time-and-size / app.log target / slf4j / roll-by-time-and-size / app.% d {åååå-MM-dd-mm}.% i.log. lynlås 5KB 20 1MB% d {åååå-MM-dd HH: mm: ss}% p% m% n 6. Konklusion
Som vi så sparer du dig for byrden ved håndtering af logfilerne manuelt ved at udnytte et logbibliotek til at rulle filerne, så du kan fokusere på udviklingen af din forretningslogik. Rullende filappendere er et værdifuldt værktøj, der skal være i enhver udviklers værktøjskasse.
Som sædvanligt finder du kilderne på GitHub, hvor eksemplerne på applikationer, der præsenteres i denne artikel, er konfigureret til at logge ved hjælp af flere forskellige rullende opsætninger for at give dig mulighed for at finde en god basekonfiguration, der yderligere tilpasses til dine behov.
