System.out.println vs Loggers

1. Hvorfor loggere?

Mens du skriver et program eller utvikler en applikasjon for bedriftsproduksjon, bruker System.out.println ser ut til å være det enkleste og enkleste alternativet. Det er ingen ekstra biblioteker som skal legges til på kursstien, og ingen ekstra konfigurasjoner skal gjøres.

Men bruker System.out.println kommer med flere ulemper som påvirker dets brukervennlighet i mange situasjoner. I denne opplæringen vil vi diskutere hvorfor og når vi ønsker å bruke en Logger over vanlig System.out og System.err. Vi viser også noen raske eksempler ved hjelp av Log4J2-loggingsrammeverket.

2. Oppsett

Før vi begynner, la oss se på de nødvendige Maven-avhengighetene og konfigurasjonene.

2.1. Maven avhengigheter

La oss starte med å legge til Log4J2-avhengigheten til vår pom.xml:

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

Vi finner de nyeste versjonene av log4j-api og log4j-kjerne på Maven Central.

2.2. Log4J2-konfigurasjon

Bruken av System.out krever ingen ekstra konfigurasjon. For å bruke Log4J2 trenger vi imidlertid en log4j.xml konfigurasjonsfil:

Nesten alle loggerrammer vil kreve et visst nivå av konfigurasjon, enten programmatisk eller gjennom en ekstern konfigurasjonsfil, for eksempel XML-filen som vises her.

3. Separere loggutdata

3.1. System.out og System.err

Når vi distribuerer applikasjonen vår til en server som Tomcat, bruker serveren sin egen logger. Hvis vi bruker System.out, stokkene havner i catalina.out. Det er mye lettere å feilsøke søknaden vår hvis logger settes i en egen fil. Med Log4j2 må vi inkludere en filappender i konfigurasjonen for å lagre applikasjonslogger i en egen fil.

Også med System.out.println, det er ingen kontroll eller filtrering av hvilke logger som skal skrives ut. Den eneste mulige måten å skille loggene på er å bruke System.out.println for informasjonslogger og System.err.println for feillogger:

System.out.println ("Dette er en informasjonsmelding"); System.err.println ("Dette er en feilmelding");

3.2. Log4J2 loggningsnivåer

I feilsøkings- eller utviklingsmiljøer ønsker vi å se all informasjonen applikasjonen skriver ut. Men i et live enterprise-program betyr flere logger en økning i ventetid. Loggerrammer som Log4J2 gir flere loggnivåkontroller:

  • FATAL
  • FEIL
  • VARSLE
  • INFO
  • DEBUG
  • SPOR
  • ALLE

Ved å bruke disse nivåene, vi kan enkelt filtrere når og hvor vi skal skrive ut hvilken informasjon:

logger.trace ("Trace log message"); logger.debug ("Feilsøkingsloggmelding"); logger.info ("Informasjonsloggmelding"); logger.error ("Feilloggmelding"); logger.warn ("Advarsel loggmelding"); logger.fatal ("Fatal log message");

Vi kan også konfigurere nivåene for hver kildekodepakke hver for seg. For mer informasjon om loggnivåkonfigurasjon, se vår Java Logging-artikkel.

4. Skrive logger til filer

4.1. Omdirigering System.out og System.err

Det er mulig å rute System.out.println til en fil ved hjelp av System.setOut () metode:

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

Og i tilfelle System.err:

PrintStream errStream = ny PrintStream (ny fil ("errFile.txt")); System.setErr (errStream); System.err.println ("Dette er en feilmelding om artikkelen");

Når du omdirigerer utdata til en fil ved hjelp av System.out eller System.err, vi kan ikke kontrollere filstørrelsen, dermed fortsetter filen å vokse så lenge programmet kjører.

Etter hvert som filstørrelsen vokser, kan det være vanskelig å åpne eller analysere disse større loggene.

4.2. Logge på filer med Log4J2

Log4J2 gir en mekanisme for systematisk å skrive logger i filer og også rulle filene basert på visse retningslinjer. For eksempel kan vi konfigurere filene som skal rulles ut basert på et mønster for dato / tid:

Eller vi kan rull filene basert på størrelse når de når en gitt terskel:

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

5. Logge på eksterne systemer

Som vi har sett i forrige avsnitt, tillater loggerrammer å skrive loggene til en fil. Tilsvarende gir de også appenders å sende logger til andre systemer og applikasjoner. Dette gjør det mulig å sende logger til en Kafka Stream eller en Elasticsearch-database ved hjelp av Log4J appenders i stedet for å bruke System.out.println.

Se vår artikkel om Log4j-appender for mer informasjon om hvordan du bruker slike appenders.

6. Tilpasse loggutdata

Ved bruk av Loggers kan vi tilpasse hvilken informasjon som skal skrives ut sammen med den faktiske meldingen. Informasjonen vi kan skrive ut inkluderer pakkenavn, loggnivå, linjenummer, tidsstempel, metodenavn, etc.

Selv om dette ville være mulig med System.out.println, det vil kreve mye manuelt arbeid, mens loggerammer gir denne funksjonaliteten ut av boksen. Med loggere, vi kan ganske enkelt definere et mønster i loggerkonfigurasjonen:

Hvis vi vurderer Log4J2 for logger-rammeverket vårt, er det flere mønstre vi kan velge mellom eller tilpasse. Se den offisielle Log4J2-dokumentasjonen for å lære mer om dem.

7. Konklusjon

Denne artikkelen forklarer forskjellige grunner til at du skal bruke et logger-rammeverk og hvorfor ikke bare stole på System.out.println for våre applikasjonslogger. Selv om det er forsvarlig å bruke System.out.println for små testprogrammer, foretrekker vi ikke å bruke den som vår viktigste loggkilde for en bedriftens produksjonsapplikasjon.

Som alltid er kodeeksemplene i artikkelen tilgjengelig på GitHub.


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