Rendszerintegráció és -felügyelet

Átírás

1 Rendszerintegráció és -felügyelet labratórium (VIMIM309) Rendszerfelügyelet támgatása kmplexesemény-feldlgzással Mérési segédlet Készítette: Bergmann Gábr, Dávid István Utlsó módsítás: február 18. Verzió: 1.1 Budapesti Műszaki és Gazdaságtudmányi Egyetem Méréstechnika és Infrmációs Rendszerek Tanszék

2 1 Bevezető A labr srán a méréseket végző hallgató a gyakrlatban is megismerkedik a rendszerintegráció és rendszerfelügyelet srán használats módszerekkel és eszközökkel. Végigköveti egy elszttt alkalmazás megvalósításának és felügyeletének legfntsabb lépéseit, ipari környezetben használt integrációs köztes réteg (middleware) technlógiák és felügyeleti eszközök használatával. A mérések a következő témakörökhöz kapcslódnak: 1. Munkaflyamatk megvalósítása Java nyelven 2. Megbízható üzenetküldés IBM WebSphere MQ alapn 3. Kmmunikáció JMS és JMX technlógia segítségével 4. OSGi szlgáltatásk fejlesztése 5. Mdell alapú eszközintegráció elszttt környezetben (SDE) 6. Felügyeleti adatk vizuális elemzése 7. Rendszerfelügyelet támgatása kmplexesemény-feldlgzással A mérések egy részén a hallgatók különféle elszttt szlgáltatásintegráció megldáskkal valósítják meg egy példarendszer üzleti lgikáját. A jelen mérés srán a megvalósítás helyett a felügyelet lesz fókuszban: szabályalapú frmalizmussal kell a krábban elkészült üzleti flyamat futását felügyelni, a JBss Drls Fusin terméke segítségével. A vizsgált rendszer felműszerezésének hatására futás közben eseményflyam keletkezik. A ha akkr jellegű deklaratív szabálykból álló mnitring rendszer ebben kereshet kmplex, időhöz kötött összefüggéseket. A hallgatók elsajátíthatják a kmplex események szabály alapú feldlgzásának alapelveit, és megismerkedhetnek az üzleti flyamatk felügyeletével. 2 Háttérismeretek 2.1 A kmplexesemény-feldlgzás alapfgalmai Az infrmatikai infrastruktúrákban, alkalmas mnitrzó megldáskat használva megfigyelhetővé válnak az erőfrrás szintű diagnsztikai események. Ilyen erőfrrás szintű esemény lehet például a következő: a szerver prcesszrának terheltsége eléri a kritikus értéket. Az események feldlgzásával lyan infrmációkat állíthatunk elő, amelyek vezérlési, döntési helyzetekben jól hasznsíthatóak. Az infrmációk kinyerésének alapja az eseményflyamn (event stream) értelmezett mintafelismerés. Az atmi esemény egy adtt frrásból származó primitív adategység a frrás mérhető paramétereiről hrdz infrmációkat. A gyakrlatban jellemző, hgy a releváns minták túl összetettek ahhz, hgy egyetlen atmi esemény le tudja írni azkat, így leírásukhz több atmi eseményt kell felhasználni, lgikailag összekapcslni ezt az összekapcslást nevezzük kmplex eseménynek, feldlgzási technikáját pedig kmplexesemény-feldlgzásnak (CEP cmplex event prcessing). (Kmplex esemény például a következő: az SLA-t veszélyezteti, ha az adatbázis szerveren a prcesszr terheltsége a kritikus szint körül van huzamsabb ideig, miközben a tartalék szerveren a diszk megtelt. ) Az egyes mintákhz végrehajtható szekvenciák, ún. akciók társíthatók, amelyek lefutását a minta felismerése váltja ki (trigger). A kmplex esemény tehát egy lyan struktúra, ami (i) atmi eseményekből, (ii) az atmi események közti lgikai, algebrai, ill. időbeli kapcslatkból, valamint (iii) a felismert eseményminták hatására végrehajtódó akciókból épül fel. 2

3 1. ábra A kmplex események atmi eseményekből épülnek fel, amelyek között algebrailag frmalizálható kapcslatkat definiálnak. Az atmi események közti kapcslatk alatt lyan fgalmakat értünk, mint srrendiség definiálása, időbeliség megkötése (például időablakk segítségével), az események előfrdulásának számssága, stb. (Ilyen alkalmas algebrai frmalizmust definiál az Event Detectin Algebra 1 és az Allen-féle intervallum algebra 2.) 2. ábra Az eseményflyamn e1, e2, e3 és e4 események érkeznek adtt időpillanatkban. Fel kell ismerni, ha két e1 esemény után két e2 következik 20 másdpercen belül. A minta srrendezés, számsság és időzítés dimenziók segítségével írható le. Fnts megkülönbözetetni pnt- és intervallum típusú eseményeket, mert az egyes típusknak másmás tulajdnságai definiáltak, így a köztük értelmezett algebrai perátrk is eltérőek lehetnek. Például a JBss Drls Fusin eseményfeldlgzó a következő ábrán részletezett temprális perátrkat definiálja az egyes típusk között: 1 James F. Allen, "Maintaining knwledge abut tempral intervals," Cmmunicatins f the ACM, vl. 26 Issue, n.11, pp , Nvember Jan Carlsn, "An Intuitive and Resurce-Efficient Event Detectin Algebra",

4 3. ábra A JBss Drls Fusin által definiált temprális perátrk. 2.2 Mikr célszerű a kmplexesemény-feldlgzás alkalmazása? Bár a mérés srán rendszerfelügyeleti feladatkat ldunk meg a CEP segítségével, maga az elv és a kapcslódó technikák más szakterületeken is jól bevált megldásnak számítanak. Klasszikus alkalmazási terület például az algritmikus kereskedés (algrithmic trading), az nline csalásk felderítése (fraud detectin), vagy a rendszerbiztnsági mnitrzás (security mnitring). Az összes alkalmazási terület sajátssága, hgy nagyszámú, elsztttan és egymástól függetlenül működő erőfrrás, vagy ágens eseményeit szükséges feldlgzni, mert feltételezzük, hgy az események kmbinált vizsgálata lyan új infrmációkat állít elő, ami üzletileg releváns; mindezt pedig alacsny késleltetéssel szükséges végrehajtani. (Az algritmikus kereskedés esetében eseményflyam lehet például a részvények árflyamának idősra. Mivel jellemzően nem egy típusú részvénnyel szkás kereskedni, hanem prtfóliókba szervezve több különböző értékpapírral, ezért nem egyértelmű, hgy egy adtt részvény értékének megváltzásakr szükséges-e adás-vételi akciót indítani, vagy sem. A döntéshez prtfólió szinten kell ptimalizálni, amihez a többi értékpapír váltzását is figyelembe kell venni, a számításkat pedig a lehető leggyrsabban szükséges végrehajtani erre a CEP egy tökéletes megldás lehet. 3 ) 2.3 Az eseményfeldlgzás technikai aspektusai, eseményfeldlgzó platfrmk Az eseménymintákat egy eseményfeldlgzó platfrm megfelelő leírónyelvének segítségével definiáljuk, amelynek bemenete az eseményflyam. A nyílt frráskódú platfrmk közül a két legeltejedtebb a JBss Drls Fusin, valamint az Esper. Emellett természetesen minden nagy gyártó rendelkezik saját implementációval: IBM InfSphere Streams (krábban: System-S), Oracle CEP, Micrsft StreamInsight, TIBCO BusinessEvents, StreamBase CEP. A mérés srán használt Drls Fusin intuitív, szabály alapú szintakszist nyújt a minták és akciók leírásáhz (LHS RHS); de akadnak lyan platfrmk is, amelyek SQL-szerű nyelvet használnak a minták definiálásáhz (az eseményflyamt query-zik ), a végrehajtandó szekvenciákat pedig update listener sztálykban tárlják ilyen elven működik például az Esper. Az eseményeket az erőfrrás maga is publikálhatja, vagy ha erre nincs felkészítve, a mnitrzó keretrendszer szlgáltatásai biztsítanak számára ilyen jellegű képességet. Mivel a gyakrlatban rövid idő alatt nagyszámú esemény keletkezhet, praktikus kkból az események nem tárlhatóak krlátlan ideig. Az eseményfeldlgzó platfrm egyik feladata az események életciklusának kezelése, hgy az elavult, régi események ne terheljék tvább a mnitrzó eszközt

5 4. ábra A mnitrzó ágensek a kmmunikációs csatrnára tvábbítják az erőfrrásk eseményeit, amit az eseményfeldlgzó platfrm értelmez és a megfelelő akciókat végrehajtja. 2.4 Egy CEP feladat megvalósításának tipikus lépései Egy feladat CEP segítségével történő megldása tipikusan a következő fáziskat érinti. 1. A megfigyelt rendszer felműszerezése. Ezzel biztsítjuk, hgy a rendszerben valóban lesznek megfigyelhető események. 2. A releváns eseményminták meghatárzása. Az üzleti célkat (business gals) figyelembe véve meghatárzzuk a releváns eseménymintákat. A minták a megfigyelhető események attribútumaira írnak elő matematikai, lgikai megkötéseket. 3. Az eseményminták leírása valamely platfrm által kínált leírónyelv segítségével és telepítés. Az eseményminták attribútumait ezen a szinten már knkrét értékekkel, számszerűsítve szükséges megadni. Ezzel előáll az eseményknfiguráció, amelyet a feldlgzó platfrm értelmezni tud. 4. Feldlgzás. 3 A JBss Drls Fusin technlógia A JBss Drls szabályalapú technlógiai platfrm részét képezi a Fusin eseményfeldlgzó. Az alábbiakban a krábbi félévben már felhasznált - Drls Expert szabályvégrehajtó mtr ismétlő jellegű áttekintése után bemutatjuk a Drls Fusin főbb elemeit. A jelen segédletben leírtakn túl erősen ajánltt az n-line JBss Drls dkumentáció használata. 3.1 Ismétlés: Drls Expert alapismeretek A Drls platfrm közpnti szerepű mdulja az Expert üzleti szabály végrehajtó rendszer (business rule engine). Tartalmazza a szabályleíró nyelv(ek)et, a végrehajtó szabálymtrt a megfelelő prgramzói interfészekkel, tvábbá az Eclipse alapú fejlesztőkörnyezetet. A Drls terminlógiában a tudásbázis (Knwledge Base) a szabályk definícióiból áll (és egyéb elemekből, pl. flyamatleírás). Tényleges szabályvégrehajtáshz ezért kérni kell egy úgynevezett sessint a tudásbázisból, amely már tartalmazni fg ténybázist, így beszúrhatóak üzleti bjektumk és tüzelhetnek szabályk. Egy tudásbázis fölé több független sessin is nyitható egyszerre. A Drls által kínált kétféle sessin közül a mi céljainknak az állapts (stateful) sessin fg megfelelni, ezért a tvábbiakban csak ezzel fglalkzunk. Itt van valódi munkamemória (wrking memry, WM), amelybe beszúrhatóak, ill. kivehetőek (POJO) tények. Ha a munkamemória tartalma alapján egy prdukciós szabály minden feltétele ki van elégítve, akkr a szabály aktivált. Mivel a feltételrészben jellemzően szabad (lekötetlen) váltzók vannak, a feltételeket valójában ezen váltzók egy knkrét lekötése (behelyettesítése) elégíti ki; ezeket a kielégítő behelyettesítéseket nevezzük aktivációnak (activatin), és a váltzók knkrét értékeiből frmált tuple ( n-nes ) aznsítja őket. A váltzók egy 5

6 knkrét behelyettesítése vagyis az aktiváció alapján a szabálypéldány tényleges végrehajtása a tüzelés (firing). Az összes érvényes aktiváció halmaza a napirend (agenda vagy cnflict set), ezek közül kell kiválasztani a tüzelendőt. A WM feltöltése után után meghívható a fireallrules() metódus, amely iterálva (előre lánclással) hajtja végre a szabálykat, flyamatsan módsítva közben a WM tartalmát (a napirendet is karbantartva); akkr tér vissza a metódus, ha nincs már tüzelhető szabály. Ezek után a WM kívülről tvább módsítható, majd újra hívható a fireallrules(), stb. Mivel a Drls is inkrementális mintaillesztőt használ, az agenda frissítéséhez szükséges értesülnie a WM váltzásairól. A WM-be beszúrást és törlést természetesen a Drls API-jain keresztül bnylítjuk, ezért ez nem kz gndt. Az bjektumk módsítása aznban Java környezetben nem detektálható egyszerűen, ezért ezt a Drls számára jelezni kell valamilyen módn. A megldás az bjektum beszúrásakr az insert() metódustól visszakaptt FactHandle referencia, melyen keresztül értesíthető a Drls Engine a módsításról, hgy újralvashassa az bjektum attribútumait. Szerencsére a leggyakribb esetben, a szabály akció részében történő módsításk esetén ennél elegánsabb megldás is van (ld. később). Egy nagyn egyszerű Drls-s prgramnak definiálnia kell az üzleti bjektumk adatmdelljét; ez Java sztálykat jelent, amelyek a JavaBean knvenciókhz igazdnak, pntsabban getxxx() és setxxx() metóduskn keresztül attribútumkat kínálnak fel (az bjektumk mezői a Drls számára nem láthatóak). Ezen felül szükség van a szabálykat definiáló fájlra (alapesetben.drl frmátumban). A keretprgram a szabálydefiníciós fájl alapján felépíttet egy Drls tudásbázist, majd kér egy állapts sessint a newstatefulknwledgesessin() metódussal. A sessin WM-jébe insert() metódussal elhelyezi a kezdeti üzleti bjektumkat, majd meghívja a fireallrules() metódust. Az IDE varázslója által generált Hell Wrld prjekt haszns példát szlgáltat a Drls Expert API megismeréséhez. 3.2 Ismétlés: Drls Expert szabálynyelv A szabályk definiálására a Drls alapértelmezetten a DRL szöveges nyelvet használja; a tvábbiakban csak ezzel a frmátummal fglalkzunk. A szabálydefiníciót a rule kulcsszó vezeti be, amelyet a szabály idézőjelek közé tett neve követi. Ezek után igény szerint a szabály működését beflyásló pciók specifikálhatóak. A szabály két legfntsabb része a when kulcsszó után következő feltételrész és a then kulcsszó után megadtt akciólista. A szabálydefiníciót end zárja. Példaként nézzük meg két Drls szabályt! rule "GdBye" when MessageBx( status == MessageBx.GOODBYE, mymessage : message ) then System.ut.println( mymessage ); end rule "Cukrz" when $szilva: Szilva () $pult: KnyhaPult (tartalm cntains $szilva) nt Object (this memberof $szilva.tartalm) ## ures a szilva then KckaCukr $cukr = new KckaCukr(); insert($cukr); mdify($szilva) { berak($cukr); } end A feltételrészbe leggyakrabban bjektumminták kerülnek, pcinális attribútum-krlátzáskkal; utóbbiakhz a hagymánys összehasnlításkn (pl. ==, <) kívül Drls-specifikus perátrk is elérhetőek, pl. halmaz-elem viszny vizsgálatára (cntains/memberof a fenti példakódban). Az bjektumk ill. attribútumaik a kettőspnt perátrral felfghatóak váltzóba (amelynek gyakran de 6

7 nem kötelezően dllárjellel kezdődő nevet adnak), és a váltzó hivatkzható lesz a feltétel ág többi részében ill. a következményrészben. Tvábbi kényszerfeltételek eval kifejezésben adhatóak meg. A feltételrészben szereplő feltételek (bjektumminta, eval) alapértelmezésben és-kapcslatban állnak, de and és r perátrkkal ill. zárójelekkel ez beflyáslható. Nagy a jelentősége a nt kvantrnak, amely az utána következő feltétel (vagy feltételek zárójelezett összessége) kielégíthetetlenségét mndja ki, vagyis: nincsenek lyan elemek a WM-ben, amelyek megadtt típusúak és megadtt visznyban állnak egymással és a többi bjektummal. Hasnló az exists kvantr, amely egzisztenciális jelleggel kielégíthetőséget mnd ki; ha egy feltétel elé helyezzük, akkr nem fg számítani, hányféleképpen elégíthető ki a feltétel, csak hgy kielégíthető-e. Végül a frall kvantr azt mndja ki, hgy az első feltételt kielégítő bármely elemekre a tvábbi feltételek is kielégíthetőek. A hárm kvantr valamelyikének hatáskörén belül megkötött Drls váltzó a hagymánys kvantr szemantikának megfelelően nem látszik ki a kvantrn kívülre. A fenti példában megfigyelhető a nt kvantr alkalmazása. A kvantrkhz hasnló működésű az akkumuláció, amelyre a kmplexesemény-feldlgzásban különösen gyakran van szükség. Az akkumuláció a megadtt feltételeket kielégítő összes váltzóbehelyettesítésből aggregál egyetlen értéket. Az aggregátr függvények listája kiterjeszthető, de a legfntsabb esetek (average, min, max, sum, cunt, ) támgatása beépített. A Drls dkumentációban szereplő alábbi példa azt mutatja be, hgyan lehet azn rendeléseket kiválasztani, amelyeknek a tételei 100 fölötti összértékűek. $rder : Order() $ttal : Number( dublevalue > 100 ) frm accumulate( OrderItem( rder == $rder, $value : value ), sum( $value ) ) Amint a példakódk is mutatják, az akció blkkba egyszerű Java utasításk írhatóak; ezen felül a Drls biztsít néhány különleges műveletet. Az insert(bj) és retract(bj) parancsk a paraméterül kaptt bjektumt beszúrják ill. kiveszik a WM-ből. Az insertlgical(bj) lgikai beszúrást hajt végre, amely visszavnódik, ha a szabály feltételrésze később érvényét veszti. A krábban tárgyalt kk miatt az attribútumk manipulációja (vagy ilyen hatással járó metódushívásk) után update(bj) hívandó, hgy a Drls is értesülhessen a váltzásról. Ennek egy elegánsabb alternatívája a mdify(bj){metódus1(),..., metódusk();} blkk, amelynek a végén ez autmatikusan megtörténik; a blkkn belül pedig az bjektum metódusai kényelmesebben hívhatóak, bj. prefix nélkül. Nem beszéltünk még a szabály pcióiról, amelyeket a when kulcsszó előtt lehet megadni. Az egyik legfntsabb pció a salience, amelyet egy egész szám követ. A megadtt szám lesz a szabály priritása (alapértelmezésben 0), és több aktivált szabály esetén a legmagasabb priritású fg tüzelni. Egy másik fnts pció az alapértelmezésben hamis értékű n-lp. Vlt már arról szó, hgy a szabálypéldány végrehajtásakr a saját aktivációja autmatikusan eltűnik az agendáról, hgy azk a szabályk se kerüljenek végtelen ciklusba, amelyek nem érvénytelenítik saját előfeltételeiket. Ha aznban az érintett szabály módsítja a feltételrészében szereplő valamelyik bjektumt, akkr a Drls újra észleli az aktiváció érvényességét és visszateszi az agendára. Ez kerülhető el n-lp true megadásával. Tartsuk észben, hgy a több szabályn keresztül lezajló kölcsönös rekurzió ellen ez sem hatáss. Szabálycsprtk definiálása (ruleflw-grup) után a lck-n-active pció azt garantálja, hgy amíg a csprt aktív, a szabály nem aktiválódhat többször. A legáltalánsabb megldás az, ha minden szabály valamilyen módn érvényteleníti saját aktivációját (pl. kckacukrt tesz a szilvába, amely így már nem lesz üres). A nyelv részletesebb, pntsabb, példákban gazdagabb leírása az nline dkumentációban lvasható. 3.3 Ismétlés: Drls fejlesztőkörnyezet és hibakeresés A Drls Eclipse-be épülő fejlesztői környezetet biztsít. A szabálydefiníciós fájlkhz fejlett editr támgatás tartzik (pl. környezetérzékeny kódkiegészítés), ezen kívül prjekt varázslóval létrehzhatóak Hell Wrld jellegű prjektek (a tudásbázist felépítő kódt innen célszerű eltanulni). 7

8 A fejlesztőkörnyezet legfntsabb feladata a hibakeresés támgatása. Ehhez a tevékenységhez nagyn fnts segítséget nyújt az Audit nézet (Windw > Shw View > Other > Drls > Audit), ahl visszamenőleg áttekinthetőek a végrehajttt szabálypéldányk, az elvégzett WM módsításk, és a hatásukra megjelent vagy megszűnt aktivációk. Ehhez aznban be kell kapcslni a lgglást, majd az Audit nézetet az elkészült lg fájlra irányítani. A lgglás a sessin létrejötte után bekapcslható a KnwledgeRuntimeLggerFactry.newFileLgger(sessin, "lgfileneve.lg") hívással. A visszakaptt KnwledgeRuntimeLgger bjektum a prgram befejeződésekr lezárandó (clse()). Ha töréspntnál (pl. a fireallrules() hívás előtt, vagy egy Drls szabály RHS részében) megállítjuk a prgramunkat, akkr tvábbi infrmációkat kaphatunk a pillanatnyi állaptról. Az Agenda nézet a cnflict set tartalmát mutatja, a Wrking Memry pedig értelemszerűen a WM-beli tényeket. Ha Java töréspntnál állunk meg, akkr a Drls debug környezetnek nincs tudmása a futó Drls BRE példányról, ezért először a Java debugglásnál megszktt Variables nézetben ki kell jelölni a Drls sessint, és csak ezután töltődnek fel a Drls debug nézetei tartalmmal. Ha aznban egy szabály akció részében elhelyezett töréspntnál állunk meg, akkr aznnal használhatóak ezek a nézetek, és a Variables nézet a Drls váltzókat mutatja. A szabály RHS-ben elhelyezett töréspntk csak akkr működnek, ha a prgramt Java Applicatin helyett Drls Applicatinként indítjuk, debug módban. 3.4 Drls Fusin események A Drls Expert alapelemeihez képest a Fusin legfntsabb kiterjesztése az esemény fgalma. Az esemény egy speciális, időpecséttel elláttt ténybjektum a munkamemóriában, amely a megfigyelt rendszer valamely elemi jelenségéről tájékztat, tehát egy alapvető állaptváltásról vagy tevékenységről. (Nem keverendő a kmplex esemény fgalmával, amely egy vagy több elemi esemény és esetleg egyéb tények kapcslatát vizsgáló Drls minta.) Események esetén különleges elvárás / knvenció, hgy ha egy attribútumt egyszer beállítttunk nulltól különböző értékre, akkr nnantól nem szkás már megváltztatni hiszen az esemény már megtörtént. Ellenben kifejezetten támgattt viselkedés, hgy biznys mezőket az esemény beszúrásakr üresen hagyjunk, és később Drls szabályk által töltsünk ki. A Drls Fusin pntszerű és időintervallum jellegű eseményeket is támgat. Így az eseménykezdetet jelző időbélyeg mellett pcinálisan időtartam is megadható (ennek hiányában pntszerű az esemény, vagyis időtartam=0). Mindkét időparamétert az eseménybjektum egy-egy mezőjéhez kell rendelni; ennek megfelelően eseménytípusnként egy alábbihz hasnló deklarációt kell tenni: declare event ) ## ez jelzi, hgy eseményt reprezentál az inditasdatuma ) ## időbélyeg attribútum elteltid ) ## hssz attribútum neve 4m30s ) ## minimálisan elvárt élettartam, ld. később (pcinális) end Amennyiben egy esemény bjektumban beszúráskr az időbélyeg kitöltetlen, a Drls autmatikusan beállítja a jelenlegi időt. Az ilyen módn definiált eseménykezdet és befejezés alapján vizsgálhatóak majd a két esemény között fennálló intervallumlgikai feltételek (ld. 2.1 szakasz) a szabályk feltételrészében. Példaként nézzünk meg egy feltételrészt: $bru: Uzemmd(uzemAllapt == Brú ) exists Uzemmd(uzemAllapt == Derű, this after[6s, 2m30s] $bru) Ez a feltétel a Brú üzemmód fennállásáról értesítő eseményekre akkr illeszkedik, ha jön még rá (legalább hat másdperccel, legfeljebb két és fél perccel a Brú befejezte után kezdődő) Derű. A temprális perátrk (intervallumlgikai visznyk) teljes listája a dkumentációban található; néhányat már láthattunk illusztrálva (2.1 szakasz 3. ábra). 8

9 3.5 Eseményflyam mód (STREAM mde) Az események intervallumlgika alapján történő összekapcslhatósága révén lehetővé válik az eseménynaplók ffline feldlgzása. Az nline eseményfeldlgzást (vagyis amikr valós időben történő eseményflyamról van szó) támgató tvábbi szlgáltatásk aznban csak egy speciális végrehajtási mód bekapcslása után lesznek elérhetőek. A Drls végrehajtó mtr STREAM módban történő futtatásáhz a tudásbázis knfigurációját ennek megfelelően kell beállítani: kcnfig.setoptin(eventprcessingoptin.stream); Az eseményflyam mód esetén be kell tartani az időrendi követelményt, vagyis az eseményeket csak az időbélyegeik srrendjében szabad beszúrni (ha nem töltjük ki kézzel az időbélyeget, az autmatikusan garantált). Ezért cserébe száms szlgáltatást nyújt a rendszer az ún. eseményflyam-óra segítségével. Ezen óra értékét tekinti a Drls a jelenlegi pillanatnak (ezért tesztelési célból a valós óra helyettesíthető manuálisan léptetett órával); például ezen óra alapján dátumzza a kitöltetlen időbélyeggel beszúrt esemény bjektumkat. Eseményflyam módban a Drls az óra alapján autmatikusan késlelteti biznys feltételek kiértékelését, amíg azkhz jövőbeli eseményekre lenne szükség, hiszen nem feltételezi, hgy nem fgnak a jövőben ilyen események beérkezni. Például az alábbi feltétel azn határzatkra illeszkedik, amelyekre 15 napn belül egy fellebbezés se érkezett; a Drls STREAM módban kivárja a 15 napt, mielőtt a mintát egy határzatra illeszkedőnek tekinti. $h : Hatarzat() nt( Fellebbezes(hatarzat == $h, this after[0d,15d] $h ) ) Eseményflyam módban lehetőség nyílik ún. csúszóablakkat használni. Az bjektumminta végéhez hzzáfűzött ver windw:time(időtartam) ill. ver windw:length(darabszám) megszrítással az bjektummintára illeszkedő események közül a (idő, darabszám szerinti) legutóbbiak választhatók ki. (Vegyük észre, hgy az utóbbi öt percben fgalm (időablak) az óra révén válik a Drls számára értelmezhetővé.) Az alábbi minta például akkr illeszkedik, ha az utóbbi 30 bejelentkezés közül egy se sikeres: nt( $la: LginAttempt($s: success) ver windw:length(30) eval ($s == true)) A darabszám szerinti időablaknál különösen figyeljünk da, hgy csak a ténybjektum sztálya és az esetleges knstans értékre lekötött mezői tartznak hzzá az ablak definíciójáhz, a többi szűrőfeltétel csak a darabszám szerinti ablaklás után lesz figyelembe véve. Ha a fenti példában az bjektummintába írtuk vlna be a success mező igazságértékének vizsgálatát, akkr az utlsó 30 sikeres bejelentkezés srára vnatkztt vlna, amely csak akkr lenne üres, ha sse történt sikeres bejelentkezés. Másfelől ilyen módn nem lehetséges egy $u: User() felhasználóhz tartzó utlsó 30 lekérdezést vizsgálni, hiszen a felhasználóval történő összekapcslás csak egy utólags szűrés lenne. A csúszóablakk egyik legfőbb felhasználása az akkumuláció kifejezések leszűkítése. Az alábbi minta azn szerverekre illeszkedik, amelyeknek az átlags CPU kihasználtsága az elmúlt két percben a hzzájuk knfigurált riasztási küszöb felett vlt: $s: Server($ct: cputreshld) $ua: java.lang.number (dublevalue > $ct) frm accumulate ( ResurceRecrd(server == $s, $util: cpuutilizatin) ver windw:time(2m), average($util)) Az eseményflyam-feldlgzó mtrk gyakrlati használatának egyik fnts feltétele, hgy nem kell a teljes múltat eltárlniuk, az infrmációtömeg már érdektelenné vált részei eltávlíthatóak. Eseményflyam módban a Drls fnts szlgáltatása az életciklus-kezelés: az intervallumösszehasnlításk és idő alapú csúszóablakk alapján autmatikusan meghatárzza, hgy melyik típusú eseményt mennyi ideig kell megőriznie, és a lejáratuk után eldbja az eseményeket. A fenti példákban ha máshl nincs ezekre az eseménytípuskra szükség a ResurceRecrd eseményeket két percig, az Uzemmd eseményeket két és fél percig őrzi meg, utána eltávlítja a munkamemóriából. Magasabb élettartam is garantálható srral az eseménybjektum deklarációjában. 9

10 4 A mérés elvégzése Rendszerfelügyelet támgatása kmplexesemény-feldlgzással A mérés srán a krábban implementált munkaflyamat szlgáltatja majd az eseményeket, amelyeket a Drls Fusin segítségével megfigyelhetővé kell tenni. Az elvégzendő feladatk tehát: Kiindulás valamelyik krábbi munkaflyamat-implementációból. Biznys előfeltételeknek teljesülnie kell, így az implementáció szükség esetén módsítandó: futhassn egyszerre akárhány flyamatpéldány; előnyös (nem kötelező), ha a flyamatpéldányk autmatikusan, kézi léptetés nélkül (is) le tudnak futni, legalább tesztelési céllal; a tesztelhetőség érdekében mindenképpen gndskdni kell arról, hgy a flyamatpéldányk végrehajtása biznys pntkn mesterségesen késleltethető legyen; végül legyen az egyes flyamatpéldánykhz egyedi aznsító rendelve, amely a flyamatn végighaladás közben nem váltzik (beleértve elágazáskat és párhuzamsságt). A munkaflyamat felműszerezése, hgy szlgáltassn x aznsítójú flyamatpéldány elkezdte / befejezte az y taszkt jellegű eseményeket. Az események bevezetése egy eseményflyam módban futtattt Drls példányba. Ügyeljünk arra, hgy a Drls nem szálbizts! Drls szabály készítése néhány érdekes kmplex esemény kezelésére: egy adtt jin csmópntnál az egyik ágra skáig várakzik a másikkal már végzett prcessz; egy adtt elágazás egyik kimenetét az utóbbi időben skkal több flyamatpéldány választtta, mint a másikat; egy adtt taszk a legutóbbi néhány végrehajtásáhz képest kiugróan régóta van mst flyamatban; egy adtt taszk nagyn sk példányban van mst egyszerre flyamatban; bónusz feladat érdeklődőknek: a fenti szabályk általánsítása, hgy egy adtt helyett akármelyik flyamatelemre működjenek, ismeretlen flyamatmdellen is. (Természetesen a megldás srán tetszés szerint használhatóak segédtények, segédszabályk, insertlgical-lal származtattt tények, stb.) Demnstrálni, hgy a definiált CEP szabályk a munkaflyamat megfelelő lejátszásával elsüthetőek. (Tehát röviden: eseményminták definiálása és az eseményflyam feldlgzása útján fgjuk felügyelni a flyamat végrehajtását.) 5 Ellenőrző kérdések A beugró kérdések (melyek nem feltétlenül az alábbi listáról lesznek kiválasztva) kizárólag az ebben a dkumentumban leírt ismereteket fgják visszakérdezni, aznban a mérés sikeres elvégzéséhez feltétlenül célszerű a Drls dkumentáció használata is. 1. Mit nevezünk egy szabály aktivációjának? Mely elemekből épül fel az aktiváció Drls esetén? 2. Mi a cnflict set (agenda, napirend)? 3. Milyen következményekkel jár, ha egy szabályalkalmazás nem érvényteleníti a saját aktivációját? Mi a teendő ilyen helyzetben? 10

11 4. Mire való az Eclipse-es Drls környezet Audit, Agenda ill. Wrking Memry nézete? 5. Miben különböznek a Drls események az egyéb tényektől, eseményflyam módban és azn kívül? 6. Mi alapján dönti el a Drls, hgy egy WM-be beszúrt ténybjektum eseménynek minősül-e? 7. Az időadatk szempntjából milyen kétféle eseményt támgat a Drls? Tekinthető-e az egyik a másik speciális eseteként? 8. Mire valók a temprális (intervallumlgikai) perátrk? 9. Milyen alkalmazási helyzetekre való a Drls eseményflyam (STREAM) módja, milyen feltételezéseket tesz, és milyen többletszlgáltatáskat nyújt? 10. Eseményflyam módban hgyan kezeli a Drls az események életciklusát? Miért van erre szükség? 11. Milyen csúszóablakkat támgat a Drls, mi a szerepük, mikr alkalmazhatóak? 11