• Articles
• admin

at få synlighed i din applikation er afgørende, når du kører din kode i produktionen. Hvad mener vi med synlighed? Primært ting som applikationsydelse via metrics, applikationssundhed og tilgængelighed, dens logfiler, hvis du har brug for at fejlfinde det, eller dets spor, hvis du har brug for at finde ud af, hvad der gør det langsomt, og hvordan du gør det hurtigere.

Metrics giver dig oplysninger om ydeevnen for hvert af elementerne i din infrastruktur. Spor vil vise dig en bredere visning af koden udførelse og flyde sammen med kode udførelse metrics. Endelig vil veludformede logfiler give et uvurderligt indblik i kodelogikudførelsen og hvad der skete i din kode. Hver af de nævnte stykker er afgørende for din ansøgning og faktisk den samlede systemobservabilitet. I dag vil vi kun fokusere på et enkelt stykke – logfilerne. For at være mere præcis – på Java-applikationslogfiler. Hvis du er interesseret i metrics, skal du tjekke vores artikel om vigtige JVM-metrics, du skal overvåge.

men før vi kommer ind i det, lad os løse et problem, der påvirkede samfundet ved hjælp af denne ramme. Den 9. December 2021 blev der rapporteret om en kritisk sårbarhed med tilnavnet Log4Shell. Identificeret som CVE-2021-44228, det lader en hacker tage fuld kontrol over en maskine, der kører Apache Log4j 2 version 2.14.1 eller lavere, så de kan udføre vilkårlig kode på den sårbare server. I vores seneste blogindlæg om log4jshell-sårbarheden, vi detaljerede, hvordan du bestemmer, om du er berørt, hvordan du løser problemet, og hvad vi, på Sematekst, har gjort for at beskytte vores system og brugere.

Log4j 1.6945 >

Husk, at Logging Services Project Management Committee den 5.August 2015 meddelte, at Log4j 1.K havde nået sin ende af livet. Alle brugere rådes til at migrere til Log4j 2.i dette blogindlæg hjælper vi dig med at forstå din nuværende Log4J – opsætning-specifikt log4j 2.derefter hjælper jeg dig med at migrere til den nyeste og bedste Log4j-version.

“jeg bruger Log4j 1.hvad skal jeg gøre?”. Gå ikke i panik, der er ikke noget galt med det. Lav en plan for overgang til Log4j 2.jeg viser dig, hvordan du bare fortsætter med at læse:). Din ansøgning vil takke dig for det. Du får sikkerhedsrettelser, ydelsesforbedringer og langt flere funktioner efter migrering.

“jeg starter et nyt projekt, hvad skal jeg gøre?”. Brug bare Log4j 2.tænk ikke engang på Log4j 1.x. Hvis du har brug for hjælp til det, skal du tjekke denne Java logging tutorial, hvor jeg forklarer alt hvad du har brug for.

Logning i Java

der er ingen magi bag logning i Java. Det hele kommer ned til at bruge en passende Java-klasse og dens metoder til at generere loghændelser. Som vi diskuterede i Java logging guide er der flere måder, du kan starte

selvfølgelig er den mest naive og ikke den bedste vej at følge bare at bruge systemet.ud og System.err klasser. Ja, du kan gøre det, og dine meddelelser vil bare gå til standard output og standard fejl. Normalt betyder det, at det vil blive udskrevet til konsollen eller skrevet til en fil af en eller anden art eller endda sendt til /dev/null og for evigt blive glemt. Et eksempel på en sådan kode kunne se sådan ud:

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) ); }}

udgangen af ovenstående kodeudførelse ville være som følger:

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

det er ikke perfekt, vel? Jeg har ingen oplysninger om, hvilken klasse der genererede beskeden og mange, mange flere “små” ting, der er afgørende og vigtige under debugging.

der er andre ting, der mangler, der ikke rigtig er forbundet med debugging. Tænk på eksekveringsmiljøet, flere applikationer eller mikroservices og behovet for at forene logning for at forenkle konfigurationen af logcentraliseringsrørledningen. Brug af systemet.ud, eller / og System.fejl i vores kode til logningsformål ville tvinge os til at gentage alle de steder, hvor vi bruger det, når vi har brug for at justere logningsformatet. Jeg ved, det er ekstremt, men tro mig, Vi har set brugen af systemet.ud i produktion kode i “traditionelle” Ansøgning implementering modeller! Selvfølgelig logger du på systemet.out er en ordentlig løsning til containeriserede applikationer, og du skal bruge det output, der passer til dit miljø. Husk på det!

på grund af alle de nævnte grunde og mange flere, som vi ikke engang tænker på, skal du undersøge et af de mulige logbiblioteker, som Log4 j, Log4j 2, Logback eller endda java.util.logning, der er en del af Java-Udviklingssættet. Til dette blogindlæg bruger vi Log4j.

Abstraktionslaget – SLF4J

emnet for at vælge den rigtige logningsløsning til din Java-applikation er noget, som vi allerede diskuterede i vores tutorial om logning i Java. Vi anbefaler stærkt at læse mindst det nævnte afsnit.

vi bruger SLF4J, et abstraktionslag mellem vores Java – kode og Log4j-det logbogsbibliotek, vi vælger. Den enkle logning Facade giver bindinger til fælles logning rammer som Log4j, Logback og java.util.skovhugst. Forestil dig processen med at skrive en logmeddelelse på følgende, forenklede måde:

du kan spørge, Hvorfor bruge et abstraktionslag overhovedet? Nå, svaret er ret simpelt – i sidste ende vil du måske ændre logningsrammen, opgradere den, forene den med resten af din teknologistak. Når du bruger et abstraktionslag sådan operation er forholdsvis enkel-du bare udveksle logning rammer afhængigheder og give en ny pakke. Hvis vi ikke skulle bruge et abstraktionslag-skulle vi ændre koden, potentielt masser af kode. Hver klasse, der logger noget. Ikke en meget flot udviklingsoplevelse.

loggeren

koden til din Java-applikation vil interagere med et standard sæt nøgleelementer, der tillader oprettelse og manipulation af loghændelser. Vi har dækket de afgørende i Vores Java logging tutorial, men lad mig minde dig om en af de klasser, som vi konstant vil bruge – loggeren.

loggeren er den vigtigste enhed, som et program bruger til at foretage logning af opkald – Opret loghændelser. Loggerobjektet bruges normalt til en enkelt klasse eller en enkelt komponent til at give kontekstbundet til en bestemt brugssag. Det giver metoder til at oprette loghændelser med et passende logniveau og videregive det til videre behandling. Du opretter normalt et statisk objekt, som du vil interagere med, for eksempel sådan:

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

og det er alt. Nu hvor vi ved, hvad vi kan forvente, lad os se på Log4j-biblioteket.

Log4j

den enkleste måde at starte med Log4j er at inkludere biblioteket i classpath i din Java-applikation. For at gøre det inkluderer vi det nyeste tilgængelige log4j-bibliotek, hvilket betyder version 1.2.17 i vores build-fil.

vi bruger Gradle og i vores enkle applikation, og afhængighedsafsnittet for Gradle build-filen ser ud som følger:

dependencies { implementation 'log4j:log4j:1.2.17'}

vi kan begynde at udvikle koden og inkludere logning ved hjælp af 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 ovenstående kode initialiserede vi Loggerobjektet ved hjælp af den statiske getLogger-metode, og vi gav navnet på klassen. Efter at have gjort det kan vi nemt få adgang til det statiske Loggerobjekt og bruge det til at producere loghændelser. Det kan vi gøre i hovedmetoden.

One side note-getLogger-metoden kan også kaldes med en streng som et argument, for eksempel:

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

det ville betyde, at vi ønsker at oprette en logger og knytte navnet på com.sematekst.blog med det. Hvis vi vil bruge det samme navn andre steder i koden Log4j vil returnere den samme Logger instans. Det er nyttigt, hvis vi ønsker at kombinere logning fra flere forskellige klasser på et enkelt sted. For eksempel logfiler relateret til betaling i en enkelt, dedikeret logfil.

Log4j indeholder en liste over metoder, der tillader oprettelse af nye loghændelser ved hjælp af et passende logniveau. De er:

• offentlig void trace (objekt besked)
• offentlig void debug(objekt besked)
• offentlig void info(objekt besked)
• offentlig void advarsel(objekt besked)
• offentlig void fejl(objekt besked)
• offentlig void fatal(objekt besked)

en generisk metode:

• offentlig tomrumslog (niveau niveau, Objektmeddelelse)

vi talte om Java logging niveauer i Vores Java logging tutorial blogindlæg. Hvis du ikke er opmærksom på dem, skal du tage et par minutter på at vænne dig til dem, da logniveauerne er afgørende for logning. Hvis du lige er kommet i gang med at logge niveauer, anbefaler vi dog, at du også går over vores guide til logniveauer. Vi forklarer alt fra hvad de er til, hvordan man vælger den rigtige, og hvordan man bruger dem til at få meningsfuld indsigt.

hvis vi skulle køre ovenstående kode, ville output, vi ville få på standardkonsollen, være som følger:

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å ikke den logmeddelelse, vi forventede. Log4j informerede os om, at der ikke er nogen konfiguration til stede. Oooops, lad os tale om, hvordan du konfigurerer Log4j…

Log4j-konfiguration

der er flere måder, vi kan konfigurere vores Log4j-logning på. Vi kan gøre det programmatisk – for eksempel ved at inkludere en statisk initialiseringsblok:

static { BasicConfigurator.configure();}

ovenstående kode konfigurerer Log4j til at udsende logfilerne til konsollen i standardformatet. Udgangen af at køre vores eksempel ansøgning ville se ud som følger:

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

opsætning af Log4j programmatisk er dog ikke særlig almindelig. Den mest almindelige måde ville være at enten bruge en egenskabsfil eller en HML-fil. Vi kan ændre vores kode og inkludere Log4J.properties-filen med følgende indhold:

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å den måde fortalte vi Log4j, at vi opretter root logger, der vil blive brugt som standard. Dens standard logging niveau er indstillet til DEBUG, hvilket betyder, at log begivenheder med sværhedsgrad DEBUG eller højere vil blive inkluderet. Så DEBUG, INFO, advare, fejl, og FATAL. Vi gav også vores logger et navn-MAIN. Dernæst konfigurerer vi loggeren ved at indstille dens output til konsol og ved at bruge mønsterlayoutet. Vi vil tale om det mere senere i blogindlægget. Udgangen af at køre ovenstående kode ville være som følger:

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

hvis vi ønsker det, kan vi også ændre Log4J. properties-filen og bruge en kaldet log4j.xml. Den samme konfiguration ved hjælp af HML-format ville se ud som følger:

<!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>

hvis vi nu ville ændre log4j. properties for log4j.xml en og hold den i klassestien udførelsen af vores eksempelapplikation ville være som følger:

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

så hvordan ved Log4j, hvilken fil der skal bruges? Lad os se på det.

Initialiseringsproces

det er afgørende at vide, at Log4j ikke gør nogen antagelser om det miljø, det kører i. Log4j antager ikke nogen form for standard log begivenheder destinationer. Når den starter, ser den efter Log4J.configuration-egenskaben og forsøger at indlæse den angivne fil som dens konfiguration. Hvis placeringen af filen ikke kan konverteres til en URL, eller filen ikke er til stede, forsøger den at indlæse filen fra classpath.

det betyder, at vi kan overskrive Log4J-konfigurationen fra classpath ved at levere-dlog4j. – konfigurationen under opstart og pege den på den rigtige placering. For eksempel, hvis vi inkluderer en fil kaldet andet.med følgende indhold:

<!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>

og derefter køre ud kode med-Dlog4j.configuration=/opt/sematekst/andet.output fra vores kode vil være som følger:

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

Log4j-tilføjere

vi har allerede brugt tilføjere i vores eksempler… ja, virkelig bare en – ConsoleAppender. Dets eneste formål er at skrive loghændelserne til konsollen. Selvfølgelig, med et stort antal loghændelser og systemer, der kører i forskellige miljøer, er det måske ikke den bedste ide at skrive rene tekstdata til standardudgangen, medmindre du kører i containere. Derfor understøtter Log4j flere typer tilføjere. Her er et par almindelige eksempler på Log4j-tilføjere:

• ConsoleAppender-den appender, der tilføjer loghændelserne til systemet.ud eller System.err med standard er systemet.uden. Når du bruger denne appender, vil du se dine logfiler i konsollen til din applikation.
• FileAppender – den appender, der tilføjer loghændelserne til en defineret fil, der gemmer dem på filsystemet.
• RollingFileAppender – den appender, der udvider Fileappenderen og roterer filen, når den når en defineret størrelse. Brugen af RollingFileAppender forhindrer logfilerne i at blive meget store og svære at vedligeholde.
• SyslogAppender – appenderen sender loghændelserne til en ekstern Syslog-dæmon.
• JDBCAppender – den appender, der gemmer loghændelserne til databasen. Husk, at denne appender ikke gemmer fejl, og det er generelt ikke den bedste ide at gemme loghændelserne i en database.
• SocketAppender – appenderen, der sender de serialiserede loghændelser til en fjernstik. Husk, at denne appender ikke bruger layout, fordi den sender de serialiserede, rå loghændelser.
• NullAppender – appenderen, der bare kasserer loghændelserne.

derudover kan du have flere tilføjere konfigureret til en enkelt applikation. Du kan f.eks. sende logfiler til konsollen og til en fil. Følgende log4j.egenskaber fil indhold ville gøre netop 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

vores root logger er konfigureret til at logge alt startende fra DEBUG sværhedsgrad og til at sende logfilerne til to tilføjere – de vigtigste og rullende. HOVEDLOGGEREN er den, vi allerede har set – den der sender dataene til konsollen.

den anden logger, den der hedder ROLLING, er den mere interessante i dette eksempel. Det bruger RollingFileAppender som skriver data til filen og lad os definere, hvor stor filen kan være, og hvor mange filer til at holde. I vores tilfælde skal logfilerne kaldes fantastiske.log og skriv dataene til/var/log/ sematekst / mappe. Hver fil skal maksimalt være 1024 KB, og der bør ikke være mere end 10 filer gemt. Hvis der er flere filer, fjernes de fra filsystemet, så snart log4j ser dem.

efter at have kørt koden med ovenstående konfiguration ville konsollen udskrive følgende indhold:

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

I /var / log / sematekst / fantastisk.logfil vi ville se:

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

Appender Log Level

det gode ved Appenders er, at de kan have deres niveau, som bør tages i betragtning ved logning. Alle de eksempler, vi hidtil har set, loggede hver meddelelse, der havde sværhedsgraden af DEBUG eller højere. Hvad hvis vi ønskede at ændre det for alle klasser i com.sematekst.blog pakke? Vi skulle kun ændre vores 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

se på den sidste linje i ovenstående konfigurationsfil. Vi har brugt Log4J. logger præfiks og sagde, at loggeren kaldet com.sematekst.blog bør kun bruges til sværhedsgrader advarer og derover, så fejl og FATAL.

vores eksempel på applikationskode ser sådan ud:

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

med ovenstående Log4j-konfiguration ser Udgangen af loggen ud som følger:

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

som du kan se, var kun ADVARSELSNIVEAULOGGEN inkluderet. Det var præcis, hvad vi ønskede.

Log4j Layouts

endelig den del af Log4J logging rammer, der styrer den måde, vores data er struktureret i vores logfil – layoutet. Log4j giver et par standard implementeringer som PatternLayout, SimpleLayout, Htmllayout, HTMLLayout, EnchancedPatternLayout og DateLayout.

i de fleste tilfælde vil du støde på Mønsteretlayout. Ideen bag dette layout er, at du kan give en række formateringsmuligheder til at definere strukturen af logfilerne. Nogle af eksemplerne er:

• d-dato og klokkeslæt for loghændelsen,
• m – meddelelse tilknyttet loghændelsen,
• t – trådnavn,
• n – platformafhængig linjeseparator,
• p – logniveau.

For mere information om de tilgængelige muligheder gå over til de officielle Log4j Javadocs for PatternLayout.

når du bruger Mønsteretlayout kan vi konfigurere, hvilken mulighed vi gerne vil bruge. Lad os antage, at vi gerne vil skrive datoen, sværhedsgraden af loghændelsen, tråden omgivet af firkantede parenteser og meddelelsen om loghændelsen. Vi kunne bruge et mønster som dette:

%d %-5p - %m%n

den fulde log4j. properties-fil i dette tilfælde kan se ud som følger:

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 bruger %d til at vise datoen, % – 5p til at vise sværhedsgraden ved hjælp af 5 tegn, %t for tråd, %m for meddelelsen og %n for linjeseparator. Udgangen, der er skrevet til konsollen efter at have kørt vores eksempelkode, ser ud som følger:

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

indlejret diagnostisk kontekst

i de fleste virkelige applikationer findes loghændelsen ikke alene. Det er omgivet af en bestemt kontekst. At tilvejebringe en sådan kontekst, per-tråd, Log4j giver den såkaldte indlejrede diagnostiske kontekst. På den måde kan vi binde en given tråd med yderligere oplysninger, for eksempel en sessionsidentifikator, ligesom i vores eksempelapplikation:

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

når du bruger et mønster, der indeholder en variabel, vil yderligere oplysninger blive inkluderet i hver logline for den givne tråd. I vores tilfælde vil udgangen se sådan ud:

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

du kan se, at oplysningerne om sessionsidentifikatoren findes i loglinjen. Bare til reference ser Log4J. properties-filen, som vi brugte i dette eksempel, ud som følger:

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

kortlagt diagnostisk kontekst

den anden type kontekstuelle oplysninger, som vi kan medtage i vores loghændelser, er kortlagt diagnostisk kontekst. Ved hjælp af MDC-klassen kan vi give yderligere nøglerelaterede oplysninger. I lighed med indlejret diagnostisk kontekst er den kortlagte diagnostiske kontekst trådbundet.

lad os se på vores eksempel applikationskode:

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 to kontekstfelter-brugeren og trinnet. For at vise alle de kortlagte diagnostiske kontekstoplysninger, der er knyttet til loghændelsen, bruger vi bare variablen i vores mønsterdefinition. For eksempel:

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

lancering af ovenstående kode sammen med konfigurationen ville resultere i følgende output:

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 også vælge, hvilke oplysninger der skal bruges ved at ændre mønsteret. For eksempel at inkludere brugeren fra den kortlagte diagnostiske kontekst kunne vi skrive et mønster som dette:

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

denne gang output ville se ud som følger:

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

du kan se, at i stedet for den generelle %S har vi brugt %S{bruger}. Det betyder, at vi er interesseret i brugervariablen fra den kortlagte diagnostiske kontekst, der er knyttet til en given loghændelse.

Migration til Log4j 2

Migration fra Log4j 1.til Log4j 2.det er ikke svært, og i nogle tilfælde kan det være meget nemt. Hvis du ikke brugte nogen intern Log4j 1.har brugt konfigurationsfiler over programmatisk opsætning af loggere, og du brugte ikke DOMConfigurator-og PropertyConfigurator-klasserne migreringen skal være så enkel som at inkludere log4j-1.2-api.jar jar fil i stedet for Log4j 1.jar-filer. Det ville tillade Log4j 2.at arbejde med din kode. Du skal tilføje Log4j 2.JAR-filer, juster konfigurationen og voil – du er færdig.

hvis du vil vide mere om Log4j 2.tjek vores Java logging tutorial og dens Log4j 2.dedikeret sektion.

men hvis du brugte intern Log4j 1.den officielle migrationsvejledning om, hvordan man flytter fra Log4j 1.til Log4j 2.vil være meget nyttigt. Den diskuterer de nødvendige kode-og konfigurationsændringer og vil være uvurderlig, når du er i tvivl.

centraliseret logning med Loghåndteringsværktøjer

afsendelse af loghændelser til en konsol eller en fil kan være godt for en enkelt applikation, men det er ikke sjovt at håndtere flere forekomster af din applikation og korrelere logfilerne fra flere kilder, når loghændelserne er i tekstfiler på forskellige maskiner. I sådanne tilfælde bliver mængden af data hurtigt uhåndterlig og kræver dedikerede løsninger – enten selvhostet eller kommer fra en af leverandørerne. Og hvad med containere, hvor du typisk ikke engang skriver logfiler til filer? Hvordan fejlfinder og debugger du et program, hvis logfiler blev udsendt til standardoutput, eller hvis container er blevet dræbt?

det er her log management services, log analyseværktøjer og cloud logging services kommer i spil. Det er en uskreven Java logning bedste praksis blandt ingeniører til at bruge sådanne løsninger, når du er seriøs omkring at styre dine logfiler og få mest muligt ud af dem. For eksempel løser Sematekstlogfiler, vores logovervågnings-og styringsprogram alle de ovennævnte problemer og meget mere.

med en fuldt administreret løsning som Sematekstlogfiler behøver du ikke styre et andet stykke af miljøet – din DIY-logningsløsning, typisk bygget ved hjælp af stykker af den elastiske stak. Sådanne opsætninger kan starte små og billige, men de vokser ofte store og dyre. Ikke kun med hensyn til infrastrukturomkostninger, men også administrationsomkostninger. Tid og løn. Vi forklarer mere om fordelene ved at bruge en administreret tjeneste i vores blogindlæg om logning af bedste praksis.

alarmering og log sammenlægning er også afgørende, når der beskæftiger sig med problemer. Til sidst, for Java-applikationer, kan du have garbage collection logs, når du tænder garbage collection logge på og begynde at analysere logfilerne. Sådanne logfiler korreleret med målinger er en uvurderlig kilde til information til fejlfinding af affaldsindsamlingsrelaterede problemer.

Resume

selvom Log4j 1.det er stadig til stede i et stort antal ældre applikationer, der bruges over hele verden. Migrationen til sin yngre version er ret enkel, men kan kræve betydelige ressourcer og tid og er normalt ikke en topprioritet. Især i store virksomheder, hvor procedurerne, lovkravene eller begge kræver revisioner efterfulgt af lange og dyre test, før noget kan ændres i et allerede kørende system. Men for dem af os, der lige er begyndt eller tænker på migration – husk, Log4j 2.den er der, den er allerede moden, hurtig, sikker og meget dygtig.

men uanset hvilken ramme du bruger til at logge dine Java-applikationer, anbefaler vi bestemt at gifte dig med din indsats med en fuldt administreret logstyringsløsning, såsom Sematekstlogfiler. Giv det en chance! Der er en 14-dages gratis prøveperiode til rådighed for dig at prøvekøre den.

glad logning!