• Articles
• admin

näkyvyyden saaminen sovellukseen on ratkaisevan tärkeää, kun käytät koodia tuotannossa. Mitä tarkoitamme näkyvyydellä? Ensisijaisesti asioita, kuten sovelluksen suorituskyvyn kautta mittareita, sovelluksen terveys, ja saatavuus, sen lokit jos sinun täytyy vianmääritys, tai sen jälkiä, jos haluat selvittää, mikä tekee siitä hidas ja miten se nopeammin.

mittarit antavat tietoa infrastruktuurin jokaisen osan suorituskyvystä. Traces näyttää sinulle laajemman kuvan koodin suorituksesta ja virtauksesta sekä koodin suoritusmittareista. Lopuksi, hyvin muotoillun lokit antaa arvokasta tietoa koodin logiikan toteutus ja mitä tapahtui koodin. Jokainen mainituista kappaleista on ratkaisevan tärkeä sovelluksellesi ja koko järjestelmän havaittavuudelle. Tänään keskitymme vain yhteen palaan-lokit. Tarkemmin-Java-sovelluslokit. Jos olet kiinnostunut mittarit, tutustu artikkeli avain JVM mittarit sinun pitäisi seurata.

kuitenkin, ennen kuin ryhdymme siihen, käsitellään tätä kehystä käyttäen asiaa, joka vaikutti yhteisöön. 9. joulukuuta 2021 uutisoitiin kriittisestä haavoittuvuudesta nimeltä Log4Shell. Tunnistettuna CVE-2021-44228: ksi, se antaa hyökkääjän hallita Apache Log4j 2-versiota 2.14.1 tai sitä pienempää konetta, jolloin he voivat suorittaa mielivaltaista koodia haavoittuvalla palvelimella. Tuoreessa Blogikirjoituksessamme Log4jShell-haavoittuvuudesta, kerroimme yksityiskohtaisesti, miten voimme selvittää, onko sinulla vaikutusta, miten ratkaista ongelma ja mitä me Sematext-palvelussa olemme tehneet järjestelmämme ja käyttäjiemme suojelemiseksi.

Log4j 1.x käyttöiän loppu

muista, että 5. elokuuta 2015 Logging Services-projektin johtoryhmä ilmoitti, että Log4j 1.x oli tullut elämänsä päähän. Kaikkia käyttäjiä kehotetaan siirtymään log4j 2: een.x. tässä blogikirjoitus, autamme sinua ymmärtämään nykyisen Log4j asetukset-erityisesti, log4j 2.x-versio-ja sen jälkeen, autan sinua siirtyä uusin ja suurin Log4j versio.

” käytän Log4j 1.x, mitä minun pitäisi tehdä?”. Älä panikoi, siinä ei ole mitään vikaa. Tee suunnitelma siirtyä Log4j 2.X. näytän sinulle, miten vain pitää käsittelyssä:). Hakemuksenne kiittää teitä siitä. Saat tietoturvakorjauksia, suorituskyvyn parannuksia ja paljon enemmän ominaisuuksia siirron jälkeen.

” aloitan uuden projektin, mitä minun pitäisi tehdä?”. Käytä Log4j 2: ta.x heti, älä edes ajattele Log4j 1.x. Jos tarvitset apua, tutustu tähän Java logging opetusohjelma, jossa selitän kaiken mitä tarvitset.

Hakkuu Jaavalla

Jaavan hakkuun takana ei ole taikaa. Kaikki riippuu sopivan Java-luokan ja sen menetelmien käyttämisestä lokitapahtumien tuottamiseen. Kuten keskustelimme Java logging guide on useita tapoja voit aloittaa

tietenkin, kaikkein naiivi ja ei paras polku seurata on vain käyttämällä järjestelmää.ulos ja järjestelmä.err-luokat. Kyllä, voit tehdä sen ja viestisi vain mennä standardin lähtö ja keskivirhe. Yleensä tämä tarkoittaa sitä, että se tulostetaan konsoliin tai kirjoitetaan jonkinlaiseen tiedostoon tai jopa lähetetään /dev/null ja unohdetaan ikuisesti. Esimerkki tällaisesta koodista voisi näyttää tältä:

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

yllä olevan koodin suorituksen ulostulo olisi seuraava:

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

se ei ole täydellistä. Minulla ei ole mitään tietoa siitä, mikä luokka tuotti viestin ja monia, paljon enemmän ”pieniä” asioita, jotka ovat ratkaisevia ja tärkeitä virheenkorjauksen aikana.

puuttuu muitakin asioita, jotka eivät varsinaisesti liity virheenkorjaukseen. Mieti suoritusympäristöä, useita sovelluksia tai mikropalveluja ja tarvetta yhtenäistää kirjautumista lokin keskitysputken kokoonpanon yksinkertaistamiseksi. Järjestelmän avulla.ulos, tai / ja järjestelmä.err meidän koodi kirjaamista varten pakottaisi meidät uusimaan kaikki paikat, joissa käytämme sitä aina, kun meidän täytyy säätää kirjaamisen muodossa. Tiedän, että se on äärimmäistä, mutta usko pois, olemme nähneet järjestelmän käytön.out in production code in ”traditional” application deployment models! Tietenkin, kirjautuminen järjestelmään.out on oikea ratkaisu konttisovelluksiin ja sinun tulisi käyttää ympäristöön sopivaa ulostuloa. Muista se!

kaikista mainituista syistä ja monista muista syistä, joita emme edes ajattele, kannattaa tutkia jokin mahdollinen kirjauskirjasto, kuten Log4 j, Log4j 2, Logback tai jopa java.util.logging, joka on osa Java Development Kit. Tässä blogikirjoitus, käytämme Log4j.

Abstraction Layer – SLF4J

oikean kirjausratkaisun valitseminen Java-sovelluksellesi on asia, josta keskustelimme jo opetusohjelmassamme Javan kirjaamisesta. Suosittelemme lukemaan ainakin mainitun osion.

käytämme SLF4J: tä, Abstraktiokerrosta Java – koodimme ja Log4j: n välillä-valitsemaamme lokikirjastoa. Yksinkertainen Puunkorjuujulkisivu tarjoaa sidokset tavallisille puunkorjuukehyksille, kuten Log4j, Logback ja java.util.kirjaaminen. Kuvittele lokiviestin kirjoittamisprosessi seuraavalla yksinkertaistetulla tavalla:

voit kysyä, miksi käyttää abstraktiokerrosta lainkaan? No, vastaus on melko yksinkertainen – lopulta, saatat haluta muuttaa puunkorjuu puitteet, päivittää sitä, yhdistää sen muun teknologian pino. Kun käytät abstraktiokerrosta, tällainen toiminta on melko yksinkertaista – vaihdat vain kirjauskehyksen riippuvuudet ja annat uuden paketin. Jos emme käyttäisi abstraktiokerrosta – meidän olisi muutettava koodia, mahdollisesti paljon koodia. Jokainen luokka, joka kirjaa jotain. Ei kovin mukava kehityskokemus.

Logger

Java-sovelluksen koodi on vuorovaikutuksessa vakiojoukon kanssa, joka mahdollistaa lokitapahtumien luomisen ja manipuloinnin. Olemme käsitelleet ratkaisevia Java logging opetusohjelma, mutta haluan muistuttaa teitä yksi luokista, joita käytämme jatkuvasti – metsuri.

metsuri on tärkein kokonaisuus, jota sovellus käyttää kirjaamiskutsujen tekemiseen – lokitapahtumien luomiseen. Metsuriobjektia käytetään yleensä yhden luokan tai yhden komponentin yhteydessä tiettyyn käyttötapaukseen sidottuna. Se tarjoaa menetelmiä luoda lokitapahtumia sopivalla lokitasolla ja välittää sitä eteenpäin jatkokäsittelyä varten. Luot yleensä staattisen objektin, jonka kanssa olet vuorovaikutuksessa, esimerkiksi näin:

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

siinä kaikki. Nyt kun tiedämme, mitä voimme odottaa, katsotaanpa Log4j kirjasto.

Log4j

yksinkertaisin tapa aloittaa Log4j: stä on sisällyttää kirjasto Java-sovelluksen hakulomakkeeseen. Tätä varten sisällytämme uusimman saatavilla olevan log4j-kirjaston, mikä tarkoittaa versiota 1.2.17 build-tiedostossamme.

käytämme Gradea ja yksinkertaisessa sovelluksessamme ja gradlen rakentamistiedoston riippuvuusosio näyttää seuraavasti:

dependencies { implementation 'log4j:log4j:1.2.17'}

voimme alkaa kehittää koodia ja sisällyttää kirjautumisen log4j: n avulla:

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

kuten näet yllä olevasta koodista alustimme Logger-objektin staattisen getLogger-menetelmän avulla ja annoimme luokan nimen. Tämän jälkeen voimme helposti käyttää staattista Logger-objektia ja käyttää sitä lokitapahtumien tuottamiseen. Voimme tehdä sen päämenetelmällä.

yksi sivuhuomautus – getLogger-menetelmää voidaan kutsua myös merkkijonolla argumenttina, esimerkiksi:

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

se tarkoittaisi, että haluamme luoda metsurin ja liittää Comin nimen.sematekstiä.blogi sen kanssa. Jos käytämme samaa nimeä missä tahansa muualla koodissa Log4j palauttaa saman Logger-instanssin. Tämä on hyödyllistä, jos haluamme yhdistää hakkuut useista eri luokista yhteen paikkaan. Esimerkiksi maksamiseen liittyvät lokit yksittäisessä, dedikoidussa lokitiedostossa.

Log4j sisältää luettelon menetelmistä, joiden avulla voidaan luoda uusia lokitapahtumia käyttäen sopivaa lokitasoa. Nuo ovat:

• public void trace (Object message)
• public void debug (Object message)
• public void info (Object message)
• public void error(Object message)
• public void fatal(Object message))

ja yksi yleinen menetelmä:

• Julkinen void log(Level level, Object message)

puhuimme Java hakkuutasot meidän Java puunkorjuu opetusohjelma blogikirjoitus. Jos et ole tietoinen niistä, ota muutaman minuutin tottua niihin, koska lokitasot ovat ratkaisevia kirjautumisen. Jos olet kuitenkin vasta aloittamassa kirjaustasojen käyttöä, suosittelemme, että käyt läpi myös lokitasot-oppaamme. Selitämme kaiken siitä, mitä ne ovat, miten valita oikea ja miten hyödyntää niitä saada mielekkäitä oivalluksia.

jos käyttäisimme yllä olevaa koodia, standardikonsolin tuloste olisi seuraava:

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.

emme nähneet sellaista lokiviestiä kuin odotimme. Log4j ilmoitti meille, että kokoonpanoa ei ole. Oooops, puhutaan miten määrittää Log4j …

Log4j Configuration

on olemassa useita tapoja, joilla voimme määrittää Log4j-lokin. Voimme tehdä sen ohjelmallisesti – esimerkiksi sisällyttämällä staattisen alustuslohkon:

static { BasicConfigurator.configure();}

yllä oleva koodi määrittää Log4j: n tulostamaan lokit konsoliin oletusmuodossa. Tuotos käynnissä esimerkkisovelluksemme näyttäisi seuraavasti:

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

Log4j: n määrittäminen ohjelmallisesti ei kuitenkaan ole kovin yleistä. Yleisin tapa olisi käyttää joko ominaisuustiedostoa tai XML-tiedostoa. Voimme muuttaa koodia ja sisällyttää log4j. properties-tiedoston, jossa on seuraava sisältö:

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äin kerroimme Log4j: lle, että luomme pääkäyttäjän, jota käytetään oletuksena. Sen oletuslokitaso on DEBUG, mikä tarkoittaa, että lokitapahtumat, joiden vakavuus on DEBUG tai korkeampi, otetaan mukaan. Joten DEBUG, INFO, varoitus, virhe, ja kohtalokas. Annoimme metsurillemme myös nimen-MAIN. Seuraavaksi määritämme metsurin asettamalla sen tulosteen konsoliksi ja käyttämällä kaavaa. Kerromme asiasta lisää myöhemmin blogikirjoituksessa. Tuloste käynnissä edellä koodi olisi seuraava:

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

jos haluamme, voimme myös muuttaa log4j. properties-tiedostoa ja käyttää yhtä nimeltään log4j.xml. Sama XML-muotoa käyttävä kokoonpano näyttäisi seuraavanlaiselta:

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

jos nyt muuttaisimme log4j. ominaisuudet log4j.xml yksi ja pitää se classpath suoritus esimerkkisovelluksemme olisi seuraava:

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

Joten mistä Log4j tietää mitä tiedostoa käyttää? Tutkitaan asiaa.

alustus

on tärkeää tietää, että Log4j ei tee mitään oletuksia siitä, millaisessa ympäristössä se on käynnissä. Log4j ei oleta minkäänlaisia oletuslokitapahtumien kohteita. Kun se käynnistyy, se etsii log4j. configuration-ominaisuuden ja yrittää ladata määritetyn tiedoston määrityksekseen. Jos tiedoston sijaintia ei voi muuntaa URL-osoitteeksi tai tiedostoa ei ole, se yrittää ladata tiedoston classpathista.

tämä tarkoittaa sitä, että voimme ylikirjoittaa log4j-kokoonpanon classpathista antamalla-Dlog4j. – kokoonpanon käynnistyksen aikana ja osoittamalla sen oikeaan paikkaan. Esimerkiksi, jos sisällytämme tiedoston nimeltä muu.xml, jonka sisältö on seuraava:

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

ja sitten loppuu koodi – Dlog4j. configuration= / opt/sematext / other.xml tuotos meidän koodi on seuraava:

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

Log4j Appenders

käytimme jo appenders esimerkkejä … no, oikeastaan vain yksi-ConsoleAppender. Sen ainoa tarkoitus on kirjoittaa lokitapahtumat konsolille. Tietenkin, suuri määrä lokitapahtumia ja järjestelmiä käynnissä eri ympäristöissä kirjoittamalla puhdasta tekstiä tietoja standardin ulostulo ei ehkä ole paras idea, ellei olet käynnissä konteissa. Siksi Log4j tukee useita erilaisia Appenders. Tässä muutamia yleisiä esimerkkejä Log4j appenders:

• ConsoleAppender – sovellus, joka liittää lokitapahtumat järjestelmään.ulos tai järjestelmä.err oletuksena on järjestelmä.ulos. Kun käytät tätä appender näet lokit konsoli sovelluksen.
• FileAppender – sovellus, joka liittää lokitapahtumat määriteltyyn tiedostoon, joka tallentaa ne tiedostojärjestelmään.
• RollingFileAppender – sovellus, joka laajentaa Tiedostonappenderia ja pyörittää tiedostoa, kun se saavuttaa määritellyn koon. Käyttö RollingFileAppender estää lokitiedostot tulossa erittäin suuri ja vaikea ylläpitää.
• SyslogAppender – sovellus, joka lähettää lokitapahtumat etäpalvelimeen.
• JDBCAppender – sovellus, joka tallentaa lokitapahtumat tietokantaan. Muista, että tämä appender ei tallenna virheitä ja se ei yleensä ole paras idea tallentaa lokitapahtumia tietokantaan.
• SocketAppender – appender, joka lähettää sarjalliset lokitapahtumat etäpistorasiaan. Muista, että tämä appender ei käytä asetteluja, koska se lähettää sarjatuotetut, raa ’ at lokitapahtumat.
• NullAppender – appender, joka vain hylkää lokitapahtumat.

mitä enemmän, voit määrittää useita Appenders yhden sovelluksen. Voit esimerkiksi lähettää lokit konsolille ja tiedostoon. Seuraava log4j.ominaisuudet tiedoston sisältö tekisi juuri niin:

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

pääkäyttäjämme on määritetty kirjaamaan kaiken DEBUGIN vakavuudesta alkaen ja lähettämään lokit kahdelle Appenderille – pääkäyttäjälle ja ROLLINGILLE. Pääkirjuri on se, jonka jo näimme-se, joka lähettää tiedot konsolille.

toinen metsuri eli ROLLING on tässä esimerkissä kiinnostavampi. Se käyttää RollingFileAppender joka kirjoittaa tiedot tiedostoon ja määritellään, kuinka suuri tiedosto voi olla ja kuinka monta tiedostoa pitää. Meidän tapauksessamme lokitiedostot pitäisi kutsua awesome.loki ja kirjoita tiedot osoitteeseen / var/log/ sematext / directory. Jokaisen tiedoston tulisi olla enintään 1024kb ja tallennettuja tiedostoja ei saisi olla enempää kuin 10. Jos tiedostoja on enemmän, ne poistetaan tiedostojärjestelmästä heti, kun log4j näkee ne.

suoritettuaan koodin yllä olevalla kokoonpanolla konsoli tulostaisi seuraavan sisällön:

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

in / var / log/sematext / awesome.lokitiedosto, jonka näkisimme:

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

Appenderin lokitaso

mukavaa Appendereissä on se, että niillä voi olla oma tasonsa, joka tulee huomioida kirjautuessa. Kaikki tähän mennessä näkemämme esimerkit kirjasivat jokaisen viestin, jolla oli DEBUGIN vakavuus tai korkeampi. Mitä jos haluaisimme muuttaa sen kaikille luokille?sematekstiä.blogipaketti? Meidän tarvitsee vain muokata log4j. properties-tiedostoamme:

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

Katso viimeinen rivi yllä asetustiedosto. Olemme käyttäneet log4j. logger-etuliitettä ja sanoneet, että metsuri kutsui comia.sematekstiä.blogia tulisi käyttää vain vakavuustasoille varoittaa ja edellä, niin virhe ja kohtalokas.

esimerkkisovelluksemme koodi näyttää tältä:

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

yllä olevalla Log4j-konfiguraatiolla lokin ulostulo näyttää seuraavalta:

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

kuten näette, vain varoitus tason Loki oli mukana. Juuri sitä me halusimme.

Log4j – asettelut

lopuksi Log4j-kirjauskehyksen se osa, joka ohjaa tietojemme rakennetta lokitiedostossamme-asettelu. Log4j tarjoaa muutamia oletustoteutuksia, kuten PatternLayout, SimpleLayout, XMLLayout, HTMLLayout, EnchancedPatternLayout ja DateLayout.

useimmissa tapauksissa kohtaat Patternlayoutin. Tämän asettelun ideana on, että voit tarjota erilaisia muotoiluvaihtoehtoja lokien rakenteen määrittelemiseksi. Esimerkkejä ovat:

• d – lokitapahtuman päivämäärä ja kellonaika,
• lokitapahtumaan liittyvä m – viesti,
• t – kierteen nimi,
• n – alustasta riippuva linjaerotin,
• p – lokitaso.

jos haluat lisätietoja käytettävissä olevista vaihtoehdoista, siirry virallisiin Log4j Javadocs-sivustoihin Kaavakuvaa varten.

kun käytät kaavaketta, voimme määrittää, mitä vaihtoehtoa haluamme käyttää. Oletetaan, että haluamme kirjoittaa päivämäärän, lokitapahtuman vakavuuden, hakasulkeilla ympäröidyn langan ja lokitapahtuman viestin. Tällaiselle kuviolle olisi käyttöä:

%d %-5p - %m%n

koko log4j. properties-tiedosto voi tässä tapauksessa näyttää seuraavanlaiselta:

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

käytämme %d päivämäärän näyttämiseen, % – 5p vakavuuden näyttämiseen 5 merkin avulla, %t viestille, % m viestille ja %n rivierottimelle. Tuloste, joka kirjoitetaan konsoliin esimerkkikoodin suorittamisen jälkeen, näyttää seuraavalta:

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

sisäkkäinen diagnostinen Konteksti

useimmissa reaalimaailman sovelluksissa lokitapahtumaa ei ole olemassa yksinään. Sitä ympäröi tietty asiayhteys. Tällaisen asiayhteyden, säiettä kohti, Log4j tarjoaa ns. sisäkkäisen diagnostisen Kontekstin. Näin voimme sitoa tietyn säikeen lisätiedoilla, esimerkiksi istuntotunnisteella, aivan kuten esimerkkisovelluksessamme:

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

käytettäessä kaavaa, joka sisältää X-muuttujan, jokaiseen lokiriviin sisällytetään lisätiedot annetulle langalle. Meidän tapauksessamme lähtö näyttää tältä:

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

voit nähdä, että istuntotunnuksen tiedot ovat lokirivillä. Ihan vain viitteeksi, log4j. properties-tiedosto, jota käytimme tässä esimerkissä, näyttää seuraavalta:

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

kartoitettu diagnostinen Konteksti

toinen kontekstuaalisen tiedon tyyppi, jonka voimme sisällyttää lokitapahtumiimme, on kartoitettu diagnostinen konteksti. MDC-luokan avulla voimme tarjota avainarvoon liittyviä lisätietoja. Samoin kuin sisäkkäinen diagnostinen konteksti, kartoitettu diagnostinen konteksti on säikeinen.

katsotaanpa esimerkkikoodiamme:

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

meillä on kaksi kontekstikenttää-käyttäjä ja askel. Näyttääksemme kaikki lokitapahtumaan liittyvät kartoitetut diagnostiset asiayhteystiedot käytämme vain X-muuttujaa kuviomäärityksessämme. Esimerkiksi:

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

edellä mainitun koodin käynnistäminen yhdessä kokoonpanon kanssa johtaisi seuraavaan tulosteeseen:

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

kaavaa muuttamalla voidaan myös valita, mitä tietoa käytetään. Esimerkiksi sisällyttää käyttäjän kartoitettu diagnostinen konteksti voisimme kirjoittaa kuvio kuin tämä:

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

tällä kertaa lähtö näyttäisi seuraavanlaiselta:

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

näet, että yleisen %X sijasta olemme käyttäneet %X{user}. Tämä tarkoittaa, että olemme kiinnostuneita käyttäjämuuttujasta tiettyyn lokitapahtumaan liittyvästä kartoitetusta diagnostisesta kontekstista.

siirtyminen log4j 2: een

siirtyminen Log4j 1: stä.x Log4j 2: een.x ei ole kova ja joissakin tapauksissa se voi olla hyvin helppoa. Jos et käyttänyt mitään sisäistä Log4j 1.X luokat, olet käyttänyt asetustiedostot yli ohjelmallisesti perustaa loggers ja et käyttänyt DOMConfigurator ja PropertyConfigurator luokat siirtämisen pitäisi olla niin yksinkertaista kuin myös log4j-1.2-api.jar jar-tiedosto Log4j 1: n sijaan.X jar files. Se mahdollistaisi Log4j 2.x toimii koodisi kanssa. Sinun pitäisi lisätä Log4j 2.x jar tiedostot, säädä kokoonpano, ja voilà-olet valmis.

jos haluat lisätietoja Log4j 2: sta.x tutustu Java logging opetusohjelma ja sen Log4j 2.x oma osio.

kuitenkin, jos käytit sisäistä Log4j: tä 1.X luokat, virallinen muuttoliike opas Miten siirtyä Log4j 1.x Log4j 2: een.x on erittäin hyödyllinen. Se käsittelee tarvittavat koodi-ja kokoonpanomuutokset ja on korvaamaton, kun epävarma.

keskitetty kirjaaminen Lokinhallintatyökaluilla

lokitapahtumien lähettäminen konsoliin tai tiedostoon voi olla hyväksi yksittäiselle sovellukselle, mutta oman sovelluksen useiden esiintymien käsittely ja lokien korrelointi useista lähteistä ei ole hauskaa, kun lokitapahtumat ovat tekstitiedostoissa eri koneilla. Tällaisissa tapauksissa datamäärä muuttuu nopeasti hallitsemattomaksi ja vaatii omia ratkaisuja – joko itse isännöityjä tai joiltakin toimittajilta tulevia. Entä kontit, joissa ei yleensä edes kirjoiteta lokitietoja tiedostoihin? Miten vianmääritys ja vianetsintä tehdään sovellukselle, jonka lokit lähetettiin vakiotulokseen tai jonka säiliö on tapettu?

tässä vaiheessa kuvaan astuvat lokinhallintapalvelut, lokin analysointityökalut ja pilvipalveluiden kirjauspalvelut. Se on kirjoittamaton Java puunkorjuu parhaita käytäntöjä insinöörien käyttää tällaisia ratkaisuja, kun olet vakavissasi hallintaan lokit ja saada kaiken irti niistä. Esimerkiksi Sematext-lokit, lokin seuranta-ja hallintaohjelmistomme, ratkaisevat kaikki edellä mainitut ongelmat ja paljon muuta.

täysin hallitulla ratkaisulla, kuten Sematext – lokilla, sinun ei tarvitse hallita toista ympäristön osaa-DIY-puunkorjuuratkaisuasi, joka on tyypillisesti rakennettu käyttäen elastisen pinon palasia. Tällaiset asetelmat voivat alkaa pienestä ja halvasta, mutta ne kasvavat usein suuriksi ja kalliiksi. Ei pelkästään infrastruktuurikustannusten vaan myös hallintokustannusten osalta. Aika ja palkka. Kerromme lisää hallitun palvelun käytön eduista blogikirjoituksessamme parhaista käytännöistä.

hälyttäminen ja lokin yhdistäminen ovat myös ratkaisevia ongelmia käsiteltäessä. Lopulta, Java sovelluksia, saatat haluta olla roskat keräys Lokit Kun otat roskat keräys kirjautuminen päälle ja alkaa analysoida lokit. Tällaiset mittareiden kanssa korreloivat lokit ovat korvaamaton tietolähde roskankeräykseen liittyvien ongelmien vianmäärityksessä.

Yhteenveto

vaikka Log4j 1.x saavutti loppuelämänsä kauan sitten se on edelleen läsnä suuri määrä vanhoja sovelluksia käytetään ympäri maailmaa. Siirtyminen nuorempaan versioon on melko yksinkertaista, mutta se voi vaatia huomattavia resursseja ja aikaa, eikä se yleensä ole etusijalla. Erityisesti suurissa yrityksissä, joissa menettelyt, lakisääteiset vaatimukset tai molemmat edellyttävät auditointeja, joita seuraa pitkä ja kallis testaus ennen kuin mitään voidaan muuttaa jo käynnissä olevassa järjestelmässä. Mutta niille meistä, jotka ovat juuri aloittamassa tai ajatellut muuttoliike-muista, Log4j 2.x on siellä, se on jo kypsä, nopea, turvallinen ja erittäin kykenevä.

mutta riippumatta siitä, mitä puitteita käytät Java-sovellusten kirjaamiseen, suosittelemme ehdottomasti liittämään ponnistelusi täysin hallittuun lokinhallintaratkaisuun, kuten Sematext-lokeihin. Kokeile! Sen koeajoon on tarjolla 14 päivän ilmainen kokeiluversio.

hyvää puunkorjuuta!