Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství

Bakalářská práce

Systém pro základní monitoring serverů a domén Marek Dorda

Vedoucí práce: Ing. Jiří Hunka

12. května 2014

Poděkování Děkuji vedoucímu této práce Ing. Jiřímu Hunkovi za připomínky a cenné rady při psaní této práce. Děkuji také Bc. Tereze Rybářové za korekturu stylistickou i gramatickou.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.

V Praze dne 12. května 2014

.....................

České vysoké učení technické v Praze Fakulta informačních technologií c 2014 Marek Dorda. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Dorda, Marek. Systém pro základní monitoring serverů a domén. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2014.

Abstract The goal of this bachelor thesis is to design and realise a platform independent open-source project, used for accessibility monitoring of server and domain related services. The main aim is a functional prototype, which offers a facilitation of future development and allows an addition of further testing and notification functions. The final prototype is made available to the developer community on GitHub. Keywords server monitoring, domain monitoring, web application, JAVA

Abstrakt Cílem této bakalářské práce je navrhnout a zrealizovat platformně nezávislý opensource projekt, který slouží k monitorování dostupnosti služeb spojených se servery a doménami. Hlavním cílem je funkční prototyp, který nabízí zázemí pro následující vývoj a rozšiřování o další možnosti testování a oznamování chyb. Výsledný prototyp je dostupný vývojářské komunitě na stránkách GitHub. ix

Klíčová slova monitoring serverů, monitoring domén, webová aplikace, JAVA

x

Obsah Úvod

1

1 Současná řešení 1.1 Testování . . . . . . . . . . 1.2 Oznámení . . . . . . . . . . 1.3 Reporty a statistiky . . . . . 1.4 Omezení pro užívání zdarma 1.5 Souhrn . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

2 Analýza a návrh aplikace 2.1 Specifikace cíle . . . . . . . . . . 2.2 Sběr požadavků . . . . . . . . . . 2.3 Analýza požadavků . . . . . . . . 2.4 Případy užití . . . . . . . . . . . 2.5 Rozdělení aplikace . . . . . . . . 2.6 Řešení síťových výpadků . . . . . 2.7 Prevence přetížení aplikace . . . . 2.8 Doménový model . . . . . . . . . 2.9 Databázový model . . . . . . . . 2.10 Specifikace použitých technologií

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . .

. . . . .

3 4 8 9 10 11

. . . . . . . . . .

15 15 15 16 21 24 24 27 28 28 31

3 Týmový rozvoj aplikace 35 3.1 Zázemí opensource projektů . . . . . . . . . . . . . . . . . . 35 3.2 Tvorba komunity . . . . . . . . . . . . . . . . . . . . . . . . 36 4 Implementace 37 4.1 Souhrn implementované funkcionality . . . . . . . . . . . . . 37 xi

4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10

Vývojové prostředí . . . . . . . . Testování . . . . . . . . . . . . . Uživatelské účty . . . . . . . . . . Šablony HTML stránek . . . . . . Modularita . . . . . . . . . . . . Komunikace mezi komponentami Uchovávání výsledků testů . . . . Výsledky a statistiky . . . . . . . Vlákna . . . . . . . . . . . . . . .

5 Další rozvoj aplikace 5.1 Modularita . . . . . . . . . . . 5.2 Testování . . . . . . . . . . . . 5.3 Nárůst počtu serverů a agentů . 5.4 Rozdělení aplikace . . . . . . . 5.5 Zpřístupnění projektu veřejnosti 5.6 Další návrhy . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

38 38 38 39 39 43 43 44 44

. . . . . .

47 47 48 48 48 49 49

Závěr

51

Literatura

53

A Seznam použitých zkratek

57

B Obrázky

59

C Zdrojové kódy 65 C.1 SQL skripty pro vytvoření databází . . . . . . . . . . . . . . 65 C.2 Ukázky modulů . . . . . . . . . . . . . . . . . . . . . . . . . 69 D Obsah přiloženého CD

75

xii

Seznam obrázků 2.1 2.2 2.3 2.4 2.5 2.6 2.7

Výsledky ankety . . . . . . . . . . . . . . . . . . . . Zjednodušený diagram případů užití . . . . . . . . . Diagram nasazení . . . . . . . . . . . . . . . . . . . . Doménový model . . . . . . . . . . . . . . . . . . . . Logické schéma databázového modelu serveru . . . . Logické schéma databázového modelu agenta . . . . . Popularita programovacích jazyků, převzato z TIOBE BV [46] . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software . . . . . .

17 23 25 29 30 30

4.1 4.2

Screenshot grafů s výsledky testování . . . . . . . . . . . . . . . Screenshot tabulky s výsledky testování . . . . . . . . . . . . .

45 45

B.1 B.2 B.3 B.4 B.5

Podrobný diagram případů užití Podrobný diagram případů užití Sběr požadavků - dotazník 1/3 Sběr požadavků - dotazník 2/3 Sběr požadavků - dotazník 3/3

60 61 62 63 64

pro běžného uživatele pro administrátora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xiii

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

32

Seznam tabulek 1.1 1.2 1.3 1.4

Přehled testovaných protokolů . . . . . . . . . . . . . . Přehled testovaných databází . . . . . . . . . . . . . . Přehled projektů testujících DNS . . . . . . . . . . . . Přehled počtu síťově nezávislých serverů provozovaných livými projekty . . . . . . . . . . . . . . . . . . . . . . 1.5 Přehled dalších možností testování . . . . . . . . . . . 1.6 Přehled funkcí API . . . . . . . . . . . . . . . . . . . . 1.7 Přehled prostředků k oznámení vzniklé chyby . . . . . 1.8 Přehled možností nastavení upozornění . . . . . . . . . 1.9 Přehled reportů a statistik . . . . . . . . . . . . . . . . 1.10 Omezení pro účty zdarma . . . . . . . . . . . . . . . . 3.1

. . . . . . . . . . . . . . . jednot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 5 6 6 7 8 9 10 10 11

Přehled vybraných funkcí u služeb nabízejících hostování projektů 36

xv

Úvod Internetový server může být jak počítač, který je připojen k síti internet a poskytuje určité služby, tak i počítačový program, který tyto služby realizuje. Každý server připojený k internetu má jednoznačný identifikátor v podobě IP adresy. Aby nebylo nutné si pamatovat všechny existující identifikátory v síti, existují domény, které je zastupují. Doména je oproti IP adrese snadněji zapamatovatelná. Pro převod domény na konkrétní IP adresu existuje překladová služba DNS. Běžná situace vypadá tak, že libovolný klient, který přistupuje k serveru prostřednictvím domény, nejprve zašle požadavek lokálnímu DNS serveru. Lokální DNS server ve spolupráci s dalšími DNS servery nakonec zajistí, že je klientovi vrácena IP adresa, na kterou je doména nasměrována. Klient pak komunikuje pouze se serverem přes získanou IP adresu. [6] Během tohoto procesu může nastat několik komplikací. Například může dojít k chybnému nastavení cílové IP adresy správcem domény. Klientovi se po zaslání požadavku na DNS server vrátí nesprávný záznam a k navázání spojení mezi klientem a serverem nikdy nedojde. Problém může nastat i na straně serveru. Může například dojít k situaci, kdy je na serveru nesprávně nastaven firewall. Nebo aplikace, která zprostředkovává danou službu, obsahuje implementační chyby. Může také dojít k přetížení serveru nebo k jiným nepředvídatelným komplikacím. Příčin možné nefunkčnosti je mnoho. V každém případě server, který není funkční, nevrátí klientovi správný výsledek. Pokud dojde k výpadku, bylo by vhodné, aby se správce služby o této skutečnosti dozvěděl co nejdříve a sjednal nápravu. Jedním ze způsobů včasného odhalení chyby je metoda, kdy dochází k pravidelnému monitorování serveru v určitém intervalu. Kontrola probíhá tak, že ve vhodně zvoleném intervalu dochází k dotazování na doménu nebo IP adresu a je kontrolo1

Úvod váno, zda monitorovaný server vrací očekávanou odpověď. Monitorovat lze i mnoho dalších služeb, na kterých závisí funkčnost serveru. Například databáze, konkrétní protokoly a služby, které využívají specifické síťové porty, v případě webových stránek například jejich obsah apod. V současné době existuje značné množství projektů, které se zabývají monitorováním serverů a domén. Většina kvalitních projektů v této oblasti ovšem není dostupná zdarma. Cílem této práce je vytvořit prototyp opensource aplikace, která zajistí především základní možnosti monitorování a oznamování vzniklého problému. Vzniklý prototyp zároveň poslouží jako zázemí pro následující vývoj v komunitě vývojářů.

2

Kapitola

Současná řešení Pro monitoring serverů a domén je vyvinuto množství projektů, které umožňují testovat různé protokoly a služby. Pro srovnání je zde uvedeno celkem šest vybraných řešení. Jedná se o tři zahraniční a tři české projekty: Pingdom - s více než 350 000 uživateli, mezi které patří například Microsoft, Pinterest, Google, HP, Apple a další, se jedná o jeden z nejrozšířenějších projektů vůbec [32]. Monitor.Us - se 110 000 uživateli se sice nejedná o nejrozšířenější projekt, jednoznačně ale poskytuje nejvíce služeb ze všech porovnávaných projektů [26]. Uptime Robot - ačkoliv neposkytuje mnoho možností nastavení, svou jednoduchostí a přehledností se tento projekt řadí mezi poměrně uživatelsky oblíbené [48]. Monitoring serverů - jeden z nejrozšířenějších českých projektů, který zároveň nabízí i velké množství služeb [24]. Irokez - jednoduchý a přehledný český projekt, který nabízí pouze základní služby [14]. Stasi - český projekt, který si díky poměrně velké nabídce služeb poskytovaných zdarma zasloužil pozornost [43]. 3

1

1. Současná řešení

1.1

Testování

1.1.1

Protokoly

3 3 3 3 3

3 3 3 3 3 3 3

3 3 3

3

3

Stasi

3 3 3 3 3 3

Irokez

3 3 3 3 3 3

Monitoring serverů

Uptime Robot

HTTP HTTPS FTP POP3 IMAP SMTP LDAP SSH Telnet TCP UDP ICMP SIP SOAP nastavitelný port s přihlašovacími údaji

Monitor.Us

Pingdom

Tabulka 1.1: Přehled testovaných protokolů

3 3 3

3

3 3

3

3

3 3 3 3 3 3

V tabulce 1.1 je uveden přehled protokolů, které nabízejí jednotlivé projekty k testování z administračního rozhraní [32][26][48][24][14][43].

1.1.2

Databáze

Tabulka 1.2 uvádí přehled databází, které nabízí jednotlivé projekty k testování [32][26][48][24][14][43]. 4

1.1. Testování

MySQL PostgreSQL

1.1.3

3

Stasi

Irokez

Monitoring serverů

Uptime Robot

Monitor.Us

Pingdom

Tabulka 1.2: Přehled testovaných databází

3 3

Domény

Tabulka 1.3 uvádí přehled projektů, které umožňují testovat DNS. Přestože se jedná o kontrolu DNS, jednotlivé projekty se zde poměrně liší v tom, co a jak kontrolují: Pingdom kontroluje na základě zadané domény, nameserveru a očekávané IP adresy, zda doména odkazuje na zadanou IP adresu [32]. Monitor.Us provádí kontrolu stejně jako Pingdom [26]. Monitoring serverů kontroluje pouze dostupnost samotného DNS serveru. Nedokáže kontrolovat domény a jejich přesměrování [24]. Irokez kontroluje pouze změny v nastavení domény. Například změnu držitele, IP adresy nebo blížící se termín expirace. Nedokáže kontrolovat, zda je doména nasměrována na správnou adresu [14]. Uptime Robot a Stasi kontrolu DNS neposkytují [48][43].

1.1.4

Počet serverů

Věrohodnost výsledků je u většího počtu serverů vyšší. Pokud je služba provozována pouze na jednom serveru, je při jeho výpadku měření nemožné. Tabulka 1.4 uvádí, na kolika síťově nezávislých serverech jsou jednotlivé projekty provozovány. U některých projektů ovšem není vždy uváděn přesný počet serverů. [32][26][48][24][14][43]. 5


3

3

Stasi

Irokez

3

Monitoring serverů

3

Uptime Robot

Monitor.Us

DNS

Pingdom

Tabulka 1.3: Přehled projektů testujících DNS

1.1.5

Monitor.Us

Uptime Robot

Monitoring serverů

Irokez

Stasi

počet síťově nezávislých serverů

Pingdom

Tabulka 1.4: Přehled počtu síťově nezávislých serverů provozovaných jednotlivými projekty

60

7

5

>2

>2

1

Další možnosti testování

Kromě výše zmíněných možností testování nabízejí jednotlivé projekty také další služby [32][26][48][24][14][43]. Například: • Existenci a neexistenci klíčových slov na stránce. • Ping. • Sledování systému, které vyžaduje vlastního klienta na straně serveru. Tím se ovšem omezuje řešení na vybrané platformy. • Kompletní kontrola stránky zkontroluje po načtení veškerého obsahu, zda jsou všechny prvky na stránce dostupné. Například obrázky, soubory, externí obsah. • Selenium umožňuje nahrát postupnou aktivitu na stránkách (vyplňování formulářů, procházení odkazů) a takto nahrané makro později spustit [37]. 6

1.1. Testování

3 3 3 3 3 3

Monitoring serverů

Uptime Robot 3 3 3

3 3

Stasi

3 3 3 3

Irokez

ping existence klíčových slov absence klíčových slov kompletní kontrola stránky podpora nástroje Selenium sledování systému

Monitor.Us

Pingdom

Tabulka 1.5: Přehled dalších možností testování

3

3

3 3

Přehled projektů a jejich dalších možností testování je uveden v tabulce 1.5.

1.1.6

API

API jednotlivých projektů mají ve své podstatě velmi podobnou funkčnost, která je přehledně uvedena v tabulce 1.6. Liší se pouze rozmanitostí možných požadavků, které více či méně usnadňují jejich používání [31][25][47]: Pingdom disponuje množstvím funkcí a detailní rozsáhlou dokumentací, což umožňuje jednoduchým příkazem provádět i komplikovanější akce (například seznam všech serverů, které měly výpadek od konkrétní doby apod.) [31]. Monitor.Us je rozsahem i kvalitou dokumentace srovnatelný s projektem Pingdom [25]. Uptime Robot v porovnání s předchozími projekty nemá tak široký výběr možných požadavků, nicméně umožňuje dostat se ke všem potřebným datům, se kterými lze posléze pracovat [47]. Monitoring serverů, Irokez a Stasi API neposkytují [24][14][43].

7


1.2

Oznámení

1.2.1

Prostředky

3 3 3 3

Stasi

3 3 3 3

Irokez

Uptime Robot

3 3 3 3

Monitoring serverů

Monitor.Us

správa kontaktů správa oznámení správa úkolů statistiky

Pingdom

Tabulka 1.6: Přehled funkcí API

Pokud je během testů objeven problém, je tato skutečnost oznámena uživateli. Kromě klasického upozornění na email nebo formou SMS jsou nabízeny ještě další varianty. Některé projekty nabízejí možnost obdržení upozornění s využitím RSS čtečky, generováním XML souboru, odesláním požadavku POST na zadanou adresu, komunikací přes IM klienta nebo dokonce odesláním zprávy na Twitter. Stále více je žádaná i forma oznámení přes mobilní aplikace na telefonu. Tabulka 1.7 uvádí přehled prostředků komunikace používaných jednotlivými poskytovateli. Je patrné, že v případě českých projektů, jako je Monitoring serverů, Irokez či Stasi, na rozdíl od projektů zahraničních, nejsou mobilní aplikace ani sociální sítě podporovány. [32][26][48][24][14][43]

1.2.2

Nastavitelnost

U všech projektů je samozřejmostí, že si lze pro každý sledovaný server nebo doménu nastavit upozornění zcela nezávisle na jiných, již zadaných, kontrolách. U některých projektů dokonce existuje správce kontaktů, kde lze jednotlivé kontakty přidávat do skupin a tyto skupiny posléze přidělovat k příslušným kontrolám. Užitečnou funkcí je možnost nastavit časovou prodlevu, která určuje dobu trvání chyby, než dojde k odeslání upozornění. Vítané je to v situaci, kdy nastane krátký, řádově několikasekundový, výpadek. Někdo by mohl 8

1.3. Reporty a statistiky

3 3

3

3

3 3 3 3

Stasi

3 3

Irokez

Uptime Robot

3 3

Monitoring serverů

Monitor.Us

SMS email XML RSS POST IM mobilní aplikace Twitter

Pingdom

Tabulka 1.7: Přehled prostředků k oznámení vzniklé chyby

3 3

3 3

3 3 3

3 3

3 3

ocenit průběžné informace o trvající chybě, odesílané v pravidelných intervalech. Pokud už chyba skončila, uživatel by mohl mít zájem o podrobný report s detaily toho, jak dlouho chyba trvala, kde byl problém apod. Další nabízenou funkcí je možnost nastavení tichého režimu, kterým lze pozastavit upozornění nebo nastavit dobu, po kterou si uživatel nepřeje dostávat žádné reporty. Například každý den od půlnoci do 6 rána. Každé pondělí celý den apod. Tabulka 1.8 uvádí, které možnosti nastavitelnosti umožňují jednotlivé projekty [32][26][48][24][14][43].

1.3

Reporty a statistiky

Po uplynutí určitého období (den, týden, měsíc) je možné si u některých projektů nastavit pravidelné reporty. Ty obsahují přehled a detailní informace o tom, k jakému počtu výpadků došlo. Dále dobu, po kterou fungovalo vše bez problémů, a celkový podíl nefunkčnosti a funkčnosti. Po přihlášení do administrace jsou tyto statistiky rovněž k dispozici. V případě některých projektů ovšem dochází k omezení jejich archivace. Projekty, u kterých si lze nastavit pravidelné reporty a které archivují statistiky po omezenou dobu, uvádí tabulka 1.9 [32][26][48][24][14][43]. 9


Irokez

Stasi

3 3 3 3 3

Monitoring serverů

3 3 3 3 3

Uptime Robot

Monitor.Us

správce kontaktů nastavitelná prodleva možnost reportu během chyby report po skončení chyby Tichý režim

Pingdom

Tabulka 1.8: Přehled možností nastavení upozornění

3

3 3

3

3 3

3 3 3 3

3

3 3

1.4

Irokez

Stasi

3 3

Monitoring serverů

3 3

Uptime Robot

Monitor.Us

pravidelné reporty archivace alespoň rok

Pingdom

Tabulka 1.9: Přehled reportů a statistik

3 3

3

3

Omezení pro užívání zdarma

Všechny porovnávané projekty kladou určitá omezení, především na účty, které jsou provozovány zdarma. Hlavním omezením je především prodloužení minimálního intervalu, po kterém probíhají pravidelné kontroly. Dalšími častými omezeními jsou nastavení maximálního počtu sledovaných serverů nebo domén, zkrácení doby archivace statistik, nemožnost exportu statistik, zamezení prohlížení výsledků aplikace traceroute v detailu chyby a další. Nejdůležitější omezení jsou uvedena v tabulce 1.10 [32][26][48][24][14][43]. Z příslušné tabulky lze mimo jiné vyčíst, že se jedná o omezení poměrně značného rozsahu. Například u projektu Monitoring serverů nejsou žádné 10

1.5. Souhrn

Monitor.Us

Uptime Robot

Monitoring serverů

Irokez

Stasi

maximální počet sledovaných serverů nebo domén minimální interval (v minutách) maximální doba archivace (ve dnech)

Pingdom

Tabulka 1.10: Omezení pro účty zdarma

1

2

50

-

2

∞

1

30

5

-

30

5

∞

1

30

-

30

540

z nabízených služeb poskytovány zdarma nebo v případě projektu Monitor.Us je dostupná historie statistik pouze z předchozího dne.

1.5 1.5.1

Souhrn Pingdom

Pingdom [32] je jeden z nejrozšířenějších projektů tohoto typu na celém světě. Kromě kontroly klasických webových prezentací nabízí i kontrolu FTP, emailových služeb a spousty dalších funkcí. Navíc lze nastavit i přihlašovací údaje a číslo portu, čímž je umožněno kontrolovat prakticky veškeré potřebné služby. Pingdom nabízí i možnost kontrolování obsahu stránky (absenci či výskyt klíčových slov) a dostupnost všech zdrojů, které jsou na stránce volány. Součástí služby je také API. Nastane-li nějaký problém u libovolné kontrolované služby, upozorní na tento fakt uživatele prostřednictvím SMS, emailu, aplikací pro Android a iOS nebo dokonce i přes Twitter. Lze nastavit zpoždění, po které musí problém přetrvávat, než dojde k odeslání upozornění. Pokud problém odezní, upozorní Pingdom uživatele a zašle mu podrobný report s detaily vzniklé situace. K dispozici je také tichý režim a správce kontaktů, který zejména při sledování většího množství serverů zlepšuje přehlednost. Reporty za uplynulý den, týden nebo měsíc si lze nechat posílat na email. 11

1. Současná řešení Po přihlášení do administračního rozhraní jsou dostupné aktuální statistiky s neomezenou historií. Zdarma je možno sledovat pouze jeden server, ale není kladeno žádné omezení na intervaly kontroly. Ke službě zdarma je k dispozici navíc i 20 SMS měsíčně bez příplatku.

1.5.2

Monitor.Us

Monitor.Us [26] nabízí ze všech porovnávaných projektů nejkomplexnější služby. Kromě kontroly klasických webových prezentací, FTP, emailových protokolů, databází, DNS, nabízí i možnost kontroly TCP, UDP, ICMP, SIP, SOAP a mnohé další funkce. Nabízí i klienta, díky kterému lze kontrolovat stav a nastavení serveru. Monitor.us umožňuje kontrolování obsahu stránky (absenci či výskyt klíčových slov), dostupnost všech zdrojů, které jsou na stránce volány. Také jako jediný z porovnávaných projektů umožňuje kontroly s využitím nástroje Selenium. Nechybí ani API. Pokud se během kontroly objeví chyba, upozornění je uživateli zasláno formou SMS, emailu, mobilní aplikací nebo IM klientem. Nechybí ani generování souboru pro RSS kanál. Lze nastavit dobu, po kterou musí chyba přetrvávat, než dojde k odeslání upozornění. Pokud odezní vzniklý problém, zašle aplikace uživateli podrobný report s detaily vzniklé situace. Samozřejmostí je i tichý režim a správce kontaktů. Pravidelné reporty je možné nechat zasílat každý den, týden nebo měsíc. Po přihlášení do administrace jsou k dispozici podrobné statistiky archivované po dobu dvou let. Zdarma je možno sledovat pouze dva servery s intervalem minimálně 30 minut. Archiv je v neplacené verzi omezen na pouhých 24 hodin a nelze využít měsíčních pravidelných reportů.

1.5.3

Uptime Robot

Uptime Robot [48] podporuje kontrolu základních webových prezentací, emailových služeb a FTP. Dovoluje nastavit přihlašovací údaje a číslo portu, čímž je umožněno kontrolovat prakticky veškeré potřebné služby. Lze nastavit i kontrolu absence či výskyt klíčových slov na stránce. K dispozici je také API. Dojde-li k problému u některé z kontrolovaných služeb, upozorní uživatele prostřednictvím SMS, emailu, mobilní aplikace nebo zprávou na Twitter. Taktéž generuje soubor pro RSS kanál. Pokud problém odezní, upozorní uživatele a zašle mu podrobný report s detaily vzniklé situace. K dispozici je 12

1.5. Souhrn správce kontaktů a možnost nastavení tichého režimu, během kterého není uživatel upozorňován na žádné události. Pravidelné reporty nejsou k dispozici. Dostupný je pouze velmi jednoduchý přehled v administraci s archivací 30 dní. U tohoto projektu existuje pouze verze zdarma. Nenabízí žádnou placenou verzi, která by poskytovala více možností. I přesto jsou zde omezení ve formě sledování maximálně 50 serverů s minimálním intervalem 5 minut.

1.5.4

Monitoring serverů

Monitoring serverů [24] nabízí nejkomplexnější služby z porovnávaných českých poskytovatelů. Umožňuje kontrolovat funkčnost klasických webových prezentací, FTP, emailových služeb, databází, DNS a další služby. Navíc lze nastavit i přihlašovací údaje a číslo portu, čímž se otevírají možnosti ke kontrole prakticky všech potřebných služeb. Upozornění na nefunkčnost libovolné sledované služby zasílá formou SMS, emailu, generováním XML souboru anebo přes RSS čtečku. Navíc lze nastavit, kdy má dojít k oznámení. Zdali okamžitě po vzniku problému, nebo až po určité době přetrvávání chyby. Taktéž uživatele upozorní na stav, kdy již chyba odezněla a zašle podrobný report s detaily vzniklé situace. K dispozici je i tichý režim, během kterého nejsou upozornění aktivní. Reporty za uplynulý den, týden nebo měsíc si lze nechat zasílat na email. Po přihlášení do administračního rozhraní jsou dostupné statistiky za období dlouhé až jeden rok. Projekt nenabízí žádné bezplatné služby. Všechny poskytované služby jsou zpoplatněny v závislosti na požadované délce intervalu kontroly. Jako další nevýhodu je nutno uvést, že není k dispozici API.

1.5.5

Irokez

Irokez [14] nabízí kontrolu klasických webových prezentací, hlídání změn na doménách a experimentální funkci monitoringu systému (vytížení procesoru, zaplnění disků apod.). Upozornění o vzniklém problému zasílá formou SMS a emailu. Lze nastavit i dobu, po kterou musí problém přetrvávat, aby došlo k tomuto upozornění. Taktéž upozorní uživatele na stav, kdy již odezněla vzniklá chyba a zašle report s detaily vzniklé situace. Pravidelné reporty nejsou k dispozici. Po přihlášení do administrace je dostupný přehled aktuálního stavu a historie za období dlouhé až jeden rok. Zdarma je možné využít nastavení kontrolování pouze dvou serverů s minimálním intervalem 30 minut. Navíc historie statistik je u verze zdarma 13

1. Současná řešení pouze po dobu jednoho měsíce. Poskytované služby postrádají možnost kontroly emailů, databází, FTP apod. Chybějící API a pravidelné reporty na email lze považovat za nedostatek.

1.5.6

Stasi

Stasi [43] nabízí kromě klasických protokolů HTTP a HTTPS také kontrolu FTP, SSH a Telnet. Navíc umožňuje nastavit konkrétní port a přihlašovací údaje, což otevírá možnosti ke kontrolování téměř všech potřebných služeb. Pokud se během kontroly objeví chyba, upozornění je uživateli zasláno formou SMS nebo emailem. Taktéž podporuje oznámení přes POST request. Lze nastavit dobu, po kterou musí problém přetrvávat, než dojde k upozornění uživatele. Po ukončení přetrvávající chyby je uživatel upozorněn a je mu zaslán podrobný report o vzniklé situaci. K dispozici je i tichý režim, během kterého nejsou upozornění aktivní. Pravidelné reporty nejsou k dispozici. V administraci jsou dostupné statistiky s historií až 540 dní zpětně. V bezplatné verzi není nijak omezen počet serverů, ale interval kontroly musí být minimálně 5 minut. Nevýhodou je absence API a pravidelných reportů.

14

Kapitola

Analýza a návrh aplikace Následující kapitola pojednává o specifikaci cílů a podrobné analýze výsledné aplikace. V kapitole je uvedeno rozdělení aplikace na jednotlivé části, popsána jejich činnost a vzájemná spolupráce. Jsou v ní sepsány funkční a nefunkční požadavky, specifikovány uživatelské role a případy použití. V závěru jsou uvedeny a odůvodněny použité technologie.

2.1

Specifikace cíle

Cílem této práce je vytvořit opensource projekt pro základní monitoring serverů a domén. Zajistit jeho snadné rozšiřování a další vývoj. Prototyp aplikace by měl zvládat podporu uživatelských účtů, testování funkčnosti a dostupnosti různých služeb a z dat nasbíraných testováním vytvářet statistiky a grafy. Prototyp by dále měl zvládat reportování výsledků a upozorňování uživatele na vzniklý problém. Testování a reportování by mělo probíhat za pomoci modulů, které samy o sobě nebudou závislé na aplikaci a v budoucnu bude tedy možné libovolný modul přidat. Uživatel by měl mít přístup ke svému účtu skrz webový prohlížeč, kde snadno může zadávat a editovat své testy a prohlížet si jejich výsledky.

2.2

Sběr požadavků

Jelikož je jedním z cílů pokusit se okolo projektu utvořit komunitu, byla zrealizována stručná neoficiální anketa cílená právě na potenciální vývojáře. Jejím cílem bylo především zjistit, jaké technologie vývojáři upřednostňují a používají. Anketa byla rozeslána několika osobám pracujících v různých softwarových společnostech a také na vybraná vývojářská fóra, 15

2

2. Analýza a návrh aplikace například www.webdeveloper.com. Ankety se zúčastnil vzorek 31 lidí. Vzhledem k tomu, že téměř všichni respondenti jsou programátoři, lze výsledky považovat za kompetentní. Kompletní podoba české varianty ankety je uvedena v příloze B.3, B.4 a B.5. Kompletní výsledky ankety jsou součástí obsahu přiloženého CD. Pro účely návrhu a implementace aplikace jsou klíčové především následující vybrané otázky: • „Co vše byste si přáli testovat?“ • „V případě, že byste se chtěli podílet na budoucím vývoji aplikace, jaký programovací jazyk upřednostňujete?“ • „Jaký preferujete operační systém na serveru?“ • „Jakým způsobem byste chtěli být informováni o výpadku či nalezené chybě?“ Na obrázku 2.1 jsou k vidění odpovědi na uvedené otázky, ze kterých lze vyčíst například to, že nejžádanější možností testování je HTTP/HTTPS a kontrola správného nasměrování domény. Naopak ping či kontrola existence nebo absence klíčových slov na webu není až tak žádaná. Z programovacích jazyků je respondenty nejžádanější Java. Srovnatelně je na tom ještě jazyk C. Všichni respondenti uvedli, že by si přáli být informování prostřednictvím emailu, více než polovina se vyjádřila kladně i k možnosti zaslání SMS. Překvapivě malý zájem byl o mobilní aplikaci. Většina respondentů preferuje na serveru operační systém Linux, nicméně Windows preferuje téměř třetina respondentů.

2.3

Analýza požadavků

Z výsledků zmíněné ankety a z podrobné analýzy projektů Pingdom [32], Monitor.Us [26], Uptime Robot [48], Monitoring serverů [24], Irokez [14] a Stasi [43] byla provedena analýza požadavků. Byl brán zřetel i na diskuzní fóra některých zmíněných projektů a stránky FAQ. Z důvodu velké rozsáhlosti uvedených požadavků nejsou v seznamu níže uvedeny konkrétní požadavky na testování (ve smyslu protokolů, databází, domén apod.) a reportování (ve smyslu SMS, emailů apod.), jelikož by výsledná aplikace měla podporovat moduly třetích stran a mělo by tedy být možné dopsat libovolný test či report. Dále by měly být naimplementovány pouze základní funkce, které umožní spuštění a běh aplikace k pozdějšímu 16

2.3. Analýza požadavků

Obrázek 2.1: Výsledky ankety 17

2. Analýza a návrh aplikace rozvoji. Funkce, které nejsou zamýšleny v rámci prototypu, jsou v textu vyznačeny kurzívou.

2.3.1

Funkční požadavky

• Uživatelský profil – registrace nového uživatele – změna údajů uživatele – deaktivace uživatele – reaktivace uživatele – smazání uživatele • Testování – přidání nových testů – editace testů – smazání testů – pozastavení a spuštění jednotlivých testů nezávisle na ostatních testech – pozastavení a spuštění testů globálně – přehled všech definovaných testů – nastavitelný interval kontroly jednotlivých testů nezávisle na ostatních testech • Výsledky testování – přehled výsledků testů – neomezená historie výsledků testů – detailní přehled konkrétních testů a jejich výsledků – veřejné výsledky testů – ikona na web třetích stran zobrazující statistiky dostupnosti – exportování výsledků • Kontakty – přehled kontaktů – přidání kontaktů 18

2.3. Analýza požadavků – mazání kontaktů – editace kontaktů – přidání kontaktních údajů u kontaktů – editace kontaktních údajů u kontaktů – smazání kontaktních údajů u kontaktů • Reportování – volitelné přiřazení kontaktů k testům nezávisle na ostatních testech – globální přiřazení kontaktů ke všem testům – nastavitelný interval pravidelných reportů – volba situací, kdy dojde k oznámení – nastavitelná prodleva odesílání reportů – pozastavení reportování globálně i nezávisle na konkrétních testech – nastavitelnost doby, po kterou jsou reporty aktivní – nastavení maximálního limitu za určité období u služeb vyžadujících platbu • Administrace – přehled uživatelů – blokace a odblokace uživatelů – povolení a zakázání testovacích modulů – povolení a zakázání reportovacích modulů – nahlášení nefunkčních modulů – upozornění na nově přidané moduly Většina z uvedených požadavků je zřejmých a není třeba je dále rozvádět. Detailněji jsou popsány pouze ty požadavky, které nemusí být zcela zřejmé a obsahují určité návaznosti, které nejsou z pouhého výčtu viditelné. Registrace nového uživatele by neměla vyžadovat příliš mnoho informací o uživateli. Mezi nejnutnější minimum lze zařadit email, uživatelské jméno a heslo. Tyto položky lze považovat jako jediné nezbytné pro úspěšnou registraci. 19

2. Analýza a návrh aplikace Deaktivace uživatele je situace, kdy uživatel již nebude chtít používat aplikaci, ale zároveň nebude chtít přijít o veškerá svá nastavení. Deaktivovaný účet se po určité době (například jeden rok) sám smaže. Během stavu nečinnosti nebude probíhat testování ani nebudou zasílány reporty. Reaktivace uživatele umožňuje znovu zprovoznit deaktivovaný účet. Pokud si uživatel zažádal o deaktivaci účtu a během doby, než došlo k jeho automatickému smazání, si svůj krok rozmyslel, reaktivací se vrátí vše do stavu před deaktivací. Přidání nových testů nabízí možnost vybrat si moduly k testování a přiřadit k nim kontakty, na které budou odesílány reporty. Součástí takto přiřazených kontaktů jsou už předem vybrané a nastavené reportovací moduly. Pozastavení a spuštění jednotlivých testů nezávisle na ostatních testech je požadavek, který nabízí možnost zastavit veškeré testování, popřípadě jen konkrétní vybrané testy. Takto pozastavené testy automaticky přestanou posílat reporty. Po opětovném spuštění testování se vše navrátí do stavu před pozastavením. Nastavitelný interval kontroly jednotlivých testů nezávisle na ostatních testech znamená, že u veškerých testovacích modulů fungujících tak, že v pravidelných intervalech zkoušejí dostupnost (respektive správnost) kontrolovaného subjektu, bude umožněno volitelně měnit interval kontroly nezávisle na dalších definovaných testech. Veřejné výsledky testů jsou výsledky libovolného testu zveřejněné pod adresou dostupnou i bez přihlášení do administrace. Tato adresa je vygenerována na žádost uživatele. Ikona na web třetích stran zobrazující statistiky dostupnosti je klasický obrázkový banner, který je generován na základě výsledků probíhajícího testu. Uživatel si tak může na stránky, které monitoruje, umístit informaci o tom, jak jsou spolehlivé. Přidání kontaktů umožňuje přidat kontakty, ke kterým jsou na základě zvolených reportovacích modulů doplněny kontaktní údaje a další nastavení. Každý z kontaktů může mít nastaveno několik reportovacích modulů. Takto připravený kontakt se poté může přiřadit k některému z testů, čímž dojde k propojení testování a reportování. 20

2.4. Případy užití Nastavitelný interval pravidelných reportů znamená, že lze nastavit libovolně dlouhý časový úsek mezi odesíláním pravidelných přehledů výsledků testování za uplynulé období. Volba situací, kdy dojde k oznámení je požadavek, který umožňuje uživateli nastavit, zda má být aplikací upozorněn na chybu v momentě, kdy nastanou, skončí, probíhají apod. Nastavitelná prodleva odesílání reportů je doba, po kterou musí chyba přetrvávat, než dojde k oznámení uživatele o vzniklé situaci. Nastavitelnost doby, po kterou jsou reporty aktivní znamená, že uživatel si zadefinuje, kdy chce dostávat reporty. Například každý všední den od 9 hodin ráno do 16 hodin odpoledne. Mimo tuto dobu nebude odesílání reportů aktivní. Nastavení maximálního limitu za určité období u služeb vyžadujících platbu je užitečná funkce využitelná například u placených SMS bran. Pokud by docházelo k častým výpadkům a následnému zasílání upozornění, náklady by mohly překročit únosnou mez. Tímto limitem lze určit maximální hranici za určité období, při jejímž dosažení dojde k deaktivaci reportování.

2.3.2

Nefunkční požadavky

• multiplatformnost • opensource • stabilita • odolnost proti výpadkům v síti • podpora modulů třetích stran

2.4

Případy užití

Aplikace je cílena především na běžné uživatele, kteří si nastaví jednotlivé testy a způsoby reportů. Vhodné by také bylo mít k dispozici administrátorská práva s možností zakazovat a povolovat různé testovací a reportovací moduly, přidávat do systému další testovací agenty apod. V neposlední řadě může být užitečná i správa uživatelů. Z tohoto důvodu návrh aplikace počítá jak s běžnými uživateli, tak i s administrátory. 21

2. Analýza a návrh aplikace Na obrázku 2.2 je pro přehlednost uveden pouze zjednodušený diagram případů užití. Kompletní a nezjednodušená verze diagramu je přiložena v příloze, zvlášť pro uživatele (obr. B.1) a zvlášť pro administrátora (obr. B.2). Registrace do systému vyžaduje ověření emailové adresy. Po úspěšném ověření je účet okamžitě aktivován a lze s ním pracovat. Správa profilu obsahuje zobrazení všech údajů o uživateli a umožňuje jejich editaci. U změny emailové adresy je opět vyžadováno její ověření. Profil lze deaktivovat, čímž se zastaví veškeré testování a zasílání reportů. Deaktivovaný profil lze opět aktivovat a nepřijít tak o data a veškerá nastavení. Profil lze také definitivně smazat. Dojde tak k úplnému a nenávratnému odstranění všech dat a uživatelských nastavení. Správa kontaktů a reportů zpřístupňuje možnost mazat, přidávat, editovat a prohlížet kontakty. Tyto kontakty slouží k reportování uživatelem zadaných testů. Je tedy nutné ke každému kontaktu přiřadit i reportovací moduly (například SMS, email nebo jiné). V rámci editace kontaktu lze editovat i výběr reportovacích modulů. Správa testů umožňuje prohlížet, přidávat, editovat, mazat, pozastavovat a spouštět testy, ke kterým je nutno přiřadit konkrétní testovací moduly. K testům je možno také přiřadit definované kontakty a aktivovat tak reportování výsledků testů. Prohlížení výsledků obsahuje přehled všech zadaných testů a jejich podrobné výsledky. Součástí jsou grafy dostupnosti, průměrné výsledky za definované období apod. Správa uživatelů zpřístupňuje možnost prohlížet si všechny registrované uživatele a jimi zadaná testování, včetně testovacích a reportovacích modulů, které k jednotlivým testům používají. Součástí je možnost uživateli zablokovat a odblokovat účet. Správa agentů umožňuje prohlížet, přidávat, mazat, povolovat a zakazovat agenty, kteří provádějí samotná testování. Správa modulů umožňuje prohlížet, povolovat a zakazovat moduly. Pokud je do systému přidán nový modul, ať už testovací nebo reportovací, je ve výchozím stavu zakázán a musí být napřed povolen. 22

2.4. Případy užití

Aplikace

Registrace do systemu

Sprava profilu

Sprava kontaktu a reportu User

Sprava testu

Prohlizeni vysledku Admin

Sprava uzivatelu

Sprava agentu

Sprava modulu

Obrázek 2.2: Zjednodušený diagram případů užití

23

2. Analýza a návrh aplikace

2.5

Rozdělení aplikace

Úkolem aplikace je měřit dostupnost služeb. To lze ale zajistit pouze v případě, kdy je samotná aplikace neustále dostupná. Dojde-li k výpadku na serveru, kde je aplikace spuštěna, budou výsledky měření chybné. Z tohoto důvodu bude výsledná aplikace rozdělena na dva nezávislé funkční celky, které se vzájemně synchronizují a zrcadlí. Toto řešení je důležité proto, aby aplikace mohla být umístěna na více síťově nezávislých místech a při výpadku sítě vždy alespoň některá její část fungovala. Pouze pro ilustraci: pokud je konkrétní služba spuštěna na dvou na sobě vzájemně nezávislých místech, která mají garantovanou dostupnost 98%, pravděpodobnost, že zaznamenají obě lokality výpadek ve stejný moment, je 0,04%. V případě rozmístění na třech různých místech je tato pravděpodobnost pouhých 0,0008%, což lze považovat za zcela zanedbatelné riziko výpadku. Základní celky aplikace budou následující: • Server bude centrálním bodem výsledné topologie. Samotný server nebude vykonávat žádné testování, bude pouze sbírat výsledky testů a případně upozorní uživatele na aktuální událost. Taktéž na něm poběží webové rozhraní aplikace. Skrze něj budou zadávány úkoly a server zajistí jejich plnění tím, že je předá dále uzlům, které toto budou mít na starost. • Agenti budou vykonávat pouze testování, které jim server zadá. Výsledky testů odešlou serveru. Agentů může být libovolně mnoho, musí být síťově nezávislí a vždy alespoň dva budou provádět měření stejné služby, aby bylo dosaženo co nejpřesnějších výsledků. Pro lepší představu rozdělení a vzájemné komunikace jednotlivých částí je na obrázku 2.3 uveden diagram nasazení.

2.6

Řešení síťových výpadků

Mohou nastat situace, kdy dojde k výpadku serveru nebo některého z agentů. V takovém případě je nutné takto vzniklé situace řešit. U vzájemné komunikace mezi jednotlivými komponentami je řešení následující: • Pokud se server pokouší odeslat připravené úkoly agentovi, který je nedostupný (ať už z důvodu chyby na serveru nebo u agenta), začne si vytvářet frontu, kterou po opětovném zprovoznění odešle. • V případě, kdy agent odesílá výsledky serveru, a opět nedojde ke spojení, je řešení stejné jako v předchozím bodě. 24

2.6. Řešení síťových výpadků

Klient

«executionEnvironment» Prohlizec

HTTP

Agent

«executionEnvironment» Aplikace

Agent

Server HTTP

«executionEnvironment» Aplikace

HTTP

«executionEnvironment» Aplikace SQL

SQL SQL «executionEnvironment» Databaze «executionEnvironment» Databaze

«executionEnvironment» Databaze

Obrázek 2.3: Diagram nasazení

Komplikovanější situace nastává u zadaných úkolů (testování, vyhodnocování výsledků, apod.) jednotlivým komponentám, jelikož je nemohou v době vlastního výpadku vykonávat.

• Během výpadku serveru bude probíhat testování, které zajišťují agenti, ale nebude fungovat server, tudíž ani webové rozhraní a reporty. Taktéž nebude nedocházet k vyhodnocování výsledků a uživatel tudíž nemůže být upozorněn na případný problém, který mohl během výpadku serveru nastat na místě, které uživatel monitoruje. Možné řešení je uvedeno v podkapitole 2.6.1. • Během výpadku agenta nastane situace, kdy dojde k nasbírání falešně negativních výsledků testů. Tedy že agent, u kterého došlo k výpadku, nasbíral během nefunkčnosti výsledky o nedostupnosti cílového serveru. Nicméně ani test prováděný z více síťově nezávislých agentů nezaručuje správné vyhodnocení vzniklé situace. Takto nasbíraná data odpovídají situaci, kdy nastane výpadek celé podsítě. Například při výpadku podsítě „Evropa“ budou servery z Ameriky hlásit nedostupnost služeb v Evropě, ale servery z Evropy chybu neodhalí. Řešení tohoto problému je nastíněno v podkapitole 2.6.2. 25


2.6.1

Zvýšeni dostupnosti serveru

Návrh aplikace počítá s centralizovaným řízením, proto je nejslabším článkem celé topologie právě její střed. Jak již bylo zmíněno, při výpadku centrálního serveru sice bude probíhat testování, ale vyhodnocování testů a upozorňování uživatele nikoliv. Je tedy nutné zajistit serveru větší stabilitu a dostupnost. Ze všech existujících řešení jsou zde uvedena dvě, která jsou pro tento projekt teoreticky i prakticky použitelná: • Server by sám o sobě byl High Availability Cluster, který garantuje téměř absolutní dostupnost [36]. Tuto variantu nabízejí i poskytovatelé hostingových služeb jakožto hotové řešení pro zákazníky. Jedná se ovšem o poměrně finančně náročnou službu. • Server by byl spuštěn alespoň na dvou síťově nezávislých místech, databáze i soubory by se mezi sebou automaticky synchronizovaly. Všichni agenti by znali adresu ke všem serverům a měli by servery seřazeny dle priorit. Pokud by se nedokázali připojit ke svému primárnímu serveru, zkusili by se připojit na další ze serverů a podobně by postupovali dále. Velkou výhodou druhého zmíněného řešení je především fakt, že by došlo k rozložení zátěže serverů. Počet požadavků na databázi by při rovnoměrném rozložení priorit mezi agenty byl v případě dvou serverů poloviční, v případě tří třetinový atd. Problém nedostupnosti serveru by se tímto změnil na problém synchronizace multi master databází. Pro tyto problémy existují hotová řešení, která zajistí okamžitou synchronizaci mezi více databázemi [33] [27].

2.6.2

Vyhodnocování výsledků

Serveru se mohou vrátit různé výsledky od různých agentů v závislosti na jejich aktuální dostupnosti. Aplikace sama musí rozhodnout o pravdivosti výsledku. Ať už dojde k výpadku agenta samotného, nebo k výpadku celé podsítě, výsledky měření nejsou věrohodné. Agent, u kterého došlo k síťovému výpadku, vždy změří negativní výsledek, přestože služba může i nemusí být dostupná. Při výpadku podsítě mohou změřit agenti ve stejné podsíti jak kladný, tak záporný výsledek, kdežto agenti mimo podsíť vždy záporný. Při odesílání takovýchto výsledků mohou nastat následující situace: • výpadek přetrvává, agent není schopen předat výsledek serveru 26

2.7. Prevence přetížení aplikace • výpadek byl krátkodobý, výsledky byly doručeny serveru V prvním případě nastane, dle chování popsaném v předchozí podkapitole, situace, kdy jsou výsledky odeslány jinému serveru (budou-li nedostupné všechny servery, začne se vytvářet fronta). Může se tedy stát, že výsledky budou na více serverech, které se nemohou kvůli výpadku sesynchronizovat. Pokud některý server obdrží výsledky od agentů, kteří mu je běžně nepředávají, znamená to, že někde nastal problém v konektivitě. Takový server se pokusí získat výsledky od všech agentů (pokud je ještě nemá) vykonávajících konkrétní monitorování a získat kompletní informaci. Mohou tudíž nastat případy, kdy server má nebo nemá kompletní informaci a kdy se dostupné výsledky shodují anebo jsou protichůdné. V případě protichůdných výsledků server odešle informaci uživateli o tom, ze kterých lokalit je monitorovaná služba dostupná, ze kterých není dostupná, a kde chybějící informace od agenta je ignorována. Ve druhém případě server zažádá agenty o nové otestování. Pokud budou výsledky i nadále protichůdné, je postup naprosto totožný jako v předchozím bodě. Přesnějších výsledků lze dosáhnout v případě, kdy komunikace mezi agenty a servery neprobíhá pouze skrze internetové připojení, ale například i prostřednictvím mobilní sítě. Agent nebo server by v takovém případě dokázal komunikovat během výpadku internetové sítě a nedocházelo by ke ztrátě dat.

2.7

Prevence přetížení aplikace

Hlavní předností aplikace oproti ostatním projektům by měla být možnost provádět veškerá testování bez jakéhokoliv omezení. Pokud by si ale velké množství uživatelů zadalo značné množství testů, kterými by nemuseli ani testovat vlastní weby nebo služby, mohlo by dojít k přetížení jak agentů, tak samotného serveru. Základním řešením by bylo zajištění dostatečného hardwarového vybavení. Tato varianta ovšem přináší značnou finanční náročnost jak na pořízení, tak na provoz. Další možností je vhodným způsobem kontrolovat, zda cíl testování opravdu patří uživateli, který si testování zadal. Pokud by monitorovaná služba nebyla ve správě uživatele, který zadal testování, bylo by možné testování buďto úplně zakázat, anebo značně omezit. Omezení by se mohlo týkat intervalu kontroly, čímž by se minimalizovala zátěž serveru pro tento konkrétní úkol. Soudě dle výsledků ankety uvedené v kapitole 2.2 lze očekávat, že nejpoužívanější metodou testování bude pravděpodobně HTTP/HTTPS a kon27

2. Analýza a návrh aplikace trola nasměrování domény. V takovém případě by řešením byl stejný postup, který používá Google [12]. Každému uživateli vygeneruje unikátní klíč, který poté lze vložit do: • TXT záznamu domény • CNAME záznamu domény • meta tagu na stránkách uživatele • souboru, který je umístěn na stránkách uživatele

2.8

Doménový model

Na obrázku 2.4 je znázorněn doménový model webové administrace výsledné aplikace. Pro přehlednost jsou v diagramu zobrazeny pouze implementované části aplikace. Doménový model agentů není uveden, jelikož se jedná o komponentu s pouze velmi jednoduchou funkčností, která nevyžaduje rozdělení do domén. U modelu bylo nutno zohlednit možnost přidávání modulů třetích stran, které mohou vyžadovat různorodá data. Například modul pro testování dostupnosti serveru pomocí funkce ping bude vyžadovat pouze IP adresu nebo doménu. Oproti tomu modul pro hlídání nasměrování domény bude vyžadovat jak doménu, tak cílovou IP adresu. U složitějších testování, jako je například kontrola obsahu stránky nebo průchod konkrétní stránkou, bude rozmanitost požadovaných dat mnohem větší. Tento problém je vyřešen tak, že se data budou ukládat ve formátu JSON. Toto je podrobně popsáno v kapitole 4.6.

2.9

Databázový model

V rámci aplikace bude nutné implementovat dvě nezávislé databáze: jednu pro server a druhou pro agenty. V případě serverové části vychází databázový model z doménového modelu. Pro přehlednost a lepší čitelnost jsou na obrázcích 2.5 a 2.6 zobrazena logická schémata databází pro implementované části. Skripty pro vytvoření databází jsou uvedeny v příloze C.1 a C.2. Moduly budou v aplikaci rozděleny na dvě samostatné tabulky - reportovací a testovací. Toto řešení bude zvoleno z důvodu možné velké rozdílnosti 28

2.9. Databázový model

Plugin -

description :char enabled :boolean filename :char title :char

PluginReport

PluginCheck

1

1 0..* -

0..* ContactDetail -

data :json down :boolean regular :boolean title :char up :boolean

0..*

Contact title :char

enabled :boolean ip :char location :char postAddress :char

0..*

Check

1..* 1

-

Agent

0..*

0..*

-

data :json enabled :boolean checked :boolean interval :int ok :boolean title :char

Result

1

0..* -

agentId :int data :json status :char time :timestamp

0..* 1

1..*

User 1 -

created :timestamp email :char enabled :boolean password :char username :char userRole :char

AgentQueue -

agentId :int query :char testId :int

Obrázek 2.4: Doménový model

29


PLUGINS # * filename * enabled * title o description

AGENTS CHECKING

#* * * * *

CONTACT_DETAIL #* * * * * *

PLUGINS_REPORT

contact_detail_id title data down up regular

agent_id ip post_address location enabled

PLUGINS_CHECK

CHECKS #* * * * * * *

REPORTING

CONTACTS # * contact_id * title

RESULTS

check_id title data enabled interval ok checked

# * time # * agent_id * status o data

USERS #* * * * * *

user_id username password email enabled created

AGENT_QUEUE

USER_ROLES

USER_ACTIVATION # * user_activation_id * email

#* * * *

# * user_role_id * authority

agent_queue_id agent_id test_id query

Obrázek 2.5: Logické schéma databázového modelu serveru

SERVERS # * ip * post_address * priority

RESULTS

CHECKS #* * * *

check_id data filename interval

# * check_id # * time * status * data

Obrázek 2.6: Logické schéma databázového modelu agenta

30

2.10. Specifikace použitých technologií těchto dvou kategorií. V budoucnu se mohou vyvíjet zcela libovolně a mohou přibývat i další kategorie modulů. Takto je zajištěna jejich vzájemná nezávislost a možnost konkrétnější implementace. Uživatel bude mít definováno konkrétní oprávnění pro užívání aplikace. Při zakládání účtu bude muset účet aktivovat emailem, čímž dojde k ověření emailové adresy. Bude moci vytvářet kontakty a testy. Nastavení k reportovacímu modulu bude uloženo v kontaktním údaji. Při zadávání testu bude povinné zvolit testovací modul, jehož konkrétní nastavení bude uloženo v takto vytvářeném testu. Test bude možné propojit s konkrétním kontaktem a tím zajistit jeho reportování. Aplikace poté sama přiřadí testu agenty, kteří budou testování realizovat. Výsledky testování budou ukládány tak, aby bylo možné dohledat konkrétní test i agenta, který měření realizoval. Výsledek sám o sobě na agentovi nebude databázově závislý pro případ, kdy dojde ke smazání agenta. Fronta pro komunikaci s agenty bude reprezentována samostatnou nezávislou tabulkou. Tabulka pro reportovaní zajišťuje, že k testu bude možné přiřadit zvolený kontakt pouze jednou. Stejně je opatřeno i přidělení testu ke konkrétnímu agentovi.

2.10

Specifikace použitých technologií

2.10.1

Programovací jazyk

Při výběru programovacího jazyka byl brán ohled na požadavek multiplatformnosti, která je vzhledem k velké rozmanitosti operačních systémů na serverech [29] opravdu důležitá. Z obrázku 2.7, který zobrazuje popularitu programovacích jazyků, je patrné, že v prvenství se střídají jazyky Java a C. Oba tyto jazyky se nejčastěji vyskytovaly mezi platformně nezávislými jazyky ve zmíněné anketě v kapitole 2.2. Nakonec byla pro vývoj vybrána Java, jelikož má oproti C rozmanitější výběr webových frameworků [16]. Aplikace tedy bude realizována v jazyce Java, konkrétně s využitím frameworku Spring, který je aktivně vyvíjeným projektem s velkou uživatelskou základnou. Jeho součástí je množství modulů, které by se v pozdějším vývoji aplikace daly použít [41]. Spring zjednodušuje psaní kódu a následná testování, a to především odstraněním těsných vazeb mezi třídami, využíváním tzv. POJO objektů, vlastní podporou AOP a mnoha dalšími vlastnostmi [49]. V jazyce Java ovšem chybí podpora ICMP protokolu [22], který má na starosti například funkce ping nebo traceroute [35]. Hlavní výhodou tohoto protokolu je, že pracuje výhradně na síťové vrstvě a nepotřebuje tak 31


Obrázek 2.7: Popularita programovacích jazyků, převzato z TIOBE Software BV [46]

ke své činnosti aplikační vrstvu [35], což řeší případné problémy s aplikačními firewally, které mohou blokovat určité porty a tím vytvářet falešný dojem nefunkčnosti sledované služby. Java umožňuje odesílání socketů na konkrétní port [22], tedy například odeslání socketu na port číslo 7 by simulovalo funkci ping [8], toto řešení ovšem využívá aplikační vrstvu [22] a neřeší to problém s případnými aplikačními firewally. Efektivním řešením, které lze v jazyce Java použít, je využití systémových příkazů a následné parsování jejich výsledků. Toto řešení může mít problémy s kompatibilitou na více operačních systémech, na druhou stranu je spolehlivější a rychlejší, neboť nevyužívá aplikační vrstvu.

2.10.2

Databáze

Podle serveru DB-Engines jsou čtyři nejpopulárnější databáze Oracle, MySQL, Microsoft SQL Server a PostgreSQL [5]. Microsoft SQL Server není multiplatformní a Oracle nabízí zdarma pouze omezenou funkčnost. Rozhodujícím aspektem při výběru mezi MySQL a PostgreSQL byla především propustnost databáze a její stabilita. V tomto směru lze ovšem nalézt množství protichůdných testů, jejichž výsledky se liší v závislosti na verzích databází a především na aplikacích, kterými byly databáze testovány. Z důvodu rozporuplnosti výsledků testů byla vybrána taková databáze, která dispo32

2.10. Specifikace použitých technologií nuje vyhovujícím množstvím funkcí. Z tohoto hlediska PostgreSQL předčí MySQL, neboť nabízí například ochranu proti brute force útoku, podporu datových typů JSON, XML a polí, možnost zadefinování vlastního datového typu a další funkce. [34] [28].

2.10.3

Webové rozhraní

Webové stránky budou psány v HTML5. Jelikož starší verze prohlížeče Internet Explorer HTML5 nepodporují [2], bude z důvodů kompatibility použit skript html5shiv, který zpětnou kompatibilitu zajistí [13]. Pro nastylování stránek bude použit SASS pro generování CSS3, přičemž bude brán zřetel na kompatibilitu ve starších prohlížečích. Pro manipulaci s HTML, animace nad modelem DOM a zpracování událostí prohlížeče bude z důvodu zjednodušení kódu použita knihovna jQuery, která využívá jazyk JavaScript [18]. Pro vykreslování grafů bude použit jQuery plugin jqPlot, který podporuje všechny potřebné funkce, například vypisování hodnot bodů v grafu po najetí myší, možnost zvětšovat vybrané oblasti grafu, možnost nastavování vlastních jednotek u obou os, podporu technologie AJAX a JSON a další možnosti [17].

33

Kapitola

3

Týmový rozvoj aplikace 3.1

Zázemí opensource projektů

V současné době existuje značné množství projektů, které nabízejí zázemí pro týmový rozvoj opensource projektů. Analytický nástroj Alexa.com uvádí žebříček oblíbenosti jednotlivých projektů [1]. Čtyři uživatelsky nejoblíbenější projekty, seřazeny sestupně podle oblíbenosti, jsou následující: 1. GitHub.com používá 5,9 miliónů uživatelů, kteří spolupracují na celkem 12,7 miliónů projektech [10]. V oblasti hostování opensource projektů se jedná o nejpoužívanější službu vůbec. 2. SourceForge.net používá více než 3,7 miliónů uživatelů, kteří vyvíjejí přes 430 tisíci projektů [38]. Tím se Sourceforge řadí na druhé místo v hostování projektů. 3. CodePlex.com hostuje přes 38 tisíc projektů [4]. Počet uživatelů neuvádí. 4. Launchpad.net má uživatelskou základnu čítající téměř 2,5 miliónů lidí [20], kteří spolupracují na necelých 35 tisících projektech [21]. V tabulce 3.1 je uveden přehled vybraných funkcí, které nabízejí jednotlivé projekty svým uživatelům [9][39][3][19]. Z příslušné tabulky lze mimo jiné vyčíst, že u dvou nejrozšířenějších projektů, kterými jsou HitHub.com a Sourceforge.net, je pokrytí funkčnosti potřebné pro vývoj kompletní. Pro účely týmového vývoje aplikace bude použit projekt GitHub.com. Nabízenou funkčností je GitHub.com srovnatelný s projekem SourceForge.net, rozhodujícím aspektem je uživatelská základna, kterou má GitHub.com větší. 35

3. Týmový rozvoj aplikace

3.2

3 3 3 3 3 3 3

Launchpad.net

3 3 3 3 3 3 3

CodePlex.com

SourceForge.net

verzování zobrazení kódu a změn bugtracking wiki podpora týmů API podpora SSH klíčů

GitHub.com

Tabulka 3.1: Přehled vybraných funkcí u služeb nabízejících hostování projektů

3

3 3 3

3 3

3 3

Tvorba komunity

Aby si projekt získal pozornost dalších vývojářů, bude nezbytná jeho propagace. Tu lze zajistit například tím, že projekt bude vyvinut do stavu, kdy jej bude možné veřejně spustit. Z kapitoly 1, která se zabývá již existujícími řešeními, je patrné, že zájem o podobné služby je značný. Pokud by byla aplikace spuštěna a získala si pozornost uživatelů, lze očekávat, že přiláká další vývojáře nejen z řad jednotlivých programátorů, ale i z řad softwarových společností. Další možností, jak rozšířit vývojový tým, by bylo například kontaktovat potencionální vývojáře prostřednictvím diskusních fór, oslovit vedoucí vysokoškolských projektů nebo se pokusit o navázání spolupráce se společnostmi, které podporují začínající projekty. Pro jednodušší začlenění nových členů týmu bude zdrojový kód dokumentován syntaxí, která odpovídá požadavkům nástroje Doxygen. Tyto požadavky splňuje například syntaxe Javadoc [7], která bude pro účely tohoto projektu použita.

36

Kapitola

4

Implementace 4.1

Souhrn implementované funkcionality

Serverová část aplikace podporuje především funkce, které umožňují její spuštění a základní užívání pro následující vývoj. Agenti jsou jednoduché webové aplikace, které zvládají přijímat zadání od serveru, v pravidelných intervalech provádět kontroly, vyhodnocovat výsledky a ty posléze odesílat serveru. Uživateli je umožněno se registrovat, měnit osobní údaje a svůj účet případně smazat. Emailová adresa uživatele je ověřována při registraci i při každé změně emailu. Uživateli je dále umožněno definovat vlastní testy, editovat je a mazat. Taktéž má možnost u testů nastavovat volitelný interval kontroly, testy pozastavovat a zase je spouštět. Naměřené výsledky testů jsou k dispozici s neomezenou historií a přehlednými statistikami, jejichž součástí jsou také grafy. Uživatel má možnost definovat kontakty, přiřazovat k nim kontaktní údaje a u jednotlivých kontaktních údajů definovat, v jakých případech a jakým způsobem mají být zasílána upozornění. Takto vytvořené kontakty je možné propojit se zadefinovanými testy. Kontakty i kontaktní údaje lze editovat a mazat. Administrátor má k dispozici přehled všech registrovaných uživatelů, dále seznam nainstalovaných testovacích i reportovacích modulů a možnost moduly zakazovat a povolovat. Aplikace plně podporuje moduly třetích stran, které jsou zcela nezávislé na samotné aplikaci. Z důvodu omezených zdrojů během vývoje je aplikace napsána pouze pro jeden server a jednoho klienta, nicméně při implementaci byl brán zřetel na to, že v budoucnu dojde k rozšíření aplikace mezi více serverů. Jsou naimplementovány ukázkové moduly pro testování databází MySQL, PostgreSQL a MSSQL, protokolů FTP, IMAP, SMTP a HTTP. 37

4. Implementace K dispozici je jeden reportovací modul, který používá email.

4.2

Vývojové prostředí

Aplikace je vyvíjena ve vývojovém prostředí NetBeans, konkrétně ve verzi 8. Tato volba je pouze otázkou osobních sympatií a zvyku. Další alternativou by mohlo být například vývojové prostředí Eclipse nebo na něm založené Spring Tool Suite, které je specializováno přímo na vývoj Spring aplikací. Jako server, v průběhu vývoje a testování, je používán GlassFish Server, konkrétně verze 4. Tento server je oficiálně vyvíjen firmou Oracle [11], která mimo jiné stojí i za vývojem programovacího jazyku Java [15] a lze tedy očekávat, že bude dosahovat pro platformu Java EE maximální kompatibility. Pro buildování aplikace je používán nástroj Maven, který podporuje správu knihoven přes veřejný repozitář a umožňuje tak snadné spuštění aplikace každému vývojáři, který by se chtěl na vývoji podílet, bez ohledu na vývojové prostředí. Vývojáři frameworku Spring ve svých tutoriálech oficiálně doporučují, vedle nástroje Maven, také další alternativu Gradle [40]. Jelikož je Maven integrován přímo v prostředí NetBeans [23], je pro účely vývoje projektu používán.

4.3

Testování

Testování aplikace probíhá pomocí jednoduchých jUnit testů na úrovni jednotlivých doménových tříd. Tyto testy kontrolují funkčnost konstruktorů, getterů a setterů. V rámci vývoje byla aplikace rovněž průběžně testována programátorem. Během těchto testů byl kladen důraz především na bezpečnost a stabilitu aplikace. Po celou dobu testování nebyl nalezen žádný závažný problém.

4.4

Uživatelské účty

Aplikace podporuje celkem tři úrovně uživatelských účtů - účet běžného uživatele, administrátora a nepřihlášeného uživatele. Jejich autentizace i autorizace, v rámci webové části aplikace, je zajištěna frameworkem Spring Security, který je přímo vyvíjen komunitou zastřešující Spring framework. Spring Security je ověřený a rozšířený nástroj, který je velmi snadno použitelný a nastavitelný. Sám o sobě navíc nabízí řešení proti nejčastějším bez38

4.5. Šablony HTML stránek pečnostním útokům, kterými jsou například session fixation, clickjacking, cross site request forgery a další metody [42]. Hesla uživatelů jsou v databázi uložena zahashovaně pomocí SHA-1 algoritmu a soli, kterou reprezentuje unikátní uživatelské jméno. U opensource aplikací, kde potenciální útočník může nahlédnout přímo do zdrojových kódů, je nezbytné, aby hesla nebyla zpětně rozluštitelná ani pomocí databáze hashů, což by právě solení unikátní solí mělo zajistit. Pro větší míru zabezpečení je systémem vyžadováno heslo dlouhé alespoň osm znaků, které musí obsahovat alespoň jedno velké písmeno, jedno malé písmeno a jednu číslici.

4.5

Šablony HTML stránek

Ve view vrstvě aplikace je z důvodu jednoduchosti použit template engine Thymeleaf, který spolupracuje se Spring Frameworkem a umožňuje pohodlnou práci s objekty při generování HTML stránky. Podporuje podmíněné vypsání HTML tagu v závislosti na proměnné z controller vrstvy, cyklický výpis proměnných typu list, práci s formuláři a mnoho dalších možností. Díky rozšíření Spring security dialect spolupracuje Thymeleaf i se Spring Security a lze tak například snadno vypisovat uživatelské jméno, podmiňovat HTML tagy uživatelským oprávněním apod. [44] Pro Thymeleaf navíc existuje rozšíření Layout Dialect, díky kterému se lze velmi snadno vyvarovat neustále se opakujícím částem kódu. Umožňuje zadefinovat šablonu a v ní určit části, které jsou následně v jednotlivých stránkách doplněny nebo změněny [45].

4.6

Modularita

Veškerá reportování a testování probíhají pomocí modulů, které jsou zcela nezávislé na aplikaci samotné. Tyto moduly lze přidávat do aplikace i za běhu systému pouhým nahráním do předem definované složky. Aplikace hlídá změny ve složce a automaticky moduly načte přes Java Classloader. Administrátor musí takto přidané moduly povolit, a tím dokončit instalaci. Reportovací i testovací moduly se liší, nicméně některé základní funkce předdefinovaného interface mají společné: getOptionsJSON vrací JSON řetězec se všemi vyžadovanými vstupy pro nastavení a běh modulu. Z tohoto výstupu se vytváří v aplikaci HTML formulář, který uživatel vyplní, než začne modul používat. Pro každou položku je nutné vyplnit pole id, které jednoznačně identifi39

4. Implementace kuje údaj, type, který určuje o jaký typ vstupu se jedná. Volitelně i options, které mají význam například u select boxu. Položky title a description určují nadpis a bližší popis jednotlivých položek, které se generují do formuláře. Příkladem může být JSON řetězec: { "inputs": [ { "id": "db", "type": "select", "title": "Database type", "description": "Choose database type.", "options" : ["MySQL", "PostgreSQL", "MSSQL"] }, { "id": "url", "type": "text", "title": "URL of DB server", "description": "e.g. db.domain.com" }, { "id": "username", "type": "text", "title": "DB login", "description": "" }, { "id": "password", "type": "password", "title": "DB password", "description": "ATTENTION! Unfortunately, we have to save password in non-hash form, because we need to use your password to log in. Is strongly recommended to create a new user with only login privileges for testing." } ] }

Na základě uvedeného příkladu se vygenerují do formuláře celkem 4 HTML elementy: 40

4.6. Modularita • select s možností výběru mezi MySQL, PostgreSQL a MSSQL • dvakrát input s atributem type="text", jeden pro url a druhý pro username • input s atributem type="password" Všechny elementy jsou generovány s příslušnými popisky a jednoznačným id. getCallRequiredParamsName vrací pole řetězců, ve kterém jsou uvedena všechna id polí z předchozího bodu, která jsou modulem vyžadována pro spuštění. Pro uvedený příklad by tedy návratová hodnota funkce byla: return new Object[]{"url", "username", "password", "db"};

4.6.1

Reportovací moduly

Reportovací moduly jsou tvořeny jedním souborem, který musí splňovat předdefinovaný interface. Další podmínkou je pojmenování třídy a balíčku, ve kterém se třída nachází. Balíček musí být vždy checkit.plugin.report a třída musí být pojmenována vždy stejně jako výsledný soubor. Kromě již zmíněných funkcí obsahuje interface také funkce specifické pro reportovací moduly: package checkit.plugin.report; public interface Report { public Object getOptionsJSON(); public Object getCallRequiredParamsName(); public void reportDown(String checkTitle, Object[] params); public void reportUp(String checkTitle, Object[] params); public void reportRegular(String checkTitle, int numberOfDowns, long timeOfDowns, Object[] params); }

reportDown, reportUp a reportRegular zajišťují reportovaní v konkrétních situacích. Kromě parametrů, které jsou funkci předány vždy, 41

4. Implementace jsou rovněž předány hodnoty všech parametrů, které vrací funkce getCallRequiredParamsName. Pro lepší představu je kompletní zdrojový kód emailového reportovacího modulu uveden v příloze C.3.

4.6.2

Testovací moduly

Testovací moduly se skládají ze dvou částí. Celkový modul je tedy tvořen dvěma soubory. První ze dvou částí je určena pro server a obsahuje funkce pro vytvoření testování a zobrazení výsledků. Druhá část je určena pro agenta a obsahuje funkce potřebné k testování. Obě části musí splňovat předdefinovaný interface. Další podmínkou je pojmenování třídy a balíčku, ve kterém se třída nachází. Balíček musí být vždy checkit.plugin.check a třída musí být pojmenována vždy stejně jako výsledný soubor, pro obě části shodně. Soubory jsou poté umístěny do různých složek. Interface té části modulu, která je určena pro server, obsahuje kromě dříve zmíněné funkce getOptionsJSON i některé další: package checkit.plugin.check; public interface Check { public Object getOptionsJSON(); public Object getTableRequiredParamsName(); public Object getTableRequiredHeaderTitle(); }

getTableRequiredParamsName vrací pole řetězců, které obsahuje názvy parametrů z JSON řetězce s výsledkem testování. Tyto hodnoty jsou následně vypsány do tabulky HTML stránky s přehledem testování. Pokud není žádoucí zobrazovat další podrobnosti, funkce vrací null. getTableRequiredHeaderTitle vrací pole řetězců, které obsahuje nadpisy pro hodnoty získané z předchozí funkce. Tyto nadpisy jsou vypsány v záhlaví generované tabulky nad příslušnými sloupci. Pokud nejsou žádné další sloupce zobrazovány, funkce vrací null. Interface té části modulu, která je určena pro agenta, obsahuje kromě dříve zmíněné funkce getCallRequiredParamsName i některé další: 42

4.7. Komunikace mezi komponentami package checkit.plugin.check; public interface CheckAgent { public Object getCallRequiredParamsName(); public Object getResultParamsName(); public Object run(Object[] params); public Object isItOk(Object[] params); }

getResultParamsName vrací pole řetězců, které určují názvy v JSON řetězci s výsledky testování. run vrací pole objektů s výsledky testování. Funkci jsou předány hodnoty parametrů z funkce getCallRequiredParamsName. isItOk vrací boolean hodnotu, která určuje, zda je výsledek správný, a monitorovaná služba tedy funguje, nebo zda je nesprávný. Funkci jsou předány hodnoty parametrů z funkce getResultParamsName. Pro lepší představu je v příloze C.4 a C.5 uveden kompletní zdrojový kód modulu pro testování dostupnosti databází.

4.7

Komunikace mezi komponentami

Vzájemná komunikace mezi servery a agenty probíhá výhradně přes HTTP požadavky. Pro vzájemnou komunikaci není proto potřeba využívat ICMP protokol. Komunikace probíhá tak, že veškeré informace k odeslání jsou automaticky zařazovány do fronty k odeslání. Tato fronta je pravidelně odesílána a po úspěšném odeslání každého prvku je tento prvek z fronty vyřazen. Pokud se nepodaří požadavek vyřídit, prvek ve frontě zůstává i nadále. Veškerá komunikace je ověřována podle IP adresy serverů i agentů, což zamezuje případnému útočníkovi zaslat falešné výsledky nebo požadavky agentům či serverům a narušit tak stabilitu aplikace.

4.8

Uchovávání výsledků testů

Počet řádků v databázové tabulce pro výsledky by mohl dosáhnout značných hodnot již v poměrně krátkém čase. Pro testování byl stanoven minimální interval 15 sekund, který je zaveden čistě pro potřeby procesů, které 43

4. Implementace probíhají během testování. Test musí být spuštěn, a následně musí počkat na odpověď nebo uplynutí doby pro timeout. Poté musí být vyhodnocen výsledek a odeslán serveru, který jej uloží do databáze. I přes tento limit existuje vážné riziko, že počet řádků v tabulce překročí hranici, kdy je ještě aplikace plynulá a použitelná. Pokud by bylo zadefinováno celkem 20 000 testů s intervalem 15 sekund a ukládán by byl každý výsledek, za méně než dva a půl roku by v databázi bylo 100 miliard výsledků. Pro optimalizaci velikosti databáze byl zvolen takový způsob ukládání, kdy je uložen pouze stav, který se liší od stavu současného. Pokud je tedy monitorovaná služba aktuálně funkční, všechny výsledky potvrzující funkčnost jsou zahazovány.

4.9

Výsledky a statistiky

Aplikace zpřístupňuje uživateli přehled výsledků všech zadefinovaných testů. Tento přehled je tvořen tabulkou, která zobrazuje veškeré údaje zaznamenané během testování, a grafy, které jsou celkem čtyři: • graf zobrazující výsledky za uplynulých 24 hodin testování • celkem tři koláčové grafy, které znázorňují poměr funkčnosti, výpadků a neměřeného období za uplynulý týden, měsíc a celkové doby, po kterou testování probíhá Pro lepší představu o vzhledu stránky s výsledky jsou na obrázcích 4.1 a 4.2 zobrazeny screenshoty generovaných grafů a tabulky přímo z aplikace.

4.10

Vlákna

U aplikace lze očekávat, že bude vykonávat poměrně velké množství požadavků. Z tohoto důvodu jsou vybrané procesy, které jsou poměrně časté nebo časově náročnější, spouštěny ve vlastním vlákně. Konkrétně tyto: • odesílání emailů pro ověření emailové adresy • sledování změn ve složkách s moduly • vzájemná komunikace mezi servery a agenty • veškerá reportování a testování

44

4.10. Vlákna

Obrázek 4.1: Screenshot grafů s výsledky testování

Obrázek 4.2: Screenshot tabulky s výsledky testování

45

Kapitola

Další rozvoj aplikace Z důvodu rozsáhlosti aplikace obsahuje prototyp pouze částečnou funkcionalitu plánované konečné podoby aplikace. Implementované části umožňují především spuštění a základní používání aplikace, aby bylo možné začít projekt vyvíjet v komunitě vývojářů.

5.1

Modularita

Současné řešení modularity sice umožňuje načtení modulu za běhu aplikace, ale například s aktualizací nebo smazáním modulu je situace komplikovanější, neboť soubor je používán aplikací a nelze jej přepsat nebo smazat. Navíc moduly načtené přes Java Classloader obsahují pouze třídu, která zajišťuje funkcionalitu vyžadovanou pro existující šablony. Nelze například definovat vlastní stránku pro zobrazení výsledků nebo vlastní stránku pro nastavení modulu. V budoucnu bude potřeba do projektu integrovat platformu OSGi, která je vyvíjena přímo pro tuto funkcionalitu a zmíněné problémy řeší. Navíc podporuje sandboxing, který momentálně není v aplikaci řešený [30]. Taktéž bude potřeba zavést mechanismus, který umožní kontrolovat vložená uživatelská data pro účely nastavení modulu. V současném řešení není možné u modulu definovat, která pole jsou povinná, která volitelná, a jak má být pole ověřováno. Pokud tedy uživatel u emailového reportovacího modulu vyplní do pole pro email libovolný řetězec, modul toto přijme a nastane chyba až při odesílání emailu. 47

5

5. Další rozvoj aplikace

5.2

Testování

Současné testování aplikace probíhá pomocí jednoduchých testů na úrovni jednotlivých doménových tříd. Bude potřeba testování dobře promyslet a navrhnout sadu automatických testů, které prověří funkčnost a stabilitu aplikace v co největší míře. Při vývoji v týmu je automatické testování velmi účinnou možností, jak udržet aplikaci stabilní a funkční. Bude potřeba také navrhnout testování pro moduly, které není v současné době zavedeno. Toto testování by mělo počítat i s tím, že modul nemusí být nutně opensource a otestovat jeho chování oproti různým vstupům a situacím.

5.3

Nárůst počtu serverů a agentů

Aplikace je momentálně implementována a testována na jednom počítači s jedním serverem a jedním agentem. Server s agentem jsou od sebe odděleni, mají oddělené databáze a komunikují spolu přes HTTP požadavky. Při vývoji aplikace byl brán zřetel na to, že počet agentů a serverů se může zvýšit, nicméně některé funkce bude potřeba pozměnit. V budoucnu bude potřeba aplikaci upravit pro případ, kdy chodí výsledky od více agentů, a kdy je více hlavních serverů, které se vzájemně zrcadlí a synchronizují.

5.4

Rozdělení aplikace

Aktuálně je aplikace rozdělena na dva funkční celky. Agent provádí monitorování a vyhodnocování výsledků a server veškerou ostatní činnost. Pro lepší stabilitu aplikace by bylo vhodné server ještě dále rozdělit na další samostatné celky, které budou mít na starost například komunikaci s agenty, obsluhu modulů, reportování, funkce webového prostředí apod. Díky takovémuto dělení by aplikace i při selhání jedné z těchto částí nadále fungovala. Jednotlivé části aplikace by mohly být na sobě nezávislé. To znamená, že by nevolaly vzájemně své funkce a nepředávaly by si úkoly. Vše by mohlo fungovat na základě změn prováděných v databázi. Pokud by například přibyl v databázi nový test, komponenta pro obsluhování agentů by okamžitě rozeslala agentům zadání nového testování. 48

5.5. Zpřístupnění projektu veřejnosti

5.5

Zpřístupnění projektu veřejnosti

Současná aplikace je prezentována na stránkách GitHub.com1 , pod pracovním názvem checkit. Bylo by vhodné zajistit produktovou stránku projektu, která je naznačena v prototypu, a aplikaci spustit pro veřejnost, protože pouze jejím používáním lze zajistit i budoucí rozvoj a zlepšování. Vhodné by bylo navázat spolupráci například se společností, která by z počátku poskytla kvalitní hosting a umožnila tak rozvoj aplikace. Při zpřístupnění aplikace veřejnosti musí být kladen důraz především na spolehlivost a stabilitu, která je v této oblasti klíčová a pomůže získat uživatele.

5.6

Další návrhy

Mezi další návrhy pro rozvoj aplikace lze zařadit: • Zlepšení uživatelského rozhraní, které není v aplikaci příliš řešeno, jelikož byl při vývoji kladen důraz především na funkčnost. • Rozšíření administrátorského nastavení přes webové rozhraní. Například možnost spouštět a zastavovat skenování složek s moduly, možnost definovat formáty času a umístění souborů s moduly apod. • Možnou podporu jazykových variant. • Vývoj uživatelského API. • Zefektivnění komunikace mezi jednotlivými komponentami. • Okamžité otestování dostupnosti služby už během vytváření nového testu. Tato funkce by umožnila uživateli ještě před spuštěním testování ověřit, zda byly zadány všechny údaje správně. Test by navíc bezprostředně po spuštění získal příslušný status a nemusel by čekat na odpověď agenta. • Stanovení minimální doby intervalu pro měření služeb, které nespravuje uživatel, který testování zadal. Více o této problematice je popsáno v kapitole 2.7. • Postupné implementování další funkčnosti z kapitoly 2.3.

1

konkrétně na adrese https://github.com/Murmand/checkit

49

Závěr Cílem této práce bylo navrhnout systém pro základní monitoring serverů a domén, implementovat prototyp tohoto systému a pokusit se okolo něj vytvořit vývojářskou komunitu pro následný týmový rozvoj. Výsledkem je webová aplikace napsaná v programovacím jazyce Java. Aplikace nabízí uživatelskou administraci dostupnou z webového rozhraní, podporuje uživatelské účty a moduly třetích stran, které jsou na aplikaci zcela nezávislé. Veškeré testování dostupnosti a oznamování o nalezených chybách probíhá výhradně formou modulů. Z výsledků testování se vytvářejí statistiky, jejichž součástí jsou i grafy. Aplikace podporuje také pravidelné reporty a okamžité oznámení jak o výpadku služby, tak i o jejím znovuobnovení. Aplikace obsahuje ukázkové moduly, které měří dostupnost HTTP, FTP, IMAP a MySQL, MSSQL a PostrgeSQL databází. Reportování probíhá emailem. Zdrojové kódy výsledného prototypu jsou umístěny na stránkách GitHub.com. V současné době se k projektu nepřidal žádný vývojář, což přisuzuji především faktu, že aplikace není nikde veřejně spuštěna k používání. Věřím, že po jejím zveřejnění přitáhne pozornost nejen uživatelů, ale i dalších vývojářů. Vývoj aplikace je díky zamýšlené rozsáhlosti teprve v začátcích. Je potřeba dokončit a vyřešit další části projektu, jako je například zdokonalení modularity, zavedení kvalitního testování, zajištění několika kvalitních serverů pro spolehlivé nasazení aplikace a dokončení implementace, která bude fungovat s více servery a agenty, dodělání produktového webu, zlepšení uživatelského rozhraní a designu, podporu jazykových variant, vývoj uživatelského API, doimplementování všech zbývajících funkcí popsaných v analýze. Vzhledem k tomu, kolik prostoru ve vývoji ještě projekt nabízí, rád bych 51

Závěr se mu i nadále věnoval v rámci diplomové práce a posunul ho zase o kousek blíže k zamýšlenému cíli.

52

Literatura [1] Alexa: Alexa Site Overview. [cit. 2014-05-11]. Dostupné http://www.alexa.com/topsites/category/Top/Computers/ Open_Source/Project_Hosting

z:

[2] Can I use...: Support tables for HTML5, CSS3, etc. [cit. 2014-03-13]. Dostupné z: http://caniuse.com/#cats=HTML5 [3] CodePlex: Documentation. [cit. 2014-05-11]. Dostupné z: http:// codeplex.codeplex.com/documentation [4] CodePlex: Project Directory. [cit. 2014-05-11]. Dostupné z: http:// www.codeplex.com/site/search [5] DB-Engines: Microsoft SQL Server vs. MySQL vs. Oracle vs. PostgreSQL Comparison. [cit. 2014-03-11]. Dostupné z: http://db-engines.com/en/system/Microsoft+SQL+Server% 3BMySQL%3BOracle%3BPostgreSQL [6] Dostálek, L.; Kabelová, A.: Velký průvodce protokoly TCP/IP a systémem DNS. Computer Press, třetí vydání, 2002, ISBN 80-7226-675-6. [7] Doxygen: Manual: Documenting the code. [cit. 2014-05-11]. Dostupné z: http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html [8] Forouzan, B. A.: TCP/IP Protocol Suite. McGraw-Hill, třetí vydání, 2006, ISBN 0-07-296772-2. [9] GitHub: Features. [cit. 2014-05-11]. Dostupné z: https://github.com/ features 53

Literatura [10] GitHub: Press. [cit. 2014-05-11]. Dostupné z: https://github.com/ about/press [11] GlassFish: GlassFish Server. [cit. 2014-04-07]. Dostupné z: https:// glassfish.java.net/ [12] Google: Verify domain ownership - Google Apps Administrator Help. [cit. 2014-03-05]. Dostupné z: https://support.google.com/a/ answer/60216?hl=en [13] html5shiv: HTML5 IE enabling script - Google Project Hosting. [cit. 2014-03-13]. Dostupné z: https://code.google.com/p/html5shiv/ [14] Irokez.cz: profesionální monitoring dostupnosti serverů. [cit. 2013-1124]. Dostupné z: http://www.irokez.cz/ [15] Java: Learn about Java Technology. [cit. 2014-03-03]. Dostupné z: http: //www.java.com/en/about/ [16] Java-source.net: Open Source Web Frameworks in Java. [cit. 201403-03]. Dostupné z: http://java-source.net/open-source/webframeworks [17] jqPlot: Charts and Graphs for jQuery. [cit. 2014-03-13]. Dostupné z: http://www.jqplot.com/ [18] jQuery: jQuery. [cit. 2014-03-13]. Dostupné z: http://jquery.com/ [19] Launchpad: Launchpad. [cit. 2014-05-11]. Dostupné z: https:// launchpad.net/ [20] Launchpad: People and teams in Launchpad. [cit. 2014-05-11]. Dostupné z: https://launchpad.net/people [21] Launchpad: Projects registered in Launchpad. [cit. 2014-05-11]. Dostupné z: https://launchpad.net/projects/ [22] Linden, P. V. D.: Just Java 2. Pearson Education, 6 vydání, 2004, ISBN 0-13-148211-4. [23] Maven: Maven Support for NetBeans. [cit. 2014-04-07]. Dostupné z: http://maven.apache.org/netbeans-module.html [24] Monitoring serverů: Monitoring serverů, měření dostupnosti stránek [Monitoring-serverů.cz]. [cit. 2013-11-24]. Dostupné z: http:// www.monitoring-serveru.cz/ 54

Literatura [25] Monitor.Us: API Documentation. [cit. 2013-11-26]. Dostupné z: http: //www.monitor.us/api/api.html#rest_api_getting_started [26] Monitor.Us: FREE Website Monitoring & Monitoring Software from Monitor.Us. [cit. 2013-11-24]. Dostupné z: http://monitor.us/en/ website-monitoring/ [27] MySQL: MySQL 5.1 Reference Manual :: 17.6.10 MySQL Cluster Replication: Multi-Master and Circular Replication. [cit. 201403-11]. Dostupné z: https://dev.mysql.com/doc/refman/5.1/en/ mysql-cluster-replication-multi-master.html [28] MySQL: MySQL 5.7 Reference Manual :: 1.3.2 The Main Features of MySQL. [cit. 2014-03-11]. Dostupné z: http://dev.mysql.com/doc/ refman/5.7/en/features.html [29] NETCRAFT LTD: February 2014 Web Server Survey | Netcraft. [cit. 2014-02-26]. Dostupné z: http://news.netcraft.com/archives/ 2014/02/03/february-2014-web-server-survey.html [30] OSGi: OSGi Alliance | Technology / The OSGi Architecture. [cit. 201405-06]. Dostupné z: http://www.osgi.org/Technology/WhatIsOSGi [31] Pingdom AB: Pingdom API documentation. [cit. 2013-11-26]. Dostupné z: https://www.pingdom.com/features/api/documentation/ [32] Pingdom AB: Website Monitoring. [cit. 2013-11-24]. Dostupné z: https://www.pingdom.com/ [33] Postgres-XC: What is Postgres-XC? [cit. 2014-03-11]. Dostupné z: http://postgres-xc.sourceforge.net/docs/1_2_beta/introwhatis.html [34] PostgreSQL: Feature Matrix. [cit. 2014-03-11]. Dostupné z: http:// www.postgresql.org/about/featurematrix/ [35] Pužmanová, R.: TCP/IP v kostce. KOPP, 2004, ISBN 80-7232-236-2. [36] Schmidt, K.: High Availability and Disaster Recovery. Springer, 2006, ISBN 978-3-540-24460-8. [37] SeleniumHQ: Selenium - Web Browser Automation. [cit. 2013-11-26]. Dostupné z: http://www.seleniumhq.org/ [38] SourceForge: About. [cit. //sourceforge.net/about

2014-05-11].

Dostupné

z:

http:

55

Literatura [39] SourceForge: Documentation. [cit. 2014-05-11]. Dostupné z: http:// sourceforge.net/p/forge/documentation/Docs%20Home/ [40] Spring: Guides. [cit. 2014-04-07]. Dostupné z: http://spring.io/ guides [41] Spring: Spring Framework Reference Documentation. [cit. 2014-03-03]. Dostupné z: http://docs.spring.io/spring/docs/4.0.2.RELEASE/ spring-framework-reference/htmlsingle/ [42] Spring: Spring Security. [cit. 2014-04-07]. Dostupné z: http:// projects.spring.io/spring-security/ [43] STASI.cz: Monitoring dostupnosti Vašeho serveru. [cit. 2013-11-24]. Dostupné z: https://www.stasi.cz/ [44] Thymeleaf: java XML/XHTML/HTML5 template engine. [cit. 201404-07]. Dostupné z: http://www.thymeleaf.org/ [45] Thymeleaf Layout Dialect: ultraq/thymeleaf-layout-dialect · GitHub. [cit. 2014-04-07]. Dostupné z: https://github.com/ultraq/ thymeleaf-layout-dialect [46] TIOBE Software BV: The Coding Standards Company. [cit. 2014-03-03]. Dostupné z: http://www.tiobe.com/index.php/content/ paperinfo/tpci/index.html [47] Uptime Robot: API. [cit. 2013-11-26]. Dostupné z: http:// uptimerobot.com/api [48] Uptime Robot: Uptime Robot. [cit. 2013-11-24]. Dostupné z: http:// uptimerobot.com/ [49] Walls, C.: Spring in Action. Manning Publications Co., třetí vydání, 2011, ISBN 978-1-935182-35-1.

56

Příloha

Seznam použitých zkratek AJAX Asynchronous JavaScript and XML AOP Aspect-Oriented Programming API Application Programming Interface CSS Cascading Style Sheets DNS Domain Name System DOM Document Object Model FAQ Frequently Asked Questions FTP File Transfer Protocol HTML HyperText Markup Language HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure ICMP Internet Control Message Protocol IM Instant Messaging IMAP Internet Message Access Protocol IP Internet Protocol JSON JavaScript Object Notation LDAP Lightweight Directory Access Protocol 57

A

A. Seznam použitých zkratek OSGi Open Service Gateway initiative POJO Plain Old Java Object POP Post Office Protocol RSS Rich Site Summary SASS Syntactically Awesome Stylesheets SIP Session Initiation Protocol SMS Short Message Service SMTP Simple Mail Transfer Protocol SOAP Simple Object Access Protocol SQL Structured Query Language SSH Secure Shell TCP Transmission Control Protocol UDP User Datagram Protocol XML Extensible Markup Language

58

Příloha

Obrázky

59

B

B. Obrázky

Obrázek B.1: Podrobný diagram případů užití pro běžného uživatele

60

Aplikace

Prehled uzivatelu a jejich zadanych testu

Zobrazeni profilu

«include»

«include»

Zmena emailove adresy

Povoleni/zakazani agentu

«include»

Blokace/odblokace uzivatelu

«extend»

Pridani agenta

«include»

Editace profilu

Prehled agentu

«include» Smazani agenta Prehled modulu «include» Povoleni/zakazani modulu

Prirazeni reportovacich metod

«include» Pridani kontaktu Editace reportovacich metod

«extend» Editace kontaktu

Admin

«include» Smazani kontaktu

Detaily testu a podrobnosti k vysledkum

«extend»

Grafy, prumerne statistiky za urcite obdobi, ...

«include»

Pozastaveni/spusteni testu

«include»

Smazani testu

«include»

«include»

«include»

Prehled kontaktu

Editace testu

«include»

Prehled testu a jejich vysledku

«include»

Pridani testu

«extend»

«extend»

Prirazeni a editace kontaktu pro pripadne reporty

Obrázek B.2: Podrobný diagram případů užití pro administrátora 61

B. Obrázky

Obrázek B.3: Sběr požadavků - dotazník 1/3

62


63

B. Obrázky


64

Příloha

Zdrojové kódy C.1

SQL skripty pro vytvoření databází

Zdrojový kód C.1: Skript pro vytvoření databáze serveru CREATE TABLE user_roles( user_role_id SERIAL PRIMARY KEY, authority VARCHAR(50) UNIQUE NOT NULL ); CREATE TABLE users( user_id SERIAL PRIMARY KEY, username VARCHAR(50) UNIQUE NOT NULL, user_role_id INTEGER NOT NULL, password VARCHAR(50) NOT NULL, email VARCHAR(100) UNIQUE NOT NULL, enabled BOOLEAN NOT NULL, created TIMESTAMP NOT NULL, FOREIGN KEY (user_role_id) REFERENCES user_roles(user_role_id) ); CREATE TABLE user_activation( user_activation_id VARCHAR(50) PRIMARY KEY, user_id INTEGER NOT NULL, email VARCHAR(100) UNIQUE NOT NULL, FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE );

65

C

C. Zdrojové kódy

CREATE TABLE contacts( contact_id SERIAL PRIMARY KEY, title VARCHAR(50) NOT NULL, user_id INTEGER NOT NULL, FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE ); CREATE TABLE plugins_report( filename VARCHAR(50) PRIMARY KEY, enabled BOOLEAN NOT NULL, title VARCHAR(50) UNIQUE NOT NULL, description VARCHAR(50) ); CREATE TABLE plugins_check( filename VARCHAR(50) PRIMARY KEY, enabled BOOLEAN NOT NULL, title VARCHAR(50) UNIQUE NOT NULL, description VARCHAR(50) ); CREATE TABLE contact_detail( contact_detail_id SERIAL PRIMARY KEY, title VARCHAR(50) NOT NULL, data JSON NOT NULL, contact_id INTEGER NOT NULL, user_id INTEGER NOT NULL, filename VARCHAR(50) NOT NULL, down BOOLEAN NOT NULL, up BOOLEAN NOT NULL, regular BOOLEAN NOT NULL, FOREIGN KEY (contact_id) REFERENCES contacts(contact_id) ON DELETE CASCADE, FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE, FOREIGN KEY (filename) REFERENCES plugins_report(filename) ON DELETE CASCADE ); CREATE TABLE checks( check_id SERIAL PRIMARY KEY,

66

C.1. SQL skripty pro vytvoření databází title VARCHAR(50) NOT NULL, data JSON NOT NULL, enabled BOOLEAN NOT NULL, user_id INTEGER NOT NULL, filename VARCHAR(50) NOT NULL, interval INTEGER NOT NULL, ok BOOLEAN NOT NULL, checked BOOLEAN NOT NULL, FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE, FOREIGN KEY (filename) REFERENCES plugins_check(filename) ON DELETE CASCADE ); CREATE TABLE reporting( user_id INTEGER NOT NULL, check_id INTEGER NOT NULL, contact_id INTEGER NOT NULL, FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE, FOREIGN KEY (check_id) REFERENCES checks(check_id) ON DELETE CASCADE, FOREIGN KEY (contact_id) REFERENCES contacts(contact_id) ON DELETE CASCADE, PRIMARY KEY (user_id, check_id, contact_id) ); CREATE RULE "reporting_on_duplicate_ignore" AS ON INSERT TO "reporting" WHERE EXISTS(SELECT 1 FROM reporting WHERE (check_id, check_id, contact_id)=(NEW.check_id, NEW.check_id, NEW.contact_id) ) DO INSTEAD NOTHING; CREATE TABLE agents( agent_id SERIAL PRIMARY KEY, ip VARCHAR(50) NOT NULL, post_address VARCHAR(50) NOT NULL, location VARCHAR(50) NOT NULL, enabled BOOLEAN NOT NULL ); CREATE TABLE checking(

67

C. Zdrojové kódy agent_id INTEGER NOT NULL, check_id INTEGER NOT NULL, user_id INTEGER NOT NULL, FOREIGN KEY (agent_id) REFERENCES agents(agent_id) ON DELETE RESTRICT, FOREIGN KEY (check_id) REFERENCES checks(check_id) ON DELETE CASCADE, FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE, PRIMARY KEY (agent_id, check_id) ); CREATE TABLE agent_queue( agent_queue_id SERIAL PRIMARY KEY, agent_id INTEGER NOT NULL, check_id INTEGER NOT NULL, query VARCHAR(50) NOT NULL ); CREATE TABLE results( check_id INTEGER NOT NULL, agent_id INTEGER NOT NULL, time TIMESTAMP NOT NULL, status VARCHAR(1) NOT NULL, data JSON, FOREIGN KEY (check_id) REFERENCES checks(check_id) ON DELETE CASCADE, PRIMARY KEY (check_id, agent_id, time) );

Zdrojový kód C.2: Skript pro vytvoření databáze agenta CREATE TABLE servers( ip VARCHAR(50) PRIMARY KEY, post_address VARCHAR(50) NOT NULL, priority INT NOT NULL ); CREATE TABLE checks( check_id INTEGER NOT NULL, data JSON NOT NULL,

68

C.2. Ukázky modulů filename VARCHAR(50) NOT NULL, interval INT NOT NULL, PRIMARY KEY (check_id) ); CREATE TABLE results( check_id INTEGER NOT NULL, time TIMESTAMP NOT NULL, status VARCHAR(1) NOT NULL, data JSON NOT NULL, PRIMARY KEY (check_id, time) );

C.2

Ukázky modulů Zdrojový kód C.3: Emailový reportovací modul

package checkit.plugin.report; import import import import import import import import import import import

java.util.Date; java.util.Properties; java.util.logging.Level; java.util.logging.Logger; javax.mail.Message; javax.mail.MessagingException; javax.mail.PasswordAuthentication; javax.mail.Session; javax.mail.Transport; javax.mail.internet.InternetAddress; javax.mail.internet.MimeMessage;

public class Email implements Report { @Override public Object getOptionsJSON() { return "{" + "\"inputs\": [" + "{" + "\"id\": \"email\"" + "\"type\": \"text\"," + "\"title\": \"Email\","

69

C. Zdrojové kódy +

"\"description\": \"e.g. [email protected]\"" + "}" + "]" + "}"; } @Override public Object getCallRequiredParamsName() { return new Object[]{"email"}; } @Override public void reportDown(String checkTitle, Object[] params) { String email = params[0].toString(); sendEmail(email, "Monitor is DOWN: " + checkTitle, "
Hi,
" + "
" + "The monitor " + checkTitle + " is currently DOWN (Service Unavailable).
" + "
" + "For further details log in to your account at myCheckIT.
" + "
" + "Best regards,
" + "CheckIT!"); } @Override public void reportUp(String checkTitle, Object[] params) { String email = params[0].toString(); sendEmail(email, "Monitor is UP: " + checkTitle, "
Hi,
" + "
" + "The monitor " + checkTitle + " is back UP (OK).
" + "
" + "For further details about antecedent failure log in to your account at myCheckIT.
" + "
" + "Best regards,
" + "CheckIT!");

70

C.2. Ukázky modulů } @Override public void reportRegular(String checkTitle, int numberOfDowns, long timeOfDowns, Object[] params) { String email = params[0].toString(); sendEmail(email, "Weekly report: " + checkTitle, "
Hi,
" + "
" + "In this week " + numberOfDowns + " failures occurred in a total time of " + timeOfDowns + " seconds.
" + "
" + "For further details log in to your account at myCheckIT.
" + "
" + "Best regards,
" + "CheckIT!"); } private void sendEmail(String email, String subject, String message) { Properties props = new Properties(); props.put("mail.smtp.auth", "true"); props.put("mail.smtp.starttls.enable", "true"); props.put("mail.smtp.host", "smtp.gmail.com"); props.put("mail.smtp.port", "587"); Session session = Session.getInstance(props, new javax.mail.Authenticator() { @Override protected PasswordAuthentication getPasswordAuthentication() { return new PasswordAuthentication(username, password); } }); try { Message msg = new MimeMessage(session); msg.setSubject(subject); msg.setRecipient(Message.RecipientType.TO, new InternetAddress(email, false));

71

C. Zdrojové kódy msg.setContent(message, "text/html; charset=utf-8"); msg.setSentDate(new Date()); Transport.send(msg); } catch (MessagingException ex) { Logger.getLogger(Email.class.getName()).log(Level.SEVERE, null, ex); } } }

Zdrojový kód C.4: Testovací modul databází, serverová část package checkit.plugin.check; public class Databases implements Check { @Override public Object getOptionsJSON() { return "{" + "\"inputs\": [" + "{" + "\"id\": \"db\"," + "\"type\": \"select\"," + "\"title\": \"Database type\"," + "\"description\": \"Choose database type.\"," + "\"options\" : [\"MySQL\", \"PostgreSQL\", \"MSSQL\"]" + "}," + "{" + "\"id\": \"url\"," + "\"type\": \"text\"," + "\"title\": \"URL of DB server\"," + "\"description\": \"e.g. db.domain.com\"" + "}," + "{" + "\"id\": \"username\"," + "\"type\": \"text\"," + "\"title\": \"DB login\"," + "\"description\": \"\"" + "},"

72

C.2. Ukázky modulů + + + + +

"{" "\"id\": \"password\"," "\"type\": \"password\"," "\"title\": \"DB password\"," "\"description\": \"ATTENTION! Unfortunately, we have to save password in non-hash form, because we need to use your password to log in. Is strongly recommended to create a new user with only login privileges for testing.\"" + "}" + "]" + "}"; } @Override public Object getTableRequiredParamsName() { return (Object) null; } @Override public Object getTableRequiredHeaderTitle() { return (Object) null; } }

Zdrojový kód C.5: Testovací modul databází, část pro agenta package checkit.plugin.check; import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; public class Databases implements CheckAgent { @Override public Object getCallRequiredParamsName() { return new Object[]{"url", "username", "password", "db"}; } @Override

73

C. Zdrojové kódy public Object getResultParamsName() { return new Object[]{"ok"}; } @Override public Object run(Object[] params) { String url = params[0].toString(); String username = params[1].toString(); String password = params[2].toString(); String db = params[3].toString(); boolean reachable = false; switch (db) { case "MSSQL": db = "sqlserver"; break; case "PostgreSQL": db = "postgresql"; break; case "MySQL": db = "mysql"; break; } try { Connection con = DriverManager.getConnection("jdbc:" + db + "://" + url, username, password); reachable = con.isValid(5); } catch (SQLException ex) { } return new Object[] {reachable}; } @Override public Object isItOk(Object[] params) { return params[0]; } }

74

Příloha

Obsah přiloženého CD

readme.txt ................................ stručný popis obsahu CD results_poll.xlsx ... kompletní výsledky ankety pro sběr požadavků src impl.................................zdrojové kódy implementace thesis....................zdrojová forma práce ve formátu LATEX text.....................................................text práce thesis.pdf...........................text práce ve formátu PDF 75

D

Sem vložte zadání Vaší práce

Recommend Documents