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