• Articles
• admin

első láthatóság az alkalmazás elengedhetetlen, ha fut a kódot a termelés. Mit jelent a láthatóság? Elsősorban olyan dolgok, mint az alkalmazás teljesítménye metrikákon keresztül, az alkalmazás állapota és elérhetősége, naplói, ha hibaelhárításra van szükség, vagy nyomai, ha meg kell találnia, hogy mi teszi lassúvá és hogyan lehet gyorsabbá tenni.

a mutatók információt nyújtanak az infrastruktúra egyes elemeinek teljesítményéről. A Traces a kódfuttatás és a folyamat szélesebb körű áttekintését mutatja a kódfuttatási mutatókkal együtt. Végül, a jól kidolgozott naplók felbecsülhetetlen betekintést nyújtanak a kódlogika végrehajtásába és a kódban történt eseményekbe. Az említett darabok mindegyike elengedhetetlen az alkalmazásához, sőt a rendszer általános megfigyelhetőségéhez. Ma csak egyetlen darabra fogunk összpontosítani-a rönkökre. Pontosabban – a Java alkalmazás naplóin. Ha érdekli a mutatók, olvassa el cikkünket a legfontosabb JVM mutatókról, amelyeket figyelnie kell.

mielőtt azonban belemennénk, Foglalkozzunk egy olyan kérdéssel, amely hatással volt a közösségre a keretrendszer használatával. 9. December 2021-én a log4shell becenevű kritikus biztonsági rést jelentették. CVE-2021-44228 néven azonosítva lehetővé teszi a támadó számára, hogy teljes mértékben átvegye az Apache Log4j 2 2.14.1 vagy újabb verziót futtató gép irányítását, lehetővé téve számukra, hogy tetszőleges kódot hajtsanak végre a sebezhető kiszolgálón. A Log4jShell biztonsági résről szóló legutóbbi blogbejegyzésünkben részletesen leírtuk, hogyan állapítható meg, hogy Ön érintett-e, hogyan oldható meg a probléma, és mit tettünk a rendszerünk és a felhasználók védelme érdekében.

Log4j 1.x End of Life

ne feledje, hogy augusztus 5-én, 2015 A naplózási szolgáltatások Projektmenedzsment Bizottsága bejelentette, hogy a Log4j 1.x elérte élete végét. Minden felhasználónak ajánlott áttérni a Log4j 2 – re.x. ebben a blogbejegyzésben, segítünk megérteni a jelenlegi Log4j beállítást-konkrétan, a log4j 2.x verzió – és ezt követően segítek áttérni a legújabb és legnagyobb Log4j verzióra.

” Log4j 1-et használok.x, mit tegyek?”. Ne essen pánikba, nincs semmi baj vele. Készítsen tervet a Log4j 2-re való áttéréshez.x. megmutatom, hogy csak olvass tovább :). Az alkalmazás fogja megköszönni, hogy. Az áttelepítés után megkapja a biztonsági javításokat, a teljesítményjavításokat és sokkal több funkciót.

“új projektet indítok, mit tegyek?”. Csak használja a Log4j 2.x azonnal, ne is gondoljon a Log4j 1-re.x. Ha segítségre van szüksége, nézze meg ezt a Java naplózási oktatóanyagot, ahol mindent elmagyarázok, amire szüksége van.

Bejelentkezés Java-ban

a Java-ban történő bejelentkezés mögött nincs varázslat. Minden jön le, hogy egy megfelelő Java osztály és a módszerek generálni log eseményeket. Amint azt a Java naplózási útmutatóban megbeszéltük, többféle módon lehet elindítani

természetesen a naivabb és nem a legjobb út a rendszer használata.ki és rendszer.err osztályok. Igen, ezt megteheti, és az üzenetek csak a standard kimenetre és a standard hibára kerülnek. Általában ez azt jelenti, hogy kinyomtatják a konzolra, vagy valamilyen fájlba írják, vagy akár elküldik a /dev/null címre, és örökre elfelejtik. Egy ilyen kód példája így nézhet ki:

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) ); }}

a fenti kódfuttatás kimenete a következő lenne:

Starting my awesome applicationMy application class com.sematext.logging.log4jsystem.SystemExample started successfully

ez nem tökéletes, igaz? Nincs információm arról, hogy melyik osztály generálta az üzenetet, és még sok-sok “apró” dologról, amelyek kulcsfontosságúak és fontosak a hibakeresés során.

vannak más dolgok, amelyek hiányoznak, amelyek nem igazán kapcsolódnak a hibakereséshez. Gondoljon a végrehajtási környezetre, több alkalmazásra vagy mikroszolgáltatásra, valamint a naplózás egységesítésének szükségességére a naplózási központosítási folyamat konfigurációjának egyszerűsítése érdekében. A rendszer használata.ki, vagy rendszer.az err a naplózási célú kódunkban arra kényszerítene minket, hogy újra megismételjük az összes helyet, ahol használjuk, amikor csak módosítanunk kell a naplózási formátumot. Tudom, hogy ez extrém, de hidd el, láttuk a rendszer használatát.ki a termelési kódot a “hagyományos” alkalmazás telepítési modellek! Természetesen naplózás a rendszerbe.az out megfelelő megoldás konténeres alkalmazásokhoz, ezért a környezetének megfelelő kimenetet kell használnia. Emlékezz erre!

az említett okok miatt és még sok más miatt, amelyekre nem is gondolunk, érdemes megvizsgálni az egyik lehetséges naplózási könyvtárat, például a Log4 j, a Log4j 2, A Logback vagy akár a java.util.naplózás, amely része a Java Development Kit. Ehhez a blogbejegyzéshez a Log4j-t fogjuk használni.

az absztrakciós réteg – SLF4J

a Java alkalmazáshoz megfelelő naplózási megoldás kiválasztásának témája olyasmi, amit már a Java-ban történő bejelentkezésről szóló oktatóanyagunkban tárgyaltunk. Javasoljuk, hogy olvassa el legalább az említett részt.

az SLF4J – t fogjuk használni, egy absztrakciós réteget a Java kódunk és a Log4j-a választott naplózási könyvtár között. Az egyszerű naplózási homlokzat kötéseket biztosít az olyan általános naplózási keretrendszerekhez, mint a Log4j, a Logback és a java.util.fakitermelés. Képzelje el a naplóüzenet írásának folyamatát a következő, egyszerűsített módon:

megkérdezheti, miért használjon egyáltalán absztrakciós réteget? Nos, a válasz meglehetősen egyszerű – végül érdemes lehet megváltoztatni a naplózási keretet, frissíteni, egyesíteni a többi technológiai veremmel. Amikor egy absztrakciós réteg ilyen művelet meglehetősen egyszerű – csak kicserélni a naplózási keret függőségek és egy új csomagot. Ha nem használnánk absztrakciós réteget – meg kellene változtatnunk a kódot, potenciálisan sok kódot. Minden osztály, amely naplózza valamit. Nem túl szép fejlesztési tapasztalat.

A Logger

a Java alkalmazás kódja kölcsönhatásba lép egy szabványos kulcselemekkel, amelyek lehetővé teszik a napló esemény létrehozását és manipulálását. A Java naplózási oktatóanyagunkban lefedtük a legfontosabbakat, de hadd emlékeztessem önöket az egyik osztályra, amelyet folyamatosan használunk – a Naplózóra.

a naplózó az a fő entitás, amelyet egy alkalmazás naplózási hívások kezdeményezésére használ – naplóesemények létrehozása. A Logger objektumot általában egyetlen osztályhoz vagy egyetlen komponenshez használják, hogy kontextushoz kössék egy adott használati esetet. Módszereket biztosít a naplózási események megfelelő naplószinttel történő létrehozására, majd továbbadására további feldolgozásra. Általában létrehoz egy statikus objektumot, amellyel kölcsönhatásba lép, például így:

... Logger LOGGER = LoggerFactory.getLogger(MyAwesomeClass.class);

és ez minden. Most, hogy tudjuk, mire számíthatunk, nézzük meg a Log4j könyvtárat.

Log4j

a legegyszerűbb módja annak, hogy log4j kezdeni, hogy tartalmazza a könyvtárat a classpath a Java alkalmazás. Ehhez mi is a legújabb elérhető log4j könyvtár, ami azt jelenti, verzió 1.2.17 a build fájlt.

az általunk használt Gradle és a mi egyszerű alkalmazás és a függőségek szakasz Gradle build fájl a következőképpen néz ki:

dependencies { implementation 'log4j:log4j:1.2.17'}

elkezdhetjük a kód fejlesztését és a naplózást a Log4j használatával:

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"); }}

amint az a fenti kódban látható, A Logger objektumot statikus getlogger metódussal inicializáltuk, és megadtuk az osztály nevét. Ezt követően könnyen hozzáférhetünk a statikus Logger objektumhoz, és felhasználhatjuk naplózási események előállítására. Ezt megtehetjük a fő módszerben.

egy oldalsó megjegyzés – a getLogger metódust argumentumként egy karakterlánccal is meg lehet hívni, például:

private static final Logger LOGGER = Logger.getLogger("com.sematext.blog");

ez azt jelentené, hogy szeretnénk létrehozni egy naplózót és társítani a com nevét.sematext.blog vele. Ha ugyanazt a nevet használjuk bárhol máshol a kódban, a Log4j ugyanazt a naplózó példányt adja vissza. Ez akkor hasznos, ha szeretnénk kombinálni naplózás több különböző osztályok egy helyen. Például a fizetéssel kapcsolatos naplók egyetlen, dedikált naplófájlban.

a Log4j felsorolja azokat a módszereket, amelyek lehetővé teszik új naplóesemények létrehozását a megfelelő naplószint használatával. Ezek a következők:

• nyilvános érvénytelen nyomkövetés (Objektumüzenet)
• nyilvános érvénytelen hibakeresés (Objektumüzenet)
• nyilvános érvénytelen információ (Objektumüzenet)
• nyilvános érvénytelen figyelmeztetés (Objektumüzenet)
• nyilvános érvénytelen hiba (Objektumüzenet)
• nyilvános érvénytelen végzetes (Objektumüzenet)

egy általános módszer:

• nyilvános érvénytelen napló (szint szint, objektum üzenet)

a Java naplózási szintekről a Java naplózási bemutató blogbejegyzésünkben beszéltünk. Ha nem ismeri őket, kérjük, szánjon néhány percet arra, hogy megszokja őket, mivel a naplószintek kulcsfontosságúak a naplózáshoz. Ha még csak most kezdi a naplózási szinteket, azt javasoljuk, hogy nézze át a naplózási szintek útmutatónkat is. Mindent elmagyarázunk, attól kezdve, hogy mik azok, hogy hogyan válasszuk ki a megfelelőt, és hogyan használjuk fel őket, hogy értelmes betekintést kapjunk.

ha a fenti kódot futtatnánk, a szabványos konzolon kapott kimenet a következő lenne:

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.

nem láttuk azt az üzenetet, amire számítottunk. Log4j tájékoztatott minket, hogy nincs konfiguráció jelen. Oooops, beszéljünk a Log4j konfigurálásáról …

Log4j konfiguráció

többféle módon konfigurálhatjuk a Log4j naplózást. Meg tudjuk csinálni programozottan – például egy statikus inicializálási blokk beillesztésével:

static { BasicConfigurator.configure();}

a fenti kód úgy konfigurálja a Log4j-t, hogy a naplókat az alapértelmezett formátumban adja ki a konzolra. A példa alkalmazás futtatásának kimenete a következőképpen néz ki:

0 INFO com.sematext.blog.ExampleLog4jProgrammaticConfig - Initializing ExampleLog4j application

a Log4j programozott beállítása azonban nem túl gyakori. A leggyakoribb módszer egy tulajdonságfájl vagy egy XML fájl használata. Megváltoztathatjuk a kódunkat, és a log4j.properties fájlt a következő tartalommal tölthetjük fel:

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

így azt mondta Log4j, hogy mi hozza létre a root logger, hogy fogják használni alapértelmezés szerint. Az alapértelmezett naplózási szint beállítása hibakeresés, ami azt jelenti, hogy napló események súlyossága hibakeresés vagy magasabb lesz benne. Tehát hibakeresés, INFO, figyelmeztetés, hiba és végzetes. Azt is adott a logger egy nevet – MAIN. Ezután konfiguráljuk a naplózót úgy, hogy a kimenetét konzolra állítjuk, majd a minta elrendezését használjuk. Erről később a blogbejegyzésben fogunk beszélni. A fenti kód futtatásának kimenete a következő lenne:

0 INFO com.sematext.blog.ExampleLog4jProperties - Initializing ExampleLog4j application

ha szeretnénk, megváltoztathatjuk a log4j. properties fájlt is, és használhatunk egy úgynevezett log4j.xml. Ugyanaz a konfiguráció XML formátumban a következőképpen néz ki:

<!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>

ha most megváltoztatnánk a log4j. properties for log4j.xml a példa alkalmazásunk végrehajtása a következő lenne:

0 INFO com.sematext.blog.ExampleLog4jXML - Initializing ExampleLog4j application

tehát honnan tudja a Log4j, hogy melyik fájlt használja? Nézzünk utána.

inicializálási folyamat

fontos tudni, hogy a Log4j nem feltételez semmilyen feltételezést arról a környezetről, amelyben fut. A Log4j nem feltételez semmilyen alapértelmezett naplózási eseményt. Amikor elindul, megkeresi a log4j. configuration tulajdonságot, és megpróbálja betölteni a megadott fájlt konfigurációként. Ha a fájl helyét nem lehet URL-re konvertálni, vagy a fájl nincs jelen, akkor megpróbálja betölteni a fájlt az osztályútvonalról.

ez azt jelenti, hogy felülírhatjuk a log4j konfigurációt a classpath-ból azáltal, hogy megadjuk a-Dlog4j.configuration-t indításkor, és a megfelelő helyre mutatjuk. Például, ha belefoglalunk egy másik nevű fájlt.xml a következő tartalommal:

<!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>

majd fut ki kódot-Dlog4j.configuration=/opt/sematext/egyéb.xml a kódunk kimenete a következő lesz:

0 INFO com.sematext.blog.ExampleLog4jXML - Initializing ExampleLog4j application

Log4j Appenders

példáinkban már használtuk az appendereket… nos, tényleg csak egy – a ConsoleAppender. Egyetlen célja, hogy a napló eseményeit a konzolra írja. Természetesen a nagyszámú naplózási esemény és a különböző környezetekben futó rendszerek nem feltétlenül a legjobb ötlet, ha tiszta szöveges adatokat írunk a szabványos kimenetre, kivéve, ha konténerekben futunk. Ezért Log4j támogatja többféle Appenders. Íme néhány gyakori példa a Log4j appenderekre:

• ConsoleAppender – az appender, amely hozzáfűzi a napló eseményeket rendszer.ki vagy rendszer.err az alapértelmezett rendszer.kifelé. Ha ezt appender látni fogja a naplókat a konzol az alkalmazás.
• FileAppender – a hozzáfűző, amely hozzáfűzi a napló eseményeket egy meghatározott fájl tárolja őket a fájlrendszerben.
• RollingFileAppender – az appender, amely kiterjeszti a FileAppender és elforgatja a fájlt, amikor elér egy meghatározott méretet. A RollingFileAppender használata megakadályozza, hogy a naplófájlok nagyon nagyok és nehezen karbantarthatók legyenek.
• SyslogAppender – az appender elküldi a napló eseményeket egy távoli Syslog démon.
• JDBCAppender – az appender, amely tárolja a napló eseményeket az adatbázisba. Ne feledje, hogy ez az appender nem tárolja a hibákat, és általában nem a legjobb ötlet, hogy tárolja a napló eseményeket egy adatbázisban.
• SocketAppender – az appender, amely elküldi a sorosított log események egy távoli socket. Ne feledje, hogy ez az appender nem használ elrendezéseket, mert elküldi a sorosított, nyers naplóeseményeket.
• NullAppender – az appender, hogy csak elveti a napló eseményeket.

mi több, több Appendert is konfigurálhat egyetlen alkalmazáshoz. Például naplókat küldhet a konzolra vagy egy fájlba. A következő log4j.a tulajdonságok fájl tartalma pontosan ezt tenné:

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

a root logger úgy van beállítva, hogy jelentkezzen mindent kezdve a hibakeresés súlyosságát, és küldje el a naplókat két Appenders – a fő és a gördülő. A fő naplózó az, amit már láttunk – az, amely elküldi az adatokat a konzolra.

a második naplózó, az úgynevezett gördülő az érdekesebb ebben a példában. Használja a RollingFileAppender amely írja az adatokat a fájlba, és nézzük meg, hogy mekkora a fájl lehet, és hány fájlt kell tartani. Esetünkben a naplófájlokat félelmetesnek kell nevezni.írjuk be az adatokat a /var/log/ sematext / könyvtárba. Minden fájl legfeljebb 1024kb lehet, és legfeljebb 10 fájl tárolható. Ha több fájl van, akkor eltávolítják őket a fájlrendszerből, amint a log4j látja őket.

miután a fenti konfigurációval futtatta a kódot, a konzol a következő tartalmat nyomtatja ki:

0 INFO com.sematext.blog.ExampleAppenders - Starting ExampleAppenders application1 WARN com.sematext.blog.ExampleAppenders - Ending ExampleAppenders application

a /var/log/sematext / félelmetes.naplófájl, amelyet látni fogunk:

0 INFO com.sematext.blog.ExampleAppenders - Starting ExampleAppenders application1 WARN com.sematext.blog.ExampleAppenders - Ending ExampleAppenders application

Appender Log Level

a szép dolog Appenders, hogy lehet, hogy a szint, amelyet figyelembe kell venni, amikor a naplózás. Az összes példa, amelyet eddig láttunk, minden olyan üzenetet naplózott, amelynek súlyossága a hibakeresés vagy annál magasabb volt. Mi lenne, ha ezt meg akarnánk változtatni a com összes osztályán.sematext.blog csomag? Csak a log4j.properties fájlt kell módosítanunk:

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

nézze meg a fenti konfigurációs fájl utolsó sorát. A log4j. logger előtagot használtuk, és azt mondtuk, hogy a logger com-ot hívta.sematext.a blogot csak a súlyossági szintek figyelmeztetésére és a fentiekre szabad használni, így hiba és végzetes.

példánk alkalmazás kódja így néz ki:

public static void main(String args) { LOGGER.info("Starting ExampleAppenderLevel application"); LOGGER.warn("Ending ExampleAppenderLevel application");}

a fenti Log4j konfigurációval a naplózás kimenete a következőképpen néz ki:

0 WARN com.sematext.blog.ExampleAppenderLevel - Ending ExampleAppenderLevel application

mint látható, csak a figyelmeztetési szint naplója volt benne. Pontosan ezt akartuk.

Log4j elrendezések

végül a Log4j naplózási keretrendszernek az a része, amely szabályozza az adataink strukturálását a naplófájlban – az elrendezés. A Log4j néhány alapértelmezett implementációt biztosít, mint a PatternLayout, SimpleLayout, XMLLayout, HTMLLayout, EnchancedPatternLayout és a DateLayout.

a legtöbb esetben a PatternLayout-tal fog találkozni. Ennek az elrendezésnek az az ötlete, hogy különféle formázási lehetőségeket kínálhat a naplók szerkezetének meghatározásához. Néhány példa a következő:

• d – a naplóesemény dátuma és időpontja,
• a naplóeseményhez társított m – üzenet,
• t – szál neve,
• n – platformfüggő vonalelválasztó,
• p-log szint.

a rendelkezésre álló opciókkal kapcsolatos további információkért keresse fel a hivatalos Log4j Javadocs-ot a PatternLayout-hoz.

a PatternLayout használatakor Beállíthatjuk, hogy melyik opciót szeretnénk használni. Tegyük fel, hogy szeretnénk megírni a dátumot, a napló esemény súlyosságát, a szögletes zárójelekkel körülvett szálat, valamint a napló esemény üzenetét. Használhatnánk egy ilyen mintát:

%d %-5p - %m%n

a teljes log4j. properties fájl ebben az esetben a következőképpen nézhet ki:

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

a %d-t használjuk a dátum megjelenítéséhez, a % – 5p-t a súlyosság megjelenítéséhez 5 karakter használatával, %t a szálhoz, %m az üzenethez, és % n A sorelválasztóhoz. A példakód futtatása után a konzolra írt kimenet a következőképpen néz ki:

2021-02-02 11:49:49,003 INFO - Initializing ExampleLog4jFormatter application

beágyazott diagnosztikai környezet

a legtöbb valós alkalmazásban a naplóesemény önmagában nem létezik. Egy bizonyos kontextus veszi körül. Az ilyen kontextus biztosításához szálanként a Log4j biztosítja az úgynevezett beágyazott diagnosztikai kontextust. Így köthetünk egy adott szálat további információkkal, például egy munkamenet-azonosítóval, akárcsak a példaalkalmazásunkban:

NDC.push(String.format("Session ID: %s", "1234-5678-1234-0987"));LOGGER.info("Initializing ExampleLog4jNDC application");

x változót tartalmazó minta használata esetén az adott szál minden egyes logline-jába további információk kerülnek. A mi esetünkben a kimenet így fog kinézni:

0 INFO com.sematext.blog.ExampleLog4jNDC Session ID: 1234-5678-1234-0987 - Initializing ExampleLog4jNDC application

láthatja, hogy a munkamenet-azonosítóval kapcsolatos információk a naplóban vannak. Csak referenciaként a log4j. properties fájl, amelyet ebben a példában használtunk, a következőképpen néz ki:

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

leképezett diagnosztikai kontextus

a naplóeseményeinkbe beilleszthető kontextusinformációk második típusa a leképezett diagnosztikai kontextus. Az MDC osztály segítségével további kulcs-értékkel kapcsolatos információkat tudunk biztosítani. A beágyazott diagnosztikai kontextushoz hasonlóan a leképezett diagnosztikai kontextus szálkötésű.

nézzük meg a példa alkalmazás kódját:

MDC.put("user", "[email protected]");MDC.put("step", "initial");LOGGER.info("Initializing ExampleLog4jNDC application");MDC.put("step", "launch");LOGGER.info("Starting ExampleLog4jNDC application");

két kontextusmezőnk van: a felhasználó és a lépés. A napló eseményhez társított összes leképezett diagnosztikai kontextus információ megjelenítéséhez csak az X változót használjuk a mintadefiníciónkban. Például:

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

a fenti kód elindítása a konfigurációval együtt a következő kimenetet eredményezné:

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

a minta megváltoztatásával kiválaszthatjuk, hogy mely információkat használjuk. Például, ha a felhasználót a leképezett diagnosztikai környezetből szeretnénk felvenni, írhatunk egy ilyen mintát:

%r %-5p %c %X{user} - %m%n

ezúttal a kimenet a következőképpen néz ki:

0 INFO com.sematext.blog.ExampleLog4jMDC [email protected] - Initializing ExampleLog4jNDC application0 INFO com.sematext.blog.ExampleLog4jMDC [email protected] - Starting ExampleLog4jNDC application

láthatjuk, hogy az Általános %X helyett a %X{user} – t használtuk. Ez azt jelenti, hogy egy adott naplóeseményhez társított leképezett diagnosztikai kontextus felhasználói változója érdekel minket.

migráció Log4j 2

migráció Log4j 1.x hogy Log4j 2.x nem nehéz, és bizonyos esetekben nagyon könnyű is lehet. Ha nem használt belső Log4j 1.x osztályok, konfigurációs fájlokat használt a naplózók programozott beállításánál, és nem használta a DOMConfigurator és PropertyConfigurator osztályokat, az áttelepítésnek olyan egyszerűnek kell lennie, mint a log4j-1.2-api.jar jar fájl a Log4j helyett 1.x jar akták. Ez lehetővé tenné Log4j 2.x dolgozni a kódot. Hozzá kell adnia a Log4j 2-t.x jar files, állítsa be a konfigurációt, és voil ons-kész.

ha többet szeretne megtudni a Log4j 2-ről.x nézze meg a Java naplózási oktatóanyagunkat és annak Log4j 2-jét.x dedikált szakasz.

azonban, ha nem használja a belső Log4j 1.x osztályok, a hivatalos migrációs útmutató a Log4j-ről való áttéréshez 1.x hogy Log4j 2.x nagyon hasznos lesz. Megvitatja a szükséges kód-és konfigurációs változtatásokat, és kétség esetén felbecsülhetetlen értékű lesz.

központosított naplózás Naplómenedzsment eszközökkel

naplóesemények küldése konzolra vagy fájlba jó lehet egyetlen alkalmazás számára, de az alkalmazás több példányának kezelése és a több forrásból származó naplók korrelálása nem szórakoztató, ha a naplóesemények különböző gépeken lévő szöveges fájlokban vannak. Ilyen esetekben az adatmennyiség gyorsan kezelhetetlenné válik, és dedikált megoldásokat igényel – akár önállóan, akár az egyik szállítótól. És mi a helyzet a konténerekkel, ahol általában nem is írnak naplókat fájlokba? Hogyan lehet hibaelhárítani és hibakeresni egy olyan alkalmazást, amelynek naplóit szabványos kimenetre bocsátották ki, vagy amelynek tárolóját megölték?

ez az, ahol a naplózási szolgáltatások, a naplóelemző eszközök és a felhőalapú naplózási szolgáltatások jönnek a játékba. Ez egy íratlan Java naplózási legjobb gyakorlat a mérnökök körében, hogy ilyen megoldásokat használjanak, amikor komolyan veszi a naplók kezelését és a legtöbbet hozza ki belőlük. Például a sematext Logs, a naplófigyelő és-kezelő szoftverünk megoldja az összes fent említett problémát, és így tovább.

egy teljesen felügyelt megoldással, mint például a Sematext naplók, nem kell kezelnie a környezet egy másik részét – a DIY naplózási megoldását, amelyet általában a rugalmas verem darabjaiból építenek fel. Az ilyen beállítások kicsiben és olcsón indulhatnak, azonban gyakran nagyok és drágák. Nem csak az infrastrukturális költségek, hanem az irányítási költségek szempontjából is. Tudod, az idő és a fizetés. A felügyelt szolgáltatás használatának előnyeiről a naplózási legjobb gyakorlatokról szóló blogbejegyzésünkben magyarázunk többet.

a riasztás és a napló összesítés szintén fontos a problémák kezelésében. Végül a Java alkalmazások esetében érdemes lehet szemétgyűjtési naplókat készíteni, miután bekapcsolta a szemétgyűjtési naplózást, és elkezdte elemezni a naplókat. Az ilyen naplók, amelyek a mutatókkal korrelálnak, felbecsülhetetlen információforrást jelentenek a szemétgyűjtéssel kapcsolatos problémák elhárításához.

összefoglaló

annak ellenére, hogy Log4j 1.x hosszú ideje elérte életének végét, még mindig jelen van a világ minden táján használt számos örökölt alkalmazásban. A fiatalabb verzióra való áttérés meglehetősen egyszerű, de jelentős erőforrásokat és időt igényelhet, és általában nem elsődleges prioritás. Különösen a nagyvállalatoknál, ahol az eljárások, a jogi követelmények vagy mindkettő auditot igényel, amelyet hosszú és drága tesztelés követ, mielőtt bármit meg lehet változtatni egy már működő rendszerben. De azok számára, akik csak most kezdik vagy gondolkodnak a migrációról-emlékezik, Log4j 2.x ott van, már érett, gyors, biztonságos és nagyon alkalmas.

de függetlenül attól, hogy milyen keretet használ a Java alkalmazások naplózásához, határozottan javasoljuk, hogy az erőfeszítéseit egy teljesen felügyelt naplózási megoldással, például a Sematext naplókkal vegye feleségül. Próbáld ki! Van egy 14 napos ingyenes próbaverzió áll az Ön számára, hogy tesztelje vezetni.

Boldog naplózást!