Introduksjon til Log4j2 - Appenders, Layouts and Filters

1. Oversikt

Logging av hendelser er et kritisk aspekt av programvareutvikling. Mens det er mange rammer tilgjengelig i Java-økosystemet, har Log4J vært den mest populære i flere tiår, på grunn av fleksibiliteten og enkelheten den gir.

Log4j 2 er en ny og forbedret versjon av det klassiske Log4j-rammeverket.

I denne artikkelen vil vi introdusere de vanligste appenderne, layoutene og filtrene via praktiske eksempler.

I Log4J2 er en appender rett og slett et mål for logghendelser; det kan være så enkelt som en konsoll og kan være komplekst som alle RDBMS. Oppsett bestemmer hvordan loggene skal presenteres, og filtre filtrerer dataene i henhold til de forskjellige kriteriene.

2. Oppsett

For å forstå flere loggkomponenter og deres konfigurasjon, la oss sette opp forskjellige testbrukstilfeller, hver bestående av en log4J2.xml konfigurasjonsfil og en JUnit 4 testklasse.

To avhengighetsavhengigheter er felles for alle eksempler:

 org.apache.logging.log4j log4j-core 2.7 org.apache.logging.log4j log4j-core 2.7 test-jar test 

Foruten det viktigste log4j-kjerne pakken må vi inkludere ‘test jar’ som tilhører pakken for å få tilgang til en kontekstregel som er nødvendig for testing av uvanlig navngitte konfigurasjonsfiler.

3. Standardkonfigurasjon

ConsoleAppender er standardkonfigurasjonen for Log4J 2 kjernepakke. Den logger meldinger til systemkonsollen i et enkelt mønster:

La oss analysere kodene i denne enkle XML-konfigurasjonen:

  • Konfigurasjon: Rotelementet til en Log4J 2 konfigurasjonsfil og attributt status er nivået på de interne Log4J-hendelsene som vi vil logge
  • Appenders: Dette elementet holder en eller flere appenders. Her konfigurerer vi en appender som sendes ut til systemkonsollen som standard ut
  • Loggere: Dette elementet kan bestå av flere konfigurerte Logger elementer. Med det spesielle Rot kan du konfigurere en navnløs standard logger som vil motta alle loggmeldinger fra applikasjonen. Hver logger kan settes til et minimum loggnivå
  • AppenderRef: Dette elementet definerer en referanse til et element fra Appenders seksjon. Derfor attributtet ‘ref'Er knyttet til en appenders'Navn' Egenskap

Den tilsvarende enhetstesten vil være like enkel. Vi får en Logger referanse og skriv ut to meldinger:

@Test offentlig ugyldig givenLoggerWithDefaultConfig_whenLogToConsole_thanOK () kaster unntak {Logger logger = LogManager.getLogger (getClass ()); Unntak e = ny RuntimeException ("Dette er bare en test!"); logger.info ("Dette er en enkel melding på INFO-nivå." + "Den blir skjult."); logger.error ("Dette er en enkel melding på FEIL-nivå." + "Dette er det minste synlige nivået.", e); } 

4. ConsoleAppender Med Mønsteroppsett

La oss definere en ny konsollappender med et tilpasset fargemønster i en egen XML-fil, og inkludere det i vår hovedkonfigurasjon:

Denne filen bruker noen mønstervariabler som blir erstattet av Log4J 2 ved kjøretid:

  • % style {…} {colorname}: Dette vil skrive ut teksten i det første brakettparet () i en gitt farge (kolornamn).
  • % høydepunkt {…} {FATAL = kolonnenavn,…}: Dette ligner på 'stil' variabelen. Men det kan gis en annen farge for hvert loggnivå.
  • % dato {format}: Dette blir erstattet av gjeldende dato i det angitte format. Her bruker vi 'DEFAULT' DateTime-format, åååå-MM-dd HH: mm: ss, SSS '.
  • % -5nivå: Skriver ut nivået på loggmeldingen på en høyrejustert måte.
  • %beskjed: Representerer den rå loggmeldingen

Men det finnes mange flere variabler og formatering i Mønsteroppsett. Du kan henvise dem til den offisielle dokumentasjonen til Log4J 2.

Nå inkluderer vi den definerte konsollappenderen i hovedkonfigurasjonen:

Enhetstesten:

@Test offentlig ugyldig givenLoggerWithConsoleConfig_whenLogToConsoleInColors_thanOK () kaster unntak {Logger logger = LogManager.getLogger ("CONSOLE_PATTERN_APPENDER_MARKER"); logger.trace ("Dette er en farget melding på TRACE-nivå."); ...} 

5. Async File Appender With JSON Layout og BurstFilter

Noen ganger er det nyttig å skrive loggmeldinger på en asynkron måte. For eksempel hvis applikasjonsytelse har prioritet fremfor tilgjengeligheten av logger.

I slike brukstilfeller kan vi bruke en AsyncAppender.

For vårt eksempel konfigurerer vi en asynkron JSON loggfil. Videre inkluderer vi et burstfilter som begrenser loggutgangen med en spesifisert hastighet:

   ...          ...        

Legg merke til det:

  • De JSON Layout er konfigurert på en måte som skriver en logghendelse per rad
  • De BurstFilter vil slippe hver begivenhet med ‘INFO’ nivå og oppover hvis det er mer enn to av dem, men maksimalt 10 droppede hendelser
  • De AsyncAppender er satt til en buffer med 80 loggmeldinger; deretter skylles bufferen til loggfilen

La oss ta en titt på den tilsvarende enhetstesten. Vi fyller den vedlagte bufferen i en sløyfe, la den skrive til disken og inspisere linjetellingen for loggfilen:

@Test offentlig ugyldig givenLoggerWithAsyncConfig_whenLogToJsonFile_thanOK () kaster unntak {Logger logger = LogManager.getLogger ("ASYNC_JSON_FILE_APPENDER"); endelig antall teller = 88; for (int i = 0; i 0 && logEventsCount <= count); }

6. RollingFile Appender og XMLLayout

Deretter oppretter vi en rullende loggfil. Etter en konfigurert filstørrelse blir loggfilen komprimert og rotert.

Denne gangen bruker vi en XML oppsett:

Legg merke til det:

  • De RollingFile appender har et 'filePattern' attributt, som brukes til å navngi roterte loggfiler og kan konfigureres med plassholdervariabler. I vårt eksempel bør den inneholde en dato og en teller før filendelsen.
  • Standardkonfigurasjonen av XMLLayout vil skrive enkeltlogg hendelsesobjekter uten rotelementet.
  • Vi bruker en størrelsesbasert policy for å rotere loggfilene våre.

Enhetstestklassen vår vil se ut som den fra forrige avsnitt:

@Test offentlig ugyldig givenLoggerWithRollingFileConfig_whenLogToXMLFile_thanOK () kaster unntak {Logger logger = LogManager.getLogger ("XML_ROLLING_FILE_APPENDER"); endelig antall teller = 88; for (int i = 0; i <count; i ++) {logger.info ("Dette er rullende fil XML-melding # {} på INFO-nivå.", i); }}

7. Syslog Appender

La oss si at vi må sende loggede hendelser til en ekstern maskin over nettverket. Den enkleste måten å gjøre det ved å bruke Log4J2 er å bruke den Syslog Appender:

   ...     ...        

Attributtene i Syslog stikkord:

  • Navn: definerer navnet på appender, og må være unikt. Siden vi kan ha flere Syslog-appenders for samme applikasjon og konfigurasjon
  • format: den kan enten settes til BSD eller RFC5424, og Syslog-postene vil bli formatert deretter
  • vert & port: vertsnavnet og porten til den eksterne Syslog-servermaskinen
  • protokoll: om du skal bruke TCP eller UPD
  • anlegget: til hvilket Syslog-anlegg arrangementet skal skrives
  • connectTimeoutMillis: tidsperiode for å vente på en etablert forbindelse, er som standard null
  • reconnectionDelayMillis: tid til å vente før du prøver på nytt

8. FailoverAppender

Nå kan det være tilfeller der en appender ikke behandler logghendelsene, og vi ikke vil miste dataene. I slike tilfeller kan FailoverAppender kommer hendig.

For eksempel hvis Syslog appender unnlater å sende hendelser til den eksterne maskinen, i stedet for å miste dataene vi kan falle tilbake til FileAppender midlertidig.

De FailoverAppender tar en primær appender og antall sekundære appenders. Hvis primæren mislykkes, prøver den å behandle logghendelsen med sekundære i rekkefølge til en lykkes, eller det ikke er noen sekundærer å prøve:

La oss teste det:

@Test offentlig ugyldig givenLoggerWithFailoverConfig_whenLog_thanOK () kaster unntak {Logger logger = LogManager.getLogger ("FAIL_OVER_SYSLOG_APPENDER"); Unntak e = ny RuntimeException ("Dette er bare en test!"); logger.trace ("Dette er en syslog-melding på TRACE-nivå."); logger.debug ("Dette er en syslog-melding på DEBUG-nivå."); logger.info ("Dette er en syslog-melding på INFO-nivå. Dette er det minste synlige nivået."); logger.warn ("Dette er en syslog-melding på WARN-nivå."); logger.error ("Dette er en syslog-melding på FEIL-nivå.", e); logger.fatal ("Dette er en syslog-melding på FATAL-nivå."); }

9. JDBC Appender

JDBC-appenderen sender logghendelser til en RDBMS ved hjelp av standard JDBC. Tilkoblingen kan oppnås enten ved hjelp av hvilken som helst JNDI-datakilde eller en hvilken som helst tilkoblingsfabrikk.

Den grunnleggende konfigurasjonen består av en Datakilde eller ConnectionFactory, ColumnConfigs og tabellnavn:

La oss nå prøve:

@Test offentlig ugyldig givenLoggerWithJdbcConfig_whenLogToDataSource_thanOK () kaster unntak {Logger logger = LogManager.getLogger ("JDBC_APPENDER"); endelig intall = 88; for (int i = 0; i <count; i ++) {logger.info ("Dette er JDBC-melding nr. {} på INFO-nivå.", count); } Tilkoblingstilkobling = ConnectionFactory.getConnection (); ResultSet resultSet = connection.createStatement () .executeQuery ("VELG TELL (*) SOM ROW_COUNT FRA logger"); int logCount = 0; hvis (resultSet.next ()) {logCount = resultSet.getInt ("ROW_COUNT"); } assertTrue (logCount == count); }

10. Konklusjon

Denne artikkelen viser veldig enkle eksempler på hvordan du kan bruke forskjellige loggingsappendere, filtrere og oppsett med Log4J2 og måter å konfigurere dem på.

Eksemplene som følger med artikkelen er tilgjengelig på GitHub.


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