Log4j Tutorial: Hvordan Konfigurere Loggeren For Effektiv Java-Program Logging
Å få synlighet i programmet er avgjørende når du kjører koden i produksjon. Hva mener vi med synlighet? Primært ting som applikasjonsytelse via beregninger, applikasjonshelse og tilgjengelighet, loggene bør du feilsøke det, eller sporene hvis du trenger å finne ut hva som gjør det sakte og hvordan du gjør det raskere.
Beregninger gir deg informasjon om ytelsen til hvert av elementene i infrastrukturen. Spor vil vise deg en bredere visning av kodekjøring og flyt sammen med kodekjøring beregninger. Til slutt vil godt utformede logger gi et uvurderlig innblikk i kodelogikkens utførelse og hva som skjedde i koden din. Hver av de nevnte brikkene er avgjørende for søknaden din og faktisk den generelle systemobservabiliteten. I dag vil vi fokusere bare på et enkelt stykke-loggene. For Å være mer presis – På Java-programlogger. Hvis du er interessert i beregninger, sjekk ut vår artikkel om viktige jvm-beregninger du bør overvåke.
Men før vi kommer inn i det, la oss ta opp et problem som påvirket samfunnet ved hjelp av dette rammeverket. Den 9. desember 2021 ble et kritisk sårbarhet kalt Log4Shell rapportert. Identifisert SOM CVE-2021-44228, lar den en angriper ta full kontroll over en maskin som kjører Apache Log4j 2 versjon 2.14.1 eller lavere, slik at de kan utføre vilkårlig kode på den sårbare serveren. I vår siste blogginnlegg Om Log4jShell sårbarhet, vi detaljert hvordan du kan avgjøre om du er berørt, hvordan du løser problemet, og hva Vi, På Sematext, har gjort for å beskytte vårt system og brukere.
Log4j 1.X Slutten Av Livet
Husk at den 5. August 2015 Logging Services Project Management Committee annonsert At Log4j 1.x hadde nådd slutten av livet. Alle brukere anbefales å migrere Til Log4j 2.x. i dette blogginnlegget vil vi hjelpe deg med å forstå Ditt Nåværende Log4j-oppsett-spesielt log4j 2.x-versjon-og etter det hjelper jeg deg med å migrere til den nyeste Og beste Log4j-versjonen.
«jeg bruker Log4j 1.x, hva skal jeg gjøre?». Ikke få panikk, det er ikke noe galt med det. Lag en plan for overgang Til Log4j 2.x. jeg skal vise deg hvordan bare holde lesing :). Din søknad vil takke deg for det. Du vil få sikkerhetsreparasjoner, ytelsesforbedringer og langt flere funksjoner etter overføring.
» jeg starter et nytt prosjekt, hva skal jeg gjøre?». Bare bruk Log4j 2.x med en gang, ikke engang tenke På Log4j 1.x. Hvis du trenger hjelp med det, sjekk Ut Denne Java logging opplæringen der jeg forklarer alt du trenger.
Logging I Java
det er ingen magi bak logging I Java. Alt kommer ned til å bruke en passende Java-klasse og dens metoder for å generere logghendelser. Som vi diskuterte I Java logging guide, er det flere måter du kan starte
Selvfølgelig er den mest naive og ikke den beste banen å følge, bare å bruke Systemet.ut Og System.feil klasser. Ja, du kan gjøre det, og meldingene dine vil bare gå til standardutgang og standardfeil. Vanligvis betyr det at det vil bli skrevet ut til konsollen eller skrevet til en fil av noe slag eller til og med sendt til/dev / null og for alltid bli glemt. Et eksempel på en slik kode kan se slik ut:
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) ); }}
utgangen av ovennevnte kodekjøring vil være som følger:
Starting my awesome applicationMy application class com.sematext.logging.log4jsystem.SystemExample started successfully
Det er ikke perfekt, ikke sant? Jeg har ingen informasjon om hvilken klasse som genererte meldingen og mange, mange flere «små» ting som er avgjørende og viktige under feilsøking.
det er andre ting som mangler som egentlig ikke er koblet til feilsøking. Tenk på utførelsesmiljøet, flere applikasjoner eller mikrotjenester, og behovet for å forene logging for å forenkle loggsentraliseringsrørledningskonfigurasjonen. Bruke Systemet.ut, eller / Og System.feil i koden vår for logging vil tvinge oss til å gjøre om alle stedene der vi bruker den når vi trenger å justere loggformatet. Jeg vet det er ekstremt, men tro meg, vi har sett Bruken Av Systemet.ut i produksjonskode i» tradisjonelle » applikasjonsdistribusjonsmodeller! Selvfølgelig, logging Til System.out er en riktig løsning for containerized applikasjoner, og du bør bruke utgangen som passer ditt miljø. Husk om det!
På grunn av alle de nevnte grunnene og mange flere som vi ikke engang tenker på, bør du se på et av de mulige loggbibliotekene, Som Log4 j, Log4j 2, Logback eller til og med java.util.logging som er en del Av Java Development Kit. For dette blogginnlegget bruker Vi Log4j.
Abstraksjonslaget-SLF4J
emnet for å velge riktig loggingsløsning for Java-applikasjonen din er noe vi allerede diskuterte i vår veiledning om logging I Java. Vi anbefaler å lese minst den nevnte delen.
VI bruker SLF4J, et abstraksjonslag mellom Vår Java-kode og Log4j – loggbiblioteket etter eget valg. Den Enkle Logging Fasaden gir bindinger for vanlige logging rammer Som Log4j, Logback, og java.util.logging. Tenk deg prosessen med å skrive en loggmelding på følgende, forenklet måte:
du kan spørre hvorfor bruke et abstraksjonslag i det hele tatt? Vel, svaret er ganske enkelt – til slutt vil du kanskje endre loggingsrammen, oppgradere den, forene den med resten av teknologibunken din. Når du bruker en abstraksjon lag slik operasjon er ganske enkel – du bare bytte logging rammeverk avhengigheter og gi en ny pakke. Hvis vi ikke skulle bruke et abstraksjonslag – måtte vi endre koden, potensielt mye kode. Hver klasse som logger noe. Ikke en veldig fin utvikling opplevelse.
Loggeren
Koden Til Java-programmet ditt vil samhandle med et standard sett med nøkkelelementer som tillater oppretting og manipulering av logghendelser. Vi har dekket de avgjørende i Vår Java logging tutorial, men la meg minne deg om en av klassene som vi vil stadig bruke-Loggeren.
Loggeren Er hovedenheten som et program bruker til å foreta logging samtaler-opprette logghendelser. Logger-objektet brukes vanligvis for en enkelt klasse eller en enkelt komponent for å gi kontekst-bundet til en bestemt brukstilfelle. Det gir metoder for å lage logghendelser med et passende loggnivå og gi det videre for videre behandling. Du vil vanligvis lage et statisk objekt som du vil samhandle med, for eksempel som dette:
... Logger LOGGER = LoggerFactory.getLogger(MyAwesomeClass.class);
Og det er alt. Nå som vi vet hva vi kan forvente, la oss se På Log4j-biblioteket.
Log4j
den enkleste måten å starte Med Log4j er å inkludere biblioteket i classpath Av Java-programmet. For å gjøre det inkluderer vi det nyeste tilgjengelige log4j-biblioteket, som betyr versjon 1.2.17 i vår build-fil.
vi bruker Gradle og i vår enkle applikasjon og avhengighetsseksjonen For Gradle build-filen ser ut som følger:
dependencies { implementation 'log4j:log4j:1.2.17'}
Vi kan begynne å utvikle koden og inkludere logging Ved Hjelp Av 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 koden ovenfor vi initialisert Logger objektet ved hjelp av statisk getLogger metoden og vi gitt navnet på klassen. Etter å ha gjort det, kan vi enkelt få tilgang til det statiske Loggobjektet og bruke det til å produsere logghendelser. Vi kan gjøre det i hovedmetoden.
One side note-getLogger-metoden kan også kalles med En Streng som et argument, for eksempel:
private static final Logger LOGGER = Logger.getLogger("com.sematext.blog");
Det ville bety at vi ønsker å lage en logger og knytte navnet på com.sematext.blogg med det. Hvis Vi vil bruke samme navn noe annet sted I koden Log4j vil returnere samme Logger eksempel. Det er nyttig hvis vi ønsker å kombinere logging fra flere forskjellige klasser på ett sted. For eksempel logger relatert til betaling i en enkelt, dedikert loggfil.
Log4j gir en liste over metoder som tillater opprettelse av nye logghendelser ved hjelp av et passende loggnivå. De er:
- offentlig ugyldig spor(Objektmelding)
- offentlig ugyldig feil(Objektmelding)
- offentlig ugyldig informasjon(Objektmelding)
- offentlig ugyldig advarsel(Objektmelding)
- offentlig ugyldig feil(Objektmelding)
- offentlig ugyldig fatal (Objektmelding)
en generisk metode:
- offentlig ugyldig logg (Nivånivå, Objektmelding)
Vi snakket Om Java logging nivåer i Vår Java logging tutorial blogginnlegg. Hvis du ikke er klar over dem, kan du ta noen minutter å bli vant til dem som logg nivåer er avgjørende for logging. Hvis du bare har begynt med loggingsnivåer, anbefaler vi at du også går over vår loggnivåguide. Vi forklarer alt fra hva de er til hvordan du velger den rette og hvordan du kan gjøre bruk av dem for å få meningsfull innsikt.
hvis vi skulle kjøre koden ovenfor, ville utgangen vi fikk 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 fikk ikke se loggmeldingen som vi forventet. Log4j informerte oss om at det ikke er noen konfigurasjon tilstede. Oooops, la oss snakke om hvordan du konfigurerer Log4j…
Log4j Configuration
det er flere måter vi kan konfigurere Log4j logging på. Vi kan gjøre det programmatisk – for eksempel ved å inkludere en statisk initialiseringsblokk:
static { BasicConfigurator.configure();}
koden ovenfor konfigurerer Log4j for å sende loggene til konsollen i standardformatet. Utgangen av å kjøre vårt eksempelprogram vil se ut som følger:
0 INFO com.sematext.blog.ExampleLog4jProgrammaticConfig - Initializing ExampleLog4j application
det er imidlertid ikke veldig vanlig å sette Opp Log4j programmatisk. Den vanligste måten ville være å enten bruke en egenskapsfil eller EN XML-fil. Vi kan endre koden vår og inkludere log4j. properties-filen med følgende innhold:
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åten fortalte Vi Log4j at vi lager rotloggeren, som vil bli brukt som standard. Standard loggingsnivå er satt TIL FEILSØKING, noe som betyr at logghendelser med alvorlighetsgrad-FEILSØKING eller høyere vil bli inkludert. SÅ FEILSØKE, INFO, ADVARE, FEIL og DØDELIG. Vi ga også vår logger et navn-MAIN. Deretter konfigurerer vi loggeren, ved å sette utgangen til konsoll og ved å bruke mønsteroppsettet. Vi vil snakke om det mer senere i blogginnlegget. Utgangen av å kjøre koden ovenfor vil være som følger:
0 INFO com.sematext.blog.ExampleLog4jProperties - Initializing ExampleLog4j application
hvis vi ønsker det, kan vi også endre log4j.properties-filen og bruke en som heter log4j.xml. Den samme konfigurasjonen VED HJELP AV XML-format vil se ut 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 nå vil endre log4j. properties for log4j.xml en og hold den i classpath utførelsen av vårt eksempelprogram vil være som følger:
0 INFO com.sematext.blog.ExampleLog4jXML - Initializing ExampleLog4j application
så Hvordan Vet Log4j hvilken fil du skal bruke? La oss se på det.
Initialiseringsprosess
Det er viktig å vite At Log4j ikke gjør noen forutsetninger om miljøet den kjører i. Log4j ikke anta noen form for standard logg hendelser destinasjoner. Når den starter, ser den etter log4j.configuration-egenskapen og prøver å laste den angitte filen som konfigurasjon. Hvis plasseringen av filen ikke kan konverteres til EN URL eller filen ikke finnes den prøver å laste filen fra classpath.
det betyr at Vi kan overskrive Log4j-konfigurasjonen fra classpath ved å gi-Dlog4j. configuration under oppstart og peke den til riktig sted. For eksempel, hvis vi inkluderer en fil som heter annet.xml med følgende innhold:
<!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 deretter kjøre ut kode med-Dlog4j. configuration= / opt / sematext / annet.xml utgangen fra koden vår vil være som følger:
0 INFO com.sematext.blog.ExampleLog4jXML - Initializing ExampleLog4j application
Log4j Appenders
Vi har allerede brukt appenders i våre eksempler … vel, egentlig bare en-ConsoleAppender. Dens eneste formål er å skrive logghendelsene til konsollen. Selvfølgelig, med et stort antall logghendelser og systemer som kjører i forskjellige miljøer, skriver rene tekstdata til standardutgangen kanskje ikke den beste ideen, med mindre du kjører i containere. Det er derfor Log4j støtter flere typer Appenders. Her er noen vanlige eksempler På Log4j appenders:
- ConsoleAppender-appender som føyer logghendelsene Til Systemet.ut Eller System.feile med standard være System.ut. Når du bruker denne appenderen, ser du loggene dine i konsollen til søknaden din.
- FileAppender-appender som føyer logghendelsene til en definert fil som lagrer dem på filsystemet.
- RollingFileAppender-appender som utvider FileAppender og roterer filen når den når en definert størrelse. Bruken Av RollingFileAppender hindrer loggfilene fra å bli veldig stor og vanskelig å vedlikeholde.
- SyslogAppender-den appender sende logg hendelser til en ekstern Syslog daemon.
- JDBCAppender-appender som lagrer logghendelsene i databasen. Husk at denne appender ikke lagrer feil, og det er vanligvis ikke den beste ideen å lagre logghendelsene i en database.
- SocketAppender-appender som sender serialiserte logghendelser til en ekstern kontakt. Husk at denne appenderen ikke bruker oppsett fordi den sender serialiserte, rå logghendelser.
- NullAppender-appender som bare forkaster logghendelsene.
i tillegg kan du ha flere Appenders konfigurert for et enkelt program. Du kan for eksempel sende logger til konsollen og til en fil. Følgende log4j.egenskaper filinnhold ville gjøre akkurat 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
vår root logger er konfigurert til å logge alt fra DEBUG alvorlighetsgrad og å sende loggene til to Appenders-HOVED og RULLENDE. Hovedloggeren er den som vi allerede så – den som sender dataene til konsollen.
den andre loggeren, DEN som heter ROLLING, er den mer interessante i dette eksemplet. Den bruker RollingFileAppender som skriver data til filen og la oss definere hvor stor filen kan være og hvor mange filer å holde. I vårt tilfelle bør loggfilene kalles awesome.logg og skriv dataene til/var/ log / sematext / katalog. Hver fil bør være maksimalt 1024KB, og det bør ikke være mer enn 10 filer lagret. Hvis det er flere filer de vil bli fjernet fra filsystemet så snart log4j ser dem.
etter å ha kjørt koden med konfigurasjonen ovenfor, vil konsollen skrive ut følgende innhold:
0 INFO com.sematext.blog.ExampleAppenders - Starting ExampleAppenders application1 WARN com.sematext.blog.ExampleAppenders - Ending ExampleAppenders application
I /var / log / sematext / awesome.loggfil vi ville se:
0 INFO com.sematext.blog.ExampleAppenders - Starting ExampleAppenders application1 WARN com.sematext.blog.ExampleAppenders - Ending ExampleAppenders application
Appender Log Level
det fine Med Appenders er at de kan ha sitt nivå som bør tas i betraktning når du logger. Alle eksemplene som vi har sett så langt logget hver melding som hadde alvorlighetsgraden AV DEBUG eller høyere. Hva om vi ønsket å endre det for alle klassene i com.sematext.bloggpakke? Vi ville bare nødt til å endre vår 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 siste linjen i konfigurasjonsfilen ovenfor. Vi har brukt log4j. logger prefikset og sa at loggeren heter com.sematext.bloggen bør bare brukes for alvorlighetsgrad ADVARE og over, SÅ FEIL og DØDELIG.
vårt eksempel programkode ser slik ut:
public static void main(String args) { LOGGER.info("Starting ExampleAppenderLevel application"); LOGGER.warn("Ending ExampleAppenderLevel application");}
med Den Ovennevnte Log4j-konfigurasjonen ser utgangen av loggen ut som følger:
0 WARN com.sematext.blog.ExampleAppenderLevel - Ending ExampleAppenderLevel application
Som du kan se, var bare WARN-nivåloggen inkludert. Det er akkurat det vi ønsket.
Log4j Oppsett
Endelig, den delen Av Log4j logging rammeverk som styrer måten våre data er strukturert i vår loggfil-oppsettet – Log4j gir noen standard implementeringer som PatternLayout, SimpleLayout, XMLLayout, HTMLLayout, EnchancedPatternLayout, Og DateLayout.
I de fleste tilfeller vil Du møte Mønsterlayout. Tanken bak dette oppsettet er at du kan gi en rekke formateringsalternativer for å definere strukturen til loggene. Noen av eksemplene er:
- d-dato og klokkeslett for logghendelsen,
- m – melding knyttet til logghendelsen,
- t – trådnavn,
- n – plattformavhengig linjeskille,
- p-loggnivå.
for mer informasjon om de tilgjengelige alternativene gå over til den offisielle Log4j Javadocs For PatternLayout.
Ved Bruk Av PatternLayout kan vi konfigurere hvilket alternativ vi ønsker å bruke. La oss anta at vi vil skrive datoen, alvorlighetsgraden av logghendelsen, tråden omgitt av firkantede parenteser og meldingen til logghendelsen. Vi kunne bruke et mønster som dette:
%d %-5p - %m%n
den fulle log4j. properties-filen i dette tilfellet kan se ut 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 bruker %d for å vise datoen, % – 5p for å vise alvorlighetsgraden ved hjelp av 5 tegn, %t for tråd, %m for meldingen og %n for linjeskilletegn. Utgangen som er skrevet til konsollen etter å ha kjørt vår eksempelkode, ser slik ut:
2021-02-02 11:49:49,003 INFO - Initializing ExampleLog4jFormatter application
Nestet Diagnostisk Kontekst
i de fleste virkelige programmer finnes ikke logghendelsen alene. Det er omgitt av en viss kontekst. For å gi en slik kontekst, per-tråd, Gir Log4j den såkalte Nestede Diagnostiske Konteksten. På den måten kan vi binde en gitt tråd med tilleggsinformasjon, for eksempel en øktidentifikator, akkurat som i vårt eksempelprogram:
NDC.push(String.format("Session ID: %s", "1234-5678-1234-0987"));LOGGER.info("Initializing ExampleLog4jNDC application");
når du bruker et mønster som inneholder x variabel tilleggsinformasjon vil bli inkludert i hver logline for den gitte tråden. I vårt tilfelle vil utgangen se slik ut:
0 INFO com.sematext.blog.ExampleLog4jNDC Session ID: 1234-5678-1234-0987 - Initializing ExampleLog4jNDC application
du kan se at informasjonen om øktidentifikatoren er i logline. Bare for referanse ser log4j.properties-filen som vi brukte i dette eksemplet ut 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
Kartlagt Diagnostisk Kontekst
den andre typen kontekstuell informasjon som vi kan inkludere i våre logghendelser, er kartlagt diagnostisk kontekst. VED HJELP AV MDC-klassen kan vi gi ytterligere nøkkelverdirelatert informasjon. I likhet med nestet diagnostisk kontekst er den tilordnede diagnostiske konteksten trådbundet.
La oss se på vårt eksempel programkode:
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 kontekstfelt-brukeren og trinnet. For å vise all den tilordnede diagnostiske kontekstinformasjonen som er knyttet til logghendelsen, bruker vi bare x-variabelen i mønsterdefinisjonen. 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
Lansering av koden ovenfor sammen med konfigurasjonen vil resultere i følgende utdata:
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å velge hvilken informasjon som skal brukes ved å endre mønsteret. For eksempel, for å inkludere brukeren fra den kartlagte diagnostiske konteksten, kan vi skrive et mønster som dette:
%r %-5p %c %X{user} - %m%n
denne gangen vil utgangen se ut 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 %X har vi brukt %X{user}. Det betyr at vi er interessert i brukervariabelen fra den tilordnede diagnostiske konteksten knyttet til en gitt logghendelse.
Migrering Til Log4j 2
Migrering Fra Log4j 1.x Til Log4j 2.x er ikke vanskelig, og i noen tilfeller kan det være veldig enkelt. Hvis du ikke bruker noen intern Log4j 1.x klasser, du har brukt konfigurasjonsfiler over programmatisk sette opp loggere og du ikke bruker DOMConfigurator og PropertyConfigurator klasser overføringen bør være så enkelt som å inkludere log4j-1.2-api.jar jar-fil i stedet For Log4j 1.x jar filer. Det ville tillate Log4j 2.x for å jobbe med koden din. Du må legge Til Log4j 2.x jar-filer, juster konfigurasjonen, og voilà – du er ferdig.
hvis Du vil lære Mer Om Log4j 2.x sjekk Ut Vår Java logging tutorial og Dens Log4j 2.x dedikert seksjon.
Men hvis du brukte intern Log4j 1.x klasser, den offisielle migrasjon guide på hvordan å flytte Fra Log4j 1.x Til Log4j 2.x vil være svært nyttig. Den diskuterer nødvendige kode-og konfigurasjonsendringer og vil være uvurderlig når du er i tvil.
Sentralisert Logging Med Loggbehandlingsverktøy
Sending av logghendelser til en konsoll eller en fil kan være bra for en enkelt applikasjon, men det er ikke morsomt å håndtere flere forekomster av applikasjonen din og korrelere loggene fra flere kilder når logghendelsene er i tekstfiler på forskjellige maskiner. I slike tilfeller blir datamengden raskt uhåndterlig og krever dedikerte løsninger-enten selv vert eller kommer fra en av leverandørene. Og hva med beholdere hvor du vanligvis ikke engang skriver logger til filer? Hvordan feilsøker og feilsøker du et program hvis logger ble sendt ut til standardutgang, eller hvis beholder er blitt drept?
det er her log management services, log analyseverktøy og cloud logging services kommer inn i bildet. Det er en uskreven Java logging beste praksis blant ingeniører å bruke slike løsninger når du er seriøs om å administrere loggene og få mest mulig ut av dem. For Eksempel Sematext Logger, vår logg overvåking og programvare, løser alle problemene nevnt ovenfor, og mer.
Med en heladministrert løsning som Sematext Logs, trenger du ikke å administrere en annen del av miljøet – DIN DIY logging løsning, vanligvis bygget ved hjelp av deler Av Elastisk Stabel. Slike oppsett kan starte små og billige, men de blir ofte store og dyre. Ikke bare når det gjelder infrastrukturkostnader, men også administrasjonskostnader. Tid og lønn. Vi forklarer mer om fordelene ved å bruke en administrert tjeneste i blogginnlegget vårt om beste praksis for logging.
Varsling og logg aggregering er også avgjørende når du arbeider med problemer. Til Slutt, For Java-programmer, kan det være lurt å ha søppelsamling logger når du slår søppelsamling logge på og begynne å analysere loggene. Slike logger korrelert med beregninger er en uvurderlig kilde til informasjon for feilsøking av søppelinnsamlingsrelaterte problemer.
Sammendrag
Selv Om Log4j 1.x nådd slutten av livet for lenge siden er det fortsatt til stede i et stort antall eldre programmer som brukes over hele verden. Overføringen til den yngre versjonen er ganske enkel, men kan kreve betydelige ressurser og tid og er vanligvis ikke en topp prioritet. Spesielt i store bedrifter hvor prosedyrer, juridiske krav, eller begge krever revisjoner etterfulgt av lang og kostbar testing før noe kan endres i et allerede kjørende system. Men for de av oss som bare starte eller tenke på migrasjon-husk, Log4j 2.x er der, den er allerede moden, rask, sikker og veldig dyktig.
men uavhengig av rammeverket du bruker for å logge Java-programmer, anbefaler vi definitivt gifte din innsats med en fullt administrert logg løsning, for Eksempel Sematext Logger. Gi det et forsøk! Det er en 14-dagers gratis prøveversjon tilgjengelig for deg å prøvekjøre den.
Glad logging!