Log på Spring Boot

1. Oversigt

I denne korte vejledning skal vi udforske de vigtigste logningsmuligheder, der er tilgængelige i Spring Boot.

Dybere information om Logback findes i A Guide to Logback, mens Log4j2 introduceres i Intro til Log4j2 - Appenders, Layouts og Filters.

2. Første opsætning

Lad os først oprette et Spring Boot-modul. Den anbefalede måde at gøre det på er at bruge Spring Initializr, som vi dækker i vores Spring Boot Tutorial.

Lad os nu oprette vores eneste klassefil, LoggingController:

@RestController offentlig klasse LoggingController {Logger logger = LoggerFactory.getLogger (LoggingController.class); @RequestMapping ("/") public String index () {logger.trace ("A TRACE Message"); logger.debug ("A DEBUG Message"); logger.info ("En INFO-besked"); logger.warn ("A WARN Message"); logger.error ("En FEJL-meddelelse"); returner "Howdy! Tjek Logs for at se output ..."; }}

Når vi har indlæst webapplikationen, vi kan udløse disse logningslinjer ved blot at besøge // localhost: 8080 /.

3. Nulstillingslogning

Spring Boot er en meget nyttig ramme. Det giver os mulighed for at glemme størstedelen af konfigurationsindstillingerne, hvoraf mange den automatisk indstiller.

I tilfælde af logning er den eneste obligatoriske afhængighed Apache Commons-logning.

Vi skal kun importere det, når vi bruger Spring 4.x (Spring Boot 1.x), da det leveres af Spring Framework's forår-jcl modul i Spring 5 (Spring Boot 2.x).

Vi skal ikke bekymre os om import forår-jcl overhovedet, hvis vi bruger en Spring Boot Starter (som vi næsten altid er). Det er fordi hver starter, som vores spring-boot-starter-web, afhænger af spring-boot-starter-logging, som allerede trækker ind forår-jcl for os.

3.1. Standard logback-logning

Når du bruger startere, bruges Logback som standard til logning.

Spring Boot forkonfigurerer det med mønstre og ANSI-farver for at gøre standardoutputtet mere læsbart.

Lad os nu køre applikationen og besøge // localhost: 8080 / side, og se hvad der sker i konsollen:

Som vi kan se, Loggerens standardlogningsniveau er forudindstillet til INFO, hvilket betyder det SPOR og FEJLFINDE beskeder er ikke synlige.

For at aktivere dem uden at ændre konfigurationen, vi kan passere -fejlfinde eller –Spor argumenter på kommandolinjen:

java -jar target / spring-boot-logging-0.0.1-SNAPSHOT.jar --trace

3.2. Logniveauer

Spring Boot også giver os adgang til en mere detaljeret logniveauindstilling via miljøvariabler. Der er flere måder, vi kan opnå dette på.

For det første kan vi indstille vores logningsniveau inden for vores VM-indstillinger:

-Dlogging.level.org.springframework = TRACE -Dlogging.level.com.baeldung = TRACE

Alternativt, hvis vi bruger Maven, kan vi definer vores logindstillinger via kommandolinjen:

mvn spring-boot: run -Dspring-boot.run.arguments = - logging.level.org.springframework = TRACE, - logging.level.com.baeldung = TRACE

Når vi arbejder med Gradle, kan vi videregive logindstillinger gennem kommandolinjen. Dette kræver indstilling af bootRun opgave.

Når det er gjort, kører vi applikationen:

./gradlew bootRun -Pargs = - logging.level.org.springframework = TRACE, - logging.level.com.baeldung = TRACE

Hvis vi ønsker at ændre ordlængden permanent, kan vi gøre det i application.properties fil som beskrevet her:

logging.level.root = WARN logging.level.com.baeldung = SPOR

Endelig kan vi skift loggeniveauet permanent ved hjælp af vores konfigurationsfil til logningsrammen.

Vi nævnte, at Spring Boot Starter bruger Logback som standard. Lad os se, hvordan vi definerer et fragment af en Logback-konfigurationsfil, hvor vi indstiller niveauet for to separate pakker:

Huske på, at hvis logniveauet for en pakke er defineret flere gange ved hjælp af de forskellige muligheder nævnt ovenfor, men med forskellige logniveauer, vil det laveste niveau blive brugt.

Så hvis vi indstiller logningsniveauerne ved hjælp af Logback, Spring Boot og miljøvariabler på samme tid, vil logniveauet være SPOR, da det er det laveste blandt de ønskede niveauer.

4. Logbogskonfigurationslogning

Selvom standardkonfigurationen er nyttig (for eksempel at komme i gang på nul tid under POC'er eller hurtige eksperimenter), er det højst sandsynligt ikke nok til vores daglige behov.

Lad os se hvordan man inkluderer en Logback-konfiguration med en anden farve og et logningsmønster med separate specifikationer for konsol og fil output, og med en anstændig rullende politik for at undgå at generere store logfiler.

For det første skal vi finde en løsning, der giver mulighed for at håndtere vores logningsindstillinger alene i stedet for at forurene application.properties, som ofte bruges til mange andre applikationsindstillinger.

Når en fil i klassestien har et af følgende navne, indlæses Spring Boot automatisk over standardkonfigurationen:

logback-spring.xml
logback.xml
logback-spring.groovy
logback.groovy

Spring anbefaler at bruge -forår variant over de almindelige, når det er muligt, som beskrevet her.

Lad os skrive en simpel logback-spring.xml:

      % sort (% d {ISO8601})% fremhævning (% - 5niveau) [% blå (% t)]% gul (% C {1.}):% msg% n% kastbar $ {LOGS} / spring-boot- logger.log% d% p% C {1.} [% t]% m% n $ {LOGS} / arkiveret / spring-boot-logger-% d {åååå-MM-dd}.% i.log 10 MB

Og når vi kører applikationen, her er output:

Som vi kan se, logger det nu SPOR og FEJLFINDE meddelelser, og det overordnede konsolmønster er både tekstmæssigt og kromatisk anderledes end før.

Det logger nu også på en fil i en / logs mappe oprettet under den aktuelle sti og arkiverer den gennem en rullende politik.

5. Log4j2-konfigurationslogning

Mens Apache Commons Logging er kernen, og Logback er den angivne referenceimplementering, er alle routinger til de andre logbiblioteker allerede inkluderet for at gøre det let at skifte til dem.

For at kunne bruge et hvilket som helst logbibliotek bortset fra Logback er vi dog nødt til at udelukke det fra vores afhængigheder.

For hver starter som denne (det er den eneste i vores eksempel, men vi kunne have mange af dem):

 org.springframework.boot spring-boot-starter-web

vi er nødt til at gøre det til en tynd version, og (kun en gang) tilføje vores alternative bibliotek her gennem en starter selv:

 org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-logging org.springframework.boot spring-boot-starter-log4j2

På dette tidspunkt er vi nødt til at placere en fil, der hedder en af følgende i klassestien:

log4j2-spring.xml
log4j2.xml

Vi udskriver gennem Log4j2 (over SLF4J) uden yderligere ændringer.

Lad os skrive en simpel log4j2-spring.xml:

        % d% p% C {1.} [% t]% m% n

Og når vi kører applikationen, her er output:

Som vi kan se, er outputen meget forskellig fra Logback - et bevis på, at vi bruger Log4j2 fuldt ud nu.

Ud over XML-konfigurationen tillader Log4j2 os også at bruge en YAML- eller JSON-konfiguration, beskrevet her.

6. Log4j2 Uden SLF4J

Vi kan også bruge Log4j2 indbygget uden at passere gennem SLF4J.

For at gøre det bruger vi simpelthen de indfødte klasser:

import org.apache.logging.log4j.Logger; import org.apache.logging.log4j.LogManager; // [...] Logger logger = LogManager.getLogger (LoggingController.class);

Vi behøver ikke at udføre nogen anden ændring af standard Log4j2 Spring Boot-konfiguration.

Vi kan nu udnytte de helt nye funktioner i Log4j2 uden at sidde fast med den gamle SLF4J-grænseflade. Men vi er også bundet til denne implementering, og vi bliver nødt til at omskrive vores kode, når vi skifter til en anden logningsramme.

7. Logning med Lombok

I de eksempler, vi har set indtil videre har vi måttet erklære en forekomst af en logger fra vores logningsramme.

Denne kedelpladekode kan være irriterende. Vi kan undgå det ved hjælp af forskellige kommentarer, der er introduceret af Lombok.

Vi bliver først nødt til at tilføje Lombok-afhængigheden i vores build-script for at arbejde med det:

 org.projectlombok lombok 1.18.4 leveret

7.1. @ Slf4j og @CommonsLog

SLF4J og Apache Commons Logging API'er giver os fleksibiliteten til at ændre vores logningsramme uden indflydelse på vores kode.

Og det kan vi brug Lomboks @ Slf4j og @CommonsLog kommentarer for at tilføje den rigtige loggerforekomst i vores klasse: org.slf4j.Logger til SLF4J og org.apache.commons.logging.Log til Apache Commons-logning.

For at se disse kommentarer i aktion, lad os oprette en klasse, der ligner LoggingController men uden en logger-instans. Vi kalder det som LombokLoggingController og kommentere det med @ Slf4j:

@RestController @ Slf4j offentlig klasse LombokLoggingController {@RequestMapping ("/ lombok") offentlig strengindeks () {log.trace ("A TRACE Message"); log.debug ("A DEBUG Message"); log.info ("En INFO-besked"); log.warn ("A WARN Message"); log.error ("En FEJL-meddelelse"); returner "Howdy! Tjek Logs for at se output ..."; }}

Bemærk, at vi har justeret uddraget kun lidt ved hjælp af log som vores logger-instans. Dette skyldes, at tilføjelse af kommentaren @ Slf4j automatisk tilføjer et felt med navnet log.

Med Nulkonfigurationslogning, applikationen bruger den underliggende logføring implementering Logback til logning. Tilsvarende bruges Log4j2-implementering til logning med Log4j2-konfigurationslogning.

Vi får den samme adfærd, når vi erstatter kommentaren @ Slf4j med @CommonsLog.

7.2. @ Log4j2

Vi kan bruge kommentaren @ Log4j2 at bruge Log4j2 direkte. Så vi foretager en simpel ændring til LombokLoggingController at bruge @ Log4j2 i stedet for @ Slf4j eller @CommonsLog:

@RestController @ Log4j2 offentlig klasse LombokLoggingController {@RequestMapping ("/ lombok") offentlig strengindeks () {log.trace ("A TRACE Message"); log.debug ("A DEBUG Message"); log.info ("En INFO-besked"); log.warn ("A WARN Message"); log.error ("En FEJL-meddelelse"); returner "Howdy! Tjek Logs for at se output ..."; }}

Bortset fra logning er der andre kommentarer fra Lombok, der hjælper med at holde vores kode ren og pæn. Mere information om dem findes i Introduktion til Project Lombok, og vi har også en tutorial om opsætning af Lombok med Eclipse og IntelliJ.

8. Pas på Java Util-logning

Spring Boot understøtter også JDK-logning gennem logging.properties konfigurationsfil.

Der er dog tilfælde, hvor det ikke er en god ide at bruge det. Fra dokumentationen:

Der er kendte classloading-problemer med Java Util Logging, der forårsager problemer, når de kører fra en 'eksekverbar jar'. Vi anbefaler, at du undgår det, når det kører fra en 'eksekverbar krukke', hvis det overhovedet er muligt.

Det er også en god praksis, når du bruger Spring 4 til manuelt at ekskludere commons-logging i pom.xml for at undgå potentielle sammenstød mellem loggningsbibliotekerne. Spring 5 håndterer det i stedet automatisk, så vi behøver ikke gøre noget, når du bruger Spring Boot 2.

9. JANSI på Windows

Mens Unix-baserede operativsystemer som Linux og Mac OS X som standard understøtter ANSI-farvekoder, på en Windows-konsol, vil alt være desværre monokromatisk.

Windows kan få ANSI-farver gennem et bibliotek kaldet JANSI.

Vi skal dog være opmærksomme på de mulige ulemper ved klasseindlæsning.

Vi skal importere og eksplicit aktivere det i konfigurationen som følger:

Logback:

  true [% thread]% highlight (% - 5level)% cyan (% logger {15}) -% msg% n

Log4j2:

ANSI escape-sekvenser understøttes indbygget på mange platforme, men er ikke som standard på Windows. For at aktivere ANSI-support skal du tilføje Jansi jar til vores applikation og indstille ejendom log4j.skipJansi til falsk. Dette gør det muligt for Log4j at bruge Jansi til at tilføje ANSI-escape-koder, når de skriver til konsollen.

Bemærk: Før Log4j 2.10 var Jansi aktiveret som standard. Det faktum, at Jansi kræver native kode, betyder det Jansi kan kun læsses af en enkelt klasse læsser. For webapplikationer betyder det Jansi-krukken skal være i webcontainerens klassesti. For at undgå at forårsage problemer for webapplikationer forsøger Log4j ikke længere automatisk at indlæse Jansi uden eksplicit konfiguration fra Log4j 2.10 og fremefter.

Det er også værd at bemærke:

Layoutdokumentationssiden indeholder nyttige Log4j2 JANSI-oplysninger i fremhæv {mønster} {stil} afsnit.
Mens JANSI kan farve output, er Spring Boot's Banner (native eller tilpasset via banner.txt fil) forbliver monokromatisk.

10. Konklusion

Vi har set de vigtigste måder at grænseflade med de store logningsrammer inden for et Spring Boot-projekt.

Vi undersøgte også de største fordele og faldgruber ved hver løsning.

Som altid er den fulde kildekode tilgængelig på GitHub.

streamalism.org