Log4j2 a népszerű és befolyásos log4j könyvtár frissített verziója, amelyet oly sok éven át széles körben használnak a Java ökoszisztémában. Verzió 2.az x megtartja elődje összes naplózási funkcióját, és erre az alapra épít néhány jelentős fejlesztéssel, különösen a teljesítmény területén.

és természetesen, tekintettel arra, hogy az instrumentális naplózás minden alkalmazáshoz, mind audit, mind hibakeresés céljából, a szilárd naplózási könyvtár kiválasztása nagyon fontos döntés.

a következő szakaszokban megnézzük, hogy a log4j2 könyvtár miért nagyszerű választás erre a döntésre, és hogyan tudjuk használni egy alkalmazásban.

alapvető Log4j2 konfiguráció

a log4j2 használatának megkezdéséhez egyszerűen hozzá kell adnia a log4j-core függőséget. Ha Maven-t használ, a következő függőséget adhatja hozzá a pom-hoz.xml fájl:

és ha Gradle-lel dolgozik, hozzá kell adnia a függőséget a buildhez.gradle fájl:

dependencies { compile group: 'org.apache.logging.log4j', name: 'log4j-core', version: '2.8.2'}

a dobozból a log4j2 automatikusan egyszerű konfigurációt biztosít, ha nem határozza meg kifejezetten magát. Az alapértelmezett konfigurációs naplózza a konzol szintjén hiba szinten vagy felett.

az üzenetek naplózásának megkezdéséhez ezzel az alapkonfigurációval csak annyit kell tennie, hogy naplózási példányt kap a LogManager osztály segítségével:

private static Logger logger = LogManager.getLogger(MyService.class);

akkor használhatja a logger objektumot a kívánt naplószintnek megfelelő módszerekkel:

logger.error("This is an error message");

a Log4j2 konfiguráció testreszabása

egyéni log4j2 konfiguráció programozható vagy konfigurációs fájlon keresztül.

a könyvtár támogatja konfigurációs fájlok írt XML, JSON, YAML, valamint a .tulajdonságok formátum. Itt fogunk használni XML, hogy megvitassák az összes példát elsősorban.

először felülbírálhatja az alapértelmezett konfigurációt egy log4j2 létrehozásával.xml fájl a classpath-on:

vessünk egy közelebbi pillantást a címkék egyszerű konfiguráció:

• Konfiguráció: a gyökér eleme egy log4j2 konfigurációs fájl; az állapot attribútum jelöli az a szint, amelyen a belső log4j eseményeket naplózza
• Appenders: ez az elem tartalmazza a appenders; példánkban egy appender megfelelő, a Rendszer konzol határozza meg
• Favágók: ez az elem tartalmazza a Logger esetekben. A gyökérelem egy szabványos logger, amely minden üzenetet

fontos megérteni, hogy a gyökér logger minden konfigurációban kötelező. Mint már említettük, ha nem ad meg egyet, akkor alapértelmezés szerint automatikusan konfigurálódik egy Konzolalkalmazóval, valamint a hibanapló szinttel.

Appenders

konfigurálása a log4j2 architektúrában az appender alapvetően felelős a naplóüzenetek küldéséért egy bizonyos kimeneti célállomásra.

íme néhány a leghasznosabb típusú csatolók, hogy a könyvtár biztosítja:

• ConsoleAppender – naplók üzeneteket a rendszerkonzol
• FileAppender – írja log üzeneteket egy fájl
• RollingFileAppender – írja az üzeneteket egy gördülő log file
• JDBCAppender – használ relációs adatbázis naplók
• AsyncAppender – tartalmaz egy listát a többi feladó, és meghatározza a naplók ezeket kell írni egy külön szál

annak érdekében, hogy jobban megértsük, hogyan működnek az appenders, nézzük meg néhány konfigurációs példát.

A RollingFileAppender

minden egyetlen fájlba történő naplózása természetesen nem ideális. Általában sokkal jobb, ha rendszeresen feltekerjük az aktív naplófájlt-pontosan ezt teszi a RollingFileAppender.

akkor is képes lesz arra, hogy túlmegy az alapokat az ilyen típusú appender és konfigurálja mind az egyéni kiváltó politika, valamint borulás stratégia.

a kiváltó házirend határozza meg, hogy mikor gördül a naplófájl, vagyis egy új fájl jön létre, míg a borulás stratégia határozza meg a fájl hengerelését.

Mint egy gyors példa, hadd konfigurálnunk kell egy appender, hogy létrehoz egy új naplófájl alapján 3 politikák:

• OnStartupTriggeringPolicy – egy új log fájl jön létre minden alkalommal, amikor a JVM kezdődik,
• TimeBasedTriggeringPolicy – a naplófájl hengerelt alapján egy dátum/idő minta
• SizeBasedTriggeringPolicy – a fájl hengerelt, amikor elér egy bizonyos méretet,

A konfigurációs fogja használni a DefaultRolloverStrategy:

láthatjuk, hogy mennyire rugalmas ez a konfigurációs stílus, és hogyan lehet beállítani a naplózási stratégia pontos szemantikáját-egészen az utolsó részletig.

A JDBCAppender

ahogy a neve is sugallja, ez az appender JDBC-t használ naplók írására egy relációs adatbázisba.

ehhez a konfigurációhoz meg kell adnia egy ConnectionSource-t, amely lehet JNDI adatforrás vagy egyéni ConnectionFactory. A logger A ConnectionSource-t használja a JDBC kapcsolatok megszerzéséhez, ezért fontos a kapcsolatkészlet használata a jobb teljesítmény érdekében.

az appender XML konfigurációs fájlban történő konfigurálásához használhatja a JDBC címkét:

mint látható, a JNDI adatforrást egyszerűen a DataSource címke jndiName attribútumával kell megadni. A ConnectionSource segítségével meghatározhatja a naplóadatok tárolására használt táblázatot és oszlopokat.

A FailoverAppender

végül vessünk egy pillantást a Failoverappenderre; ez meghatározza az elsődleges appendert és a biztonsági mentések listáját, amelyek belépnek a naplózás kezelésére, ha az elsődleges meghibásodik.

például konfigurálhat egy elsődleges Jdbcappendert, egy másodlagossal a RollingFile és a Console appenders – t abban az esetben, ha adatbázis-kapcsolat nem hozható létre:

termelési környezetben, a naplózási mechanizmus hibaelhárítási stratégiája mindig jó ötlet.

elrendezések konfigurálása

míg a feladók felelősek a naplóüzenetek küldéséért egy rendeltetési helyre, az elrendezéseket az appenderek használják a naplóüzenet formázásának meghatározására.

itt van egy rövid leírás a log4j2 által kínált, leggyakrabban használt elrendezésekről:

• PatternLayout-konfigurálja üzenetek szerint egy karakterlánc minta
• JsonLayout-meghatározza a JSON formátum naplóüzenetek
• CsvLayout-lehet használni, hogy hozzon létre üzeneteket CSV formátumban

A Mintternlayout

az első típusú elrendezés fogunk nézni a Mintternlayout. Ez egy meglehetősen rugalmas megoldás, amely sok ellenőrzést biztosít a naplóüzenet végső kimenetén.

a mechanizmust elsősorban egy konverziós minta hajtja, amely konverziós specifikátorokat tartalmaz. Minden egyes specifikátor a % jellel kezdődik, amelyet módosítók követnek, amelyek olyan dolgokat vezérelnek, mint az üzenet szélessége és színe, valamint egy konverziós karakter, amely képviseli a tartalmat, például a dátumot vagy a szál nevét.

nézzünk egy példát konfigurálása PatternLayout, hogy beállítja a napló vonalak mutatják a dátum, téma, jelentkezzen szinten napló üzenet a különböző színek a különböző napló szint:

Ezek a használt leggyakoribb kódok megéri a megértést, részletesen, vessünk egy közelebbi pillantást:

• %d{HH:mm:ss.SSS} – kimenetek időpontja a napló esemény a megadott formátumban
• %t – kimenetek a szál neve
• %szint – megjeleníti a log level üzenet
• %jelölje ki a {%- os szinten} – is használják, hogy meghatározzák a színek, a minta között kapcsos zárójelek
• %msg%n – kimenet az üzenet napló

A kimenetet megjeleníti a log szint különböző színek:

elolvashatod a teljes lehetőséget meghatározó minták a log4j2 dokumentációt PatternLayout.

A Jsonlayout

naplózási adatoknak a JSON formátum használatával van néhány jelentős előnye,mint például a naplók elemzésének és feldolgozásának megkönnyítése az eszközök naplózásával.

a jsonlayout log4j2-ben történő konfigurálásához egyszerűen meghatározhatja a megfelelő címkét:

<JSONLayout complete="true" compact="false"/>

beállítás teljes = true egy jól kialakított JSON dokumentumot hoz létre:

ahhoz, hogy képes legyen JSON előállítására, hozzá kell adnia a jackson-databind könyvtárat a classpath-hoz:

A szűrők

szűrők konfigurálása a log4j2-ben annak meghatározására szolgál, hogy egy naplóüzenetet feldolgozni vagy kihagyni kell-e.

a szűrő konfigurálható a teljes konfigurációhoz vagy logger vagy appender szinten.

a könyvtár többféle szűrőt biztosít:

• BurstFilter-szabályozza a log események száma megengedett
• DynamicThresholdFilter-szűrők log vonalak alapján bizonyos attribútumok
• RegexFilter-szűrők üzenetek alapján, hogy azok megfelelnek a rendszeres kifejezés

akkor például, hogy ellenőrizzék a sebesség, amellyel az alkalmazás hagyjuk naplózni az adatokat.

ehhez beállíthat egy Burstfiltert, amelyet az információs üzenetekre alkalmazhat:

<Filters> <BurstFilter level="INFO" rate="10" maxBurst="100"/></Filters>

Ez szelektíven figyelmen kívül hagyja az információs szintű üzenetek forgalmát, miközben gondoskodik arról, hogy ne veszítse el az információ feletti fontosabb üzeneteket.

ebben az esetben a rate határozza meg a másodpercenként feldolgozandó átlagos naplóüzeneteket, a maxBurst pedig szabályozza a forgalmi tört teljes méretét, mielőtt a szűrő elkezdi megszüntetni a naplóbejegyzéseket.

hasonlóképpen konfigurálhatjuk az appendert csak egy adott reguláris kifejezésnek megfelelő naplóüzenetek elfogadására:

<Appenders> <JDBC name="JDBCAppender"> <RegexFilter regex="*jdbc*" onMatch="ACCEPT" onMismatch="DENY"/> </JDBC></Appenders>

Összességében ez a szűrési mechanizmus nagy pontossággal használható annak biztosítására, hogy az Általános naplózási konfiguráció minden egyes appender nyomon kövesse a megfelelő információkat. Az a képesség, hogy csak naplózni nagyon specifikus és releváns információkat általában vezet nagyon gyors kiváltó ok elemzés, különösen a komplex rendszerek-különösen, ha párosul egy erős napló megtekintési eszköz.

Loggers

konfigurálása a gyökér logger mellett további Logger elemeket is definiálhatunk különböző naplószintekkel, csatolókkal vagy szűrőkkel. Minden Logger megköveteli a neve, hogy lehet használni, később hivatkozni, hogy:

<Loggers> <Logger name="RollingFileLogger"> <AppenderRef ref="RollingFileAppender" /> </Logger></Loggers>

ahhoz, Hogy írni napló üzenetek segítségével ez különösen a Logger, akkor kaphat egy hivatkozás segítségével a LogManager osztály:

Logger rfLogger = LogManager.getLogger("RollingFileLogger");rfLogger.info("User info updated");

egy Másik nagyon gyakori módja annak, hogy a struktúra a hierarchia ezek a favágók alapján a Java osztály:

Logger logger = LogManager.getLogger(MyServiceTest.class);

Segítségével Kereséseket

a Kereséseket képviseli a módját, hogy helyezze be a külső értékek a log4j2 konfiguráció. Már láttunk egy példát a Dátumkeresésre a RollingFileAppender konfigurációban:

<RollingFile name="RollingFileAppender" fileName="logs/app.log" filePattern="logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.log.gz">

a ${dátum:yyy-MM} keresés beilleszti az aktuális dátumot a fájlnévbe, míg az előző $ egy escape karakter, a keresési kifejezés beillesztése a filePattern attribútumba.

beillesztheti a Rendszer tulajdonságai értékek a log4j2 konfigurációs formátumban ${sys:property_name}:

<File name="ApplicationLog" fileName="${sys:path}/app.log"/>

egy Másik típusú információk keresése, majd helyezze a Java környezet információk:

<PatternLayout header="${java:version} - ${java:os}"> <Pattern>%d %m%n</Pattern></PatternLayout>

további részletek az az adat, akkor helyezze át a kereséseket a log4j2 dokumentáció.

Programmatic Configuration

a konfigurációs fájlok mellett a log4j2 programozottan is konfigurálható. Van néhány különböző módon lehet csinálni, hogy:

• hozzon létre egy egyéni ConfigurationFactory
• használja a Konfigurátor osztály
• módosítsa a konfiguráció után inicializálás
• össze tulajdonságok fájlok programadó konfigurációs

vessünk egy pillantást, hogyan kell beállítani egy elrendezés, valamint appender programból:

a Következő megadhatunk egy favágó segítségével a LoggerConfig osztály munkatársa a appender, majd frissítse a konfiguráció:

Akkor kezdi el használni a logger, mint mindig:

Logger pLogger = LogManager.getLogger("programmaticLogger");pLogger.info("Programmatic Logger Message");

Ez a stílus a fluent API vezethet, hogy egy gyorsabb fejlődés, ismétlés összetettebb fakitermelés konfigurációk, mert most részesülő, az előnyöket dolgozik közvetlenül a Java kódot.

azonban, mivel az XML még olvashatóbb és kompaktabb lehet, gyakran programozottan fejlesztheti a konfigurációt, majd mindent elvégezve XML-re konvertálhatja.

egyéni Naplószintek

a log4j2 beépített naplószintjei a következők:

• OFF
• FATAL
• hiba
• figyelmeztet
• INFO

DEBUG

• TRACE
• minden

Ezen felül egyéni naplószintet is meghatározhat az alkalmazás igényeinek megfelelően.

például az új naplószint meghatározásához használhatja a szintet.forName () API-az új szintnév megadása, valamint egy egész szám, amely a szint helyét jelöli a naplószintek hierarchiájában:

Level myLevel = Level.forName("NEW_LEVEL", 350);

meghatározni, Hogy mi egész értéket kell használni, akkor nézd meg a meghatározott értékeknél a többi napló szint a log4j2 dokumentáció:

A 350 értéket hozza a szintet között FIGYELMEZTETNI az INFÓ, ami azt jelenti, hogy az üzenet akkor jelenik meg, ha a szint beállítása INFO, vagy meghaladja.

egy üzenet egyéni szintű naplózásához a log () módszert kell használnia:

logger.log(myLevel, "Custom Level Message");

az egyenértékű XML konfiguráció lehet:

<CustomLevels> <CustomLevel name="NEW_XML_LEVEL" intLevel="350" /></CustomLevels>

akkor a standard log API-n keresztül használható:

logger.log(Level.getLevel("NEW_XML_LEVEL"),"Custom XML Level Message");

az új egyéni szintek ugyanúgy jelennek meg, mint a standardok:

11:28:23.558 NEW_LEVEL - Custom Level Message11:28:23.559 NEW_XML_LEVEL - Custom XML Level Message

Migrating from Log4j 1.x

ha áttelepít egy alkalmazást az 1.x változata a könyvtár az aktuális 2.x verzió, van egy pár útvonalak követheti:

• használja a log4j 1.x bridge
• manuálisan frissítse az API-t, és a

konfiguráció használata a híd használatával triviális. A log4j függőséget csak a log4j-1.2-api könyvtárra kell cserélnie:

bár ez a gyorsabb módszer, hátránya, hogy korlátozott a konvertálható konfiguráció típusában.

a kézi módszer természetesen több munka, de végül egy rugalmasabb és erősebb naplózási megoldáshoz vezet.

Íme néhány a leggyakoribb típusú változások, amit meg kell tennie:

következtetés

A naplófájlok kritikusak bármely termelési környezetben, és a jó naplózási megoldás kiválasztása lehet a különbség az 5 perc eltöltése és a teljes nap eltöltése között, hogy megértsük a termelési problémát.

A Log4j2 hatékony és robusztus naplózási megoldás a modern Java alkalmazásokhoz, számos konfigurációs opcióval.

lehetővé teszi a fejlett naplózási bevált gyakorlatok, például a gördülő fájlok, a naplózási kimeneti célállomások különböző típusai, a strukturált naplózási formátumok, például a JSON vagy az XML egyszerű konfigurálását, több naplózót és szűrőt, valamint egyéni naplózási szinteket használva.

végül, ha túl kell lépnie a naplóadatok manuális elemzésén, feltétlenül nézze meg a Retrace APM naplózási képességeit.