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

Transkript

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

2

3 Č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

4

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

6

7 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

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

9 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

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

11 Obsah Úvod 1 1 Současná řešení Testování Oznámení Reporty a statistiky Omezení pro užívání zdarma Souhrn Analýza a návrh aplikace Specifikace cíle Sběr požadavků Analýza požadavků Případy užití Rozdělení aplikace Řešení síťových výpadků Prevence přetížení aplikace Doménový model Databázový model Specifikace použitých technologií Týmový rozvoj aplikace Zázemí opensource projektů Tvorba komunity Implementace Souhrn implementované funkcionality xi

12 4.2 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 Další rozvoj aplikace Modularita Testování Nárůst počtu serverů a agentů Rozdělení aplikace Zpřístupnění projektu veřejnosti Další návrhy 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í C.2 Ukázky modulů D Obsah přiloženého CD 75 xii

13 Seznam obrázků 2.1 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 Software BV [46] Screenshot grafů s výsledky testování Screenshot tabulky s výsledky testování B.1 Podrobný diagram případů užití pro běžného uživatele B.2 Podrobný diagram případů užití pro administrátora B.3 Sběr požadavků - dotazník 1/ B.4 Sběr požadavků - dotazník 2/ B.5 Sběr požadavků - dotazník 3/ xiii

14

15 Seznam tabulek 1.1 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 jednotlivými projekty Přehled dalších možností testování Přehled funkcí API Přehled prostředků k oznámení vzniklé chyby Přehled možností nastavení upozornění Přehled reportů a statistik Omezení pro účty zdarma Přehled vybraných funkcí u služeb nabízejících hostování projektů 36 xv

16

17 Ú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 kontrolo- 1

18 Ú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

19 Kapitola 1 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ž 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 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

20 1. Současná řešení Tabulka 1.1: Přehled testovaných protokolů Pingdom Monitor.Us Uptime Robot Monitoring serverů Irokez Stasi HTTP HTTPS FTP POP3 IMAP SMTP LDAP SSH Telnet TCP UDP ICMP SIP SOAP nastavitelný port s přihlašovacími údaji 1.1 Testování Protokoly 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] 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

21 1.1. Testování Tabulka 1.2: Přehled testovaných databází Pingdom Monitor.Us Uptime Robot Monitoring serverů MySQL PostgreSQL Irokez Stasi 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] 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

22 1. Současná řešení Tabulka 1.3: Přehled projektů testujících DNS Pingdom Monitor.Us Uptime Robot Monitoring serverů Irokez DNS Stasi Tabulka 1.4: Přehled počtu síťově nezávislých serverů provozovaných jednotlivými projekty Pingdom Monitor.Us Uptime Robot Monitoring serverů Irokez Stasi počet síťově nezávislých serverů > 2 > 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: 6 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].

23 1.1. Testování Tabulka 1.5: Přehled dalších možností testování Pingdom Monitor.Us Uptime Robot Monitoring serverů Irokez Stasi ping existence klíčových slov absence klíčových slov kompletní kontrola stránky podpora nástroje Selenium sledování systému Přehled projektů a jejich dalších možností testování je uveden v tabulce 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

24 1. Současná řešení Tabulka 1.6: Přehled funkcí API Pingdom Monitor.Us Uptime Robot správa kontaktů správa oznámení správa úkolů statistiky Monitoring serverů Irokez Stasi 1.2 Oznámení Prostředky Pokud je během testů objeven problém, je tato skutečnost oznámena uživateli. Kromě klasického upozornění na 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] 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

25 1.3. Reporty a statistiky Tabulka 1.7: Přehled prostředků k oznámení vzniklé chyby Pingdom Monitor.Us Uptime Robot Monitoring serverů Irokez Stasi SMS XML RSS POST IM mobilní aplikace Twitter 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

26 1. Současná řešení Tabulka 1.8: Přehled možností nastavení upozornění Pingdom Monitor.Us Uptime Robot Monitoring serverů Irokez Stasi správce kontaktů nastavitelná prodleva možnost reportu během chyby report po skončení chyby Tichý režim Tabulka 1.9: Přehled reportů a statistik Pingdom Monitor.Us Uptime Robot Monitoring serverů Irokez Stasi pravidelné reporty archivace alespoň rok 1.4 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

27 1.5. Souhrn Tabulka 1.10: Omezení pro účty zdarma Pingdom 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) 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 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, ový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, u, 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 . 11

28 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 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, ový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, u, 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ů Uptime Robot Uptime Robot [48] podporuje kontrolu základních webových prezentací, ový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, u, 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

29 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 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, ový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, u, 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 . 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 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 u. 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

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

31 Kapitola 2 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

32 2. Analýza a návrh aplikace například 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 u, 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, ů 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

33 2.3. Analýza požadavků Obrázek 2.1: Výsledky ankety 17

34 2. Analýza a návrh aplikace rozvoji. Funkce, které nejsou zamýšleny v rámci prototypu, jsou v textu vyznačeny kurzívou Funkční požadavky 18 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ů

35 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 , uživatelské jméno a heslo. Tyto položky lze považovat jako jediné nezbytné pro úspěšnou registraci. 19

36 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

37 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í 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

38 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í ové 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 ové 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, 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

39 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

40 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í: 24 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ě.

41 2.6. Řešení síťových výpadků Klient «executionenvironment» Prohlizec HTTP Agent Server Agent «executionenvironment» Aplikace 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 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

42 2. Analýza a návrh aplikace 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] 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: 26 výpadek přetrvává, agent není schopen předat výsledek serveru

43 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 kon- 27

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

45 2.9. Databázový model Plugin - description :char - enabled :boolean - filename :char - title :char PluginReport PluginCheck 1 1 Agent 0..* ContactDetail 0..* - enabled :boolean - ip :char - location :char - postaddress :char - data :json - down :boolean - regular :boolean - title :char - up :boolean 1..* 1 Contact - title :char 0..* 0..* 0..* Check - data :json - enabled :boolean - checked :boolean - interval :int - ok :boolean - title :char 0..* 1 0..* Result - agentid :int - data :json - status :char - time :timestamp 0..* 1..* 1 User AgentQueue 1 - created :timestamp - char - enabled :boolean - password :char - username :char - userrole :char - agentid :int - query :char - testid :int Obrázek 2.4: Doménový model 29

46 2. Analýza a návrh aplikace PLUGINS CONTACT_DETAIL # * contact_detail_id * title * data * down * up * regular # * filename * enabled * title o description PLUGINS_REPORT PLUGINS_CHECK CHECKING AGENTS # * agent_id * ip * post_address * location * enabled CONTACTS # * contact_id * title REPORTING # * check_id * title * data * enabled * interval * ok * checked CHECKS # * time # * agent_id * status o data RESULTS USERS # * user_id * username * password * * enabled * created USER_ACTIVATION # * user_activation_id * # * user_role_id * authority USER_ROLES AGENT_QUEUE # * 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 # * check_id * data * filename * interval CHECKS # * check_id # * time * status * data RESULTS Obrázek 2.6: Logické schéma databázového modelu agenta 30

47 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 em, čímž dojde k ověření ové 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 Specifikace použitých technologií 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

48 2. Analýza a návrh aplikace 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 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á dispo- 32

49 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] 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

50

51 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

52 3. Týmový rozvoj aplikace Tabulka 3.1: Přehled vybraných funkcí u služeb nabízejících hostování projektů GitHub.com SourceForge.net CodePlex.com Launchpad.net verzování zobrazení kódu a změn bugtracking wiki podpora týmů API podpora SSH klíčů 3.2 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

53 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. ová adresa uživatele je ověřována při registraci i při každé změně u. 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

54 4. Implementace K dispozici je jeden reportovací modul, který používá 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 bez- 38

55 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ě identifi- 39

56 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

57 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"}; 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

58 4. Implementace jsou rovněž předány hodnoty všech parametrů, které vrací funkce getcallrequiredparamsname. Pro lepší představu je kompletní zdrojový kód ového reportovacího modulu uveden v příloze C 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

59 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

60 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 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 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í ů pro ověření ové 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

61 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