dynaTrace - Memória szivárgás beazonosítása

Az előző cikk folytatásaként, egy éles rendszerben előfordult memória szivárgáson keresztül fogom megmutatni, hogy hogyan is kell a dynaTrace-szel a gyökér okokig eljutni. Általában minden azzal kezdődik, hogy a dynaTrace-től kapunk egy riasztást, hogy kevés a szabad memória vagy túl sokat GC-zik az appserver, majd a Process Health dashboardon validáljuk, hogy valóban ez a helyzet. Restart után készítettem néhány Memory Consumption Trending dump-ot és beazonosítottam, hogy mely osztályok példány száma növekszik. Esetünkben a BasifTopup osztályból 669.195 darab volt a heap-en.

Ezután a System Profile/Sensors menüpont alatt a BasifTopup osztályra felhelyeztem egy memória szenzort. A dynaTrace hot sensor placement feature segítségével, külön újraindítás nélkül, futásidőben aktiválódott ez a szenzor szabály.

Selective Memory Dump-ok készítésével látható váltak az objektum allokációk, ahonnan pedig továbbfúrtam azokhoz a PurePath-okhoz, ahol ezek az objektum példányok létrejöttek.

A PurePath hívási láncnál megjelent, hogy a BasifTopup példányai, a registerResultInUnitOfWork() metódus hívásnál keletkeznek nagy számban. Innen két kattintással a bytecode visszafejtésével elém tárult a forráskód, ami alapján megtettem a javaslataimat a probléma elhárítása érdekében.

Hát nem egyszerű és nagyszerű? :))

dynaTrace - Memória dump típusok

Gyorsan meg akarod találni a memória szivárgás (memory leak) valódi okát? Használj dynaTrace-t! Attól függően, hogy milyen információra van szükséged, 3 féle heap dump típus készítése közül választhatsz:

1. Deep Memory Leak Analysis:

Ez a hagyományos heap dump-nak feleltethető meg, azaz az objektumok kapcsolatai, a referenciák mentén lekövethető. A heap méretétől függően több percbe is telhet a dump létrehozása, mialatt a JVM mással nem foglalkozik, így napközben való készítése, éles környezetben csak indokolt esetben javasolt. Az elkészített dump utófeldolgozását a dynaTrace Analysis szerver fogja elvégezni. Gyakori kérdés, de a dynaTrace-es dump-ot más eszközzel (Eclipse Memory Analyzer, IBM HA) nem tudjuk beolvasni.

2. Memory Consumption Trending:

Ezzel a dump-pal megkapjuk, hogy melyik osztályból hány példány volt a memóriában. Az előnye, hogy néhány másodperc alatt lefut, azaz nem akasztja meg az alkalmazás futását, így éles környezetben, akár napközben is használható. Ha memória fogyást tapasztalunk, készítünk pl. 10 percenként pár dumpot és összehasonlíthatjuk őket, hogy mely osztályok példányszáma növekszik folyamatosan. 

3. Selective Memory Dump:

Miután a Memory Consumption Trending dump-ok készítésével meghatároztuk azokat az osztályokat, amelyek példányszáma növekszik, ezen az osztályokra memória szenzort tehetünk fel, majd a Selective Memory Dump készítésével megtekinthetjük, hogy a PurePath hívási láncban ezek az objketumok melyik metódusnál jönnek létre. Nagyon hasznos feature!

A folytatásban pedig egy esettanulmányt fogok megmutatni, hogy a gyakorlatban hogyan kell egy memory leak gyökér okát beazonosítani a dynaTrace-szel.

EMA and Plumbr - Memory leak hunting

Hogy ne mindig csak a dynaTrace-ről legyen szó, most az Eclipse Memory Analyzer-rel és a Plumbr eszközökkel mutatom meg, hogyan lehet megoldni egy memória szivárgást. Egy web-alkalmazásnál tapasztaltam azt a jelenséget, hogy néhány undeploy-deploy művelet hatására java.lang.OutOfMemoryError: PermGen space hiba keletkezett. A szokásostól eltérően, most nem a dynaTrace-t vettem elő (mert az adott szerveren nem volt DT licence) hanem más alternatívákat.

Az OutOfMemory hatására készült egy heap dump, amit betöltöttem az EMA eszközbe. Itt van egy jó tutorial az EMA-val való ClassLoading leak megtaláláshoz. A megoldáshoz nem kellett sokat keresgélni, mert már a beépített Leak Suspect Report is kimutatta, hogy hol lesz a probléma, mindenesetre azért kicsit magam is megnézegettem a dumpot, ahol bebizonyosodott, hogy az oracle jdbc driver miatt, az osztálybetöltő nem tudott felszabadulni.

Már rég kiakartam próbálni a java agnet alapú Plumbr free verzióját, ezért ez a memory leak pont kapóra jött nekem. A Plumbr nem az utólag elkészített heap dump-ot analizálja, hanem real-time figyeli az alkalmazásunkat és ha egy anomáliát talál, azonnal kijelzi a probléma okát és még megoldási javaslatokkal is ellát minket. Ezt már nevezem!

Itt, itt meg itt találtam néhány leírást ami pontosan illeszkedett erre a problémára, röviden tehát a leak-et az okozta, hogy az adatbázis driver nem került sohasem felszabadításra egy WildFly bug miatt, amit az osztálybetöltési policy módosításával sem sikerült orvosolni. Végül, más megoldás hiányában - egy nem szép - de működő programozott megoldást próbáltam ki amivel megoldódott a hibajelenség.

Jut eszembe, a Java 8-ban már nincs is perm gen space helyette van metaspace. :)

dynaTrace - JDBC batch insert

A teljesítménybeli problémák egy része konfigurációs (jvm, pool) hiányosságokra vezethető vissza, azonban a legtöbb esetben mégis maga az alkalmazás kódja vagy az egyes API-k ill. keretrendszerek nem megfelelő használata okozza a legsúlyosabb veszteségeket. Már az egyetemen is mondogatták, hogy nagy mennyiségű adat beszúrását kötegelve végezzük el, mert a DML műveletek (insert, update, delete) egyenként történő végrehajtása, külön-külön adatbázis feldolgozást és magasabb hálózati overhead-et is jelent.

Az alábbi program 20.000 JDBC insert műveletet fog lefuttatni egyenkénti (tehát nem kötegelt) végrehajtással.

Ahogy a dynaTrace PurePath dashleten is láthatjuk, a válaszidő 13.4 másodperc volt, 97%-ban Input-Output művelettel a lekérdezések végrehajtásánál.

Módosítsuk a programot és nézzük meg, hogy mennyi javulást érünk el, ha az insert műveleteket kötegelve hajtjuk végre.

Az alábbi képen látható eredmény magáért beszél, sikerült a válaszidőt 1.8 másodpercre lecsökkenteni minimális forráskód módosítással. 

Érdemes arra odafigyelni, hogy a nagyméretű kötegek esetén időnként (minden x insert után) futtassunk le egy JDBC batch insertet, különben OutOfMemorError keletkezhet amennyiben a heap memória megtelik!

dynaTrace ingyen - Teljes verzió, 30 napig

Frissítve: 2016.05.25

Igen! Ezen az oldalon bárki számára letölthető a teljes funkcionalitású dynaTrace és 30 napon keresztül szabadon használható, akár éles környezetben is. A free trial licence a következőket tartalmazza:

• Java agents: 5
• .NET agents: 5
• Webserver agents: 5
• PHP agents: 5
• Node.js agents: 5
• No SQL: 5
• Native (C/C++) agent: 5
• Database: 5 (8 CPU Core)
• Host monitoring agent: 5
• IBM Integration Bus agent: 5
• UEM volume: 100.000

Először is regisztrálni kell egy céges e-mail címmel a Compuware web-oldalán, majd a kiküldött e-mailben található linkre kattintva meg kell adni az új jelszavunkat. Ezután egyből hozzáférést kapunk a közösségi portálhoz, a hivatalos fórumhoz és a dynaTrace teljes dokumentációjához, amelyben részletesen le van írva minden információ egészen a telepítéstől a használatig! Az induláshoz szerencsére nem kell átolvasni a teljes doksit, mivel a kezdőoldalon egy 4 lépéses varázsló vezet el minket a dynaTrace használatba vételéhez. A letöltéstől számítva, nagyjából 15 perc alatt beüzemelhető a rendszer!

A dynaTrace használata és a performancia vagy funkcionális problémák beazonosítása persze igényel egy kis gyakorlatot, ezért ha bármilyen kérdésed lenne a telepítéssel vagy a konfigurálással kapcsolatban esetleg egy gyors elemzést kérnél tőlem a vizsgált alkalmazásodról, nagyon szívesek segítek! Ne kíméljetek! .)

dynaTrace - Nemcsak tűzoltásra!

A dynaTrace egy hasznos eszköz az éles környezetben felmerült teljesítménybeli és stabilitási problémák beazonosításához, de lássuk be ez nem más mint tűzoltás! Én azt javaslom, hogy ne csak akkor kezdjünk el foglalkozni a problémákkal ha már ég a ház, mert ilyenkor biztos sokkal nagyobb lesz a kárunk és a javítási költség is!


A problémákat jóval korábban, már a fejlesztés-tesztelés fázisban ki kellene mutatni, így azok gyorsan orvosolhatók! Felmerülhet a kérdés, hogy miért használjunk dynaTrace-t amikor ott vannak a már jól bevált teszteszközök? A dynaTrace-t nem a teszteszközök helyett, hanem azokkal integrálva érdemes használni! Az alapvető probléma a teszt eszközökkel, hogy azok csupán rámutatnak a sokáig tartó kérésekre ill. hibákra, de nem tudják felfedni a problémák valódi okát, mivel nem látnak bele az alkalmazásba!

A dynaTrace integrálható a legtöbb kereskedelmi és nyílt teszteszközzel, legyen az terheléses (JMeter, LoadRunner), felületi (Selenium) vagy éppen egység teszt (JUnit, TestNG). A leghatékonyabb eredményt akkor érhetjük el, amikor ezt a folyamatos integrációs környezetünkbe is beillesztjük.

A gyakorlatban ez úgy néz ki, hogy egy CI eszköz (gombnyomásra vagy ütemezve) meghajtja az alábbi lépéseket:

1. Forráskód letöltése az SCM-ből
2. A build eszköz lefordítja a kódot, létrejönnek a build termékek
3. Lefuttat egy SonarQube kód analizálást
4. Átszól egy REST-es interface-n a dynaTrace-nek, hogy kezdheti a session mentést
5. Lefuttatja a dynaTrace-szel integrált unit teszteket
6. Telepíti a web-alkalmazást a tesztkörnyezetbe
7. Lefuttatja a dynaTrace-szel integrált felületi és terheléses teszteket
8. Átszól egy REST-es interface-en a dynaTrace-nek, hogy zárja le a session mentést

Nézzük is meg, hogy mit nyertünk vele:

• Minden egyes release-hez automatikusan létrejön egy dynaTrace session, ami tartalmazza a PurePath-okat és minden mérési eredményt a dinamikus jellemzőkről (lekérdezések ideje, kivételek száma, válaszidők, stb...)
• Minden egyes release-hez megkapjuk a kód statikus jellemzőit (System.out.println()-ek száma, stb...)
• Mivel a trendekből kiolvashatjuk a dinamikus (dynaTrace) és statikus (SonarQube) jellemzőket, a negatív elváltozásokat azonnal felismerhetjük
• Tetszőleges 2 release jellemzőit is összehasonlíthatjuk

Persze a dynaTrace a fejlesztőknek is tartogat hasznos funkciókat. Az Eclipse ill. az MS Visual stúdióval történő integrációt követően, a dynaTrace-ben megjelenő metódusokra kattintva átugorhatunk a fejlesztőkörnyezetünkben lévő projekt megfelelő metódusára!

Legközelebb pedig egy teljesen új témával jelentkezem, ez pedig az An...

dynaTrace - Te még nem használod?

Ezt a cikket egy összefoglalónak szántam azoknak akik gyorsan egy átfogó képet szeretnének kapni a dynaTrace hibakeresési ill. monitorozó képességeiről és remélhetőleg a bejegyzés végére mindenkinek kiderül, hogy miért mondogatom mindig azt, hogy a dynaTrace nélkül most már soha többé nem akarok szoftvert fejleszteni! 

PurePath technológia

A PurePath technológia lehetővé teszi, hogy JAVA, .NET, PHP, C rendszereken keresztül az összes felhasználó összes kérését lekövessük a hívási láncon keresztül, akár éles környezetben is a 4% alatti overhead-nek köszönhetően (így a hibákat nem kell a teszt környezetben reprodukálni). Sőt a technológiát kliens oldalon is használhatjuk a dynaTrace AJAX Edition kiegészítővel.

Az idő információk és a hívási lánc felrajzolásán túl elkaphatjuk a metódus argumentumokat ill. visszatérési értékeket, megtekinthetjük a keletkezett kivételeket és naplóüzeneteket, elcsíphetjük az SQL lekérdezések paramétereit is.

A gyökér okok gyors meghatározása

A dynaTrace közel 30 dashletet (Response Time HotSpots, Exceptions, Browser Errors, stb...) ad ahhoz, hogy a hibák gyökér okait minél gyorsabban beazonosítsuk és ahhoz is lehetőséget nyújt hogy bármikor tovább fúrjunk egy másik dashlet felé. Példaként a baloldali dashlet a metódus HotSpot-okat mutatja a kijelölt metódus hívási lánccal együtt, a jobb oldali pedig a database HotSpot-okat a hívó féllel.


Architekturális ábra a kapcsolódó rendszerekkel

A TransactionFlow dashlet, a kiválasztott időablakra vonatkozólag megmutatja a rendszer aktuális architektúráját, az áthaladó kérések irányát, a problémás komponenseket valamint a rétegek között eltelt időket is.

A felhasználói műveletek teljes lekövetése avagy mit csinált az user

Probléma esetén a felhasználók rendszerint betelefonálnak a help desk-re, hogy ez meg az nem működik, hibával találkoztak a felületen. Ilyenkor a legelső kérdés az szokott lenni, hogy mit csinált a felhasználó, mire kattintott. Ezen információk összegyűjtése nem mindig könnyű feladat. Persze a dynaTrace-szel egyszerű a dolgunk, csak leszűrünk a felhasználó nevére és megnézzük a látogatása során végrehajtott akciókat, majd szükség szerint tovább fúrunk a PurePath-okhoz.


Monitorozás és riasztás

A dynaTrace-t sokan csak egy hibafeltáró eszköznek gondolják, de az üzemeltetés számára leginkább a monitorozó és riasztási képességek bizonyulnak a leghasznosabbnak. Az alapértelmezett dashboard-ok mellett a rendelkezésre álló measure-ökre feliratkozva akár egy adott metódus vagy lekérdezés válaszidejét esetleg hívásszámát is monitorozhatunk. Ha a monitorozott metódus válaszideje meghaladna egy határt (riasztás), automatikusan készíthetünk heap és thread dump-ot valamint a problémás időszakhoz tartozó PurePath-okat session-ként is exportálhatjuk, amit egy harmadik félnek átadva már képes lesz analizálni a gyökér okokat.

Üzleti tranzakciók kialakítása

A PurePath-ok szűrésével és csoportosításával az üzlet számára fontos jellemzőket is vizualizálhatjuk. Az alábbi ábrán például a bevételek alakulását (metódus paramétereket elfogva és összeadva) követhetjük utazási irodánként ill. úticél szerint csoportosítva. Egy másik példaként az egyik nagy légitársaságnál tartott piloton, a felhasználói élményt (válaszidők és a hibák száma szerint számolva) kellett monitorozni a különböző platformról jövő felhasználok szerint csoportosítva, ahol is jól látszott hogy az Android 2.x-et használó felhasználóknál nagyobb az elégedetlenség és a visszafordulás aránya.

A legújabb technológiák folyamatos támogatása

A dynaTrace legújabb kiadásával az új alkalmazás szerver verziók mellett a Cloud, BigData és Mobil technológiák is támogatást élveznek, csak néhányat megemlítve: IIS8, JBoss AS 7, Glassfish 3.1, WebSphere AS 8.5, Weblogic 12, Cassandra, Mongo DB, HBase, Hadoop 2.x, Solr.

Gyors telepíthetőség és beüzemelés

Az agent alapú technológiának köszönhetően a telepítéshez a forráskódot NEM kell módosítani, pl. Java esetén csak egy JVM argumentumot kell beilleszteni az alkalmazást futtató szerverhez. A kollektorok és a dynaTrace szerver elindítása után, minden további konfigurációt egy Eclipse alapú vastag kliens alkalmazáson keresztül végezhetünk el.

Már 2 éve a piacvezető APM megoldás

A Gartner elemzése szerint 2011-ben és 2012-ben is a Compuware dynaTrace volt a vezető APM megoldás, amihez hozzájön, hogy a Fortune 500-ból jelenleg 386 a Compuware ügyfele.


És ez még csak a kezdet, a dynaTrace-t nemcsak az éles hibák felkutatásához és monitorozásához használhatjuk, de a fejlesztői és a tesztkörnyezetben is nagy segítségünkre lehet, mivel már a fejlesztés korai szakaszában kimutathatjuk az esetleges problémákat, amivel elkerülhető az éles környezetbe való kijutásuk.

DynaTrace - A feltárt szerver oldali hibák 2.

Az előző post folytatásaként ismét néhány jellegzetes hibatípust gyűjtöttem össze amelyekkel jómagam foglalkoztam a stabilizációs projekt kapcsán. Hát igen, a DynaTrace ezen hibák megtalálásában is elég hasznosnak bizonyult, nézzük is meg hogy hogyan segített.

Hiányzó TimeOut-ok

Sok helyen találkoztam azzal, hogy a WebService, EJB, URLConnection vagy DB lekérdezéseknél nem voltak timeout-ok definiálva. A timeout-ok hiánya néha komoly stabilitási problémákhoz is vezetett, pl. többször is előfordult, hogy egy belassult web-szolgáltatás miatt a kérések feltorlódtak így a válaszidők is megnövekedtek. Ha már a timeout-okat állítgatjuk, a programozott (java kódbeli) megadás helyett érdemes inkább a konfigurációs paraméterrel való megadást választani, így akár futásidőben is módosíthatjuk az értékét.

Ahogy az alábbi ábra is mutatja, a timeout jellegű hibákat a DynaTrace segítségével elég egyszerűen be lehet azonosítani!

Prepared Statement problémák

Szintén gyakori eset, hogy az SQL lekérdezések paraméterei string konkatenációval voltak beillesztve a PreparedStatement-nél preferált paraméter binding helyett. Ezzel két probléma is van, egyrészt SQL injection-ra adhat lehetőséget másrészt a statement cache-t nem tudjuk majd jól kihasználni.

A lekérdezések végrehajtása alapvetően 2 fázisra osztható az előkészítésre és a paraméterek behelyettesítésével történő végrehajtásra. Az előkészítés egy cpu igényes művelet, ami minden statement legelső végrehajtásakor lefut. Ez a fázis a parszolás, a szintaktikai ellenőrzés és fordítás valalmint a végrehajtási terv elkészítésének a lépéseit tartalmazza. Az előkészített statement, a db connection-onként nyilvántartott statement cache-ben eltárolódik és amíg ebben a cache-ben megtalálható, addig a következő végrehajtások során csak a paramétereket kell behelyettesíteni, az erőforrás igényes előkészítést már nem kell újból végrehajtani.

Nézzünk erre egy példát! Vegyük a "SELECT ID id, DESCRIPTION desc FROM mytable WHERE BL=? ORDER BY desc" lekérdezést, ahol is helyesen a WHERE feltételnél található paraméter nincs beégetve, így ebben a formában a lekérdezés a statement cache-ben csak 1 helyet foglal, függetlenül attól hogy milyen paramétert használunk a lekérdezés során. Az alábbi DynaTrace-el beazonosított SQL lekérdezés pedig a kerülendő változat, miszerint ugyanaz a lekérdezés 8 helyet foglal el a statement cache-ben mivel a paraméter be lett égetve a lekérdezésbe.

Érdemes tudni, hogy a WebSphere alkalmazás szerver alatt a prepared statement cache size alapértelmezett értéke 10, JBoss alatt pedig ha nincs definiálva akkor 0, így ennek az értékét még akkor is érdemes megnövelni ha egyébként paraméterezett sql-eket használtunk!

A statement cache pontos bekonfigurálásához érdemes monitorozást végezni a WebSphere admin console integrált IBM TivoliPerformance Viewer vagy a DynaTrace segítségével a Prepared Statement Cache Discard Count PM-re feliratkozva. Sőt a DynaTrace ezen felül lehetőséget biztosít a parszolás nélkül végrehajtott lekérdezések arányának a monitorozásához is az Executions without parse ratio metrika segítségével.

Java implementációs hibák sokasága

A konfigurációs problémák mellett rengeteg java implementációs hiba is napvilágra került, éppen csak néhány példát megemlítve:

• Néhány lapozó komponens lekérte az összes rekordot, nemcsak az adott oldalon megjelenítendőket.
• Explicit garbage collector hívások a Java kódban.
• Túl gyakori és felesleges Runtime.exec() hívások.
• Le nem kezelt (és néha a felületre is kijutott) kivételek.
• Memória szivárgások. (Memory Leak)
• Custom megoldások implementációs hibái: Saját DB Connection Pool szinkronizációs és logikai hibák.

Ne maradj le a folytatásról sem!

DynaTrace - A feltárt szerver oldali hibák 1.

A stabilizációs projekt során közel 500 hibát sikerült beazonosítanunk és megoldanunk, melyek döntő többsége valamilyen kódolási vagy konfigurációs problémára volt visszavezethető. A következő néhány bejegyzésemben ezekből emelnék ki néhány fontosabbat és írnék a megoldásukról is!

Nem optimális JVM beállítások

Az éles banki környezetben több mint 10 WebSphere klaszter volt kialakítva. A WAS szerverekhez kapcsolódó performancia problémák nyomozásakor találtunk környezetenkénti konfigurációs eltéréseket (melyek megelőzéséről egy későbbi cikkemben fogok írni) valamint nem optimális és hiányzó beállításokat melyekből most csak egyet emelnék ki, mégpedig a JVM Garbage Collector beállításait.

Amikor egy alkalmazás szerveren tranzakcionális jellegű web-alkalmazásokat futtatunk (melyeknél sok a rövid életű objektum), akkor IBM JVM esetén a gencon lesz a nyerő Garbage Collector stratégia! Ennek ellenére a szerverek többségénél nem volt megadva gc policy (alapértelmezett az optthruput) vagy egy másik gc policy volt definiálva, ahol pedig a gencon volt beállítva a nursery terület mérete túl alacsonynak bizonyult, feltehetően nem volt finomhangolva.

Habár a JVM GC tunning a VisualVM eszközzel is megoldható lett volna,  nekünk pont jól jött hogy a DynaTrace is támogatja a JVM monitorozását. A gc suspension time és a heap memória kihasználtság monitorozásához így összedobtunk egy DynaTrace-es dashboard-ot, az optimalizálás során pedig közel 90%-os GC suspension time csökkenést sikerült elérni, ami várakozási időben elég komoly javulást jelentett. (lásd az alábbi ábrákat)

Hiányzó IceFaces konfigurációs paraméterek

A DynaTrace beépített Exceptions nézetét használtuk fel, hogy a keretrendszeri és az alkalmazásokhoz tartozó kivételeket láthatóvá tegyük. Esetünkben a top 20-as listában jópár IceFaces-es kivétel keletkezett, melyek hiányzó web.xml konfigurációs paraméterekre voltak visszavezethetők!

Persze felmerülhet a kérdés, hogy milyen költséges lehet egy kivétel feldobása? Általában elhanyagolható, azonban a fenti esetben ez a kb. 10.000 IceFaces-es kivétel mindössze 10 perc alatt gyűlt össze, így egyértelműen javítani kellett! Amire érdemes odafigyelni, hogy nagy számú kivétel esetén a catch ágban elhelyezett kompenzációs logika valamint a több rétegen keresztül gyűjtögetett stack trace-ek kinaplózása okozhat még jelentősebb performancia problémát!

A folytatás hamarosan következik...

DynaTrace - Performancia problémák monitorozása

A performancia problémák analizálása mellett a DynaTrace kiválóan alkalmas a teljes rendszerünk monitorozására és az incidens alapú riasztások kialakítására is! A mostani bejegyzésben a lehetőségek részletes ismertetése helyett, inkább néhány olyan dashboard-ot fogok bemutatni aminek nagy hasznát vettem a SWAT-os problémák felkutatása során.

Ahhoz, hogy bizonyos jellemzőket (Measure) - pl. processzor kihasználtság, jvm heap használat, válasz idők, stb... - monitorozni tudjunk, fel kell rájuk iratkozni és ezután lehetőségünk van arra hogy a saját készítésű chart-oknál (több chart-ból képzett logikai egység a dashboard), incidens detektálásnál vagy a DynaTrace-es business transaction-oknál hivatkozzunk rájuk. A DynaTrace az alapértelmezett és a kiválasztott measure-ök adatait a Perfromance Warehouse-ban fogja eltárolni. Fontos megjegyezni, hogy ezek az eltárolt adatok csak aggregátumok, azaz a min, max, avg, sum és count értékek tárolódnak el a meghatározott időablakra nézve (10sec, de akár módosítható is a DynaTrace felületén).

Bejelentkező oldali válaszidők

Mivel a bejelentkezési oldal válaszideje eleinte eléggé problémás volt, ezért létrehoztunk egy measure-t a login.jsp válaszidejéhez és készítettünk hozzá 2 chartot amit egy dashboard-ban foglaltunk össze. A felső chart az adott időszakra nézett maximális, átlagos és a minimális válaszidőket tartalmazta az alsó chart pedig a login.jsp -re érkező kérések számát, azaz a terhelést. Amikor azt tapasztaltuk, hogy közel állandó terhelés mellett elkezdtek emelkedni a válaszidők, a dashboard-ról tovább tudtunk fúrni (drill down) az érintett PurePath-okhoz vagy a TransactionFlow-hoz, így gyorsan beazonosítottuk a problémás komponenseket és a megnövekedett válaszidők pontos okát.

 
Összegzett válaszidők alkalmazásonkénti lebontása

Mivel a konténerekben több web-alkalmazás is futott, ezért készítettünk egy olyan dashboard-ot, amivel a válaszidőket alkalmazások szerint lebontva (a web-kontext-root alapján) is tudtuk monitorozni. A lenti dashboard-on is látható, hogy volt néhány alkalmazás ami folyamatosan benne volt a top 5-ben, így az optimalizálást is értelemszerűen ezekkel kezdtük!

 
JMX és PMI alapú measure-ök létrehozása

A DynaTrace arra is ad lehetőséget, hogy a standard JMX-es (pl.:JBoss,Tomcat) vagy a WebSphere által használt PMI-s measure-ökre is feliratkozzunk, így többek között kinyerhetjük az AJP-s CurrentThreadBusy értékét aminek a folyamatos monitorozásáért egy saját készítésű Server Health Dashboard felelt.

Server Health Dashboard

Az alábbi dashboard 12 chart-ból lett összeállítva. Az első sorban, egy klaszterbe kötött 4 szerver-re érkező request-ek száma látható, ami kifejezetten hasznos volt amikor a load balancer-ek félreterhelését vizsgáltuk és egy újabb terhelés kiegyenlítő stratégiát kerestünk. A második sorban a jmx measure-ből kinyert AJP-CurrentThreadBusy értékeinek az alakulása látható a 4 szerver szerint eltérő színnel jelezve. Amikor valamelyik hátérrendszerrel problémák adódtak (pl. szinkronizációs hibák) az AJP-s Thread-ek hirtelen megemelkedése mindig azonnal jelezte a problémát. A harmadik sorban az egyes szerverekhez tartozó heap memória használatát monitoroztuk, ahol egy kis jvm tunning után egyből megjelentek a jól ismert fűrész fogak. A 4. sorban található chart-okkal pedig a szerverekhez tartozó CPU használatot és a request-ek szerverek közötötti eloszlását monitoroztuk.

PurePath-ok csoportosítása a JSESSIONID alapján

A DynaTrace-nek a business transaction koncepciója lehetőséget ad arra, hogy a számunkra fontos PurePath-okra szűrési feltételeket és csoportosításokat fogalmazzunk meg, majd az így kialakított BT-at saját chart-okon jelenítsük meg. Egy ilyen üzleti tranzakció volt a PurePath-ok jsessionid alapján történő csoportosítása, amit az alábbi képernyőkép szerint adhatunk meg a DynaTrace felületén.

A business transaction eredményét táblázatos formában is megtekinthetjük, ahonnan tovább szűrhetünk pl. a PurePathok irányába, így könnyen vissza tudtuk követni, hogy a felhasználók milyen műveleteket hajtottak végre egy-egy munkamenet során.

Az előbb ismertetett business transaction-hoz hasonlóan a HTTP Session userName alapján történő csoportosításhoz is készítettünk egy üzleti tranzakciót, így a help desk számára mindig értékes információkkal tudtunk szolgálni amikor valamelyik felhasználó kéréseit kellett visszakövetni egy adott időintervallumban.

A folytatásban a DynaTrace-el feltárt hibákból szemezgetek néhányat.

DynaTrace - Performancia problémák analizálása

A következőkben a performancia problémák analizálásához kapcsolódó dynaTrace-es dashboard-okat fogom bemutatni. Az analizálást sok hasznos feature is segíti, ilyen például a dashboardok közötti átnavigálhatóság, a hotspotok azonnali kijelzése vagy az időablak széleskörű állíthatósága. 

PurePaths

A PurePath-ok minden egyes kérésnek a teljes végrehajtási útvonalát tartalmazzák, (beleértve az RMI, WebService, JMS, EJB hívásokat) kontextus információkkal kiegészítve (naplók, kivételek, metódus argumentumok). Az alábbi példánál a kijelölt PurePath hívási láncán és a jobb oldali HotSpots panelon is könnyen beazonosítható, hogy a teljes végrehajtási időért a validateCreditCardNumber(String,int) metódus volt a felelős! Gondoljunk csak bele, hogy egy nagyobb rendszer esetén ezt mennyi idő lett volna megállapítani a hagyományos módszerek segítségével...

WebRequests

A WebRequests nézetnél megtekinthető, hogy milyen egyedi webes kérések (URI+Query String) érkeztek a kiválasztott időintervallumban. Ahogy a cikk elején említettem innen tovább fúrhatunk bármilyen irányba.

MethodHotspots

A method hotspots nézetből megtudhatjuk, hogy a kijelölt időszakban mely metódusok futása tartott a legtovább. Ez a nézet kiválóan alkalmas arra, hogy beazonosítsuk azokat a metódusokat amelyeken érdemes lesz optimalizálni. Ha további infóra lenne szükségünk, lefúrhatunk azokhoz a PurePath-okhoz is ahol a kiválasztott metódus meghívásra került. 

Methods

A metódus nézetnél többek között kideríthetjük, hogy melyik metódus hívódott meg a legtöbbször, mennyi volt a metódusok átlagos végrehajtási ideje vagy hogy összesen mennyi időt vett igénybe a végrehajtásuk.

WebServices, Messaging

A Web szolgáltatásokról és a Messaging-ről is begyűjthetünk néhány információt az ezekhez tartozó dashboard-oknál vagy a lefúrások során.

Logging, Exceptions

Az előbbiekhez hasonlóan a PurePath-okból kiindulva vagy az időablakra való szűkítéssel megnézhetjük a napló üzeneteket és a keletkezett kivételeket is. Feliratkozhatunk egy-egy számunkra érdekes kivételre, majd lefúrhatunk azokhoz a PurePath-okhoz ahol ez előfordult. Érdemes megemlíteni, hogy az alkalmazás belső működéséhez tartozó kivételek is kijelzésre kerülnek, de ezeket mint Business Exception-öket el tudjuk rejteni.

Transaction Flow

A Transaction Flow nézetből megtudhatjuk, hogy a PurePath-ok honnan indultak ki, milyen alrendszereken haladtak keresztül és hogy hol mennyi időt töltöttek el, azaz beazonosíthatjuk azokat a rendszereket amik a belassulásokért felelősek.

Nagyvállalati környezetben legtöbbször nincs a teljes rendszerre kiterjedő architekturális leírás, hiányosan vagy egyáltalán nincsenek ledokumentálva az alkalmazások közötti kapcsolatok és függőségek. Valószínűleg költséges lenne, de gondoljunk bele ha az összes rendszerre feltelepítenénk a dynaTrace ágenseit, a Transaction Flow segítségével automatikusan feltérképezhetnénk a rendszer teljes architektúráját. Sőt! Mivel a feltérképezés folyamatos, mindig naprakészek információink is lennének.

Annak ellenére hogy csak a fontosabb lehetőségekre tértem ki, így a cikk végére azt hiszem már körvonalazódik hogy mire is képes a dynaTrace. A folytatásban a dynaTrace-es performancia monitorozásról fogok blogolni.