• Articles
• admin

inzicht krijgen in uw toepassing is cruciaal bij het uitvoeren van uw code in productie. Wat bedoelen we met zichtbaarheid? Voornamelijk dingen zoals de prestaties van de toepassing via statistieken, applicatie gezondheid, en beschikbaarheid, de logs moet je nodig hebt om het op te lossen, of de sporen als je nodig hebt om erachter te komen wat maakt het traag en hoe het sneller te maken.

Metrics geven u informatie over de prestaties van elk van de elementen van uw infrastructuur. Traces toont u een breder beeld van de uitvoering van de code en stroom samen met de uitvoering van de code metrics. Tot slot, goed gemaakte logs zal een onschatbaar inzicht in de code logica uitvoering en wat er gebeurde in uw code te bieden. Elk van de genoemde stukken is cruciaal voor uw toepassing en inderdaad de algehele observeerbaarheid van het systeem. Vandaag, zullen we alleen richten op een enkel stuk – de logs. Om preciezer te zijn – op Java applicatie logs. Als u geïnteresseerd bent in metrics, check out ons artikel over de belangrijkste JVM metrics die u moet controleren.

echter, voordat we er in gaan, laten we een probleem aanpakken dat de gemeenschap beà nvloedde met behulp van dit framework. Op December 9, 2021, een kritieke kwetsbaarheid bijgenaamd Log4Shell werd gemeld. Geïdentificeerd als CVE-2021-44228, het laat een aanvaller volledige controle over een machine draaien Apache Log4j 2 versie 2.14.1 of lager, waardoor ze willekeurige code uit te voeren op de kwetsbare server. In onze recente blogpost over de log4jshell kwetsbaarheid, we gedetailleerd hoe om te bepalen of u worden getroffen, hoe het probleem op te lossen, en wat we, bij Sematext, hebben gedaan om ons systeem en gebruikers te beschermen.

Log4j 1.X End Of Life

houd in gedachten dat op 5 augustus 2015 de Logging Services Project Management Committee aangekondigd dat de Log4j 1.x had zijn einde van zijn leven bereikt. Alle gebruikers wordt geadviseerd om te migreren naar Log4j 2.x. in deze blogpost, zullen wij u helpen uw huidige log4j setup begrijpen-specifiek, de log4j 2.X-versie-en daarna, Ik zal u helpen migreren naar de nieuwste en beste Log4j-versie.

” Ik gebruik Log4j 1.x, wat moet ik doen?”. Geen paniek, er is niets mis mee. Maak een plan voor de overgang naar Log4j 2.x. Ik zal je laten zien hoe gewoon blijven lezen :). Je sollicitatie zal je daarvoor bedanken. U krijgt de beveiligingsoplossingen, prestatieverbeteringen en veel meer functies na de migratie.

” ik begin een nieuw project, wat moet ik doen?”. Gebruik gewoon de Log4j 2.x meteen, denk niet eens aan Log4j 1.x. Als je hulp nodig hebt met dat, check out Deze Java logging tutorial waar ik alles wat je nodig hebt uit te leggen.

loggen in Java

er is geen magie achter loggen in Java. Het komt allemaal neer op het gebruik van een geschikte Java-klasse en de methoden om log gebeurtenissen te genereren. Zoals we besproken hebben in de Java logging guide zijn er meerdere manieren waarop je

kunt starten natuurlijk is het meest naïeve en niet het beste pad om te volgen gewoon het gebruik van het systeem.uit en systeem.err lessen. Ja, je kunt dat doen en je berichten gaan gewoon naar de standaard uitvoer en standaard fout. Meestal betekent dit dat het zal worden afgedrukt naar de console of geschreven naar een bestand van een soort of zelfs verzonden naar /Dev/null en voor altijd worden vergeten. Een voorbeeld van een dergelijke code zou er zo uit kunnen zien:

public class SystemExample { public static void main(String args) { System.out.println("Starting my awesome application"); // some work to be done System.out.println( String.format("My application %s started successfully", SystemExample.class) ); }}

de uitvoer van de bovenstaande code uitvoering zou als volgt zijn:

Starting my awesome applicationMy application class com.sematext.logging.log4jsystem.SystemExample started successfully

dat is niet perfect, toch? Ik heb geen informatie over welke klasse gegenereerd de boodschap en veel, veel meer “kleine” dingen die cruciaal en belangrijk zijn tijdens het debuggen.

er zijn andere dingen die ontbreken die niet echt verbonden zijn met debuggen. Denk na over de uitvoeringsomgeving, meerdere toepassingen of microservices, en de noodzaak om logboekregistratie te verenigen om de configuratie van de log centralisatiepijplijn te vereenvoudigen. Het systeem gebruiken.uit, of / en systeem.fout in onze code voor logging doeleinden zou ons dwingen om alle plaatsen waar we het gebruiken opnieuw te doen wanneer we nodig hebben om de logging formaat aan te passen. Ik weet dat het extreem is, maar geloof me, we hebben het gebruik van het systeem gezien.uit in productie code in “traditionele” toepassing deployment modellen! Natuurlijk, logging naar het systeem.out is een goede oplossing voor containerized toepassingen en je moet de output die past bij uw omgeving te gebruiken. Vergeet dat niet!

vanwege alle genoemde redenen en nog veel meer waar we niet eens aan denken, zou je een van de mogelijke logboekbibliotheken moeten bekijken, zoals Log4 j, Log4j 2, Logback, of zelfs de java.util.logging dat is een onderdeel van de Java Development Kit. Voor deze blogpost gebruiken we Log4j.

de abstractielaag-SLF4J

het onderwerp van het kiezen van de juiste logging oplossing voor uw Java applicatie is iets dat we al hebben besproken in onze tutorial over loggen in Java. We raden het lezen van ten minste de genoemde sectie.

we gebruiken SLF4J, een abstractielaag tussen onze Java-code en Log4j – de logboekbibliotheek van onze keuze. De eenvoudige Logging gevel biedt bindingen voor gemeenschappelijke logging frameworks zoals Log4j, Logback, en java.util.logging. Stel je het proces voor van het schrijven van een logbericht op de volgende, vereenvoudigde manier:

u kunt zich afvragen waarom een abstractielaag überhaupt wordt gebruikt? Nou, het antwoord is vrij eenvoudig – uiteindelijk, wilt u misschien de logging kader te veranderen, upgrade het, verenigen met de rest van uw technologie stack. Bij het gebruik van een abstractielaag is zo ‘ n operatie vrij eenvoudig – je wisselt gewoon de afhankelijkheden van het logboekraamwerk uit en levert een nieuw pakket op. Als we geen abstractielaag zouden gebruiken – zouden we de code moeten veranderen, mogelijk veel code. Elke klas die iets registreert. Niet echt een mooie ontwikkeling ervaring.

de Logger

de code van uw Java-toepassing zal interageren met een standaard set van sleutelelementen die het aanmaken en bewerken van loggebeurtenissen mogelijk maken. We hebben de cruciale behandeld in onze Java logging tutorial, maar laat me je herinneren aan een van de klassen die we voortdurend zullen gebruiken – de Logger.

de Logger is de belangrijkste entiteit die een toepassing gebruikt om logboekaanroepen te maken – loggebeurtenissen maken. Het logger-object wordt meestal gebruikt voor een enkele klasse of een enkel onderdeel om context-gebonden aan een specifieke use case te bieden. Het biedt methoden om loggebeurtenissen met een geschikt logniveau te maken en door te geven voor verdere verwerking. U zult meestal een statisch object dat u zal interageren met, bijvoorbeeld als dit:

... Logger LOGGER = LoggerFactory.getLogger(MyAwesomeClass.class);

en dat is alles. Nu we weten wat we kunnen verwachten, laten we eens kijken naar de Log4j bibliotheek.

Log4j

de eenvoudigste manier om met Log4j te beginnen is door de bibliotheek op te nemen in het klasspad van uw Java-toepassing. Om dat te doen nemen we de nieuwste beschikbare log4j-bibliotheek op, wat Versie 1.2.17 betekent in ons build-bestand.

we gebruiken Gradle en in onze eenvoudige toepassing en de afhankelijkheden sectie voor Gradle build bestand ziet er als volgt uit:

dependencies { implementation 'log4j:log4j:1.2.17'}

we kunnen beginnen met het ontwikkelen van de code en logging opnemen met behulp van Log4j:

package com.sematext.blog;import org.apache.log4j.Logger;public class ExampleLog4j { private static final Logger LOGGER = Logger.getLogger(ExampleLog4j.class); public static void main(String args) { LOGGER.info("Initializing ExampleLog4j application"); }}

zoals je kunt zien in de bovenstaande code hebben we het logger object geïnitialiseerd met behulp van de statische getLogger methode en hebben we de naam van de klasse opgegeven. Na het doen van dat kunnen we gemakkelijk toegang tot de statische Logger object en gebruiken om log gebeurtenissen te produceren. We kunnen dat doen in de belangrijkste methode.

Eén kant opmerking-de getLogger methode kan ook aangeroepen worden met een String als argument, bijvoorbeeld:

private static final Logger LOGGER = Logger.getLogger("com.sematext.blog");

het zou betekenen dat we een logger willen maken en de naam van com willen associëren.sematext.blog ermee. Als we dezelfde naam ergens anders in de code gebruiken zal Log4j dezelfde logger instantie retourneren. Dat is handig als we logging van meerdere verschillende klassen op één plaats willen combineren. Bijvoorbeeld, logboeken met betrekking tot betaling in een enkel, speciaal logbestand.

Log4j biedt een lijst van methoden die het mogelijk maken van nieuwe loggebeurtenissen met behulp van een passend logniveau. Dat zijn:

• public void trace (Object message)
• public void debug (Object message)
• public void info (Object message)
• public void warn (Object message)
• public void error (Object message)
• public void fatal (Object message))

en één generieke methode:

• public void log (niveau niveau, Object bericht)

We spraken over Java logging niveaus in onze Java logging tutorial blog post. Als u zich niet bewust bent van hen, neem dan een paar minuten om te wennen aan hen als de log niveaus zijn cruciaal voor het loggen. Als je nog maar net begonnen bent met logging levels, raden we je aan om ook onze log levels guide door te nemen. We leggen alles uit, van wat ze zijn tot hoe de juiste te kiezen en hoe ze te gebruiken om zinvolle inzichten te krijgen.

als we de bovenstaande code zouden uitvoeren, zou de uitvoer die we op de standaard console zouden krijgen als volgt zijn:

log4j:WARN No appenders could be found for logger (com.sematext.blog.ExampleLog4j).log4j:WARN Please initialize the log4j system properly.log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

We hebben het Logbericht niet gezien dat we verwacht hadden. Log4j informeerde ons dat er geen configuratie aanwezig is. Oooops, laten we het hebben over het configureren van Log4j…

Log4j configuratie

er zijn meerdere manieren waarop we onze log4j logging kunnen configureren. We kunnen het programmatisch doen – bijvoorbeeld door een statisch initialisatieblok op te nemen:

static { BasicConfigurator.configure();}

de bovenstaande code configureert Log4j om de logs uit te voeren naar de console in het standaard formaat. De uitvoer van het uitvoeren van onze voorbeeldtoepassing ziet er als volgt uit:

0 INFO com.sematext.blog.ExampleLog4jProgrammaticConfig - Initializing ExampleLog4j application

het programmatisch instellen van Log4j is echter niet erg gebruikelijk. De meest gebruikelijke manier zou zijn om een properties bestand of een XML bestand te gebruiken. We kunnen onze code wijzigen en het log4j. properties Bestand toevoegen met de volgende inhoud:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %x - %m%n

op die manier hebben we Log4j verteld dat we de root logger maken, die standaard zal worden gebruikt. Het standaard logboekniveau is ingesteld op debuggen, wat betekent dat loggebeurtenissen met Ernst debuggen of hoger worden opgenomen. Dus DEBUG, INFO, waarschuwen, fout, en fataal. We gaven onze logger ook een naam – MAIN. Vervolgens configureren we de logger, door de uitvoer in te stellen op console en door de patroon lay-out te gebruiken. We zullen er later meer over praten in de blogpost. De uitvoer van het uitvoeren van de bovenstaande code zou als volgt zijn:

0 INFO com.sematext.blog.ExampleLog4jProperties - Initializing ExampleLog4j application

als we dat willen, kunnen we ook het log4j.properties bestand wijzigen en een genaamd gebruiken log4j.xml. Dezelfde configuratie met XML-indeling zou er als volgt uitzien:

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"><log4j:configuration> <appender name="MAIN" class="org.apache.log4j.ConsoleAppender"> <param name="Target" value="System.out"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%r %-5p %c %x - %m%n" /> </layout> </appender> <root> <priority value ="debug"></priority> <appender-ref ref="MAIN" /> </root></log4j:configuration>

als we nu de log4j.properties voor log4j.xml een en houd het in de classpath de uitvoering van onze voorbeeldtoepassing zou als volgt zijn:

0 INFO com.sematext.blog.ExampleLog4jXML - Initializing ExampleLog4j application

dus hoe weet Log4j welk bestand te gebruiken? Laten we dat eens bekijken.

initialisatieproces

het is van cruciaal belang om te weten dat Log4j geen veronderstellingen maakt met betrekking tot de omgeving waarin het draait. Log4j gaat niet uit van enige vorm van standaard log gebeurtenissen bestemmingen. Wanneer het Start zoekt het naar de log4j. configuration eigenschap en probeert het opgegeven bestand te laden als zijn configuratie. Als de locatie van het bestand niet kan worden geconverteerd naar een URL of het bestand niet aanwezig is, probeert het het bestand te laden vanuit het classpath.

dat betekent dat we de Log4j configuratie van classpath kunnen overschrijven door de-Dlog4j.configuration aan te bieden tijdens het opstarten en deze naar de juiste locatie te wijzen. Bijvoorbeeld, als we een bestand met de naam other opnemen.xml met de volgende inhoud:

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"><log4j:configuration> <appender name="MAIN" class="org.apache.log4j.ConsoleAppender"> <param name="Target" value="System.out"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%r %-5p %c %x - %m%n" /> </layout> </appender> <root> <priority value ="debug"></priority> <appender-ref ref="MAIN" /> </root></log4j:configuration>

en voer dan de code uit met-Dlog4j. configuration= / opt / sematext / other.xml de uitvoer van onze code zal als volgt zijn:

0 INFO com.sematext.blog.ExampleLog4jXML - Initializing ExampleLog4j application

Log4j Appenders

we hebben al appenders gebruikt in onze voorbeelden… nou, eigenlijk slechts één-de ConsoleAppender. Het enige doel is om de loggebeurtenissen naar de console te schrijven. Natuurlijk, met een groot aantal log gebeurtenissen en systemen die draaien in verschillende omgevingen schrijven van pure tekstgegevens naar de standaarduitvoer kan niet het beste idee zijn, tenzij je draait in containers. Dat is de reden waarom Log4j ondersteunt meerdere soorten Appenders. Hier zijn een paar veel voorkomende voorbeelden van Log4j appenders:

• ConsoleAppender – de appender die de loggebeurtenissen aan het systeem toevoegt.uit of systeem.fout met de standaard systeem.uit. Wanneer u deze appender gebruikt, ziet u uw logs in de console van uw applicatie.
• FileAppender – de appender die de loggebeurtenissen toevoegt aan een gedefinieerd bestand dat ze op het bestandssysteem opslaat.
• RollingFileAppender – de appender die de FileAppender uitbreidt en het bestand roteert wanneer het een bepaalde grootte bereikt. Het gebruik van RollingFileAppender voorkomt dat de logbestanden steeds zeer groot en moeilijk te onderhouden.
• SyslogAppender-de appender die de loggebeurtenissen naar een externe Syslog-daemon verzendt.
• JDBCAppender – de appender die de loggebeurtenissen in de database opslaat. Houd er rekening mee dat deze appender geen fouten zal opslaan en het is over het algemeen niet het beste idee om de log gebeurtenissen op te slaan in een database.
• Socket-Appender-de appender die de serialized log gebeurtenissen naar een externe socket stuurt. Houd er rekening mee dat deze appender geen lay-outs gebruikt omdat het de serialized, raw log gebeurtenissen verzendt.
• NullAppender – de appender die de loggebeurtenissen gewoon weggooit.

Bovendien kunt u meerdere Appenders instellen voor een enkele toepassing. U kunt bijvoorbeeld logs naar de console en naar een bestand sturen. De volgende log4j.eigenschappen bestandsinhoud zou precies dat doen:

log4j.rootLogger=DEBUG, MAIN, ROLLINGlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %x - %m%nlog4j.appender.ROLLING=org.apache.log4j.RollingFileAppenderlog4j.appender.ROLLING.File=/var/log/sematext/awesome.loglog4j.appender.ROLLING.MaxFileSize=1024KBlog4j.appender.ROLLING.MaxBackupIndex=10log4j.appender.ROLLING.layout=org.apache.log4j.PatternLayoutlog4j.appender.ROLLING.layout.ConversionPattern=%r %-5p %c %x - %m%n

onze root logger is geconfigureerd om alles te loggen vanaf de ernst van de foutopsporing en om de logs te sturen naar twee Appenders – de hoofd-en de rollende. De hoofdlogger is degene die we al zagen-degene die de gegevens naar de console stuurt.

de tweede logger, de zogenaamde ROLLING, is de interessantere in dit voorbeeld. Het maakt gebruik van de RollingFileAppender die de gegevens naar het bestand schrijft en laten we definiëren hoe groot het bestand kan zijn en hoeveel bestanden te houden. In ons geval moeten de logbestanden geweldig worden genoemd.log en schrijf de gegevens naar/var/log/ sematext / directory. Elk bestand mag maximaal 1024KB zijn en er mogen niet meer dan 10 bestanden worden opgeslagen. Als er meer bestanden worden verwijderd uit het bestandssysteem zodra log4j ze ziet.

na het uitvoeren van de code met de bovenstaande configuratie zou de console de volgende inhoud afdrukken:

0 INFO com.sematext.blog.ExampleAppenders - Starting ExampleAppenders application1 WARN com.sematext.blog.ExampleAppenders - Ending ExampleAppenders application

In de / var / log / sematext / awesome.logbestand dat we zouden zien:

0 INFO com.sematext.blog.ExampleAppenders - Starting ExampleAppenders application1 WARN com.sematext.blog.ExampleAppenders - Ending ExampleAppenders application

Appender Log Level

het leuke aan Appenders is dat ze hun niveau kunnen hebben waarmee rekening moet worden gehouden bij het loggen. Alle voorbeelden die we hebben gezien tot nu toe gelogd elk bericht dat de ernst van DEBUG of hoger had. Wat als we dat wilden veranderen voor alle klassen in de com.sematext.blog pakket? We hoeven alleen ons log4j. properties bestand te wijzigen:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %x - %m%nlog4j.logger.com.sematext.blog=WARN

Kijk naar de laatste regel in het bovenstaande configuratiebestand. We hebben gebruik gemaakt van de log4j. logger prefix en zei dat de logger genaamd com.sematext.blog mag alleen worden gebruikt voor Ernst niveaus waarschuwen en hoger, dus fout en fataal.

onze voorbeeldtoepascode ziet er als volgt uit:

public static void main(String args) { LOGGER.info("Starting ExampleAppenderLevel application"); LOGGER.warn("Ending ExampleAppenderLevel application");}

met de bovenstaande Log4j configuratie ziet de uitvoer van de logging er als volgt uit:

0 WARN com.sematext.blog.ExampleAppenderLevel - Ending ExampleAppenderLevel application

zoals je kunt zien, werd alleen het WARN level log opgenomen. Dat is precies wat we wilden.

Log4j-lay-outs

ten slotte, het deel van het log4j-logboekraamwerk dat de structuur van onze gegevens in ons logbestand bepaalt – de lay-out. Log4j biedt een paar standaard implementaties zoals PatternLayout, SimpleLayout, XMLLayout, HTMLLayout, EnchancedPatternLayout en de DateLayout.

in de meeste gevallen zult u de PatternLayout tegenkomen. Het idee achter deze lay-out is dat u een verscheidenheid aan opmaakopties kunt bieden om de structuur van de logs te definiëren. Enkele voorbeelden zijn::

• d-datum en tijd van de loggebeurtenis,
• m-bericht geassocieerd met de loggebeurtenis,
• t – threadnaam,
• n – platform – afhankelijk regelscheidingsteken,
• p-logniveau.

voor meer informatie over de beschikbare opties ga naar de officiële Log4j Javadocs voor de PatternLayout.

bij het gebruik van de PatternLayout kunnen we instellen welke optie we willen gebruiken. Laten we aannemen dat we de datum, de ernst van de log gebeurtenis, de thread omgeven door vierkante haakjes, en de boodschap van de log gebeurtenis willen schrijven. We kunnen een patroon als dit gebruiken:

%d %-5p - %m%n

het volledige log4j.properties bestand kan er in dit geval als volgt uitzien:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%d %-5p - %m%n

we gebruiken de %d om de datum weer te geven, de %- 5p om de ernst weer te geven met 5 tekens, %T voor thread, %m voor het bericht en % n voor regelscheidingsteken. De uitvoer die naar de console is geschreven na het uitvoeren van onze voorbeeldcode ziet er als volgt uit:

2021-02-02 11:49:49,003 INFO - Initializing ExampleLog4jFormatter application

geneste diagnostische Context

in de meeste toepassingen in de echte wereld bestaat de loggebeurtenis niet op zichzelf. Het is omgeven door een bepaalde context. Om een dergelijke context te bieden, per-thread, biedt Log4j de zogenaamde geneste diagnostische Context. Op die manier kunnen we een gegeven thread verbinden met aanvullende informatie, bijvoorbeeld een session identifier, net als in onze voorbeeldtoepassing:

NDC.push(String.format("Session ID: %s", "1234-5678-1234-0987"));LOGGER.info("Initializing ExampleLog4jNDC application");

bij gebruik van een patroon dat x-variabele bevat, zal aanvullende informatie worden opgenomen in elke logline voor de gegeven thread. In ons geval zal de uitvoer er zo uitzien:

0 INFO com.sematext.blog.ExampleLog4jNDC Session ID: 1234-5678-1234-0987 - Initializing ExampleLog4jNDC application

u kunt zien dat de informatie over de sessie-id zich in de logline bevindt. Gewoon ter referentie, het log4j.properties bestand dat we in dit voorbeeld hebben gebruikt ziet er als volgt uit:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %x - %m%n

in kaart gebrachte diagnostische Context

het tweede type contextuele informatie dat we in onze loggebeurtenissen kunnen opnemen, is in kaart gebrachte diagnostische context. Met behulp van de MDC-klasse kunnen we aanvullende key-value gerelateerde informatie verstrekken. Net als geneste diagnostische context is de toegewezen diagnostische context thread-bound.

laten we eens kijken naar onze voorbeeldtoepascode:

MDC.put("user", "[email protected]");MDC.put("step", "initial");LOGGER.info("Initializing ExampleLog4jNDC application");MDC.put("step", "launch");LOGGER.info("Starting ExampleLog4jNDC application");

we hebben twee contextvelden – de gebruiker en de stap. Om alle toegewezen diagnostische contextinformatie weer te geven die geassocieerd is met de log event gebruiken we gewoon de x variabele in onze patroondefinitie. Bijvoorbeeld::

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %X - %m%n

het starten van de bovenstaande code samen met de configuratie zou resulteren in de volgende uitvoer:

0 INFO com.sematext.blog.ExampleLog4jMDC {{step,initial}{user,[email protected]}} - Initializing ExampleLog4jNDC application1 INFO com.sematext.blog.ExampleLog4jMDC {{step,launch}{user,[email protected]}} - Starting ExampleLog4jNDC application

we kunnen ook kiezen welke informatie we gebruiken door het patroon te wijzigen. Bijvoorbeeld, om de gebruiker uit de toegewezen diagnostische context op te nemen, kunnen we een patroon als dit schrijven:

%r %-5p %c %X{user} - %m%n

deze keer zou de uitvoer er als volgt uitzien:

0 INFO com.sematext.blog.ExampleLog4jMDC [email protected] - Initializing ExampleLog4jNDC application0 INFO com.sematext.blog.ExampleLog4jMDC [email protected] - Starting ExampleLog4jNDC application

u kunt zien dat we in plaats van de algemene %X{user} de %X {user} hebben gebruikt. Dat betekent dat we geïnteresseerd zijn in de gebruiker variabele uit de toegewezen diagnostische context geassocieerd met een bepaalde log gebeurtenis.

migratie naar Log4j 2

migratie vanuit Log4j 1.x naar Log4j 2.x is niet moeilijk en in sommige gevallen kan het heel gemakkelijk zijn. Als je geen interne Log4j 1 hebt gebruikt.x klassen, je hebt configuratiebestanden gebruikt over het programmatisch instellen van loggers en je hebt niet de domconfigurator en PropertyConfigurator klassen gebruikt de migratie moet zo eenvoudig zijn als het opnemen van de log4j-1.2-api.jar jar bestand in plaats van de Log4j 1.x jar bestanden. Dat zou Log4j 2 toestaan.x om met je code te werken. Je zou de Log4j 2 moeten toevoegen.x jar bestanden, pas de configuratie aan, en voilà-je bent klaar.

als u meer wilt weten over Log4j 2.x Bekijk onze Java logging tutorial en zijn Log4j 2.X speciale sectie.

echter, als u interne Log4j 1 hebt gebruikt.x klassen, de officiële migratie gids over hoe te verplaatsen van Log4j 1.x naar Log4j 2.x zal erg behulpzaam zijn. Het bespreekt de benodigde code en configuratie veranderingen en zal van onschatbare waarde zijn bij twijfel.

gecentraliseerde logboekregistratie met Logbeheertools

het verzenden van loggebeurtenissen naar een console of een bestand kan goed zijn voor een enkele toepassing, maar het verwerken van meerdere instanties van uw toepassing en het correleren van de logboeken van meerdere bronnen is niet leuk wanneer de loggebeurtenissen zich in tekstbestanden op verschillende machines bevinden. In dergelijke gevallen, de hoeveelheid gegevens wordt snel onbeheersbaar en vereist speciale oplossingen – hetzij self-hosted of afkomstig van een van de leveranciers. En hoe zit het met containers waar je meestal niet eens logs naar bestanden schrijft? Hoe kunt u problemen oplossen en debuggen met een toepassing waarvan de logboeken zijn verzonden naar de standaarduitvoer of waarvan de container is uitgeschakeld?

dit is waar Log management services, log analysetools en cloud logging services een rol spelen. Het is een ongeschreven Java logging best practice onder ingenieurs om dergelijke oplossingen te gebruiken als je serieus bent over het beheer van uw logs en het krijgen van het meeste uit hen. Bijvoorbeeld, Sematext Logs, onze log monitoring en management software, lost alle hierboven genoemde problemen, en meer.

met een volledig beheerde oplossing zoals Sematext Logs, hoeft u geen ander deel van de omgeving te beheren – uw Doe-het-zelf logging oplossing, meestal gebouwd met behulp van stukken van de Elastic Stack. Dergelijke opstellingen kunnen klein en goedkoop beginnen, maar ze groeien vaak groot en duur. Niet alleen in termen van infrastructuurkosten, maar ook in termen van beheerskosten. Je weet wel, tijd en loon. We leggen meer uit over de voordelen van het gebruik van een managed service in onze blogpost over logging best practices.

alarmering en logaggregatie zijn ook cruciaal bij het omgaan met problemen. Uiteindelijk, voor Java-toepassingen, wilt u misschien garbage collection logs hebben zodra u garbage collection logging op en beginnen met het analyseren van de logs. Dergelijke logs gecorreleerd met statistieken zijn een onschatbare bron van informatie voor het oplossen van vuilnis collectie-gerelateerde problemen.

samenvatting

hoewel Log4j 1.x bereikte zijn einde van het leven een lange tijd geleden het is nog steeds aanwezig in een groot aantal legacy toepassingen gebruikt over de hele wereld. De migratie naar de jongere versie is vrij eenvoudig, maar kan aanzienlijke middelen en tijd vereisen en is meestal niet een topprioriteit. Vooral in grote ondernemingen waar de procedures, wettelijke vereisten of beide audits vereisen gevolgd door lange en dure tests voordat er iets kan worden gewijzigd in een reeds draaiend systeem. Maar voor degenen onder ons die net beginnen of denken over migratie – vergeet niet, Log4j 2.x is er, het is al volwassen, snel, veilig en zeer capabel.

maar ongeacht het framework dat u gebruikt voor het loggen van uw Java-toepassingen, raden we u zeker aan om uw inspanningen te combineren met een volledig beheerde log management oplossing, zoals Sematext Logs. Probeer het eens! Er is een 14-daagse gratis proefperiode beschikbaar voor u om te testen rijden.

Gelukkig loggen!