Log4j Tutorial: så här konfigurerar du loggen för effektiv Java-Applikationsloggning
att få synlighet i din applikation är avgörande när du kör din kod i produktion. Vad menar vi med synlighet? Främst saker som applikationsprestanda via mätvärden, applikationshälsa och tillgänglighet, dess loggar om du behöver felsöka det eller dess spår om du behöver ta reda på vad som gör det långsamt och hur man gör det snabbare.
Metrics ger dig information om prestanda för var och en av elementen i din Infrastruktur. Spår visar dig en bredare bild av kodkörningen och flödet tillsammans med kodkörningsmätningar. Slutligen kommer välgjorda loggar att ge en ovärderlig inblick i kodlogikens utförande och vad som hände i din kod. Var och en av de nämnda bitarna är avgörande för din ansökan och faktiskt det övergripande systemet observerbarhet. Idag kommer vi att fokusera endast på ett enda stycke – stockarna. För att vara mer exakt – på Java-applikationsloggar. Om du är intresserad av mätvärden, kolla in vår artikel om viktiga JVM-mätvärden du bör övervaka.
men innan vi kommer in i det, låt oss ta itu med ett problem som påverkat samhället med hjälp av denna ram. Den 9 December 2021 rapporterades en kritisk sårbarhet med smeknamnet Log4Shell. Identifierad som CVE-2021-44228 låter den en angripare ta fullständig kontroll över en maskin som kör Apache Log4j 2 version 2.14.1 eller lägre, så att de kan köra godtycklig kod på den sårbara servern. I vårt senaste blogginlägg om Log4jShell-sårbarheten detaljerade vi hur du bestämmer om du påverkas, hur du löser problemet och vad vi på Sematext har gjort för att skydda vårt system och användare.
Log4j 1.x slutet av livet
Tänk på att den 5 augusti 2015 Loggningstjänster Project Management Committee meddelade att Log4j 1.x hade nått sitt slut på livet. Alla användare rekommenderas att migrera till Log4j 2.x. i det här blogginlägget hjälper vi dig att förstå din nuvarande Log4j – inställning-specifikt log4j 2.X-version-och efter det hjälper jag dig att migrera till den senaste och bästa Log4j-versionen.
”Jag använder Log4j 1.x, vad ska jag göra?”. Var inte panik, det är inget fel med det. Gör en plan för övergång till Log4j 2.x. jag ska visa dig hur bara fortsätta läsa:). Din ansökan kommer att tacka dig för det. Du får säkerhetsfixar, prestandaförbättringar och mycket fler funktioner efter migrering.
”jag startar ett nytt projekt, vad ska jag göra?”. Använd bara Log4j 2.x direkt, tänk inte ens på Log4j 1.x. Om du behöver hjälp med det, kolla in den här Java-loggningshandledningen där jag förklarar allt du behöver.
logga in Java
det finns ingen magi bakom att logga in Java. Allt handlar om att använda en lämplig Java-klass och dess metoder för att generera logghändelser. Som vi diskuterade i Java-loggningsguiden finns det flera sätt att börja
naturligtvis är den mest naiva och inte den bästa vägen att följa bara med systemet.ut och System.fela klasser. Ja, du kan göra det och dina meddelanden går bara till standardutmatningen och standardfelet. Vanligtvis betyder det att det kommer att skrivas ut till konsolen eller skrivas till en fil av något slag eller till och med skickas till /dev/null och för alltid glömmas bort. Ett exempel på en sådan kod kan se ut så här:
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) ); }}
utmatningen av ovanstående kodkörning skulle vara enligt följande:
Starting my awesome applicationMy application class com.sematext.logging.log4jsystem.SystemExample started successfully
det är inte perfekt, eller hur? Jag har ingen information om vilken klass som genererade meddelandet och många, många fler ”små” saker som är avgörande och viktiga under felsökning.
det finns andra saker som saknas som inte är riktigt kopplade till felsökning. Tänk på exekveringsmiljön, flera applikationer eller mikrotjänster och behovet av att förena loggning för att förenkla loggens centraliseringspipelinekonfiguration. Använda systemet.ut, eller / och systemet.fel i vår kod för loggningsändamål skulle tvinga oss att göra om alla platser där vi använder den när vi behöver justera loggningsformatet. Jag vet att det är extremt, men tro mig, Vi har sett användningen av systemet.ut i produktionskod i ”traditionella” applikationsdistributionsmodeller! Naturligtvis loggar du till systemet.out är en lämplig lösning för containeriserade applikationer och du bör använda den utgång som passar din miljö. Kom ihåg det!
på grund av alla nämnda skäl och många fler som vi inte ens tänker på, bör du titta på ett av de möjliga loggbiblioteken, som Log4 j, Log4j 2, Logback eller till och med java.util.loggning som är en del av Java Development Kit. För detta blogginlägg kommer vi att använda Log4j.
Abstraktionsskiktet – SLF4J
ämnet att välja rätt loggningslösning för din Java-applikation är något som vi redan diskuterade i vår handledning om att logga in Java. Vi rekommenderar starkt att du läser åtminstone det nämnda avsnittet.
vi kommer att använda SLF4J, ett abstraktionslager mellan vår Java – kod och Log4j-loggningsbiblioteket efter eget val. Den enkla Loggningsfasaden ger bindningar för vanliga loggningsramar som Log4j, Logback och java.util.loggning. Föreställ dig processen att skriva ett loggmeddelande på följande förenklade sätt:
du kan fråga Varför använda ett abstraktionslager alls? Tja, svaret är ganska enkelt-så småningom kanske du vill ändra loggningsramen, uppgradera den, förena den med resten av din teknikstack. När du använder ett abstraktionslager är en sådan operation ganska enkel-du byter bara loggningsramberoenden och ger ett nytt paket. Om vi inte skulle använda ett abstraktionslager – skulle vi behöva ändra koden, potentiellt mycket kod. Varje klass som loggar något. Inte en mycket trevlig utveckling erfarenhet.
loggern
koden för din Java-applikation kommer att interagera med en standarduppsättning av nyckelelement som tillåter logghändelse skapande och manipulation. Vi har täckt de avgörande i vår Java loggning handledning, men låt mig påminna dig om en av de klasser som vi ständigt kommer att använda – Logger.
loggen är den viktigaste enheten som en applikation använder för att ringa loggningssamtal – skapa logghändelser. Logger-objektet används vanligtvis för en enda klass eller en enda komponent för att tillhandahålla kontextbunden till ett specifikt användningsfall. Det ger metoder för att skapa logghändelser med en lämplig loggnivå och vidarebefordra den för vidare bearbetning. Du skapar vanligtvis ett statiskt objekt som du kommer att interagera med, till exempel så här:
... Logger LOGGER = LoggerFactory.getLogger(MyAwesomeClass.class);
och det är allt. Nu när vi vet vad vi kan förvänta oss, låt oss titta på Log4j-biblioteket.
Log4j
det enklaste sättet att börja med Log4j är att inkludera biblioteket i klassvägen för din Java-applikation. För att göra det inkluderar vi det senaste tillgängliga log4j-biblioteket, vilket betyder version 1.2.17 i vår byggfil.
vi använder Gradle och i vår enkla applikation och avsnittet beroenden för Gradle build-fil ser ut som följer:
dependencies { implementation 'log4j:log4j:1.2.17'}
vi kan börja utveckla koden och inkludera loggning med 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"); }}
som du kan se i ovanstående kod initierade vi Logger-objektet med hjälp av den statiska getLogger-metoden och vi gav namnet på klassen. Efter att ha gjort det kan vi enkelt komma åt det statiska Logger-objektet och använda det för att producera logghändelser. Vi kan göra det i huvudmetoden.
en sidnot-getLogger-metoden kan också kallas med en sträng som ett argument, till exempel:
private static final Logger LOGGER = Logger.getLogger("com.sematext.blog");
det skulle innebära att vi vill skapa en logger och associera namnet com.sematext.blogga med det. Om vi kommer att använda samma namn någon annanstans i koden Log4j kommer att returnera samma Logger instans. Det är användbart om vi vill kombinera loggning från flera olika klasser på en enda plats. Till exempel loggar relaterade till betalning i en enda, dedikerad loggfil.
Log4j ger en lista över metoder som gör det möjligt att skapa nya logghändelser med hjälp av en lämplig loggnivå. De är:
- 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)
och en generisk metod:
- Offentlig ogiltig logg (nivånivå, Objektmeddelande)
vi pratade om Java loggning nivåer i vår Java loggning handledning blogginlägg. Om du inte känner till dem, ta några minuter att vänja sig vid dem eftersom loggnivåerna är avgörande för loggning. Om du precis har börjat med loggningsnivåer rekommenderar vi att du också går igenom vår loggnivåguide. Vi förklarar allt från vad de är till hur man väljer rätt och hur man använder dem för att få meningsfulla insikter.
om vi skulle köra ovanstående kod skulle utmatningen vi skulle få på standardkonsolen vara som följer:
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.
vi såg inte loggmeddelandet som vi förväntade oss. Log4j informerade oss om att det inte finns någon konfiguration närvarande. Oooops, låt oss prata om hur du konfigurerar Log4j…
Log4j-konfiguration
det finns flera sätt att konfigurera vår Log4j-loggning. Vi kan göra det programmatiskt – till exempel genom att inkludera ett statiskt initialiseringsblock:
static { BasicConfigurator.configure();}
ovanstående kod konfigurerar Log4j för att mata ut loggarna till konsolen i standardformatet. Utgången från att köra vår exempelapplikation skulle se ut som följer:
0 INFO com.sematext.blog.ExampleLog4jProgrammaticConfig - Initializing ExampleLog4j application
att konfigurera Log4j programmatiskt är dock inte så vanligt. Det vanligaste sättet är att antingen använda en egenskapsfil eller en XML-fil. Vi kan ändra vår kod och inkludera filen log4j. properties med följande innehåll:
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
på så sätt berättade vi Log4j att vi skapar root logger, som kommer att användas som standard. Dess standard loggningsnivå är inställd på DEBUG, vilket innebär att logghändelser med svårighetsgrad DEBUG eller högre kommer att inkluderas. Så felsöka, INFO, varna, fel och dödlig. Vi gav också vår logger ett namn-MAIN. Därefter konfigurerar vi loggen genom att ställa in dess utgång till konsol och genom att använda mönsterlayouten. Vi kommer att prata om det mer senare i blogginlägget. Utmatningen av att köra ovanstående kod skulle vara enligt följande:
0 INFO com.sematext.blog.ExampleLog4jProperties - Initializing ExampleLog4j application
om vi vill kan vi också ändra filen log4j.properties och använda en som heter log4j.xml. Samma konfiguration med XML-format skulle se ut som följer:
<!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>
om vi nu skulle ändra log4j. properties för log4j.xml en och behåll den i classpath utförandet av vår exempelapplikation skulle vara som följer:
0 INFO com.sematext.blog.ExampleLog4jXML - Initializing ExampleLog4j application
så hur vet Log4j vilken fil som ska användas? Låt oss titta på det.
Initialiseringsprocess
det är viktigt att veta att Log4j inte gör några antaganden om miljön den körs i. Log4j antar inte någon form av standardlogghändelser destinationer. När den startar Letar den efter egenskapen log4j.configuration och försöker ladda den angivna filen som dess konfiguration. Om platsen för filen inte kan konverteras till en URL eller om filen inte finns försöker den ladda filen från klassvägen.
det betyder att vi kan skriva över Log4j-konfigurationen från klassvägen genom att tillhandahålla-Dlog4j. – konfigurationen under start och peka den till rätt plats. Till exempel, om vi inkluderar en fil som heter other.xml med följande innehåll:
<!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>
och kör sedan ut kod med-Dlog4j.configuration=/opt/sematext/other.xml utmatningen från vår kod kommer att vara enligt följande:
0 INFO com.sematext.blog.ExampleLog4jXML - Initializing ExampleLog4j application
Log4j Appenders
vi använde redan appenders i våra exempel … ja, egentligen bara en – ConsoleAppender. Dess enda syfte är att skriva logghändelserna till konsolen. Naturligtvis, med ett stort antal logghändelser och system som körs i olika miljöer kan det inte vara den bästa ideen att skriva ren textdata till standardutmatningen, om du inte kör i behållare. Det är därför Log4j stöder flera typer av Appenders. Här är några vanliga exempel på Log4j appenders:
- ConsoleAppender-den appender som lägger logghändelserna till systemet.ut eller System.fela med standard är systemet.ut. När du använder denna appender kommer du att se dina loggar i konsolen i din ansökan.
- FileAppender – den appender som lägger till logghändelserna i en definierad fil som lagrar dem i filsystemet.
- RollingFileAppender – den appender som utökar FileAppender och roterar filen när den når en definierad storlek. Användningen av RollingFileAppender förhindrar att loggfilerna blir mycket stora och svåra att underhålla.
- SyslogAppender – appender skickar logghändelserna till en fjärr Syslog-demon.
- JDBCAppender – den appender som lagrar logghändelserna i databasen. Tänk på att denna appender inte lagrar fel och det är i allmänhet inte den bästa tanken att lagra logghändelserna i en databas.
- SocketAppender – den appender som skickar serialiserade logghändelser till en fjärruttag. Tänk på att denna appender inte använder layouter eftersom den skickar serialiserade, råa logghändelser.
- NullAppender – appender som bara kasserar logghändelserna.
Dessutom kan du ha flera tillägg konfigurerade för en enda applikation. Du kan till exempel skicka loggar till konsolen och till en fil. Följande log4j.egenskaper filinnehåll skulle göra exakt det:
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
vår root logger är konfigurerad för att logga allt från DEBUG svårighetsgrad och att skicka loggarna till två Appenders – huvud och rullande. HUVUDLOGGEN är den som vi redan såg – den som skickar data till konsolen.
den andra loggen, den som heter ROLLING är den mer intressanta i det här exemplet. Den använder RollingFileAppender som skriver data till filen och låt oss definiera hur stor filen kan vara och hur många filer att hålla. I vårt fall ska loggfilerna kallas fantastiska.logga och skriv data till/var/ log / sematext / directory. Varje fil bör vara högst 1024kb och det bör inte finnas mer än 10 filer lagrade. Om det finns fler filer kommer de att tas bort från filsystemet så snart log4j ser dem.
efter att ha kört koden med ovanstående konfiguration skulle konsolen skriva ut följande innehåll:
0 INFO com.sematext.blog.ExampleAppenders - Starting ExampleAppenders application1 WARN com.sematext.blog.ExampleAppenders - Ending ExampleAppenders application
i /var/log/sematext / häftigt.loggfil vi skulle se:
0 INFO com.sematext.blog.ExampleAppenders - Starting ExampleAppenders application1 WARN com.sematext.blog.ExampleAppenders - Ending ExampleAppenders application
Appender Log Level
det fina med Appenders är att de kan ha sin nivå som bör beaktas vid loggning. Alla exempel som vi hittills har sett loggade varje meddelande som hade svårighetsgraden av DEBUG eller högre. Tänk om vi ville ändra det för alla klasser i com.sematext.bloggpaket? Vi skulle bara behöva ändra vår log4j. properties-fil:
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
titta på den sista raden i ovanstående konfigurationsfilen. Vi har använt log4j. logger prefix och sa att logger kallas com.sematext.blogg bör endast användas för svårighetsgrader Varna och ovan, så fel och dödlig.
vårt exempel programkod ser ut så här:
public static void main(String args) { LOGGER.info("Starting ExampleAppenderLevel application"); LOGGER.warn("Ending ExampleAppenderLevel application");}
med ovanstående Log4j-konfiguration ser utmatningen från loggningen ut som följer:
0 WARN com.sematext.blog.ExampleAppenderLevel - Ending ExampleAppenderLevel application
som du kan se var endast VARNINGSNIVÅLOGGEN inkluderad. Det är precis vad vi ville ha.
Log4j-layouter
slutligen, den del av Log4j – loggningsramen som styr hur våra data är strukturerade i vår loggfil-layouten. Log4j ger några standardimplementeringar som PatternLayout, SimpleLayout, XMLLayout, HTMLLayout, EnchancedPatternLayout och DateLayout.
i de flesta fall kommer du att stöta på PatternLayout. Tanken bakom denna layout är att du kan tillhandahålla en mängd olika formateringsalternativ för att definiera loggens struktur. Några av exemplen är:
- d-datum och tid för logghändelsen,
- m – meddelande associerat med logghändelsen,
- t – trådnamn,
- n – plattformsberoende linjeavskiljare,
- p – loggnivå.
för mer information om tillgängliga alternativ, gå över till de officiella Log4j Javadocs för PatternLayout.
när vi använder PatternLayout kan vi konfigurera vilket alternativ vi vill använda. Låt oss anta att vi skulle vilja skriva datumet, svårighetsgraden av logghändelsen, tråden omgiven av fyrkantiga parenteser och meddelandet om logghändelsen. Vi kan använda ett mönster som detta:
%d %-5p - %m%n
den fullständiga log4j. properties-filen i det här fallet kan se ut som följer:
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
vi använder %d för att visa datumet, % – 5p för att visa svårighetsgraden med 5 tecken, %t för tråd, %m för meddelandet och %n för linjeavgränsare. Utgången som skrivs till konsolen efter att ha kört vår exempelkod ser ut som följer:
2021-02-02 11:49:49,003 INFO - Initializing ExampleLog4jFormatter application
kapslade diagnostiska sammanhang
i de flesta verkliga applikationer logghändelsen inte existerar på egen hand. Det är omgivet av ett visst sammanhang. För att tillhandahålla ett sådant sammanhang, per tråd, tillhandahåller Log4j det så kallade kapslade diagnostiska sammanhanget. På så sätt kan vi binda en given tråd med ytterligare information, till exempel en sessionsidentifierare, precis som i vår exempelapplikation:
NDC.push(String.format("Session ID: %s", "1234-5678-1234-0987"));LOGGER.info("Initializing ExampleLog4jNDC application");
när du använder ett mönster som innehåller X-variabel kommer ytterligare information att inkluderas i varje logglinje för den givna tråden. I vårt fall kommer utmatningen att se ut så här:
0 INFO com.sematext.blog.ExampleLog4jNDC Session ID: 1234-5678-1234-0987 - Initializing ExampleLog4jNDC application
du kan se att informationen om sessionsidentifieraren finns i logglinjen. Bara för referens ser filen log4j. properties som vi använde i det här exemplet ut som följer:
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
Mapped Diagnostic Context
den andra typen av kontextuell information som vi kan inkludera i våra logghändelser är mapped diagnostic context. Med hjälp av MDC-klassen kan vi tillhandahålla ytterligare nyckelvärdesrelaterad information. I likhet med kapslade diagnostiska sammanhang är det mappade diagnostiska sammanhanget trådbundet.
Låt oss titta på vårt exempel applikationskod:
MDC.put("user", "[email protected]");MDC.put("step", "initial");LOGGER.info("Initializing ExampleLog4jNDC application");MDC.put("step", "launch");LOGGER.info("Starting ExampleLog4jNDC application");
vi har två kontextfält-användaren och steget. För att visa all den mappade diagnostiska kontextinformationen som är associerad med logghändelsen använder vi bara X-variabeln i vår mönsterdefinition. Till exempel:
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
starta ovanstående kod tillsammans med konfigurationen skulle resultera i följande utgång:
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
vi kan också välja vilken information som ska användas genom att ändra mönstret. Till exempel, för att inkludera användaren från det mappade diagnostiska sammanhanget kan vi skriva ett mönster så här:
%r %-5p %c %X{user} - %m%n
den här gången skulle utmatningen se ut som följer:
0 INFO com.sematext.blog.ExampleLog4jMDC [email protected] - Initializing ExampleLog4jNDC application0 INFO com.sematext.blog.ExampleLog4jMDC [email protected] - Starting ExampleLog4jNDC application
du kan se att istället för den allmänna %X har vi använt %X{user}. Det betyder att vi är intresserade av användarvariabeln från det mappade diagnostiska sammanhanget som är associerat med en given logghändelse.
migrering till Log4j 2
migrering från Log4j 1.X till Log4j 2.x är inte svårt och i vissa fall kan det vara väldigt enkelt. Om du inte använde någon intern Log4j 1.X-klasser, du har använt konfigurationsfiler via programmatiskt inställning av loggers och du använde inte DOMConfigurator och PropertyConfigurator klasserna migreringen ska vara så enkel som att inkludera log4j-1.2-api.jar jar-fil istället för Log4j 1.x jar-filer. Det skulle tillåta Log4j 2.x för att arbeta med din kod. Du skulle behöva lägga till Log4j 2.X jar-filer, justera konfigurationen, och voil brasilian – du är klar.
om du vill lära dig mer om Log4j 2.x kolla in vår Java loggning handledning och dess Log4j 2.X dedikerad sektion.
men om du använde intern Log4j 1.X-klasser, den officiella migrationsguiden om hur man flyttar från Log4j 1.X till Log4j 2.x kommer att vara till stor hjälp. Den diskuterar nödvändiga kod-och konfigurationsändringar och kommer att vara ovärderlig när du är osäker.
centraliserad loggning med Logghanteringsverktyg
att skicka logghändelser till en konsol eller en fil kan vara bra för en enda applikation, men att hantera flera instanser av din applikation och korrelera loggarna från flera källor är inte kul när logghändelserna finns i textfiler på olika maskiner. I sådana fall blir mängden data snabbt ohanterlig och kräver dedikerade lösningar – antingen självvärd eller kommer från en av leverantörerna. Och vad sägs om behållare där du vanligtvis inte ens skriver loggar till filer? Hur felsöker och felsöker du ett program vars loggar släpptes till standardutmatning eller vars behållare har dödats?
det är här logghanteringstjänster, logganalysverktyg och molnloggningstjänster spelar in. Det är en oskriven Java loggning bästa praxis bland ingenjörer att använda sådana lösningar när du menar allvar med att hantera dina loggar och få ut det mesta av dem. Till exempel löser Sematextloggar, vår loggövervaknings-och hanteringsprogramvara, alla problem som nämns ovan och mer.
med en helt hanterad lösning som Sematextloggar behöver du inte hantera en annan del av miljön – din DIY-loggningslösning, vanligtvis byggd med bitar av den elastiska stacken. Sådana inställningar kan börja små och billiga, men de blir ofta stora och dyra. Inte bara när det gäller infrastrukturkostnader utan också förvaltningskostnader. Du vet, tid och lön. Vi förklarar mer om fördelarna med att använda en hanterad tjänst i vårt blogginlägg om bästa praxis för loggning.
varning och loggaggregering är också avgörande när man hanterar problem. Så småningom, för Java-applikationer, kanske du vill ha sophämtningsloggar när du aktiverar sophämtningsloggning och börjar analysera loggarna. Sådana loggar som är korrelerade med mätvärden är en ovärderlig informationskälla för felsökning av sophämtningsrelaterade problem.
sammanfattning
även om Log4j 1.x nådde sin livslängd för länge sedan det är fortfarande närvarande i ett stort antal äldre applikationer som används över hela världen. Migreringen till sin yngre version är ganska enkel, men kan kräva betydande resurser och tid och är vanligtvis inte högsta prioritet. Särskilt i stora företag där förfarandena, lagkraven eller båda kräver revisioner följt av långa och dyra tester innan något kan ändras i ett redan löpande system. Men för de av oss som just har börjat eller funderar på migration – kom ihåg, Log4j 2.x är där, det är redan moget, snabbt, säkert och mycket kapabelt.
men oavsett vilket ramverk du använder för att logga dina Java-applikationer, rekommenderar vi definitivt att du gifter dig med dina ansträngningar med en helt hanterad logghanteringslösning, till exempel Sematextloggar. Ge det ett försök! Det finns en 14-dagars gratis provperiod tillgänglig för dig att provköra den.
Glad loggning!