System.out.println vs Loggers

1. Hvorfor loggere?

Mens du skriver et program eller udvikler en virksomheds produktionsapplikation ved hjælp af System.out.println synes at være den enkleste og nemmeste mulighed. Der er ingen ekstra biblioteker, der skal føjes til klassestien, og der skal ikke foretages yderligere konfigurationer.

Men ved hjælp af System.out.println kommer med flere ulemper, der påvirker dets anvendelighed i mange situationer. I denne vejledning diskuterer vi hvorfor og hvornår vi ønsker at bruge en logger over almindelig gammel System.out og System.err. Vi viser også nogle hurtige eksempler ved hjælp af Log4J2-logningsrammen.

2. Opsætning

Før vi begynder, lad os se på de krævede Maven-afhængigheder og konfigurationer.

2.1. Maven afhængigheder

Lad os starte med at tilføje Log4J2-afhængighed til vores pom.xml:

 org.apache.logging.log4j log4j-api 2.12.1 org.apache.logging.log4j log4j-core 2.12.1 

Vi kan finde de nyeste versioner af log4j-api og log4j-kerne på Maven Central.

2.2. Log4J2-konfiguration

Brugen af System.out kræver ingen yderligere konfiguration. For at bruge Log4J2 har vi dog brug for en log4j.xml konfigurationsfil:

Næsten alle loggerrammer kræver et vis konfigurationsniveau, enten programmatisk eller gennem en ekstern konfigurationsfil, såsom XML-filen vist her.

3. Adskillelse af logoutput

3.1. System.out og System.err

Når vi distribuerer vores applikation til en server som Tomcat, bruger serveren sin egen logger. Hvis vi bruger System.out, logfiler ender i catalina.out. Det er meget lettere at debugge vores applikation, hvis logfiler placeres i en separat fil. Med Log4j2 skal vi medtage en filappender i konfigurationen for at gemme applikationslogfiler i en separat fil.

Også med System.out.println, er der ingen kontrol eller filtrering af, hvilke logfiler der skal udskrives. Den eneste mulige måde at adskille logfilerne på er at bruge System.out.println for informationslogfiler og System.err.println til fejllogfiler:

System.out.println ("Dette er en informationsbesked"); System.err.println ("Dette er en fejlmeddelelse");

3.2. Log4J2 logningsniveauer

I fejlfindings- eller udviklingsmiljøer ønsker vi at se alle de oplysninger, applikationen udskriver. Men i en live virksomhedsapplikation betyder flere logfiler en stigning i ventetid. Loggerrammer som Log4J2 giver flere kontrolniveauer på logniveau:

  • FATAL
  • FEJL
  • ADVARE
  • INFO
  • FEJLFINDE
  • SPOR
  • ALLE

Brug disse niveauer, Vi kan nemt filtrere, hvornår og hvor de oplysninger skal udskrives:

logger.trace ("Trace log message"); logger.debug ("Fejlfindingslogmeddelelse"); logger.info ("Info logmeddelelse"); logger.error ("Fejllogmeddelelse"); logger.warn ("Advar logmeddelelse"); logger.fatal ("Fatal logmeddelelse");

Vi kan også konfigurere niveauerne for hver kildekodepakke individuelt. For flere detaljer om konfiguration af logniveau henvises til vores artikel om Java-logning.

4. Skrivning af logfiler til filer

4.1. Omlægning System.out og System.err

Det er muligt at rute System.out.println til en fil ved hjælp af System.setOut () metode:

PrintStream outStream = ny PrintStream (ny fil ("outFile.txt")); System.setOut (outStream); System.out.println ("Dette er en baeldung-artikel");

Og i tilfælde af System.err:

PrintStream errStream = ny PrintStream (ny fil ("errFile.txt")); System.setErr (errStream); System.err.println ("Dette er en baeldung artikelfejl");

Når du omdirigerer output til en fil ved hjælp af System.out eller System.err, vi kan ikke kontrollere filstørrelsen, dermed fortsætter filen med at vokse i løbet af applikationens kørsel.

Da filstørrelsen vokser, kan det være svært at åbne eller analysere disse større logfiler.

4.2. Logge på filer med Log4J2

Log4J2 giver en mekanisme til systematisk at skrive logfiler i filer og også rulle filerne baseret på bestemte politikker. For eksempel kan vi konfigurer de filer, der skal rulles ud på baggrund af et dato- / tidsmønster:

Eller vi kan rull filerne baseret på størrelse, når de når en given tærskel:

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

5. Logning til eksterne systemer

Som vi har set i det foregående afsnit tillader loggerrammer at skrive logfiler til en fil. På samme måde leverer de også appenders til at sende logfiler til andre systemer og applikationer. Dette gør det muligt at sende logfiler til en Kafka Stream eller en Elasticsearch-database ved hjælp af Log4J appenders i stedet for at bruge System.out.println.

Der henvises til vores Log4j appender-artikel for flere detaljer om, hvordan man bruger sådanne appenders.

6. Tilpasning af logoutput

Ved hjælp af loggere kan vi tilpasse, hvilke oplysninger der skal udskrives sammen med den aktuelle meddelelse. De oplysninger, vi kan udskrive, inkluderer pakkenavn, logniveau, linjenummer, tidsstempel, metode navn osv.

Mens dette ville være muligt med System.out.println, det ville kræve meget manuelt arbejde, mens logningsrammer giver denne funktionalitet ud af kassen. Med loggere, vi kan simpelthen definere et mønster i loggerkonfigurationen:

Hvis vi overvejer Log4J2 til vores logger-ramme, er der flere mønstre, som vi kan vælge imellem eller tilpasse. Se den officielle Log4J2-dokumentation for at lære mere om dem.

7. Konklusion

Denne artikel forklarer forskellige grunde til, at man bruger en logger-ramme, og hvorfor ikke kun stole på System.out.println til vores applikationslogfiler. Mens det er forsvarligt at bruge System.out.println til små testprogrammer foretrækker vi ikke at bruge det som vores vigtigste logningskilde til en virksomheds produktionsapplikation.

Som altid er kodeeksemplerne i artiklen tilgængelige på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found