• Articles
• admin

obținerea vizibilității în aplicația dvs. este crucială atunci când rulează codul în producție. Ce înțelegem prin vizibilitate? În primul rând, lucruri precum performanța aplicației prin valori, sănătatea aplicației și disponibilitatea, jurnalele sale ar trebui să fie depanate sau urmele sale dacă trebuie să vă dați seama ce o face lentă și cum să o faceți mai rapidă. Valorile

vă oferă informații despre performanța fiecăruia dintre elementele infrastructurii dvs. Traces vă va arăta o imagine mai largă a execuției și fluxului de cod împreună cu valorile de execuție a codului. În cele din urmă, jurnalele bine realizate vor oferi o perspectivă neprețuită asupra executării logicii codului și a ceea ce se întâmpla în codul dvs. Fiecare dintre piesele menționate este crucială pentru aplicația dvs. și, într-adevăr, pentru observabilitatea generală a sistemului. Astăzi, ne vom concentra doar pe o singură bucată – jurnalele. Pentru a fi mai precis – pe jurnalele de aplicații Java. Dacă sunteți interesat de valori, consultați articolul nostru despre valorile cheie JVM pe care ar trebui să le monitorizați.

cu toate acestea, înainte de a intra în ea, să abordăm o problemă care a afectat comunitatea folosind acest cadru. Pe 9 decembrie 2021, a fost raportată o vulnerabilitate critică poreclită Log4Shell. Identificat ca CVE-2021-44228, permite unui atacator să preia controlul complet asupra unei mașini care rulează Apache Log4j 2 versiunea 2.14.1 sau mai mică, permițându-le să execute cod arbitrar pe serverul vulnerabil. În postarea noastră recentă pe blog despre vulnerabilitatea Log4jShell, am detaliat cum să determinăm dacă sunteți afectat, cum să rezolvați problema și ce am făcut noi, la Sematext, pentru a ne proteja sistemul și utilizatorii.

Log4j 1.X sfârșitul vieții

rețineți că pe 5 August 2015 Comitetul de management al proiectului Logging Services a anunțat că Log4j 1.x a ajuns la sfârșitul vieții. Toți utilizatorii sunt sfătuiți să migreze la Log4j 2.x. în această postare pe blog, vă vom ajuta să înțelegeți configurarea curentă Log4j – în mod specific, log4j 2.versiunea x – și după aceea, vă voi ajuta să migrați la cea mai recentă și cea mai mare versiune Log4j.

„folosesc Log4j 1.x, ce ar trebui să fac?”. Nu intrați în panică, nu este nimic în neregulă cu ea. Faceți un plan de tranziție la Log4j 2.x. vă voi arăta cum continuați să citiți :). Aplicația dvs. vă va mulțumi pentru asta. Veți primi remedieri de securitate, Îmbunătățiri de performanță, și mult mai multe caracteristici după migrare.

„încep un nou proiect, ce ar trebui să fac?”. Doar utilizați Log4j 2.x imediat, nici măcar nu vă gândiți la Log4j 1.x. Dacă aveți nevoie de ajutor în acest sens, consultați acest tutorial de logare Java unde vă explic tot ce aveți nevoie.

logare în Java

nu există nici o magie în spatele logare în Java. Totul se reduce la utilizarea unei clase Java adecvate și a metodelor sale pentru a genera evenimente de jurnal. Așa cum am discutat în Ghidul de logare Java, există mai multe moduri în care puteți începe

desigur, cea mai naivă și nu cea mai bună cale de urmat este doar utilizarea sistemului.afară și sistem.err clase. Da, puteți face acest lucru și mesajele dvs. vor merge doar la ieșirea standard și eroarea standard. De obicei, asta înseamnă că va fi tipărit pe consolă sau scris într-un fișier de un fel sau chiar trimis la /dev/null și va fi uitat pentru totdeauna. Un exemplu de astfel de cod ar putea arăta astfel:

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

ieșirea executării codului de mai sus ar fi după cum urmează:

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

nu e perfect, nu? Nu am nicio informație despre ce clasă A generat mesajul și multe, multe alte lucruri „mici” care sunt cruciale și importante în timpul depanării.

există și alte lucruri care lipsesc, care nu sunt într-adevăr conectate la depanare. Gândiți-vă la mediul de execuție, la mai multe aplicații sau microservicii și la necesitatea de a unifica înregistrarea pentru a simplifica configurația conductei de centralizare a jurnalului. Utilizarea sistemului.afară, sau / și sistem.eroare în codul nostru în scopuri de logare ne-ar forța să refaceți toate locurile în care îl folosim ori de câte ori avem nevoie pentru a ajusta formatul de logare. Știu că este extrem, dar crede-mă, am văzut utilizarea sistemului.în codul de producție în modelele de implementare a aplicațiilor „tradiționale”! Desigur, conectarea la sistem.out este o soluție adecvată pentru aplicații containerizate și ar trebui să utilizați ieșirea care se potrivește mediului dvs. Amintiți-vă despre asta!

din cauza tuturor motivelor menționate și multe altele la care nici măcar nu ne gândim, ar trebui să vă uitați într-una dintre posibilele biblioteci de logare, cum ar fi Log4 j, Log4j 2, Logback sau chiar java.util.logare care face parte din kitul de dezvoltare Java. Pentru această postare pe blog, vom folosi Log4j.

stratul de abstractizare – SLF4J

subiectul alegerii soluției potrivite de logare pentru aplicația dvs. Vă recomandăm să citiți cel puțin secțiunea menționată.

vom folosi SLF4J, un strat de abstractizare între codul nostru Java și Log4j – biblioteca de logare la alegere. Fațada simplă de logare oferă legături pentru cadre comune de logare precum Log4j, Logback și java.util.logare. Imaginați-vă procesul de scriere a unui mesaj de jurnal în următorul mod simplificat:

s-ar putea întreba de ce folosesc un strat de abstractizare la toate? Ei bine, răspunsul este destul de simplu – în cele din urmă, poate doriți să schimbați cadrul de înregistrare, să îl actualizați, să îl unificați cu restul stivei dvs. de tehnologie. Când utilizați un strat de abstractizare, o astfel de operație este destul de simplă – schimbați doar dependențele cadrului de înregistrare și furnizați un nou pachet. Dacă nu ar fi să folosim un strat de abstractizare – ar trebui să schimbăm codul, potențial o mulțime de cod. Fiecare clasă care înregistrează ceva. Nu este o experiență de dezvoltare foarte frumos.

Loggerul

codul aplicației Java va interacționa cu un set standard de elemente cheie care permit crearea și manipularea evenimentelor din jurnal. Le – am acoperit pe cele cruciale în tutorialul nostru de logare Java, dar permiteți-mi să vă reamintesc despre una dintre clasele pe care le vom folosi în mod constant-Loggerul.

Loggerul este entitatea principală pe care o aplicație o folosește pentru a efectua apeluri de logare – creați evenimente de jurnal. Obiectul Logger este de obicei utilizat pentru o singură clasă sau o singură componentă pentru a furniza legat de context la un caz de utilizare specific. Acesta oferă metode pentru a crea evenimente jurnal cu un nivel de jurnal adecvat și transmite-l pentru prelucrare ulterioară. De obicei, veți crea un obiect static cu care veți interacționa, de exemplu astfel:

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

și asta e tot. Acum, că știm la ce ne putem aștepta, să ne uităm la Biblioteca Log4j.

Log4j

cel mai simplu mod de a începe cu Log4j este de a include biblioteca în classpath aplicației Java. Pentru a face acest lucru, includem cea mai nouă bibliotecă log4j disponibilă, ceea ce înseamnă versiunea 1.2.17 în fișierul nostru de construire.

folosim Gradle și în aplicația noastră simplă, iar secțiunea dependențe pentru fișierul de construire Gradle arată după cum urmează:

dependencies { implementation 'log4j:log4j:1.2.17'}

putem începe să dezvoltăm codul și să includem înregistrarea folosind 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"); }}

după cum puteți vedea în codul de mai sus, am inițializat obiectul Logger utilizând metoda statică getlogger și am furnizat numele clasei. După ce facem acest lucru, putem accesa cu ușurință obiectul static Logger și îl putem folosi pentru a produce evenimente de jurnal. Putem face acest lucru în metoda principală.

o notă laterală-metoda getLogger poate fi apelată și cu un șir ca argument, de exemplu:

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

ar însemna că vrem să creăm un logger și să asociem numele com.sematext.blog cu ea. Dacă vom folosi același nume oriunde altundeva în codul Log4j va returna aceeași instanță Logger. Acest lucru este util dacă dorim să combinăm logarea din mai multe clase diferite într-un singur loc. De exemplu, jurnalele legate de plată într-un singur fișier jurnal dedicat.

Log4j oferă o listă de metode care permit crearea de noi evenimente jurnal folosind un nivel de jurnal adecvat. Acestea sunt:

• public void trace (mesaj obiect)
• public void debug (mesaj obiect)
• public void info (mesaj obiect)
• public void warn (mesaj obiect)
• public void error (mesaj obiect)
• public void fatal (mesaj obiect)

și o metodă generică:

• public void log (nivel nivel, mesaj obiect)

am vorbit despre nivelurile de logare Java în postarea noastră de blog tutorial de logare Java. Dacă nu sunteți conștienți de ele, vă rugăm să luați câteva minute pentru a vă obișnui cu ele, deoarece nivelurile de jurnal sunt cruciale pentru logare. Dacă tocmai ați început cu nivelurile de logare, vă recomandăm să treceți și peste ghidul nostru de niveluri de jurnal. Vă explicăm totul, de la ceea ce sunt până la cum să o alegeți pe cea potrivită și cum să le folosiți pentru a obține informații semnificative.

dacă ar fi să rulăm codul de mai sus, ieșirea pe care o vom obține pe consola standard ar fi după cum urmează:

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.

nu am văzut mesajul de jurnal pe care l-am așteptat. Log4j ne-a informat că nu există nici o configurație prezentă. Oooops, hai să vorbim despre cum să configurați Log4j…

configurare Log4j

există mai multe moduri în care putem configura log4j logare nostru. O putem face programatic – de exemplu prin includerea unui bloc de inițializare statică:

static { BasicConfigurator.configure();}

codul de mai sus configurează Log4j pentru a scoate jurnalele în consolă în formatul implicit. Rezultatul rulării aplicației noastre de exemplu ar arăta după cum urmează:

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

cu toate acestea, configurarea Log4j programatic nu este foarte frecventă. Cel mai comun mod ar fi să fie utilizați un fișier de proprietăți sau un fișier XML. Putem schimba codul nostru și includ fișierul log4j. properties cu următorul conținut:

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

în acest fel am spus Log4j că vom crea logger rădăcină, care va fi utilizat în mod implicit. Nivelul său implicit de înregistrare în jurnal este setat la depanare, ceea ce înseamnă că vor fi incluse evenimente jurnal cu severitate depanare sau mai mare. Deci depanare, INFO, avertiza, eroare, și FATAL. De asemenea, i – am dat loggerului nostru un nume-principal. Apoi, configurăm loggerul, setând ieșirea la consolă și utilizând aspectul modelului. Vom vorbi despre asta mai târziu în postarea pe blog. Rezultatul rulării codului de mai sus ar fi după cum urmează:

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

dacă dorim, putem schimba și fișierul log4j. properties și putem folosi unul numit log4j.xml. Aceeași configurație folosind formatul XML ar arăta după cum urmează:

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

dacă am schimba acum log4j. properties pentru log4j.xml unul și păstrați-l în classpath execuția aplicației noastre de exemplu ar fi după cum urmează:

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

deci, de unde știe Log4j ce fișier să folosească? Să ne uităm la asta.

procesul de inițializare

este esențial să știm că Log4j nu face nicio presupunere cu privire la mediul în care rulează. Log4j nu își asumă nici un fel de destinații implicite evenimente jurnal. Când pornește, caută proprietatea log4j.configuration și încearcă să încarce fișierul specificat ca configurație. Dacă locația fișierului nu poate fi convertită într-o adresă URL sau fișierul nu este prezent, acesta încearcă să încarce fișierul din calea classpath.

asta înseamnă că putem suprascrie configurația Log4j din classpath furnizând-Dlog4j.configuration în timpul pornirii și îndreptându-l spre locația corectă. De exemplu, dacă includem un fișier numit altele.xml cu următorul conținut:

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

și apoi a alerga afară de cod cu-Dlog4j. configuration = /opt/sematext / alte.xml ieșirea din Codul nostru va fi după cum urmează:

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

Log4j Appenders

am folosit deja appenders în exemplele noastre… Ei bine, într – adevăr doar unul-ConsoleAppender. Singurul său scop este de a scrie evenimentele de jurnal în consolă. Desigur, cu un număr mare de evenimente de jurnal și sisteme care rulează în medii diferite, scrierea datelor text pur la ieșirea standard poate să nu fie cea mai bună idee, cu excepția cazului în care rulați în containere. De aceea, Log4j acceptă mai multe tipuri de anexe. Iată câteva exemple comune de aplicații Log4j:

• ConsoleAppender – appender care adaugă evenimentele jurnal la sistem.afară sau sistem.err cu implicit fiind sistemul.afară. Când utilizați acest appender, veți vedea jurnalele dvs. în consola aplicației dvs.
• FileAppender – appender care adaugă evenimentele jurnal la un fișier definit stocarea lor pe sistemul de fișiere.
• RollingFileAppender – appender care extinde FileAppender și rotește fișierul atunci când ajunge la o dimensiune definită. Utilizarea RollingFileAppender împiedică fișierele jurnal de a deveni foarte mare și greu de întreținut.
• SyslogAppender – appender trimiterea evenimentelor jurnal la un demon syslog la distanță.
• JDBCAppender – appender care stochează evenimentele jurnal în baza de date. Rețineți că acest appender nu va stoca erori și, în general, nu este cea mai bună idee pentru a stoca evenimentele jurnal într-o bază de date.
• SocketAppender – appender care trimite evenimentele jurnal serializate la o priză de la distanță. Rețineți că acest appender nu utilizează machete, deoarece trimite serializate, evenimente jurnal raw.
• NullAppender – appender care aruncă doar evenimentele jurnal.

mai mult, puteți configura mai multe aplicații pentru o singură aplicație. De exemplu, puteți trimite jurnale la consolă și la un fișier. Următoarele log4j.proprietăți conținutul fișierului ar face exact asta:

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

logger nostru rădăcină este configurat pentru a înregistra totul pornind de la gravitatea depanare și pentru a trimite jurnalele la două Appenders – principal și de rulare. Loggerul principal este cel pe care l – am văzut deja-cel care trimite datele către consolă.

al doilea logger, cel numit ROLLING, este cel mai interesant din acest exemplu. Folosește RollingFileAppender care scrie datele în fișier și să definim cât de mare poate fi fișierul și câte fișiere să păstreze. În cazul nostru, fișierele jurnal ar trebui să fie numite minunat.înregistrați și scrieți datele în directorul/var/log/ sematext/. Fiecare fișier ar trebui să aibă maximum 1024kb și nu ar trebui să fie stocate mai mult de 10 fișiere. Dacă există mai multe fișiere, acestea vor fi eliminate din sistemul de fișiere imediat ce log4j le vede.

după rularea codului cu configurația de mai sus, consola va imprima următorul conținut:

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

în / var/log/sematext / minunat.fișier jurnal pe care l-am vedea:

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

Appender Log Level

lucru frumos despre Appenders este că acestea pot avea nivelul lor, care ar trebui să fie luate în considerare la logare. Toate exemplele pe care le-am văzut până acum au înregistrat fiecare mesaj care a avut severitatea depanării sau mai mare. Dacă am vrea să schimbăm asta pentru toate clasele din com.sematext.pachet blog? Va trebui doar să modificăm fișierul nostru log4j. properties:

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

Uită-te la ultima linie din fișierul de configurare de mai sus. Am folosit prefixul log4j. logger și a spus că logger numit com.sematext.blog-ul ar trebui să fie utilizat numai pentru nivelurile de severitate avertizează și de mai sus, deci eroare și fatală.

exemplul nostru de cod de aplicație arată astfel:

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

cu configurația Log4j de mai sus, ieșirea înregistrării arată după cum urmează:

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

după cum puteți vedea, a fost inclus doar Jurnalul de nivel WARN. Exact asta ne-am dorit.

Log4j Layouts

în cele din urmă, partea din cadrul log4j logging care controlează modul în care datele noastre sunt structurate în fișierul nostru jurnal – aspectul. Log4j oferă câteva implementări implicite, cum ar fi PatternLayout, SimpleLayout, XMLLayout, HTMLLayout, EnchancedPatternLayout și DateLayout.

în cele mai multe cazuri, veți întâlni Modelulaspect. Ideea din spatele acestui aspect este că puteți oferi o varietate de opțiuni de formatare pentru a defini structura jurnalelor. Unele dintre exemple sunt:

• d-Data și ora evenimentului Jurnal,
• m – mesaj asociat evenimentului Jurnal,
• t – nume fir,
• n – platformă separator de linie dependent,
• nivel p – jurnal.

pentru mai multe informații cu privire la opțiunile disponibile peste cap de la oficial Log4j Javadocs pentru PatternLayout.

când folosim PatternLayout putem configura ce opțiune am dori să folosim. Să presupunem că am dori să scriem data, severitatea evenimentului Jurnal, firul înconjurat de paranteze pătrate și mesajul evenimentului Jurnal. Am putea folosi un model ca acesta:

%d %-5p - %m%n

fișierul log4j. properties complet în acest caz ar putea arăta după cum urmează:

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

folosim %d pentru a afișa data, %- 5p pentru a afișa severitatea folosind 5 caractere, %t pentru fir, %m pentru mesaj și %n pentru separatorul de linie. Ieșirea care este scrisă în consolă după rularea codului nostru de exemplu arată după cum urmează:

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

context Diagnostic imbricat

în majoritatea aplicațiilor din lumea reală, evenimentul jurnal nu există singur. Este înconjurat de un anumit context. Pentru a oferi un astfel de context, pe fir, Log4j oferă așa-numitul Context de Diagnostic imbricat. În acest fel, putem lega un fir dat cu informații suplimentare, de exemplu, un identificator de sesiune, la fel ca în aplicația noastră de exemplu:

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

când se utilizează un model care include x variabilă informații suplimentare vor fi incluse în fiecare linie de logare pentru firul dat. În cazul nostru, ieșirea va arăta astfel:

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

puteți vedea că informațiile despre identificatorul sesiunii se află în linia de jurnal. Doar pentru referință, fișierul log4j.properties pe care l-am folosit în acest exemplu arată după cum urmează:

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

mapat context Diagnostic

al doilea tip de informații contextuale pe care le putem include în evenimentele noastre jurnal este mapat context diagnostic. Folosind clasa MDC putem oferi informații suplimentare legate de valoarea cheii. Similar contextului de diagnostic imbricat, contextul de diagnostic mapat este legat de fir.

să ne uităm la codul nostru de aplicație exemplu:

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

avem două câmpuri de context – utilizatorul și pasul. Pentru a afișa toate informațiile context de diagnostic mapate asociate cu evenimentul jurnal folosim doar variabila X în definiția noastră model. De exemplu:

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

lansarea codului de mai sus împreună cu configurația ar avea ca rezultat următoarea ieșire:

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

de asemenea, putem alege ce informații să folosim schimbând modelul. De exemplu, pentru a include utilizatorul din contextul de diagnostic mapat, am putea scrie un model ca acesta:

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

de data aceasta de ieșire ar arăta după cum urmează:

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

puteți vedea că în loc de % X general am folosit % x{utilizator}. Asta înseamnă că suntem interesați de variabila utilizator din contextul de diagnostic mapat asociat cu un eveniment jurnal dat.

migrarea la Log4j 2

migrarea la Log4j 1.x la Log4j 2.x nu este greu și, în unele cazuri, poate fi foarte ușor. Dacă nu ați folosit Niciun Log4j 1 intern.clase x, ați folosit fișiere de configurare peste programatic configurarea loggers și nu ați utilizat DOMConfigurator și PropertyConfigurator clase migrarea ar trebui să fie la fel de simplu ca inclusiv log4j-1.2-api.fișier jar jar în loc de Log4j 1.x fișiere jar. Asta ar permite Log4j 2.x pentru a lucra cu codul. Va trebui să adăugați Log4j 2.x fișiere jar, reglați configurația, și voil – ați terminat.

dacă doriți să aflați mai multe despre Log4j 2.x consultați tutorialul nostru de logare Java și Log4j 2.x secțiune dedicată.

cu toate acestea, dacă ați folosit Log4j intern 1.x clase, ghidul oficial de migrare cu privire la modul de a trece de la Log4j 1.x la Log4j 2.x va fi de mare ajutor. Se discută modificările necesare de cod și de configurare și va fi de neprețuit atunci când aveți dubii.

logare centralizată cu instrumente de gestionare a Jurnalului

trimiterea evenimentelor din jurnal către o consolă sau un fișier poate fi bună pentru o singură aplicație, dar gestionarea mai multor instanțe ale aplicației dvs. și corelarea jurnalelor din mai multe surse nu este distractivă atunci când evenimentele din jurnal sunt în fișiere text pe diferite mașini. În astfel de cazuri, cantitatea de date devine rapid imposibil de gestionat și necesită soluții dedicate – fie auto-găzduite, fie provenind de la unul dintre furnizori. Și cum rămâne cu containerele în care, de obicei, nici măcar nu scrieți jurnale în fișiere? Cum depanați și depanați o aplicație ale cărei jurnale au fost emise la ieșirea standard sau al cărui container a fost ucis?

aici intră în joc serviciile de gestionare a jurnalelor, instrumentele de analiză a jurnalelor și serviciile de înregistrare în cloud. Este o bună practică nescrisă de logare Java în rândul inginerilor de a utiliza astfel de soluții atunci când sunteți serios în ceea ce privește gestionarea jurnalelor și obținerea la maximum a acestora. De exemplu, jurnalele Sematext, software-ul nostru de monitorizare și gestionare a jurnalelor, rezolvă toate problemele menționate mai sus și multe altele.

cu o soluție complet gestionată, cum ar fi jurnalele Sematext, nu trebuie să gestionați o altă piesă a mediului – soluția dvs. de înregistrare DIY, construită de obicei folosind bucăți din stiva elastică. Astfel de setări pot începe mici și ieftine, cu toate acestea, ele cresc adesea mari și scumpe. Nu doar în ceea ce privește costurile de infrastructură, ci și costurile de gestionare. Știi, timpul și statul de plată. Vă explicăm mai multe despre avantajele utilizării unui serviciu gestionat în postarea noastră de pe blog despre cele mai bune practici de logare.

alertarea și agregarea jurnalului sunt, de asemenea, cruciale atunci când se ocupă de probleme. În cele din urmă, pentru aplicațiile Java, poate doriți să aveți jurnalele de colectare a gunoiului odată ce porniți logarea de colectare a gunoiului și începeți să analizați jurnalele. Astfel de jurnale corelate cu valorile sunt o sursă neprețuită de informații pentru depanarea problemelor legate de colectarea gunoiului.

rezumat

chiar dacă Log4j 1.X a ajuns la sfârșitul vieții cu mult timp în urmă este încă prezent într-un număr mare de aplicații vechi utilizate în întreaga lume. Migrarea la versiunea sa mai tânără este destul de simplă, dar poate necesita resurse și timp substanțiale și, de obicei, nu este o prioritate maximă. În special în întreprinderile mari, unde procedurile, cerințele legale sau ambele necesită audituri urmate de teste lungi și costisitoare înainte ca orice să poată fi schimbat într-un sistem deja în funcțiune. Dar pentru aceia dintre noi care abia încep sau se gândesc la migrație – amintiți-vă, Log4j 2.x este acolo, este deja matur, rapid, sigur și foarte capabil.

dar, indiferent de Cadrul pe care îl utilizați pentru logarea aplicațiilor Java, vă recomandăm cu siguranță să vă îmbinați eforturile cu o soluție de gestionare a jurnalelor complet gestionată, cum ar fi jurnalele Sematext. Dă-o încercare! Există o încercare gratuită de 14 zile disponibilă pentru a o testa.

logare fericită!