Körkép

A Wikipediában remek írás található a loggolás alapkoncepcióiról.

A két (három) fő versenyző a log4j, a java logging API == java.util.logging == JUL == JSR47 és a Java Commons Logging == JCL. Ez utóbbi nem valódi loggoló framework, hanem csak egy adapter, ami futási időben megkeresi és használja a rendelkezésre álló frameworköt. Hasznos lehet, ha nem akarunk egy modult hozzákötni a log4j-hez, JUL-hoz vagy akármihez. Viszont vannak teljesítménybeli és funkcionális hátrányai a használatának, amit ez cikk részletez: Think again before adopting the commons-logging API

Íme egy vélemény a log4j és a JUL közti különbségekről. Régen olvastam már, de mélyen egyetértek vele annyi kiegészítéssel, hogy a folyamatos kényelmetlenségek miatt én még rühellem is a Java Logging Api-t.

(A szerző, Ceki Gülcü a log4j egyik alapembere. Van egy blogja is, amiben rokonszenves dolgokat ír. Pl. megemlíti Linus Torvalds GIT vs SVN-es előadását. Hát igen, nekem sem tetszett az a stílus, erről már nem is beszélve.)

Mostanában mintha kicsit külön utakon járna az Apache csoporttól, mert egy ideje a log4j utódján, a LogBack-en és a SLF4J-n dolgozik, ami a JCL utódja. (A Wikipediás cikk nem említi még ezeket.) Az SLF4J-ben lesz log4j támogatás elvileg. Nem tudom mennyire lesz hatékony az SLF4J, de a JCL helyett gondolom azért kellett új adapter framework-öt kezdeni, mert valamit máshogy (jobban) akartak megcsinálni.

A log4j már Java 1.1 óta létezik, a JUL pedig az 1.4-es jávában jött be. Belenézve a log4j honlapjába hamar kiderül, hogy nem létezik az 5-ös java újításait kihasználó verzió. A log4j 2.0 lett volna hivatott ezt a feladatot betölteni, de nem túl sok aktivitás látható a témában. Update 2008.03.17: Időközben Google-osok csináltak egy aranyos log5j nevű cuccot, ami log4j alapokon kihasználja a java 5 feature-jeit. Ha jól emlékszem nagyjából egy osztály az egész.

A LogBack és a SLF4J viszont hamarosan használható állapotba kerül. 0.9.X verziónál tart mostanában a LogBack. A javafórumon volt egy szócsata a logBack-ról és az isDebugEnabled használatáról. Egyik fontos tanulság számomra az volt, hogy az emberek sokféle stílusban loggolnak, de ez nagyban függhet a fejlesztett alkalmazástól is. Van aki sokszor tudja használni a toString-et, van akinek nincs erre lehetősége. Az isDebugEnabled pedig valójában csak akkor elhagyható, ha a paraméterlistában nincsenek azonnal kiértékelendő kifejezések. A vararg használata loggolásnál mindenesetre nagyon hasznos lehet String kiértékelés helyett.

Mikor melyiket érdemes választani? Konzervatív moduloknál JCL-t, ha felmerülhet olyan igény, hogy a modult befoglaló környezet nem log4j alapú, egyébként log4j-t. Új projekteknél lehet hogy már LogBack-et vagy SLF4J-t választanék, de azért előtte tájékozódnék, hogy vannak-e olyan appenderek, amik nekem kellhetnek. log4j-hez (mivel már elég régi motoros a szakmában) például elég sokféle appender van.

MDC

Nemrég egy szerveralkalmazás logjának minden egyes sorában fel kellett tüntetnem az éppen csatlakozott kliens IP-címét. Nagyon régen ezt úgy csináltuk, hogy bevezettünk egy kötött log message formátumot, amibe szeparátorokkal bele volt téve a szükséges információ. Tudom hogy ez ronda megoldás. Mivel most adatbázisba kellett loggolni, -ahol külön oszlop kellett az IP címre- ez nem lett volna (könnyen) járható út.

Szerencsére Java 1.2 óta használható a log4j MDC (Mapped Diagnostic Context) nevű megoldása, ami InheritableThreadLocal-ba teszi a kívánt információkat egy Hashtable-be. Ilyen egyszerűen lehet betenni az információt a java kódban:

MDC.put("ip", ipaddress);

Az InheritableThreadLocal lényege, hogy az adott szálból kreált szálak átveszik a szülő szálhoz ily módon csatolt változókat. Szerver alkalmazásoknál -főleg ahol egy szálcsoport szolgál ki egy klienst- eszményi megoldás. A konfigban a ConversionPattern-ben a %X{propname} kifejezéssel lehet kinyerni a betett információkat. Egy külső modul loggolásába is be lehet illeszteni ezeket az MDC-ket anélkül, hogy a külső modul kódjába beleírnánk. Ha pl. Hibernate-et használunk és megfelelően állítjuk be a konfigot, a belső Hibernate logokban is látszani fog az MDC, pl. hogy melyik kliensre vonatkozik az adott Hibernate művelet.

A múltkor idézett cikkben van példa az MDC és az NDC (Nested Diagnostic Context) használatára. Az NDC az MDC verem stílusú változata.

Azt írják ügyelni kell rá, hogy a szálak befejezésekor az MDC-k és NDC-k tartalmát töröljük, különben az így eltárolt információkat a GC nem tudja kilapátolni a memóriából. Swing-gel is használtam és nem működött teljesen zökkenőmentesen. Néha nem került bele a szükséges információ a logba, de ez annak a számlájára is írható, hogy nem mélyedtem még bele nagyon a Swing szálkezelésébe. (De már kéne.)

A logBack-ban is lesz MDC támogatás, bár a Google egyelőre Bug-okat ad ki első találatnak a témában. Az slf4j támogatja, viszont a JCL nem, ahogy ez az írás említi. A java logging api-ról most hirtelen nem sikerült kiderítenem hogy támogatja-e, de az iménti írás szerint valószínűleg nem.

Breaking News

• Nemrég kijött az Eclipse 3.4M2.
• Jó kis meccs van az Index fórumon a Java topikban Checked vs Unchecked exception témában. A javafórumon is megvolt ez a téma június környékén, de nem ennyire intenzíven.
• Van még mit írni a logokról, (MDC, log4j-logBack-Jsr47-JCL-jslf4j) csak most sok a meló.

Nagy logok, Lognézegetők

Néhány program életében eljön az az időszak, amikor több megabájtos fájlokat kezd el okádni, amiket már elég nehéz kezelni notepad-del vagy tail paranccsal. Nálam a rekordot egy adatkonvertáló szoftver tartja, ami -minden adatot loggolva ami a rendszer határait átlépte- óránként többszáz megát hányt ki. Mellesleg a használt Windows NT szerver elég ijesztő hibajelenséget produkált, amikor pár nap után telepumpálódott az egész winchester-e. Távolról nem lehetett adminisztrálni, közelről pedig teljesen úgy nézett ki, mint valami hardverhiba, mivel a szerver az újraindítás után nem tudott rendesen felállni. (Ugyebár nem volt hely a vinyón.) Amíg rá nem jöttünk, hogy csak törölni kell a pár gigás log könyvtárat volt szaladgálás, pánik, minden.

Szóval amikor már lapátolni kell a log fájlokat, hasznos lehet egy lognézegető eszköz, pl. a Baretail nevezetű. Meg tud nyitni igazán nagy fájlokat, egyszerre akár többet is, követi a végét, jól működik a scrollbar, lehet színezni a sorok betűinek és hátterének színét minták alapján (error-ok pirosítása). Ez egy nagyon hasznos feature. A háttérszínt érdemesebb beállítani, mert az szembeötlőbb. Csapatmunkánál pedig érdemes ugyanazt a színezést használni mindenkinek. Lehet exportálni és importálni a színezési preferenciákat, talán valami XML formátumban. Az ingyenes verzió nem tud pár alapvető dolgot, pl. a keresést (regexp, egyéb), de a BareTail Pro-ban már benne van. Ez utóbbi letölthető trial-ban és komoly 25 dollárba kerül. Ja, fontos hogy ez egy Windows program.

Létezik még egy hasonló, de lényegesen kevesebb tudást felhalmozó, kissé kényelmetlen loggolós plugin Eclipse-re, de ez elég félbehagyott projektnek látszik: Graysky

A RollingFileAppenderek pedig az alapműveltséghez tartoznak. Tudnak naponta, óránként, percenként (?) új fájlot kezdeni konfigtól függően. Már amelyik logging framework-ben van ilyen.

Update 2008.07.21 A javalistán az elmúlt napokban Log4j file elemzese címmel megjelent egy kérdés, ami pont a logfájlok nézegetésével és az ahhoz használt eszközökkel foglalkozik. A következőket ajánlják: Mindtree Insight (végül ez lett a bejövős az kérdés feltevőjének), Chainsaw , Vigilog (ezzel valami gebasz volt), valamint Perl/Awk. Ha nagyon hiper-ultra-extra logcsoportosítások kellenének, akkor talán elkezdenék Perl-ben programozni, de egyébként -bármennyire is tisztelem a "víáj lovagokat"- command promptban elég nehéz versenyezni egy adott célra kihegyezett, valóban jó GUI-s eszközzel.

log4j JDBCAppender

Összegyűlt néhány loggolós okosság, amiket nem kellene elfelejteni. Azokat fogom mostanában leírni többek között.

A log4j-ben van egy úgynevezett JDBCAppender, amivel adatbázisba lehet loggolni. A conversionPattern-nek lehet megmondani egy SQL utasítást így valahogy:

<param name="ConversionPattern" value="INSERT INTO log (level, name, message) VALUES ('%p','%c', '%m')">

És nagyjából működik. Itt leírják, hogyan kell property fájlban konfigurálni, itt pedig van példa az xml konfigurációjára. A javadoc-ban pirossal-vastaggal ki van emelve, hogy ne használd, mert gagyi és ki lesz szedve. És valóban: a connection-ökkel elég rosszul bánik, elhasal ha a message-ben aposztróf van, nem támogat tárolt eljárásokat, prepared statement-eket, exception-öket pedig egyszerűen nem loggol. De azért kezdetnek használható. Dankomannhauptnál van egy használhatóbb megvalósítás, de nem próbáltam ki.

Budapest New Technology Meetup Október

http://newtech.meetup.com/42/

Szóval fogtam magam és lebattyogtam erre a Meetup-ra...

Kiss Róbert (SOTE): Virtuális Gyógyszerkutatás: Természetesen nem nagyon volt lövésem a dologhoz, de az lejött hogy a fehérjekutatáshoz iszonyat sok számítási kapacitás kell. 1000 PC 3 hónapig ment, hogy leteszteljen 255 kombinációt -ha jól értelmeztem- és ebből 25 lett használható, ezekből lehet majd egyszer gyógyszer. Le is patentolták a vegyületeket. Úgynevezett "dokkoló" szoftvert használtak. Gyakorlatilag ez a szimulációs szoftver.

Pécskai Balázs, Fischer Kristóf (Mimóza Kommunikációs Kft.): Nextwork robotépítő verseny. Lesz egy Legós robotépítő verseny jövőre, azt reklámozták. Egy alap robotlegó készlet 90 ropiba kerül. Nem veszek, úgysem lenne időm legózni.

Benedek Balázs (Magyar Villamosmérnök- és Informatikus-hallgatók Egyesülete): 24 órás programozó verseny. Pár mondat elhangzott a "24 órás" kulisszatitkairól. Nem is tudtam, hogy miskolciak a gyökerei, ott rendezték meg először, csak akkor még nem az volt a neve. Segítséget keresnek a szervezéshez, feladatkiírásokhoz. Merthogy a verseny csak 24 óra, de a feladatkiírással tovább kell szórakozni, az 72 óra. Hahh... egyáltalán nem 24 óra a verseny, komoly felkészülés kell hozzá. Össze kell reszelni a segédkönyvtárakat, algoritmusokat, hogy a versenyen már minél több dolgot csak ki kelljen venni a dobozból és használni. Elhangzott hogy egyre több külföldi csapat indul a megmérettetésen (akik rendre le is nyomják hazai csapatokat). Nem tudom mi lehet ennek az oka, de hajrá srácok, mutassátok meg!

Szalai Ferenc (AVAXIO Informatikai Kft.): Ata-over-Ethernet - adattárolás, egyszerűen és célratörően. Ez már nekem nagyon hardver volt, de az lejött hogy van élet az adatbázisok és fájlszerverek fölött (után/mögött/alatt) is. Gondolom komolyabb adattömeggel dolgozó szolgáltatások általában ehhez hasonló vagy épp ilyen architektúrákat használnak.

Kozman Bálint: Szoftver vizualizáció. Rövid volt az előadás ehhez a témához. Egy egyszerű példa lett bemutatva blokkok és egymásbaágyazások megjelenítésére egy forrásfájlon belül, de vannak még bőven felhasználási területek. Régebben volt is egy indexfórumos téma, ami a programsorok tömegét és a modulok kapcsolódásait térképezi fel különböző méretű buborékok formájában. A Team activity analysis-ben is igen jó szolgálatot tehet. Ez csak egy hirtelen talált példa. Láttam olyat is, hogy -szintén verziókontroll alapján- a kódsorok szaporodását és kicserélődését követi nyomon. Ha valamilyen szinten össze van kötve a verziókontroll egy bugtracking rendszerrel, az további hasznos ábrák rajzolására ad lehetőséget. Kicsit el lettek bagatelizálva az előadás utáni kérdések, pl. lehetne-e ezekből művészeti alkotásokat készíteni, de szerintem jócskán vannak hasznos aspektusai. Pl. ha egy idegen kódra kell ráugrani, hasznosabb ránézni "felülről" egy ilyen vizualizációval, mert maguk a kódsorok vagy esetleg az UML diagramok nyálazgatása nem ad átfogó képet, nem látni a fától az erdőt. Főleg ha nincsenek UML diagramok -mint általában. Kódreview-ekhez is segítség lehet a vizualizáció, mert kibújnak a zsákból a funkcionalitással túlzsúfolt osztályok, vagy a mindennel összekapcsolt modulok. Jó eszköz lehet ez egy vezető fejlesztőnek, ha tudja használni.

A helyet nehéz megtalálni, de nagyon hangulatos. Igazi underground stílusú építészklub csupasz fagerendákkal és vakolattal, de ami kell az nagyon rendben van tartva. Volt bárpult, 450 a sör (jófajta), 150 vagy 250 a bor decije. Az előadások után lehetett volna még cimbizni, de nekem el kellett húznom.