A banki stabilizációs projekt keretében alkalmazott egyik nagyágyú a dynaTrace volt, aminek a megismeréséhez az első héten egy 3 napos dynaTrace core oktatáson vettünk részt, majd az előadó segítségével felkonfiguráltuk az éles környezethez a dynaTrace-t. Mivel kifejezetten hasznosnak bizonyult a performancia jellegű problémák beazonosításához, így a következő cikksorozatommal egy bevezetést fogok nyújtani a dynaTrace világába.
A nagyvállalati alkalmazásoknál gyakran előforduló jelenség, hogy a felhasználók a nagy válaszidőkre, instabil és bugos alkalmazásokra vagy éppen az időszakosan elérhetetlen rendszerekre panaszkodnak. Jobb esetben ilyenkor megtörténik a hiba bejelentése, majd a fejlesztőkhöz napokkal később eljut az általában hiányosan kitöltött hibariport akik elkezdik az alrendszerekhez tartozó napló állományokat bújni és időnként felkeresik az architekteket némi plusz információ reményében hogy megoldást találjanak a problémára.
Mi a gond ezzel a megközelítéssel?
Mi lenne a megoldás?
Egy olyan nézet, ahol is a felhasználók által végrehajtott összes műveletet teljes részletességgel real-time letudnánk követni. Azaz, hogy a kérések mikor és milyen rendszereken haladtak keresztül, az egyes alrendszereken belül milyen sorrendben milyen metódusok hívódtak meg és ezeknél mennyi időt töltött a végrehajtás. Igen, többek között pont erre lesz jó a dynaTrace! A dynaTrace egyik legnagyobb előnye, hogy ezen információk begyűjtéséhez sehol sem kell a kódhoz hozzányúlni, csupán egy JAVA/JVM vagy .NET/CLR argumentumot kell felvenni! Érdemes még megemlíteni, hogy a 2%-nál kevesebb overhead-nek köszönhetően éles környezetben is használható!
A dynaTrace architektúra
A dynaTrace egy performancia menedzsment és monitoring (APM) eszköz, amely lehetővé teszi a teljesítménybeli ill. stabilitási problémák analizálását és monitorozását, többrétegű heterogén (Support Matrix) rendszereken keresztül. Az egyedi felhasználói tranzakciók analizálása (7*24) a PurePath technológia segítségével történik, ami nem aggregált hanem a pontos értékekkel dolgozik.
A fenti ábrán egy piros vonal jelöli a PurePath-t, vagyis a felhasználó által indított tranzakciót (kérést) ami végighalad az alrendszereken keresztül. A dynaTrace a felhasználók minden egyes kéréséhez egy új PurePath-t fog elmenteni, amihez a hívási lánc, a pontos végrehajtási idők, kivételek, naplóbejegyzések, metódus argumentumok és visszatérési értékek is rögzítésre kerülnek.
A mérendő információk finomhangolásához szenzorokat definiálhatunk a szervereken. Minden szerverre egy-egy ágenst kell feltelepíteni, pl. Java esetében JVM argumentumon keresztül. Az ágensek, az általuk összegyűjtött információkat a PurePath Collector-nak adják tovább. A PurePath kollektorok nem végeznek semmilyen feldolgozást, csupán az ágensek adatait fogadják és továbbítják a dynaTrace Server felé ahol is begyűjtött információk tényleges feldolgozása történik. A dynaTrace Analysis Server feladata a begyűjtött heap dumpok feldolgozása, a Perfromance Warehouse pedig a historikus adatokat tárolásáért felel. A rögzített adatok monitorozásához és analizálásához a dynaTrace Client-el csatlakoznunk kell a dynaTrace Server-hez.
Lassan már 4 hónapja használom a dynaTrace-t és ezalatt az idő alatt sikerült kiismernem a lehetőségeit és korlátait is, így ha bármilyen kérdésed lenne a dynaTrace-el kapcsolatban, ne tartsd magadban hanem dobj meg egy kommenttel!
A dynaTrace-es kalandozás nemsokára folytatódik...
A nagyvállalati alkalmazásoknál gyakran előforduló jelenség, hogy a felhasználók a nagy válaszidőkre, instabil és bugos alkalmazásokra vagy éppen az időszakosan elérhetetlen rendszerekre panaszkodnak. Jobb esetben ilyenkor megtörténik a hiba bejelentése, majd a fejlesztőkhöz napokkal később eljut az általában hiányosan kitöltött hibariport akik elkezdik az alrendszerekhez tartozó napló állományokat bújni és időnként felkeresik az architekteket némi plusz információ reményében hogy megoldást találjanak a problémára.
Mi a gond ezzel a megközelítéssel?
- A problémák egyértelmű beazonosításához nem áll minden információ a rendelkezésünkre vagy ha igen, akkor túl sokáig tart a kinyerésük.
- Nagyvállalati rendszerek esetén a felhasználók kérései több rendszeren is keresztülhaladnak ezért a belassulások, stabilitási problémák és a hibák beazonosítása kifejezetten nehéz feladat. A felderítés során leginkább a napló állományokra támaszkodhatunk, amik az egyes rendszereknél elszórva (nem központosítva) helyezkednek el.
- A naplóállományok egyenkénti átnézése sok időt vehet igénybe és legtöbbször pont a számunkra fontos kontextus információk hiányoznak belőle.
- Mivel a problémákra nem tudunk egyből reagálni, romlik a felhasználói elégedettség és csökken az üzleti teljesítőképesség is.
Mi lenne a megoldás?
Egy olyan nézet, ahol is a felhasználók által végrehajtott összes műveletet teljes részletességgel real-time letudnánk követni. Azaz, hogy a kérések mikor és milyen rendszereken haladtak keresztül, az egyes alrendszereken belül milyen sorrendben milyen metódusok hívódtak meg és ezeknél mennyi időt töltött a végrehajtás. Igen, többek között pont erre lesz jó a dynaTrace! A dynaTrace egyik legnagyobb előnye, hogy ezen információk begyűjtéséhez sehol sem kell a kódhoz hozzányúlni, csupán egy JAVA/JVM vagy .NET/CLR argumentumot kell felvenni! Érdemes még megemlíteni, hogy a 2%-nál kevesebb overhead-nek köszönhetően éles környezetben is használható!
A dynaTrace architektúra
A dynaTrace egy performancia menedzsment és monitoring (APM) eszköz, amely lehetővé teszi a teljesítménybeli ill. stabilitási problémák analizálását és monitorozását, többrétegű heterogén (Support Matrix) rendszereken keresztül. Az egyedi felhasználói tranzakciók analizálása (7*24) a PurePath technológia segítségével történik, ami nem aggregált hanem a pontos értékekkel dolgozik.
A fenti ábrán egy piros vonal jelöli a PurePath-t, vagyis a felhasználó által indított tranzakciót (kérést) ami végighalad az alrendszereken keresztül. A dynaTrace a felhasználók minden egyes kéréséhez egy új PurePath-t fog elmenteni, amihez a hívási lánc, a pontos végrehajtási idők, kivételek, naplóbejegyzések, metódus argumentumok és visszatérési értékek is rögzítésre kerülnek.
A mérendő információk finomhangolásához szenzorokat definiálhatunk a szervereken. Minden szerverre egy-egy ágenst kell feltelepíteni, pl. Java esetében JVM argumentumon keresztül. Az ágensek, az általuk összegyűjtött információkat a PurePath Collector-nak adják tovább. A PurePath kollektorok nem végeznek semmilyen feldolgozást, csupán az ágensek adatait fogadják és továbbítják a dynaTrace Server felé ahol is begyűjtött információk tényleges feldolgozása történik. A dynaTrace Analysis Server feladata a begyűjtött heap dumpok feldolgozása, a Perfromance Warehouse pedig a historikus adatokat tárolásáért felel. A rögzített adatok monitorozásához és analizálásához a dynaTrace Client-el csatlakoznunk kell a dynaTrace Server-hez.
Lassan már 4 hónapja használom a dynaTrace-t és ezalatt az idő alatt sikerült kiismernem a lehetőségeit és korlátait is, így ha bármilyen kérdésed lenne a dynaTrace-el kapcsolatban, ne tartsd magadban hanem dobj meg egy kommenttel!
A dynaTrace-es kalandozás nemsokára folytatódik...
Nagyon jó bevezető cikk!
VálaszTörlésRengeteg kérdésem lenne, de a két legfontosabb:
- Mennyibe kerül?
- Hogyan rendeli össze a különböző hívásokat, pl. egy böngésző klikket egy EJB metódushívással egy web service hívással és a végén egy adatbázis lekérdezéssel. Mi alapján tudja ezeket összerendelni? Valami varázslat, vagy neked is kell támogatnod benne?
Köszi! Nyugodtan kérdezzetek, bár a köv. DynaTrace-es cikkeimből szerintem átfog jönni a lényeg.
VálaszTörlés* A licence-t JVM-enként lehet megvásárolni. Mivel éles környezetben használjuk, a bank a Production Edition-t vette meg, aminek az ára milliós(HUF) nagyságrendben mozog.
* Ezért a PurePath technológia a felelős. A belépési pontnál generál egy egyedi azonosítót, amit tovább passzolgat a hívások során. A teljes PurePath összerakását pedig a kollektorok által begyűjtött adatokból a DynaTrace szerver végzi el.
Kliens oldalon egyébként egy JavaScriptet szúr be az oldalakhoz a felhasználói interakciók követéséhez (DynaTrace UEM feature - külön licence).
Mennyire szól bele a mérési adatokba az a tény, hogy (Heisenberg szavaival élve) egyszerre vagyunk szemlélői és résztvevői az eseményeknek?
VálaszTörlésA dynaTrace architektúra ábráját megnézve látható, hogy a dynaTrace kliens (amivel figyeljük az eseményeket) a dynaTrace szerverhez kapcsolódik nem pedig közvetlenül a jvm-ekhez. Így a szemlélő nincs befolyásoló hatással a mérési eredményekre!
TörlésArchitekturalisan igen, gyakrolatilag azonban a dynaTrace kliens mindenkeppen kommunikal a JVM-mel (informaciot nyer ki belole), ezzel valamilyen hatast biztos kifejt a JVM-re (bizonyos mertekig lassitja).
TörlésAz információkat az ágensek nyerik ki, csak ezek vannak hatással a JVM-re, az overhead a cikkben leírt kb. 2% konstans (ennek az okairól a köv. cikkben fogok írni), a DynaTrace kliens közvetlenül nincs hatással a performanciára mivel csak a begyűjtött adatokat olvassa ki a szervertől!
TörlésSzia nagyon jó bevezető. Engem az érdekelne, hogy azok a cégek akik bedolgoznak a banknak milyen formában tudják megvizsgálni az outputokat. Ezalatt azt értem, hogy nyilván ha fizetős akkor nem minden cég tudja megvenni a dynatrace klienst vagy az ingyenes?
VálaszTörlésOff: kaja még mindig ugyanolyan jó? :)
Amikor a DynaTrace-el felderítünk egy problémát akkor kiszoktuk exportálni az ehhez tartozó session-t, ami a problémás PurePath-okat és az ezekhez tartozó a kontextus információkat jelenti. Ezt oda tudjuk adni a fejlesztőknek vagy a külsős cégeknek, így az ingyenesen elérhető DynaTrace klienssel megvizsgálhatják ezeket.
VálaszTörlésEsetleg érdemes megfontolni a DynaTrace Development Edition beszerzését, ami alkalmas a PurePath-ok realtime analizálására a fejlesztési időben (monitorozásra nem). Ennek a licencelése jóval kedvezőbb.
Igen, a kaja még mindig nagyon jó! A bank nevét szándékosan nem említettem, de úgy látszik páran már ki is találtátok... :)