Hvordan Log4J2 Fungerer: 10 Måter å Få Mest Mulig ut av det
Log4j2 Er den oppdaterte versjonen av det populære og innflytelsesrike log4j-biblioteket, som brukes mye i Hele Java-økosystemet i så mange år. Versjon 2.x beholder alle loggfunksjonene til forgjengeren og bygger på det grunnlaget med noen betydelige forbedringer, spesielt innen ytelse.og selvfølgelig, gitt hvordan instrumental logging er for enhver applikasjon, både for revisjon og feilsøking, er det en ganske viktig beslutning å velge et solid loggbibliotek.I de følgende avsnittene skal vi se på hvorfor log4j2-biblioteket er et godt valg for den avgjørelsen, og hvordan vi kan bruke den i et program.
Basic Log4j2 Configuration
for å begynne å bruke log4j2 i prosjektet ditt, trenger du bare å legge til log4j-kjerneavhengigheten. Hvis Du bruker Maven, kan du legge til følgende avhengighet til pom.xml-fil:
og hvis du jobber Med Gradle, må du legge til avhengigheten til bygningen.gradle file:
dependencies { compile group: 'org.apache.logging.log4j', name: 'log4j-core', version: '2.8.2'}
ut av boksen vil log4j2 automatisk gi en enkel konfigurasjon, hvis du ikke eksplisitt definerer en selv. Standardkonfigurasjonen logger til konsollen PÅ FEILNIVÅ eller høyere.
for å begynne å logge meldinger ved hjelp av denne grunnleggende konfigurasjonen, er alt du trenger å gjøre, å få En Logger-forekomst ved Hjelp Av LogManager-klassen:
private static Logger logger = LogManager.getLogger(MyService.class);
deretter kan du bruke logger-objektet med metoder som svarer til loggnivået du vil ha:
logger.error("This is an error message");
Tilpasse Log4j2-Konfigurasjonen
en egendefinert log4j2-konfigurasjon kan opprettes enten programmatisk eller gjennom en konfigurasjonsfil.
biblioteket støtter config-filer skrevet I XML, JSON, YAML, samt .egenskaper format. HER skal VI bruke XML til å diskutere alle eksempler primært.
Først kan du overstyre standardkonfigurasjonen ved å opprette en log4j2.xml-fil på classpath:
La oss se nærmere på kodene som brukes i denne enkle konfigurasjonen:
- Konfigurasjon: rotelementet i en log4j2 konfigurasjonsfil; statusattributtet representerer nivået der interne log4j-hendelser skal logges
- Appenders: dette elementet inneholder en liste over appenders; i vårt eksempel er en appender som svarer Til Systemkonsollen definert
- Loggers: dette elementet inneholder en liste Over Logger forekomster. Rotelementet er en standardlogger som sender ut alle meldinger
Det er viktig å forstå At Rotloggeren er obligatorisk i hver konfigurasjon. Som diskutert, hvis du ikke gir en, vil den automatisk bli konfigurert som standard med En Konsoll appender og FEILLOGGNIVÅET.
Konfigurere Appenders
i log4j2-arkitekturen er en appender i utgangspunktet ansvarlig for å sende loggmeldinger til et bestemt utgangsmål.
her er noen av de mest nyttige typene appenders som biblioteket gir:
for bedre å forstå hvordan appenders fungerer, la Oss Se På Noen Konfigurasjonseksempler.
RollingFileAppender
Logging alt i en enkelt fil er selvsagt ikke ideell. Det er vanligvis mye bedre å rulle over den aktive loggfilen regelmessig-som Er akkurat Hva RollingFileAppender gjør.
Du vil også kunne gå utover det grunnleggende med denne typen appender og konfigurere både en tilpasset utløsende policy og rollover-strategi.
utløsingspolicyen bestemmer når loggfilen rulles, noe som betyr at en ny fil opprettes, mens overføringsstrategien bestemmer hvordan filen rulles.
som et raskt eksempel, la oss konfigurere en appender som oppretter en ny loggfil basert på 3 policyer:
- OnStartupTriggeringPolicy – en ny loggfil opprettes hver gang JVM starter
- TimeBasedTriggeringPolicy – loggfilen rulles basert på et dato/klokkeslett mønster
- SizeBasedTriggeringPolicy – filen rulles når den når en viss størrelse
Konfigurasjonen vil bruke defaultrolloverstrategy:
Du kan se hvor fleksibel denne konfigurasjonsstilen er, og hvordan du kan justere den nøyaktige semantikken til loggstrategien din-ned til minste detalj.
JDBCAppender
som navnet antyder, bruker denne appenderen JDBC til å skrive logger til en relasjonsdatabase.
for denne konfigurasjonen må du definere En ConnectionSource, som enten kan være EN Jndi-Datakilde eller en tilpasset Connectionsfactory. Loggeren bruker ConnectionSource for å få JDBC-tilkoblinger, og derfor er det viktig å bruke et tilkoblingsbasseng for bedre ytelse.
for å konfigurere appender I XML config-filen, kan DU bruke jdbc-taggen:
SOM du kan se, er jndi-datakilden ganske enkelt angitt ved hjelp av jndiname-attributtet For DataSource-taggen. Sammen Med ConnectionSource kan du definere tabellen og kolonnene som skal brukes til lagring av loggdataene.
FailoverAppender
Til Slutt, La Oss ta en titt på FailoverAppender; dette definerer en primær appender og en liste over sikkerhetskopier som vil gå inn for å håndtere logging i tilfelle den primære mislykkes.
du kan for eksempel konfigurere en primær JDBCAppender, med en sekundær RollingFile og Console appenders i tilfelle en databasetilkobling ikke kan opprettes:
i et produksjonsmiljø er det alltid en god ide å ha en failover-strategi for loggingsmekanismen.
Konfigurere Oppsett
mens appenders er ansvarlige for å sende loggmeldinger til et mål, brukes layoutene av appenders til å definere hvordan en loggmelding skal formateres.
her er en kort beskrivelse av noen av de mer brukte layoutene som log4j2 tilbyr:
- PatternLayout – konfigurerer meldinger i henhold til Et Strengmønster
- JsonLayout – definerer ET json – format for loggmeldinger
- CsvLayout-kan brukes til å lage meldinger I ET CSV-format
PatternLayout
Den første typen layout vi skal se på Er PatternLayout. Dette er en ganske fleksibel løsning som gir deg mye kontroll over den endelige utgangen av loggmeldingen.
mekanismen er primært drevet av et konverteringsmønster som inneholder konverteringsspesifikatorer. Hver spesifiserer begynner med % – tegnet, etterfulgt av modifikatorer som styrer ting som bredde og farge på meldingen, og et konverteringstegn som representerer innholdet, for eksempel dato eller trådnavn.
La oss se på et eksempel på å konfigurere Et Mønsterlayout som konfigurerer logglinjer for å vise dato, tråd, loggnivå og loggmelding med forskjellige farger for forskjellige loggnivåer:
disse spesifiseringene er vel verdt å forstå i detalj, så la oss se nærmere på:
- %d{hh:mm:ss.Sss} – utganger datoen for logghendelsen i det angitte formatet
- %t – utganger trådnavnet
- %nivå – viser loggnivået for meldingen
- %høydepunkt{%nivå} – brukes til å definere fargene for mønsteret mellom krøllete parenteser
- %msg%n – utganger loggmeldingen
utgangen vil vise loggnivåene med forskjellige farger:
du kan lese mer om hele settet av ALTERNATIVER for å definere mønstre i log4j2 dokumentasjon på patternlayout.
JsonLayout
Logging av data ved HJELP AV json-formatet har noen betydelige fordeler, for eksempel å gjøre loggene enklere å bli analysert og behandlet ved å logge verktøy nedover linjen.
For å konfigurere jsonlayout i log4j2, kan du bare definere den tilsvarende taggen:
<JSONLayout complete="true" compact="false"/>
innstilling complete=true vil produsere et velformet json-dokument:
for å kunne produsere JSON må du også legge til jackson-databind-biblioteket i klassebanen:
Konfigurere Filtre
Filtre i log4j2 brukes til å avgjøre om en loggmelding skal behandles eller hoppes over.
et filter kan konfigureres for hele konfigurasjonen eller på logger eller appender nivå.
biblioteket inneholder flere typer filtre som kan brukes:
- BurstFilter – kontrollerer antall logghendelser tillatt
- DynamicThresholdFilter – filtrerer logglinjer basert på bestemte attributter
- RegexFilter-filtrerer meldinger basert på om de samsvarer med et regulært uttrykk
du kan for eksempel kontrollere hastigheten som programmet får lov til å logge data.
for å gjøre det, kan du sette opp Et BurstFilter og bruke DET PÅ INFOMELDINGER:
<Filters> <BurstFilter level="INFO" rate="10" maxBurst="100"/></Filters>
dette vil selektivt ignorere kontroll trafikken PÅ INFO nivå meldinger og under samtidig sørge for at du ikke mister noen av de viktigste meldingene OVER INFO.
i dette tilfellet, rate definerer gjennomsnittlig logger meldinger som skal behandles per sekund, og maxBurst styrer den totale størrelsen på trafikken burst før filteret begynner å eliminere loggoppføringer.
På Samme måte kan vi konfigurere appender bare for å godta loggmeldinger som samsvarer med et bestemt regulært uttrykk:
<Appenders> <JDBC name="JDBCAppender"> <RegexFilter regex="*jdbc*" onMatch="ACCEPT" onMismatch="DENY"/> </JDBC></Appenders>
Samlet sett kan denne filtreringsmekanismen brukes med stor presisjon for å sikre at hver appender i din generelle loggkonfigurasjon sporer riktig informasjon. Evnen til å bare logge svært spesifikk og relevant informasjon fører generelt til svært rask grunnårsaksanalyse, spesielt i komplekse systemer-spesielt når det kombineres med et kraftig loggvisningsverktøy.
Konfigurere Loggere
Foruten Roten logger, kan vi også definere flere Logger elementer med ulike logg nivåer, appenders eller filtre. Hver Logger krever et navn som kan brukes senere for å referere det:
<Loggers> <Logger name="RollingFileLogger"> <AppenderRef ref="RollingFileAppender" /> </Logger></Loggers>
for å skrive loggmeldinger ved hjelp av Denne Spesielle Logger, kan du få en referanse til Den ved Hjelp Av LogManager-klassen:
Logger rfLogger = LogManager.getLogger("RollingFileLogger");rfLogger.info("User info updated");
En annen svært vanlig måte å strukturere hierarkiet til disse loggerne er basert På Java-klassen:
Logger logger = LogManager.getLogger(MyServiceTest.class);
bruke oppslag
oppslag representerer en måte å sette inn eksterne verdier i log4j2-konfigurasjonen. Vi har allerede sett et eksempel på dato oppslag I RollingFileAppender konfigurasjon:
<RollingFile name="RollingFileAppender" fileName="logs/app.log" filePattern="logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.log.gz">
$ {date:yyy-MM} oppslaget vil sette inn gjeldende dato i filnavnet, mens forrige $ er et escape-tegn, for å sette inn oppslagsuttrykket i filepattern-attributtet.
Du kan også sette Inn Systemegenskaper verdier i log4j2 konfigurasjon ved hjelp av formatet ${sys:property_name}:
<File name="ApplicationLog" fileName="${sys:path}/app.log"/>
En annen type informasjon du kan slå opp og sette Inn Er Java environment information:
<PatternLayout header="${java:version} - ${java:os}"> <Pattern>%d %m%n</Pattern></PatternLayout>
du kan finne mer informasjon om hva slags data du kan sette inn gjennom oppslag i log4j2 dokumentasjon.
Programmatisk Konfigurasjon
foruten konfigurasjonsfiler kan log4j2 også konfigureres programmatisk. Det er noen forskjellige måter å gjøre det på:
- opprett en egendefinert Konfigurasjonsfactory
- bruk Konfiguratorklassen
- endre konfigurasjonen etter initialisering
- kombiner egenskapsfiler og programmatisk konfigurasjon
La oss ta en titt på hvordan du konfigurerer et oppsett og legger til programmatisk:
Neste kan du definere en logger ved hjelp Av LoggerConfig-klassen, knytte appen til den, og oppdater konfigurasjonen:
deretter kan du begynne å bruke loggeren som vanlig:
Logger pLogger = LogManager.getLogger("programmaticLogger");pLogger.info("Programmatic Logger Message");
denne stilen med fluent API kan føre til en raskere utvikling og iterasjon på mer komplekse loggingskonfigurasjoner fordi du nå drar nytte av fordelene ved å jobbe direkte med Java-kode.MEN GITT AT XML fortsatt kan være mer lesbar og kompakt, kan DU ofte utvikle konfigurasjonen programmatisk og deretter konvertere DEN til XML når alt er gjort.
Tilpassede Loggnivåer
de innebygde loggnivåene for log4j2 er:
- AV
- FATAL
- FEIL
- ADVARSEL
- INFO
- DEBUG
- SPOR
- ALLE
I tillegg til disse kan du også definere et tilpasset loggnivå i henhold til dine søknadsbehov.
for eksempel, for å definere dette nye loggnivået, kan Du gjøre Bruk av Nivået.forName () API-angi det nye nivånavnet og et heltall som representerer stedet for nivået i loggnivåhierarkiet:
Level myLevel = Level.forName("NEW_LEVEL", 350);
for å bestemme hvilken heltallverdi du skal bruke, kan du se på verdiene som er definert for de andre loggnivåene i log4j2-dokumentasjonen:
350-verdien setter nivået mellom WARN og INFO, noe som betyr at meldingene vil bli vist når nivået er satt TIL INFO eller høyere.
for å logge en melding på egendefinert nivå må du bruke log () – metoden:
logger.log(myLevel, "Custom Level Message");
den tilsvarende XML-konfigurasjonen kan være:
<CustomLevels> <CustomLevel name="NEW_XML_LEVEL" intLevel="350" /></CustomLevels>
da kan DEN brukes via standard log API:
logger.log(Level.getLevel("NEW_XML_LEVEL"),"Custom XML Level Message");
de nye tilpassede nivåene vises på samme måte som standardene:
11:28:23.558 NEW_LEVEL - Custom Level Message11:28:23.559 NEW_XML_LEVEL - Custom XML Level Message
Migrerer Fra Log4j 1.x
hvis du overfører et program ved hjelp av 1.x versjon av biblioteket til gjeldende 2.x versjon, det er et par ruter du kan følge:
- bruk log4j 1.x bridge
- manuelt oppdatere API og konfigurasjonen
Ved hjelp av broen er trivielt. Du trenger bare å erstatte log4j avhengighet med log4j-1.2-api bibliotek:
selv om dette er den raskere metoden, har den ulempen ved å være begrenset i typen konfigurasjon som kan konverteres.
den manuelle metoden er selvsagt mer arbeid, men vil etter hvert føre til en mer fleksibel og kraftig loggingsløsning.
Her er noen av de vanligste endringene du må gjøre:
Konklusjon
Loggfiler er kritiske i ethvert produksjonsmiljø, og å velge en god loggløsning kan være forskjellen mellom å bruke 5 minutter og tilbringe en hel dag for å forstå et problem i produksjonen.Log4j2 Er en kraftig og robust logging løsning for moderne Java-programmer, med et bredt spekter av konfigurasjonsmuligheter.
Det gir enkel konfigurasjon av avanserte logging beste praksis som rullende filer, ulike typer logging utgang destinasjoner, støtte for strukturerte logging formater SOM JSON eller XML, ved hjelp av flere loggere og filtre, og tilpassede loggnivåer.
Til Slutt, Når du trenger å gå utover manuelt analysere loggdata, definitivt sjekke ut logging evner inkludert I Retrace APM.
Leave a Reply