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.
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.
Nincsenek megjegyzések:
Megjegyzés küldése
Megjegyzés: Megjegyzéseket csak a blog tagjai írhatnak a blogba.