Naplózás: mit, hogyan, hol és mivel?

Üdv mindenkinek a CodeGym közösségben! Ma beszéljünk a naplózásról:

1. Mi az, miért létezik, mikor érdemes használni, mikor érdemes elkerülni.
2. Milyen naplózási megvalósítások érhetők el a Java-ban, és mit kell tennie ezekkel a naplózási lehetőségekkel.
És naplózási szintek. Megbeszéljük, mi az a függelék, és hogyan kell helyesen konfigurálni.
3. A csomópontok naplózása és azok helyes konfigurálása, hogy minden a kívánt módon működjön.

Ez az anyag széles közönség számára készült. Mindenki számára világos lesz, aki csak ismeri a Java-t, valamint azoknak, akik már dolgoznak, de még csak felfedezték a logger.info("log something"); Let's go!

Miért van szükség naplózásra?

Nézzünk meg néhány valós esetet, amikor a naplózás megoldhat egy problémát. Íme egy példa a munkámból. Vannak olyan pontok, ahol egy alkalmazás integrálódik más szolgáltatásokkal. A naplózást ezeken a pontokon használom egyfajta "alibit" megállapítására : ha az integráció nem működik, akkor könnyen kideríthető, melyik oldalon van a probléma. Kívánatos az adatbázisban tárolt fontos információk naplózása is. Például egy adminisztrátori felhasználó létrehozása. Pontosan ez az a fajta dolog, amit jó lenne naplózni.

Eszközök a Java-ba való bejelentkezéshez

A jól ismert Java naplózási megoldások közül a következőket emelhetjük ki:

• Log4j
• JUL — java.util.logging
• JCL – Jakarta Commons naplózása
• Logback
• SLF4J – Egyszerű naplózási homlokzat Java-hoz

System.err.println

Kezdetben volt a System.err.println (naplóbejegyzések megjelenítése a konzolon). Még ma is ezt a technikát használják hibakereséskor a napló gyors rögzítésére. Természetesen itt nincs megvitatandó beállítás, ezért csak emlékezzen erre a módszerre, és továbblépünk.

Log4j

Ez egy teljes megoldás, amelyet a fejlesztők szükségből hoztak létre. Az eredmény egy igazán érdekes eszköz, amelyet használhat. Különféle körülmények miatt ez a megoldás nem került be a JDK-ba, ami az egész közösséget nagyon felzaklatta. A Log4j olyan konfigurációs beállításokkal rendelkezik, amelyek lehetővé teszik a bejelentkezést a csomagban com.example.type, és kikapcsolhatja az alcsomagban com.example.type.generic. Ez lehetővé teszi a nem naplózandó kód gyors kizárását. Itt fontos megjegyezni, hogy a Log4j-nek két változata létezik: 1.2.x és 2.xx, és ezek nem kompatibilisek egymással . A Log4j hozzáadta az appender fogalmát(naplók írásához használt eszköz) és az elrendezés (napló formázása). Ez lehetővé teszi, hogy csak azt naplózza, amire szüksége van, és pontosan úgy naplózza, ahogyan szüksége van rá. A függelékről kicsit később fogunk még beszélni.

JUL — java.util.logging

Ennek a megoldásnak az egyik legfontosabb előnye, hogy a JUL benne van a JDK-ban (Java Development Kit). Sajnos a kidolgozásakor az alkotók nem a népszerű Log4j segédprogramot vették alapul, hanem az IBM megoldását. Ennek a döntésnek következményei voltak. A valóság az, hogy most senki sem használja a JUL-t. A JUL naplózási szintjei eltérnek a Logback, Log4j és Slf4j szintjeitől. Ez megnehezíti számukra, hogy megértsék egymást. A logger létrehozása többé-kevésbé hasonló. Ehhez importálást kell végrehajtania:

java.util.logging.Logger log = java.util.logging.Logger.getLogger(LoggingJul.class.getName());

Az osztálynév át lett adva, így tudjuk, honnan származnak a naplózásaink. A Java 8-tól kezdve átadhatja a Supplier<String>. Ez segít nekünk csak akkor olvasni és létrehozni egy sort, amikor valóban szükségünk van rá, nem pedig minden alkalommal, ahogy az korábban történt. A fejlesztők csak a Java 8 megjelenésével oldották meg végre a fontos problémákat, és tették igazán használhatóvá a JUL-t. Nevezetesen paraméteres metódusok Supplier<String> msgSupplier, az alábbiak szerint:

public void info(Supplier<String> msgSupplier) {
   log(Level.INFO, msgSupplier);
}

JCL – Jakarta Commons naplózása

Mivel sokáig nem létezett ipari szabvány a naplózásra vonatkozóan, és sokan készítettek saját egyéni naplózót, a döntés született a JCL, egy általános wrapper kiadása mellett, amelyet mások mellett is lehetne használni. Miért? Néha a projekthez hozzáadott függőségek a projektben lévőtől eltérő naplózót használtak. Emiatt tranzitív függőségekként kerültek a projektbe, és ez valódi problémákat okozott, amikor megpróbálták összerakni az egészet. Sajnos a csomagolás nem volt túl működőképes, és nem adott hozzá semmit. Valószínűleg kényelmes lenne, ha mindenki JCL-t használna. De nem ez történt, így a JCL használata jelenleg nem a legjobb ötlet.

Logback

A nyílt forráskódú elérési út nehézkes... Ugyanaz a fejlesztő, aki a Log4j-t írta, a Logbacket is írta utódnaplózási keretrendszerként. Ugyanaz az ötlet volt, mint a Log4j. A Logback különbségei a következők:

• jobb teljesítmény
• hozzáadva az Slf4j natív támogatását
• kibővített szűrési lehetőségek

Alapértelmezés szerint a Logback nem igényel konfigurációt, és minden eseményt DEBUG vagy magasabb szinten rögzít. Ha némi testreszabásra van szüksége, azt XML konfigurációval érheti el:

<configuration> 
    <appender name="FILE" class="ch.qos.logback.core.FileAppender"> 
        <file>app.log</file> 
        <encoder> 
            <pattern>%d{HH:mm:ss,SSS} %-5p [%c] - %m%n</pattern> 
        </encoder> 
    </appender> 
    <logger name="org.hibernate.SQL" level="DEBUG" /> 
    <logger name="org.hibernate.type.descriptor.sql" level="TRACE" /> 
    <root level="info"> 
        <appender-ref ref="FILE" /> 
    </root> 
</configuration>

SLF4J – Egyszerű naplózási homlokzat Java-hoz

Valamikor 2006-ban a Log4j egyik alapító atyja elhagyta a projektet, és létrehozta az Slf4j-t (Simple Logging Facade for Java), a Log4j, a JUL, a közös naplózás és a Logback csomagolóanyagát. Amint láthatja, eljutottunk odáig, hogy egy burkolólapot hozzunk létre... Ebben az esetben ez két részre oszlik: egy API-ra, amelyet az alkalmazásban használunk, és egy megvalósításra, amelyhez különálló függőségek az egyes naplózási típusokhoz. Például slf4j-log4j12.jarés slf4j-jdk14.jar. Be kell kapcsolnia a megfelelő megvalósítást, és ennyi: az egész projekt használni fogja. Az Slf4j támogatja az összes legújabb szolgáltatást, például a naplózáshoz használt karakterláncok formázását. Korábban is volt ilyen probléma. Tegyük fel, hogy létrehozunk egy ilyen naplóbejegyzést:

log.debug("User " + user + " connected from " + request.getRemoteAddr());

Az összefűzési operátornak köszönhetően az userobjektum csendben karakterláncsá válik a -nak köszönhetően user.toString(). Ez időt vesz igénybe, és lelassítja a rendszert. És ez rendben is lehet, ha az alkalmazás hibakeresését végezzük. Akkor kezdünk problémákba ütközni, ha ennek az osztálynak a naplózási szintje INFO vagy magasabb. Más szóval, ne írjuk ezt a naplóbejegyzést (INFO vagy magasabb), és ne használjunk karakterlánc-összefűzést. Elméletileg magának a naplózási könyvtárnak kellene foglalkoznia ezzel. Amint megtörtént, ez bizonyult a legnagyobb problémának a Log4j első verziójában. Nem hozott tisztességes megoldást, ehelyett valami ilyesmit javasolt:

if (log.isDebugEnabled()) {
    log.debug("User " + user + " connected from " + request.getRemoteAddr());
}

Vagyis a naplózáshoz egy kódsor helyett 3 írást javasoltak! A naplózásnak minimálisra kell csökkentenie a kódváltozásokat, és a három sor egyértelműen sérti ezt az általános megközelítést. Az Slf4j-nek nem voltak kompatibilitási problémái a JDK-val és az API-val, így azonnal megjelent egy jó megoldás:

log.debug("User {} connected from {}", user, request.getRemoteAddr());

ahol {}a metódusnak átadott argumentumok helyőrzőit jelöli. Vagyis az elsőnek {}felel meg user, a másodiknak {}pedig request.getRemoteAddr(). Ezzel a módszerrel csak akkor hajtunk végre karakterlánc-összefűzést, ha a naplószint megköveteli a naplóbejegyzés megírását. Ezt követően az Sjf4j népszerűsége gyorsan növekedni kezdett. Jelenleg ez a legjobb megoldás. Ennek megfelelően vessünk egy pillantást a slf4j-log4j12kötés segítségével történő naplózásra.

Amit naplózni kell

Természetesen nem szabad mindent naplózni. Ez gyakran nem szükséges, sőt néha veszélyes is. Ha például naplózza valaki személyes adatait, és azok valahogy kiszivárognak, akkor valódi problémák lesznek, különösen a nyugati piacokra koncentráló projektekben. De vannak olyan dolgok is, amelyeket mindenképpen be kell jegyezned :

1. Az alkalmazás kezdete/vége. Tudnunk kell, hogy az alkalmazás valóban a várt módon kezdődött-e és fejeződött be.
2. Biztonsági kérdések. Itt jó lenne naplózni valakinek a jelszavának kitalálására tett kísérleteket, az adminisztrátorok bejelentkezésének eseteit stb.
3. Bizonyos alkalmazási állapotok . Például az egyik állapotból a másikba való átmenet egy üzleti folyamatban.
4. Bizonyos hibakeresési információk a megfelelő naplózási szinttel együtt.
5. Bizonyos SQL-szkriptek. Vannak valós esetek, amikor erre szükség van. De ismét a naplószintek ügyes beállításával kiváló eredményeket érhet el.
6. A futó szálak naplózhatók, amikor ellenőrizzük, hogy a dolgok megfelelően működnek.

Népszerű hibák a naplózásban

Számos árnyalat van itt, de külön megemlítünk néhány gyakori hibát:

1. Túlzott fakitermelés. Nem szabad minden olyan lépést naplózni, amely elméletileg fontos lehet. Itt egy jó ökölszabály: a rönkök nem haladhatják meg a terhelés 10%-át. Ellenkező esetben teljesítményproblémák lépnek fel.
2. Minden adat naplózása egy fájlba. Ez egy bizonyos ponton nagyon megnehezíti a napló olvasását/írását, nem is beszélve arról, hogy bizonyos rendszereken korlátok vannak a fájlméretben.
3. Helytelen naplószintek használata. Minden naplószintnek világos határai vannak, és ezeket tiszteletben kell tartani. Ha egy határ nem világos, megállapodhat arról, hogy melyik szintet használja.

Napló szintek

Mik azok a naplószintek? A naplóbejegyzések hierarchiájának valamilyen módon történő létrehozásához bizonyos konvenciókra és elhatárolásokra van szükség. Ezért vezették be a naplószinteket. A szint az alkalmazásban van beállítva. Ha egy bejegyzés egy meghatározott szint alatt van, akkor nem kerül naplózásra. Például vannak naplóink, amelyeket az alkalmazás hibakeresése során használunk. Normál működés közben (amikor az alkalmazást rendeltetésszerűen használják) nincs szükség ilyen naplókra. Ezért a naplózási szint magasabb, mint a hibakeresésnél. Nézzük meg a naplózási szinteket a Log4j segítségével. A JUL-on kívül más megoldások is ugyanazokat a naplózási szinteket használják. Itt vannak csökkenő sorrendben:

• KI: Nincsenek naplóbejegyzések rögzítve; mindent figyelmen kívül hagynak.
• VÉGZETES: Hiba, amely megakadályozza az alkalmazás futásának folytatását. Például: "JVM kifogyott a memóriából hiba".
• HIBA: Az ezen a szinten lévő hibák olyan problémákat jeleznek, amelyeket meg kell oldani. A hiba nem állítja le az alkalmazás egészét. Más kérések megfelelően működhetnek.
• FIGYELMEZTETÉS: Figyelmeztetést jelentő naplóbejegyzések. Valami váratlan történt, de a rendszer képes volt megbirkózni és teljesítette a kérést
• INFORMÁCIÓ: Naplóbejegyzések, amelyek fontos műveleteket jeleznek az alkalmazásban. Ezek nem hibák vagy figyelmeztetések. Ezek várható rendszeresemények.
• HIBAKERESÉS: A naplóbejegyzéseknek az alkalmazás hibakereséséhez szükséges. Annak biztosítására, hogy az alkalmazás pontosan azt tegye, amit elvárnak, vagy az alkalmazás által végrehajtott műveletek leírására, azaz "Bevitt módszer1".
• TRACE: Alacsonyabb prioritású naplóbejegyzések hibakereséshez. A legalacsonyabb naplószint.
• ALL: Egy naplószint az alkalmazás összes naplóbejegyzésének írásához.

Az INFO naplózási szint valahol az alkalmazásban engedélyezve van, ekkor minden szint bejegyzése naplózásra kerül, az INFO-tól a FATAL-ig. Ha a FATAL naplószint be van állítva, akkor csak az adott szintű naplóbejegyzések kerülnek kiírásra.

Napló naplózása és küldése: Függelék

Nézzük meg, hogyan működik mindez, amikor a Log4j-t használjuk, amely bőséges lehetőséget biztosít a naplók írására/küldésére:

• fájlba írni —DailyRollingFileAppender
• információkat írni a konzolra —ConsoleAppender
• naplókat írni egy adatbázisba —JDBCAppender
• naplók küldésének kezelése TCP/IP-n keresztül —TelnetAppender
• annak biztosítása érdekében, hogy a naplózás ne befolyásolja negatívan a teljesítményt –AsyncAppender

Van még néhány megvalósítás: a teljes lista itt érhető el . Mellesleg, ha nem létezik a hozzá tartozó csatoló, akkor az sem probléma. A Log4j által támogatott Appender interfész megvalósításával saját függeléket írhat .

Naplózási csomópontok

Demonstrációs célokra egy Slf4j felületet fogunk használni, a Log4j implementációjával. A naplózó létrehozása nagyon egyszerű: egy nevû osztályban MainDemo, amely némi naplózást végez, hozzá kell adnunk a következõket:

org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(MainDemo.class);

Ezzel létrehozunk egy loggert. A naplóbejegyzés elkészítéséhez számos módszer áll rendelkezésre, amelyek neve tükrözi, hogy melyik naplózási szintet fogja használni. Például:

logger.trace("Method 1 started with argument={}", argument);
logger.debug("Database updated with script = {}", script);
logger.info("Application has started on port = {}", port);
logger.warn("Log4j didn't find the log4j.properties file. Please fix this.");
logger.error("Connection refused to host = {}", host);

Bár áthaladunk az órán, a végső név az osztály teljes neve, beleértve a csomagokat is. Ez azért történik, hogy a későbbiekben a naplózást csomópontokra bontsa, és minden csomóponthoz beállítsa a naplózási szintet és a hozzáfűzőt. Például a naplózót az osztályban hozták létre com.github.romankh3.logginglecture.MainDemo. A név adja az alapot a naplózási csomópontok hierarchiájának létrehozásához. A fő csomópont a legfelső szintű RootLogger . Ez az a csomópont, amely a teljes alkalmazás összes naplóbejegyzését megkapja. A többi csomópont az alábbiak szerint ábrázolható: A függelékek meghatározott naplózási csomópontokhoz vannak beállítva. Most megnézzük a log4j.properties fájlt, hogy lássunk egy példát ezek beállítására.

A log4j.properties fájl lépésenkénti útmutatója

Egyszerre mindent beállítunk, és meglátjuk, mi lehetséges:

log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender

Ez a sor azt mondja, hogy regisztráljuk a CONSOLE hozzáfűzőt, amely az org.apache.log4j.ConsoleAppender megvalósítást használja. Ez a függelék információkat ír a konzolba. Ezután egy másik függeléket regisztrálunk. Ez egy fájlba írja:

log4j.appender.FILE=org.apache.log4j.RollingFileAppender

Fontos megjegyezni, hogy magukat a csatolókat még konfigurálni kell. Miután regisztráltuk a függelékeinket, meghatározhatjuk, hogy mely naplózási szintek és milyen függelékek kerüljenek felhasználásra a csomópontokon.

log4j.rootLogger=DEBUG, KONZOL, FÁJL

• A log4j.rootLogger azt jelenti, hogy a gyökércsomópontot konfiguráljuk, amely az összes naplóbejegyzést tartalmazza
• Az egyenlőségjel utáni első szó jelzi az írandó minimális naplózási szintet (esetünkben ez a DEBUG)
• A vessző után feltüntetjük az összes használandó függeléket.

Egy konkrétabb naplózási csomópont beállításához egy ehhez hasonló bejegyzést kell használnia:

log4j.logger.com.github.romankh3.logginglecture=TRACE, OWN, CONSOLE

ahol log4j.logger.egy adott csomópontra hivatkozik. Esetünkben com.github.romankh3.logginglecture. most beszéljünk a CONSOLE függelék konfigurálásáról:

# CONSOLE appender customization
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.threshold=DEBUG
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=[%-5p] : %c:%L : %m%n

Itt látjuk, hogy be lehet állítani azt a konkrét szintet, amelyen az appender elkezd dolgozni. Íme egy példa arra, hogy mi történik valójában: tegyük fel, hogy egy INFO szintű üzenetet fogad a naplózó csomópont, és továbbítja a hozzá rendelt csatolónak. Ha a csatoló küszöbértéke WARN, akkor megkapja a naplóbejegyzést, de nem csinál vele semmit. Ezután el kell döntenünk, hogy az üzenet melyik elrendezést használja. A példában a PatternLayout-ot használom, de sok más lehetőség is van. Ebben a cikkben nem foglalkozunk velük. Példa a FILE függelék konfigurálására:

# File appender customization
log4j.appender.FILE=org.apache.log4j.RollingFileAppender
log4j.appender.FILE.File=./target/logging/logging.log
log4j.appender.FILE.MaxFileSize=1MB
log4j.appender.FILE.threshold=DEBUG
log4j.appender.FILE.MaxBackupIndex=2
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=[ %-5p] - %c:%L - %m%n

Beállíthatja azt a fájlt, amelybe a naplóbejegyzések kerüljenek beírásra, amint az ebből a sorból látható:

log4j.appender.FILE.File=./target/logging/logging.log

A bejegyzés a fájlba kerül logging.log. A fájlmérettel kapcsolatos problémák elkerülése érdekében beállíthatja a maximumot, amely ebben az esetben 1 MB. MaxBackupIndexazt jelzi, hogy hány ilyen naplófájl lesz. Ha ennél több fájlt kell létrehoznunk, akkor az első fájl törlődik. Ha egy valós példát szeretne látni, amikor a naplózás be van állítva, lépjen a GitHub nyilvános tárházába .

Erősítse meg, amit megbeszéltünk

Próbáljon meg egyedül mindent, amit leírtunk:

• Hozzon létre saját projektet a fenti példánkhoz hasonlóan.
• Ha tudja, hogyan kell használni a Mavent, használja. Ha nem, akkor olvassa el ezt az oktatóanyagot, amely leírja, hogyan kell csatlakoztatni a könyvtárat.

összefoglalva

1. Beszéltünk a Java-ban létező naplózási megoldásokról.
2. Szinte az összes ismert naplózókönyvtárat egy ember írta :D
3. Megtanultuk, mit kell és mit nem szabad naplózni.
4. Kiszámoltuk a naplószinteket.
5. Megismerkedtünk a naplózási csomópontokkal.
6. Megnéztük, mi az a függelék, és mire való.
7. Lépésről lépésre létrehoztunk egy log4j.proterties fájlt.

Kiegészítő anyagok

1. CodeGym: Logger lecke
2. Weekly Geekly: Java naplózás. Helló Világ
3. Kódolási horror: Probléma a naplózással
4. YouTube: A Java naplózási pokol megértése – az alapok. Java naplózási pokol és hogyan maradj ki belőle
5. Log4j: Függelék
6. Log4j: Elrendezés

Tekintse meg másik cikkemet is:

• Hibakeresés az IntelliJ IDEA-ban: útmutató kezdőknek