Hibakeresés és naplózás Java környezetben

Hibakeresés és naplózás Java környezetben Célok, lehetőségek, minták, implementáció Konstantinusz Kft. 2009

1. Tartalomjegyzék 1. Tartalomjegyzék... 2 2. Bevezetés... 2 3. Hibakeresés probléma felvetés... 2 1.1. A hiba reprodukálása... 3 1.2. A hiba azonosítása... 3 1.3. A hiba javítása... 4 4. Naplózás... 4 1.4. Log keretrendszerek... 4 1.5. Szintek... 5 1.6. Logger helyes hívása a kódban... 6 1.7. Kivételek naplózása... 10 1.8. Különböző környezetek... 11 5. Összefoglalás... 11 2. Bevezetés A szoftverfejlesztés egyik nagy igazsága az, hogy nincs kész rendszer. Valamilyen formában mindig változik: újabb igények kerülnek megvalósításra, új környezetbe kerül, változnak a rendszer paraméterei. Ennek következménye az, hogy a rendszer teljes élettartamában találkozunk újabb és újabb hibákkal. Előfordulhat, hogy egy régebbi fejlesztés reagál kedvezőtlenül egy új paraméter értékre, vagy új fejlesztés hoz nem várt eredményt. Ezért van szükség arra, hogy a rendszer felépítésében és kommunikációjában maximálisan támogassa a hibakereséssel kapcsolatos elvárásokat. Az egyes programegységek egységesen kerüljenek naplózásra, a rendszerüzenetek, és a naplóbejegyzések megfelelő információkat tartalmazzanak az eseményekről. 3. Hibakeresés probléma felvetés A hibákra előbb vagy utóbbi fény derül. Az esetek többségében a felhasználó funkcionális tesztet végző vagy éles rendszert használó találkozik vagy logikai hibával, vagy olyan működésbeli problémával, ami a feladat végrehajtását lehetetleníti el. A hiba jelentkezhet például egy üzleti folyamat végrehajtása közben vagy az után, az eredmény ellenőrzésekor a rendszer outputjait vizsgálva egy riportban vagy esetleg adatbázisban. Miután a felhasználó észlelte a hibát a szoftvert szállítójának feladata, hogy reprodukálja, azonosítsa és javítsa azt a felhasználói leírások, inputok és az alkalmazás outputok alapján. 2/11

Ehhez kapunk segítséget, ha alkalmazzuk a naplózó eszközöket (logging), illetve lépésről lépésre vizsgáljuk a kódot (debug). A két módszer szemléletében és alkalmazási módban eltérő, azonban mindkettő fontos szerepet kap a szoftverhibák elhárításában. Mielőtt részletezzük az első módszert vizsgáljuk meg, hogy milyen feladatokat kell elvégeznünk miután egy hiba a tudomásunkra jutott. 1.1. A hiba reprodukálása A hiba reprodukálhatósága alatt azt értjük, hogy ugyanazon verziójú alkalmazással egy másik környezetben, egy másik példányon is előállítható, megismételhető. A hiba reprodukálására szükség van, egyrészt a hiba azonosításához, másrészt a javítás teszteléséhez. Ha a hiba azonosításához szükséges információk nem állnak rendelkezésre, vagy felmerült a gyanú, hogy a hiba hatása több feladatot is érint, és szükség van a hiba követésére e feladatok esetén is, akkor még az azonosítás előtt reprodukálni kell a hibát. Ha a hiba azonosítása már megtörtént, akkor csak a javítás utáni teszteset összeállításához szükséges az, hogy a hibát újra elő tudjuk állítani. A hiba reprodukálása koránt sem olyan egyszerű probléma, mint ahogy első hallásra tűnik. Azt gondolnánk, hogy elegendő ugyanazokat az adatokat felvinnünk a képernyőkön, amiket a felhasználó is felvitt korábban, és már is megvan a hiba. Azonban ez csak ritkán és viszonylag egyszerű feladatok estén vezet eredményre. Figyelembe kell vennünk még a környezet egyes részeit, amennyiben hatásuk van az adott feladatra: az adatbázis állapotot egyéb külső paraméterek integrációs környezet a rendszerben korábban végrehajtott feladatok A legtöbb esetben csak a fentiek figyelembevételével sikerülhet a hiba reprodukálása. Azt tűzzük ki tehát célul, hogy a megfelelő információk álljanak rendelkezésre akkor, amikor a hibát reprodukálni szeretnénk. Az információk konkrét tartalma az üzleti esettől függ, a feladat határozza meg. Feltételezzük, hogyha a megfelelő információk megvannak, akkor a hiba reprodukálható. 1.2. A hiba azonosítása A hiba azonosítása alatt azt értjük, hogy megvan a programkódban az a rész, ami az adott paraméterek alapján a hibás működést eredményezi. A hiba azonosításához nem feltétlenül van szükség a reprodukálásra. Amennyiben a hibával kapcsolatban kapott információk elégségesek az azonosításához, és egyértelmű a probléma, nem kell megvárnunk a reprodukálást, lehet a kettőt párhuzamosan végezni. 3/11

Gyakran előfordul az például helytelen kivételkezelés esetén, hogy a kapott hiba egy előzőleg elnyelt kivétel, korábbi hiba miatt következik be. Ekkor általában a legrészletesebb stacktrace és leírás sem elegendő, ugyanis nem az okról kapunk információt, hanem csak a következményről. A következmény pedig nem határozza meg egyértelműen magát a kiváltó okot. A helytelen kivételkezelés szélsőséges esetben történhet egy másik feladatban, egy másik modulban, sőt akár egy másik alkalmazásban is. Az a cél, hogy alkalmazás ne adjon félrevezető információkat a hiba előfordulásának programkódbeli helyéről, azaz ne legyenek elnyelt kivételek. 1.3. A hiba javítása A hiba javítása talán egy kicsit kevésbé tartozik e témakörhöz, mint az előző kettő. Mégis fontos megemlíteni, hogy azon túl, hogy a konkrét logikai hibát kijavítjuk, fordítsunk arra is figyelmet, hogy ha esetleg az azonosításhoz vagy a reprodukáláshoz nem álltak elő a megfelelő információk, akkor azokat pótoljuk a javításkor, jelenítsük meg a logban. Esetleg, ha látszanak hasonló hiányosságok egyéb program részekben, akkor azokat is alakítsuk át, hogy a megfelelő információk megjelenjenek egy későbbi nyomozást támogatva. A cél az, hogy a hiba javításkor is kövessük a meghatározott logolási mintát illetve, ha eltérést találunk attól, akkor javítsuk azt is. 4. Naplózás Ma már nem kell naplózó keretrendszert fejleszteni az alkalmazás részeként. Nem kell kitalálni, hogyan rögzüljenek a naplóbejegyzések. Már kezünkben vannak azok a log keretrendszerek, melyek sok év tapasztalatát fogják össze magukban, és nagyon jó eszközrendszert adnak a kezünkbe, hogy egységes, jól paraméterezhető log környezetet hozzunk létre egy alkalmazáson belül. 1.4. Log keretrendszerek A Java keretrendszerek közül elsőként az Apache commons-logging-ot kell szemügyre vennünk. Meglepően nem a JDK-ban helyet kapott Logger a legáltalánosabb eszköz, hanem a commonslogging. Ez a vékony keretrendszer egy absztrakt réteget húz minden logger implementáció fölé a JDK fölé is. Ezért van az, hogy ideális döntés, ha ezt kötjük az alkalmazásba. Mivel az alkalmazásunkba egy absztrakt réteget kötöttünk be így annak segítségével különböző logger keretrendszereket is összekapcsolhatunk vagy váltogathatunk közöttük kedvünkre csupán a konfigurációt módosítva. Sok előnye közül ez az egyik, ha a commons-logging keretrendszert használjuk az alkalmazásunkban. Sokszor viszont mégsem használjuk a commons logging-ot, mivel a log4j egy másik keretrendszer önállóan is képes ellátni egy alkalmazás egységes loggolását. Amennyiben nem 4/11

kívánjuk változtatni az logger implementációt, a log4j-t is köthetjük az alkalmazásba. Abban az esetben van szükségünk commons loggingra, ha felmerül, hogy az adott implementációt cseréljük az alkalmazásunk alatt. # Use Log4j org.apache.commons.logging.log=org.apache.commons.logging.i mpl.log4jlogger # Configuration file of the log log4j.configuration=log4j.properties 1. kódrészlet commons-logging.properties log4j implementációval 1.5. Szintek A legtöbb keretrendszer egyik központi koncepcionális eleme az egyes log üzenetek küldésekor definiálható szint. A szint a naplóüzenet olyan tulajdonsága, amit a keretrendszer használ annak eldöntésére, hogy az adott üzenetet kell-e naplózni adott konfiguráció mellett vagy nem. A különböző szintek különböző napló részletezettséget képviselnek. A különböző keretrendszerek eltérnek abban, hogy milyen szinteket használhatunk illetve, hogy definiálhatunk-e saját szinteket vagy sem. Nézzük a leggyakrabban használt szinteket és szerepüket: TRACE A műveletek minden részletét naplózzuk. DEBUG A hibakeresést támogató napló bejegyzéseket naplózzuk. INFO A program futásával kapcsolatos, tájékoztató információkat naplózzuk. WARN Valamilyen szokatlan működést jelző bejegyzéseket naplózzuk. ERROR Hibák naplózása. FATAL Leálláshoz vezető hibákat naplózzuk. A szinteket két helyen használjuk: loghívás paramétereként a programkódban konfigurációs beállításként az aktuális futás naplózására A szintek között egy rendezési reláció áll fenn. A fenti lista a leggyengébbtől indul a legerősebbig. Az a szabály, hogy a konfigurált szint és az annál erősebb üzenetek jelennek meg a naplóban. Nézzünk egy példát: A programkódban az adott üzenetet adott szinttel - jelen esetben DEBUG szinttel - küldjük el a naplózó keretrendszernek. //loghívás logger.info( Job done: +jobid); 5/11

2. kódrészlet loghívás üzenet <! Az üzenet nem lesz log-entry, mert a szintje kisebb, mint a konfigurált szint--> <level value="warn"/> 3. kódrészlet konfigurált szint warn > info <! Az üzenet log-entry lesz, mert a szintje megegyezik a konfigurált szinttel --> <level value="info"/> 4. kódrészlet konfigurált szint info <!-- Az üzenet log-entry lesz, mert a szintje nagyobb a konfigurált szintnél --> <level value="debug"/> 5. kódrészlet konfigurált szint debug < info 1.6. Logger helyes hívása a kódban A jól átgondolt és megtervezett naplózás komoly segítség lesz az alkalmazás későbbi szakaszaiban. Azonban akár egyetlen elhamarkodott és átgondolatlan loghívás vagy annak üzenete is súlyos problémákat okozhat. A következőkben áttekintjük azokat a problémákat és felhívjuk rájuk a figyelmet, amiket a helytelenül alkalmazott naplóbejegyzések okozhatnak. A problémákat és azok elkerülését három aspektusból vizsgáljuk. Ez a három feladat vár arra a programozóra, aki egy bizonyos loghívást szeretne elhelyezni a programkódban. Megfelelő üzenet előállítása Az üzenetek formátuma általában String. Ezt könnyen emésztik a keretrendszerek, és valóban a legmegfelelőbb forma egy naplóbejegyzéshez. A String példány sokféleképpen előállhat. Nézzünk néhány példát a legegyszerűbbtől a bonyolultabbakig. 6/11

// i) logger.info( Checking Job. ); // ii) logger.info( Checking Job: +jobid); // iii) logger.info( Checking Job: +job.getid()); // iv) logger.info( Checking Job: +jobid.tostring()); 6. kódrészlet egyszerű üzenetek Az első esetben nagy valószínűséggel nem adódik probléma futás közben. Annál több adódhat viszont akkor, amikor értelmezni próbáljuk a naplót. A legegyszerűbb, és legveszélytelenebb módja a log üzenet előállításához. Kétségtelen azonban, hogy a legkevésbé informatív is. Sok esetben valóban elegendő a statikus üzenet, viszont az e fajta üzeneteknél kell a leginkább odafigyelni a meg fogalmazásra. Ebben az esetben sem történik probléma, viszont az előálló String példány szélsőséges esetben értelmetlen lehet. Mivel jelen példában nem tudunk a loghívás környezetéről semmit, tegyük fel, hogy lehetséges az az esetet, amikor a jobid=null. Ekkor a következő eredményt kapjuk: Checking Job: null Természetesen értelmező a naplóbejegyzés, ha tudjuk a mögöttes logikát. Viszont egy avatatlan szem nem sok információt képes kinyerni ebből. Tartsuk szem előtt azt, hogy laikusok is olvashatják a naplót. Jó megoldás lehet a következő: // ii) logger.info( Checking Job: + (jobid==null? unknown check previous log-entries for error :jobid) ); Ekkor már egy barátságosabb üzenetet kapunk: Checking Job: unknown check previous log-entries for Talán most már látszanak a problémák a következő bejegyzésekkel is. A harmadik esetben már súlyos problémát (NullPointerException-t) kapunk, ha a job null értéket vesz fel. 7/11

Természetesen ekkor is segít a következő: // iii) logger.info( Checking Job: + (job==null? unknown check previous log-entries for error :job.getid()) ); Értelmetlen és buta, mégis gyakori hiba az, amikor egy már létező vagy új loghívásban valamelyik objektum után explicit meghívjuk a tostring() metódust. Természetesen, ha nincs ott az explicit hívás, akkor az adott objektum példányon valóban a tostring() hívódik meg automatikusan. Viszont ez esetben job=null esetén a null, mint szöveg jelenik meg a bejegyzésben. Explicit tostring() esetén pedig előáll a iii) eset és a NullPointerException probléma. A fenti példák egyszerűen elkerülhetők, mégis sok hibaforrást rejtenek, ha nem figyel a fejlesztő. A következőkben nézzünk meg komplexebb naplózási igényt és megoldást. Az alap probléma az, hogy az üzenetet össze kell állítani valamilyen logika szerint. Viszont ezt a logikát csak abban az esetben szeretnénk futtatni, amennyiben maga a loghívás logentry-t hoz majd létre, azaz a konfigurációban szereplő szint gyengébb vagy azonos, mint a loghívásban szereplő szint. // i) helyes if(log.isdebugenabled()) { String message; // üzenet előállító logika // csak akkor fut le, // ha debug entry-ket is naplózunk log.debug(message); } // ii) helyes String message=null; if(log.istraceenabled()) { // üzenet előállító logika // csak akkor fut le, // ha trace entry-ket is naplózunk } // az üzenet előállítása korábban történik, mint az üzenet naplózása log.trace(message); 8/11

// helytelen String message; // üzenet előállító logika // mindig lefut log.debug(message); A megfelelő szint megválasztása 6. kódrészlet elérhető szint vizsgálata helyes - helytelen Tartsuk szem előtt, hogy a szintek szerepe az, hogy lehetőség legyen megkülönböztetni a naplót vizsgáló felhasználók körét. Ne jelenítsünk meg felesleges üzeneteket az erősebb szinteken, ha azok nem szükségesek az adott napló olvasónak. Az is fontos azonban, hogy a szükséges üzenetek ne maradjanak gyengébb szinten, ha az egy erősebb szintet is érdekelheti. Az alábbiakban egy általános mintát látunk a szintekre és az üzenetek tartalmára vonatkozóan. A trace szinten általában az algoritmusok részeredményeit jelenítjük meg. A trace szint teljes és egységes alkalmazása komoly kihívás. Emiatt és az erőforrás igény miatt legtöbbször el is marad, és csak néhány kulcs algoritmus esetén valósul meg. A debug szint a paraméterek és az algoritmusok végeredményének naplózására használható. Ez az információ általában elégséges a legtöbb hiba reprodukálásához és azonosításához. Az info szint a felhasználó, adminisztrátor, vagy egyéb rendszerek szempontjából fontos üzeneteket jeleníti meg. Az üzemeltetéshez szükséges információkat szolgáltatja. A programban történő elhelyezés Azt már láttuk, hogy lehet vizsgálni a szükséges szint aktív voltát. Ezen túl viszont fontos az is, hogy a különböző utasításokban milyen hatása lesz a loghívásnak. Vizsgáljuk meg az if then else szerkezetet. A logikától függően legtöbbször info szinten szükség van a feltétel kiértékelésének eredményére. Debug szinten pedig szinte mindig. Azaz legalább debug szinten naplózni kell a feltétel eredményét. Ezt a következőképpen érdemes megtenni. 9/11

if(){ log.debug( World Peace Completed ); } else if(){ log.debug( World Peace Still In Progress ); } else{ log.debug( World Peace Failed But Not Given Up ); } Másik fontos szerkezet a ciklus. Velük kapcsolatban arra kell ügyelni, hogy a ciklusmagba írt loghívás többször megtörténik. Tehát ha van olyan rész az üzenetben, mely a cikluson kívül előállítható, akkor azt tegyük meg. Nagyszámú ismétlés esetén gyorsan növekszik a logfájl mérete. Feltételes ciklus befejeződése esetén fontos információ lehet a lefutások száma. 1.7. Kivételek naplózása A keretrendszerek lehetőséget adnak arra, hogy egy kivételt (Throwable) naplózzunk. Ezt általában megtehetjük minden szinten. A kivétel naplózása azt jelenti, hogy a stacktrace-t kiírjuk a naplóbejegyzésbe. Fontos szempont, a kivételek felismerhetősége. Nézzük meg, milyen szempontoknak kell megfelelnie a kivételeknek a logfájlban: Dokumentálhatóság Egyértelműség Üzemeltető felhasználó számára azonosítható hibajelzés Egyszerű és jó megoldás az, ha minden kivételpéldányhoz vagy üzenethez kódot rendelünk, valamint, a gyorsabb behatárolhatóság kedvéért, egy prefixet rakunk a kód elé, mely az üzleti modult vagy valamilyen egyéb egységet jelöl. Ezt a módszert alkalmazva a következőképpen néz ki egy bejegyzés: [DEBUG] MOD1-00012 Exception message from Module1. stacktrace [DEBUG] MOD2-00100 Exception message from Module2. stacktrace A kivételek naplózásával kapcsolatban az egyik kulcs az, hogy soha ne nyeljünk el kivételt naplózás nélkül. Természetesen vannak olyan kivételek, melyeket programozás technikai okokból 10/11

elnyelünk (pl.: adatbázis kapcsolat lezáráskor), de az üzleti folyamatot, logikát érintő kivételeket tilos naplózás nélkül elnyelni. 1.8. Különböző környezetek A naplózás igazi jelentőségét akkor látjuk, amikor az alkalmazásunk több környezetben is fut. Legtöbb esetben az alkalmazás az éles környezeten túl még felhasználói teszt és fejlesztői teszt környezetekben is működik párhuzamosan. Erre azért van szükség, hogy a verzióváltások és a tesztelés gördülékenyen hajtódjanak végre. Ideális esetben az egyes környezetek identikusak, ám ez a gyakorlatban ritkán teljesül. Sokszor előfordul az, hogy az alkalmazás tesztelése nem teljes vagy csak adott környezetben fordul elő egy adott hiba. Megfelelő szintű és részletes napló esetén azonnal látjuk a hiba okát és előfordulhat, hogy elegendő csak a konfigurációs beállításokon vagy a törzsadatokon módosítani, hogy javítsuk a hibát. Az egyes környezetekben lehetőség van arra, hogy a naplózás szintjét eltérően állítsuk be. Ez akkor hasznos, ha az éles környezet naplóját nem akarjuk alacsony szintű bejegyzésekkel terhelni, viszont egy adott feladatot szeretnénk alacsony szinten végig követni a tesztrendszerben. 5. Összefoglalás Láthatjuk, hogy a megfelelő naplózás komoly segítséget nyújt mind a fejlesztőnek, mind az üzemeltetőnek hosszútávon. Az alkalmazás fejlesztésekor azonban általában nincs elegendő erőforrás az loghívások elégséges létrehozására viszont néhány kulcs funkció esetében elkerülhetetlen a részletes megvalósítás. Fontos, hogy ne csak próbálkozzunk a megfelelő naplózással, hanem fektessünk erőforrást a kialakításra az alkalmazás fejlesztése során. Ez a befektetés többszörösen megtérül majd. A helytelen, félrevezető naplózás legalább olyan káros, mint a naplózás hiánya. A megfelelő naplózás kialakítása a fejlesztői és üzemeltetői fluktuációt is nagyban megkönnyíti és csökkenti a kockázatot. Fontos a fejlesztők megfelelő instruálása a naplózással kapcsolatban. Az alkalmazott keretrendszer lehetőségeit, a naplózás mintáit és az elvárásokat is tisztázni kell. Így a rendszer egységesen kerül naplózásra. 11/11