streamalism.org

1. Overzicht

Hoewel logbestanden vaak nuttige informatie overbrengen, worden ze natuurlijk groter in de loop van de tijd, en als ze voor onbepaalde tijd mogen groeien, kan hun grootte een probleem worden.

Logboekregistratiebibliotheken pakken dit probleem aan met behulp van rollende bestandstoevoegingen, die automatisch het huidige logboekbestand “rollen” of archiveren en het loggen in een nieuw bestand hervatten wanneer zich bepaalde vooraf gedefinieerde omstandigheden voordoen, waardoor ongewenste stilstand wordt voorkomen.

In dit artikel zullen we onderzoeken hoe rollende bestandsaanhangers kunnen worden geconfigureerd in enkele van de meest gebruikte logboekregistratiebibliotheken: Log4j, Log4j2 en Slf4j.

We laten zien hoe u logbestanden kunt rollen op basis van grootte, datum / tijd en een combinatie van grootte en datum / tijd. We zullen ook laten zien hoe u elke bibliotheek configureert om automatisch de oude logbestanden te comprimeren en later te verwijderen, zodat we geen vervelende huishoudcode hoeven te schrijven.

2. Onze voorbeeldtoepassing

Laten we beginnen met een voorbeeldtoepassing die enkele berichten registreert. Deze code is gebaseerd op Log4j, maar kan eenvoudig worden aangepast om met Log4j2 of Slf4j te werken:

importeer org.apache.log4j.Logger; openbare klasse Log4jRollingExample {privé statische Logger-logger = Logger.getLogger (Log4jRollingExample.class); public static void main (String [] args) gooit InterruptedException {for (int i = 0; i <2000; i ++) {logger.info ("Dit is de" + i + "keer dat ik 'Hallo wereld' zeg.") ; Thread.sleep (100); }}}

De applicatie is nogal naïef - het schrijft een aantal berichten in een lus, met een korte vertraging tussen iteraties. Met 2.000 lussen die moeten worden uitgevoerd en een pauze van 100 ms in elke lus, duurt het iets meer dan drie minuten om de toepassing te voltooien.

We zullen dit voorbeeld gebruiken om verschillende functies van verschillende soorten rollende bestandsaanhangers te demonstreren.

3. Rolling File Appenders in Log4j

3.1. Afhankelijkheden van Maven

Allereerst, om Log4j in uw applicatie te gebruiken, voegt u deze afhankelijkheid toe aan uw project pom.xml het dossier:

 log4j log4j 1.2.17 

Om de extra appenders van apache-log-extra's die we in de volgende voorbeelden zullen gebruiken, voeg de volgende afhankelijkheid toe, waarbij u ervoor zorgt dat u dezelfde versie gebruikt die we voor Log4j hebben gedeclareerd om volledige compatibiliteit te garanderen:

 log4j apache-log4j-extra's 1.2.17 

Je kunt de nieuwste release van Log4j en Apache Log4j Extras vinden op Maven Central.

3.2. Rollen op basis van bestandsgrootte

In Log4j, net als in de andere logboekregistratiebibliotheken, wordt het rollen van bestanden gedelegeerd aan de appender. Laten we eens kijken naar de configuratie voor een rollende bestandsappender in Log4j die rolt op basis van de bestandsgrootte:

Hier hebben we Log4j geconfigureerd om het logbestand te rollen wanneer het 5 KB groot is, met behulp van de MaxFileSize parameter. We hebben Log4j ook geïnstrueerd om maximaal twee opgerolde logbestanden te bewaren met behulp van de MaxBackupIndex parameter.

Toen we onze voorbeeldtoepassing uitvoerden, kregen we de volgende bestanden:

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 

Wat is er gebeurd? Log4j begon te schrijven naar het app.log het dossier. Toen de bestandsgrootte de limiet van 5 KB overschreed, is Log4j verhuisd app.log naar app.log.1, creëerde een gloednieuw, leeg app.log, en ging door met het schrijven van nieuwe logberichten naar app.log.

Dan na het nieuwe app.log overschreden de limiet van 5 KB, werd dit rolproces herhaald. Deze keer, app.log.1 werd verplaatst naar app.log.2, plaats maken voor een nieuwe, lege app.log.

Het rollende proces werd verschillende keren herhaald tijdens de run, maar aangezien we onze appender hebben geconfigureerd om maximaal twee opgerolde bestanden te bewaren, is er geen bestand met de naam app.log.3.

We hebben dus een van de oorspronkelijke problemen opgelost omdat we nu een limiet kunnen instellen voor de grootte van de geproduceerde logbestanden.

Aan de andere kant, toen we de eerste regel van app.log.2, het bevatte het bericht met betrekking tot de 700e iteratie, wat betekent dat alle vorige logboekberichten verloren waren gegaan:

2016-11-27 10:28:34 INFO Dit is de 700 keer dat ik 'Hallo wereld' zeg. 

Laten we eens kijken of we een setup kunnen bedenken die beter geschikt is voor een productieomgeving, waar het verliezen van logboekberichten niet als de beste aanpak kan worden beschouwd.

Om dat te doen, gaan we andere krachtigere, flexibelere en configureerbare Log4j-appenders gebruiken die worden verzonden in een speciaal pakket genaamd apache-log4j-extra's.

De appenders in dit artefact bieden veel opties om het rollen van het hout te verfijnen, en ze introduceren de verschillende concepten van triggering beleid en doorlopend beleid. De triggering beleid beschrijft wanneer een rol zou moeten plaatsvinden, terwijl de doorlopend beleid beschrijft hoe het rollen moet worden uitgevoerd. Deze twee concepten zijn de sleutel tot rollende logbestanden en worden min of meer expliciet ook door andere bibliotheken gebruikt, zoals we binnenkort zullen zien.

3.3. Rollen met automatische compressie

Laten we teruggaan naar het Log4j-voorbeeld en onze setup verbeteren door de automatische compressie van de opgerolde bestanden toe te voegen om ruimte te besparen:

Met de triggering beleid element, hebben we verklaard dat de rol zou moeten plaatsvinden wanneer het logboek groter is dan de grootte van 5.120 bytes.

Binnen de doorlopend beleid label, de ActiveFileName parameter geeft het pad aan van de belangrijkste logbestanden met de laatste berichten en de BestandsnaamPatroon parameter specificeert een sjabloon die beschrijft wat het pad van de opgerolde bestanden zou moeten zijn. Laten we opmerken dat dit inderdaad een patroon is vanwege de speciale tijdelijke aanduiding %ik wordt vervangen door de index van het opgerolde bestand.

Laten we dat ook opmerken BestandsnaamPatroon eindigt met een ".gz ” uitbreiding. Telkens wanneer we een extensie gebruiken die is gekoppeld aan een ondersteund gecomprimeerd formaat, zullen we de oude opgerolde bestanden zonder extra moeite van onze kant laten comprimeren.

Wanneer we de applicatie nu uitvoeren, krijgen we een andere set logbestanden:

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 

Het bestand app.current.log is waar de laatste logboeken zijn opgetreden. Eerdere logboeken zijn gerold en gecomprimeerd toen hun grootte de ingestelde limiet bereikte.

3.4. Rollen op basis van datum en tijd

In andere scenario's wilt u misschien Log4j configureren om de bestanden te rollen op basis van de datum en tijd van de logberichten in plaats van de grootte van het bestand. In een webtoepassing wilt u bijvoorbeeld dat alle logboekberichten op één dag in hetzelfde logbestand staan.

Om dat te doen, kunt u de TimeBasedRollingPolicy. Met dit beleid is het verplicht om een ​​sjabloon op te geven voor het pad van het logbestand dat een tijdgerelateerde tijdelijke aanduiding bevat. Elke keer dat een logbericht wordt verzonden, verifieert de appender wat het resulterende logboekpad zou zijn, en als het verschilt van het laatst gebruikte pad, zal er een roll plaatsvinden. Hier is een snel voorbeeld dat zo'n appender configureert:

3.5. Rollen op basis van grootte en tijd

Het combineren van de SizeBasedTriggeringPolicy en de TimeBasedRollingPolicy, je kunt een appender krijgen die rolt op basis van datum / tijd, en wanneer de grootte van het bestand de ingestelde limiet bereikt, rolt het ook op basis van de grootte:

Toen we onze applicatie met deze setup uitvoerden, hebben we de volgende logbestanden verkregen:

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.log

Het bestand app.19-26.1481393470902.log is waar de huidige logboekregistratie plaatsvindt. Zoals u kunt zien, worden alle logs in het interval tussen 19:25 en 19:26 opgeslagen in meerdere gecomprimeerde logbestanden waarvan de namen beginnen met 'ongeveer 19-25 ″. De "%ik" placeholder wordt vervangen door een steeds groter aantal.

4. Rolling File Appenders in Log4j2

4.1. Afhankelijkheden van Maven

Om Log4j2 als onze geprefereerde logboekbibliotheek te gebruiken, moeten we de POM van ons project bijwerken met de volgende afhankelijkheid:

 org.apache.logging.log4j log4j-core 2.7 

Zoals gewoonlijk vind je de laatste versie op Maven Central.

4.2. Rollen op basis van bestandsgrootte

Laten we onze voorbeeldtoepassing wijzigen om de Log4j2-logboekregistratiebibliotheken te gebruiken en laten we nu onderzoeken hoe we het rollen van bestanden kunnen instellen op basis van de grootte van het logboekbestand in de log4j2.xml configuratiebestand:

  % d {jjjj-MM-dd UU: mm: ss}% p% m% n 

In de Beleid tag hebben we alle activeringsbeleidsregels gespecificeerd die we willen toepassen. OnStartupTriggeringPolicy activeert een roll elke keer dat de applicatie start, wat handig kan zijn voor stand-alone applicaties. We hebben toen een SizeBasedTriggeringPolicy waarin staat dat een roll moet plaatsvinden wanneer het logbestand 5 KB bereikt.

4.3. Rollen op basis van datum en tijd

Laten we met behulp van het beleid van Log4j2 een appender instellen om het logbestand te rollen en te comprimeren op basis van tijd:

  % d {jjjj-MM-dd UU: mm: ss}% p% m% n 

Hier is de sleutel het gebruik van TimeBasedTriggeringPolicy waarmee we tijdgerelateerde tijdelijke aanduidingen kunnen gebruiken in de sjabloon van de opgerolde bestandsnamen. Merk op dat aangezien we slechts één triggeringbeleid nodig hadden, we de Beleid tag zoals we deden in het vorige voorbeeld.

4.4. Rollen op basis van grootte en tijd

Zoals eerder beschreven, is een interessanter scenario het rollen en comprimeren van logboekbestanden op basis van zowel tijd als grootte. Hier is een voorbeeld van hoe we Log4j2 voor deze taak kunnen instellen:

  % d {jjjj-MM-dd UU: mm: ss}% p% m% n 

Met deze configuratie hebben we aangegeven dat een rol moet plaatsvinden op basis van tijd en grootte. De appender kan begrijpen naar welk tijdsinterval we verwijzen vanwege het patroon dat wordt gebruikt voor de bestandsnaam, "app.% d {MM-dd-jjjj-HH-mm}.% i.log.gz ', die impliciet een rol instelt die elke minuut plaatsvindt en het opgerolde bestand comprimeert.

We hebben ook een DefaultRolloverStrategy om oude opgerolde bestanden te verwijderen die aan bepaalde criteria voldoen. We configureren de onze om bestanden te verwijderen die overeenkomen met het gegeven patroon wanneer ze ouder zijn dan 20 dagen.

4.5. Afhankelijkheden van Maven

Om Log4j2 als onze geprefereerde logboekbibliotheek te gebruiken, moeten we de POM van ons project bijwerken met de volgende afhankelijkheid:

 org.apache.logging.log4j log4j-core 2.7 

Zoals gewoonlijk vind je de laatste versie op Maven Central.

5. Rolling File Appenders in Slf4j

5.1. Afhankelijkheden van Maven

Als u Slf4j2 met een Logback-backend als logboekbibliotheken wilt gebruiken, voegt u deze afhankelijkheid toe aan uw pom.xml:

 ch.qos.logback logback-classic 1.1.7 

Zoals gewoonlijk vind je de laatste versie op Maven Central.

5.2. Rollen op basis van bestandsgrootte

Laten we nu eens kijken hoe we Slf4j in plaats daarvan kunnen gebruiken, met zijn standaard back-end Log terug. Laten we eens kijken hoe we het rollen van bestanden in het configuratiebestand kunnen instellen logback.xml, die in het klassenpad van de toepassing wordt geplaatst:

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

Opnieuw komen we het concept van rollend beleid tegen. Het basismechanisme is hetzelfde als dat wordt gebruikt door Log4j en Log4j2. De FixedWindowRollingPolicy stelt ons in staat om een ​​plaatsaanduiding voor een index te gebruiken in het naampatroon van het opgerolde bestand.

Wanneer de grootte van het logboekbestand de geconfigureerde limiet overschrijdt, wordt een nieuw bestand toegewezen en wordt de oude inhoud opgeslagen als het eerste bestand van de lijst, waardoor de bestaande bestanden een plaats verder worden verschoven.

5.3. Rollen op basis van tijd

In Slf4j kunnen we een logboekbestand rollen op basis van tijd met behulp van het verstrekte TimeBasedRollingPolicy. Met dit beleid kunnen we de sjabloonnaam van het rollende bestand specificeren met behulp van tijd- en datumgerelateerde tijdelijke aanduidingen:

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

5.4. Rollen op basis van grootte en tijd

Als u een bestand moet rollen, zowel op basis van tijd als grootte, kunt u het meegeleverde SizeAndTimeBasedRollingPolicy. Wanneer u dit beleid gebruikt, moet u zowel een tijdgerelateerde tijdelijke aanduiding als een indexplaatshouder opgeven.

Elke keer dat de grootte van het logboekbestand voor een bepaald tijdsinterval groter wordt dan de geconfigureerde groottelimiet, wordt een ander logboekbestand gemaakt met dezelfde waarde voor de tijdgerelateerde tijdelijke aanduiding maar met een verhoogde index:

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

6. Conclusie

Zoals we zagen, bespaart het gebruik van een logboekregistratiebibliotheek om de bestanden te rollen u de last van het handmatig beheren van de logbestanden, zodat u zich kunt concentreren op de ontwikkeling van uw bedrijfslogica. Rollende bestandsaanhangers zijn een waardevol hulpmiddel dat in de gereedschapskist van elke ontwikkelaar zou moeten zitten.

Zoals gewoonlijk vind je de bronnen op GitHub, waar de voorbeeldtoepassingen die in dit artikel worden gepresenteerd, zijn geconfigureerd om te loggen met behulp van verschillende rollende opstellingen om je in staat te stellen een goede basisconfiguratie te vinden die verder kan worden aangepast aan je behoeften.