2012. május 8., kedd

DynaTrace - Performancia menedzsment felsőfokon!

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

    8 megjegyzés:

    1. Nagyon jó bevezető cikk!
      Rengeteg 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?

      VálaszTörlés
    2. Köszi! Nyugodtan kérdezzetek, bár a köv. DynaTrace-es cikkeimből szerintem átfog jönni a lényeg.

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

      VálaszTörlés
    3. 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és
      Válaszok
      1. A 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és
      2. Architekturalisan 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és
      3. Az 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és
    4. Szia 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?
      Off: kaja még mindig ugyanolyan jó? :)

      VálaszTörlés
    5. 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.

      Esetleg é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... :)

      VálaszTörlés

    Megjegyzés: Megjegyzéseket csak a blog tagjai írhatnak a blogba.