streamalism.org

1. Oversikt

Mens loggfiler ofte overfører nyttig informasjon, vokser de naturlig over tid, og hvis de får lov til å vokse på ubestemt tid, kan størrelsen deres bli et problem.

Loggbiblioteker adresserer dette problemet ved hjelp av rullende filtilleggere, som automatisk "ruller" eller arkiverer den nåværende loggfilen og fortsetter loggingen i en ny fil når visse forhåndsdefinerte forhold oppstår, og dermed forhindrer uønsket nedetid.

I denne artikkelen vil vi undersøke hvordan du konfigurerer rullende filtilleggere i noen av de mest brukte loggbibliotekene - Log4j, Log4j2 og Slf4j.

Vi viser hvordan du ruller loggfiler basert på størrelse, dato / tid og en kombinasjon av størrelse og dato / tid. Vi vil også demonstrere hvordan du konfigurerer hvert bibliotek til automatisk komprimering og senere sletting av de gamle loggfilene, og sparer oss for å skrive kjedelig husholdningskode.

2. Eksempel på søknad

La oss starte med et eksempel på et program som logger noen meldinger. Denne koden er basert på Log4j, men den kan enkelt endres for å fungere med Log4j2 eller Slf4j:

importer org.apache.log4j.Logger; offentlig klasse Log4jRollingExample {privat statisk loggerlogger = Logger.getLogger (Log4jRollingExample.class); public static void main (String [] args) kaster InterruptedException {for (int i = 0; i <2000; i ++) {logger.info ("Dette er" + i + "gangen jeg sier 'Hello World'.") ; Tråd. Søvn (100); }}}

Applikasjonen er ganske naiv - den skriver noen meldinger i en løkke, med en kort forsinkelse mellom gjentakelser. Med 2000 sløyfer å kjøre og en pause på 100 ms i hver sløyfe, bør applikasjonen ta litt mer enn tre minutter å fullføre.

Vi bruker dette eksemplet til å demonstrere flere funksjoner av forskjellige typer rullende filtilleggere.

3. Rolling File Appenders i Log4j

3.1. Maven avhengigheter

Først og fremst, for å bruke Log4j i applikasjonen din, legg til denne avhengigheten til prosjektet ditt pom.xml fil:

 log4j log4j 1.2.17 

For å bruke de ekstra appenderne som tilbys av apache-log-ekstra som vi bruker i de neste eksemplene, legger til følgende avhengighet, og sørg for å bruke den samme versjonen som vi erklærte for Log4j for å sikre full kompatibilitet:

 log4j apache-log4j-ekstra 1.2.17 

Du finner den siste utgivelsen av Log4j og Apache Log4j Extras på Maven Central.

3.2. Rullende basert på filstørrelse

I Log4j, som i de andre loggbibliotekene, blir filrulling delegert til appender. La oss se på konfigurasjonen for en rullende filappender i Log4j som ruller basert på filstørrelse:

Her konfigurerte vi Log4j til å rulle loggfilen når størrelsen når 5KB, ved hjelp av MaxFileSize parameter. Vi ba også Log4j om å beholde maksimalt to rullede loggfiler ved hjelp av MaxBackupIndex parameter.

Da vi kjørte eksempelsøknaden vår, fikk 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 

Hva skjedde? Log4j begynte å skrive til app.log fil. Når filstørrelsen overskred 5KB-grensen, flyttet Log4j app.log til app.log.1, opprettet en helt ny, tom app.log, og fortsatte å skrive nye loggmeldinger til app.log.

Så etter det nye app.log overskred 5KB-grensen, ble denne rullende prosessen gjentatt. Denne gangen, app.log.1 ble flyttet til app.log.2, å gi plass til nok et nytt, tomt app.log.

Rullende prosess ble gjentatt flere ganger under løpet, men siden vi konfigurerte appenderen vår til å beholde maksimalt to rullede filer, er det ikke noen fil som heter app.log.3.

Så vi har løst et av de opprinnelige problemene fordi vi nå kan sette en grense for størrelsen på de produserte loggfilene.

På den annen side, når vi sjekket første linje av app.log.2, den inneholdt meldingen knyttet til den 700. iterasjonen, noe som betyr at alle tidligere loggmeldinger hadde gått tapt:

2016-11-27 10:28:34 INFO Dette er 700 gangen jeg sier 'Hello World'. 

La oss se om vi kan komme med et oppsett som er bedre egnet for et produksjonsmiljø, der tap av loggmeldinger ikke kan betraktes som den beste tilnærmingen.

For å gjøre det skal vi bruke andre kraftigere, fleksible og konfigurerbare Log4j appendere som sendes i en dedikert pakke kalt apache-log4j-tillegg.

Appenderne i denne gjenstanden tilbyr mange alternativer for å finjustere stokkrullingen, og de introduserer de forskjellige begrepene utløsende policy og rullerende politikk. De utløsende policy beskriver når en rull skal forekomme, mens rullerende politikk beskriver hvordan rullingen skal utføres. Disse to begrepene er nøkkelen til å rulle loggfiler og brukes mer eller mindre eksplisitt av andre biblioteker, som vi snart vil se.

3.3. Rullende med automatisk komprimering

La oss gå tilbake til Log4j-eksemplet og forbedre oppsettet vårt ved å legge til automatisk komprimering av de rullede filene for å spare plass:

Med utløsende policy element, sa vi at rullen skulle oppstå når loggen overstiger størrelsen på 5,120 byte.

Innen rullerende politikk stikkord, de ActiveFileName parameter angir banen til hovedloggfilene som inneholder de siste meldingene og FileNamePattern parameteren angir en mal som beskriver banen til de rullede filene. La oss merke til at dette virkelig er et mønster fordi den spesielle plassholderen %Jeg vil bli erstattet med indeksen til den rullede filen.

La oss også merke det FileNamePattern ender med en “.gz ” Utvidelse. Hver gang vi bruker en utvidelse tilknyttet et støttet komprimert format, vil vi få de gamle rullede filene komprimert uten ekstra innsats fra vår side.

Nå når vi kjører applikasjonen, får vi et annet sett med loggfiler:

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 12.12.2016 19:27 70 app.current.log 

Filen app.current.log er der de siste loggene oppstod. Tidligere logger er rullet og komprimert når størrelsen nådde den angitte grensen.

3.4. Rullende basert på dato og klokkeslett

I andre scenarier kan det være lurt å konfigurere Log4j til å rulle filene basert på dato og klokkeslett for loggmeldingene i stedet for filstørrelsen. I et webapplikasjon kan det for eksempel være lurt å ha alle loggmeldingene utstedt på en dag i samme loggfil.

For å gjøre det kan du bruke TimeBasedRollingPolicy. Med denne policyen er det obligatorisk å spesifisere en mal for banen til loggfilen som inneholder en tidsrelatert plassholder. Hver gang en loggmelding utstedes, verifiserer appender hva den resulterende loggbanen ville være, og hvis den skiller seg fra den sist brukte banen, vil en rull forekomme. Her er et raskt eksempel som konfigurerer en slik appender:

3.5. Rullende basert på størrelse og tid

Kombinere SizeBasedTriggeringPolicy og TimeBasedRollingPolicy, du kan skaffe deg en appender som ruller basert på dato / tid, og når størrelsen på filen når den angitte grensen, ruller den også basert på størrelse:

Da vi kjørte applikasjonen vår med dette oppsettet, fikk vi følgende loggfiler:

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 2016/12/12 19:26 240 app.19-26.1481393449152.log.gz 03/12/2016 19:26 3.528 app.19-26.1481393470902.log

Filen app.19-26.1481393470902.log er der gjeldende loggføring finner sted. Som du kan se, er alle loggene i intervallet mellom 19:25 og 19:26 lagret i flere komprimerte loggfiler med navn som starter med “ca. 19-25 ″. De "%Jeg" plassholder erstattes av et stadig økende antall.

4. Rolling File Appenders i Log4j2

4.1. Maven avhengigheter

For å bruke Log4j2 som vårt foretrukne loggbibliotek, må vi oppdatere prosjektets POM med følgende avhengighet:

 org.apache.logging.log4j log4j-core 2.7 

Som vanlig kan du finne den nyeste versjonen på Maven Central.

4.2. Rullende basert på filstørrelse

La oss endre eksempelprogrammet vårt for å bruke Log4j2-loggbibliotekene, og la oss nå utforske hvordan vi kan konfigurere filrulling basert på størrelsen på loggfilen i log4j2.xml konfigurasjonsfil:

  % d {åååå-MM-dd HH: mm: ss}% p% m% n 

I Retningslinjer tag, spesifiserte vi alle utløsende retningslinjer vi vil bruke. OnStartupTriggeringPolicy utløser en rull hver gang applikasjonen starter, noe som kan være nyttig for frittstående applikasjoner. Vi spesifiserte deretter a SizeBasedTriggeringPolicy om at en rull skal forekomme når loggfilen når 5KB.

4.3. Rullende basert på dato og klokkeslett

Ved å bruke policyene som tilbys av Log4j2, la oss sette opp en appender for å rulle og komprimere loggfilen basert på tid:

  % d {åååå-MM-dd HH: mm: ss}% p% m% n 

Her er nøkkelen bruken av TimeBasedTriggeringPolicy som lar oss bruke tidsrelaterte plassholdere i malen for de rullede filnavnene. Vær oppmerksom på at siden vi bare trengte en enkelt utløsende policy, trenger vi ikke bruke Retningslinjer som vi gjorde i forrige eksempel.

4.4. Rullende basert på størrelse og tid

Som tidligere beskrevet er et mer overbevisende scenario å rulle og komprimere loggfiler basert på både tid og størrelse. Her er et eksempel på hvordan vi kan sette opp Log4j2 for denne oppgaven:

  % d {åååå-MM-dd HH: mm: ss}% p% m% n 

Med denne konfigurasjonen uttalte vi at en rull skulle forekomme basert på tid og størrelse. Appender er i stand til å forstå hvilket tidsintervall vi refererer til på grunn av mønsteret som brukes til filnavnet, “app.% d {MM-dd-åååå-HH-mm}.% i.log.gz ”, som implisitt setter en rull som skal skje hvert minutt og komprimerer den rullede filen.

Vi la også til en DefaultRolloverStrategy for å slette gamle rullede filer som samsvarer med visse kriterier. Vi konfigurerer våre til å slette filer som samsvarer med det gitte mønsteret når de er eldre enn 20 dager.

4.5. Maven avhengigheter

For å bruke Log4j2 som vårt foretrukne loggbibliotek, må vi oppdatere prosjektets POM med følgende avhengighet:

 org.apache.logging.log4j log4j-core 2.7 

Som vanlig kan du finne den nyeste versjonen på Maven Central.

5. Rolling File Appenders i Slf4j

5.1. Maven avhengigheter

Når du vil bruke Slf4j2 med en Logback-backend som loggbibliotek, kan du legge til denne avhengigheten til pom.xml:

 ch.qos.logback logback-classic 1.1.7 

Som vanlig kan du finne den nyeste versjonen på Maven Central.

5.2. Rullende basert på filstørrelse

La oss nå se hvordan du bruker Slf4j i stedet, med standard back-end Tilbakekobling. La oss undersøke hvordan vi kan konfigurere filrulling i konfigurasjonsfilen logback.xml, som er plassert i applikasjonens klassesti:

 target / slf4j / roll-by-size / app.log target / slf4j / roll-by-size / app.% i.log.zip 1 3 1MB 5KB% -4relativ [% thread]% -5nivå% logger {35} -% msg% n 

Igjen møter vi konseptet rullende politikk. Den grunnleggende mekanismen er den samme som den som brukes av Log4j og Log4j2. De FixedWindowRollingPolicy tillater oss å bruke en indeksplassholder i navnet på den rullede filen.

Når størrelsen på loggfilen vokser over den konfigurerte grensen, tildeles en ny fil, og det gamle innholdet lagres som den første filen på listen, og flytter de eksisterende ett sted lenger.

5.3. Rullende basert på tid

I Slf4j kan vi rulle en loggfil basert på tid ved hjelp av den medfølgende TimeBasedRollingPolicy. Denne policyen lar oss spesifisere malnavnet til den rullende filen ved hjelp av tids- og datorelaterte plassholdere:

 target / slf4j / roll-by-time / app.log target / slf4j / roll-by-time / app.% d {yyyy-MM-dd-HH-mm} .log.zip 20 1MB% d {yyyy-MM -dd HH: mm: ss}% p% m% n 

5.4. Rullende basert på størrelse og tid

Hvis du trenger å rulle en fil både basert på tid og størrelse, kan du bruke den medfølgende SizeAndTimeBasedRollingPolicy. Når du bruker denne policyen, må du spesifisere både en tidsrelatert plassholder og en indeksplassholder.

Hver gang størrelsen på loggfilen for et bestemt tidsintervall vokser utover den konfigurerte størrelsesgrensen, opprettes en annen loggfil med samme verdi for den tidsrelaterte plassholderen, men med en inkrementert indeks:

 target / slf4j / roll-by-time-and-size / app.log target / slf4j / roll-by-time-and-size / app.% d {åååå-MM-dd-mm}.% i.log. zip 5KB 20 1MB% d {åååå-MM-dd HH: mm: ss}% p% m% n 

6. Konklusjon

Som vi så, sparer du deg fra byrden med å administrere loggfilene manuelt, ved å bruke et loggbibliotek for å rulle filene, slik at du kan fokusere på utviklingen av forretningslogikken din. Rolling file appenders er et verdifullt verktøy som burde være i hver utviklers verktøykasse.

Som vanlig finner du kildene på GitHub, hvor eksempelapplikasjonene som presenteres i denne artikkelen er konfigurert til å logge ved hjelp av flere forskjellige rullende oppsett for å tillate deg å finne en god basekonfigurasjon som kan justeres ytterligere for å dekke dine behov.