Administrátoři se v minulosti typicky starali o to, aby aplikace tzv. jela. S rostoucí závislostí firem na IT, podporou různých zařízení, hybridními prostředími, a geograficky oddělenými pracovišti se ale jejich role změnila. Aplikace je často velmi důležitou součástí byznysu firma a už nestačí, aby jen „jela“. Musí fungovat velmi dobře. Nedostupnost e-shopu, zákaznického portálu, internetového bankovnictví nebo gamingového serveru totiž může stát jejich provozovatele hodně peněz. Podobně jako nedostupnost interního systému typu CRM či ERP zase způsobuje ztráty spojené s poklesem produktivity.

Přístupy k měření výkonu aplikací

Aplikace jsou obvykle jedinou součástí firemní infrastruktury, se kterou uživatel (zaměstnanec / zákazník) přijde do styku. Jejich výkonnost je tak často ztotožňována i s „výkonností“ celého IT firmy a promítá se i do reputace jejího IT oddělení. Pominu-li smysluplnost tohoto pohledu, pravdou zůstává, že se aplikacím v dnešní době přirozeně věnuje velká pozornost. V průběhu let se proto vyvinulo několik přístupů, které administrátorům pomáhají s řešením dvou základních problémů. Tedy toho, aby aplikace fungovala tak, jak chceme, a toho, aby fungovala rychle.

SNMP

Tím nejjednodušším je monitoring protokolu SNMP. Administrátor má díky SNMP k dispozici informace o tom, jak si aplikační server stojí z hlediska vytížení a čerpání systémových prostředků. Dostává zároveň informaci o tom, zda aplikace funguje, či nikoliv. Neví ale, jak se aplikace chová ke svému příjemci, tedy například, zda nevykazuje chybová hlášení, prodlevy apod. Obrázek o její funkčnosti je tak velmi omezený.

Syntetické testy vs. agentní řešení

Komplexnějším přístupem je vytváření tzv. syntetických uživatelů, kteří simulují průchod aplikací a zjišťují funkčnost/odezvu důležitých transakcí a scénářů. Jedná se o metodu nezávislou na použitém operačním systému. Typicky poskytuje odpovědi na otázky typu: Fungují transakce tak, jak mají? Jak rychle se požadovaná data k uživateli dostanou? Nevýhodou přirozeně je, že simulace neposkytují skutečný reporting toho, jak se aplikace k uživateli chová. Syntetičtí uživatelé mohou mít mj. problém se specifickými prohlížeči nebo zařízeními, a především nesledují scénáře, které nebyly předem nastaveny. Neodhalí též problém nevyskytující se v době průběhu syntetického testu, a pokud problém odhalí, nejsou schopní změřit, zda je problém na aplikaci či síti.

Pokročilou možností pracující s již reálnými uživateli je využití tzv. agentů, kteří jsou instalováni na aplikační servery. Tento přístup umožňuje sledovat skutečné operace a poskytuje detailní viditelnost do fungování aplikace napříč její architekturou. Poskytuje téměř veškeré představitelné informace spojené s výkonností aplikace napříč různými prostředími, a to až na úroveň detekce úzkých hrdel způsobených nesprávným kódováním. Tato oblast je doménou komplexních systémů, jako jsou například ty od New Relic, CA nebo AppDynamics.

Monitoring výkonnosti aplikací prostřednictvím viditelnosti do sítě

Syntetičtí uživatelé i agenti mají řadu výhod a v posledních letech jsou dominantními přístupy k managementu výkonnosti aplikací. Zároveň však mají i jednu, především pro menší a střední firmy velmi podstatnou nevýhodu – náročnost. A to jak po finanční stránce, tak z pohledu konfigurace a správy systému. Proto se vedle nich vyvinul „pružnější“ přístup k tomu, jak získat nezkreslený obraz o tom, co uživatel při práci s aplikací zažívá (User Experience, UX).

Obr. Příklad APM reportu

Tento přístup vychází z myšlenky, že se problémy sice mohou objevit na jakékoliv vrstvě (na vině může být síť, špatná komunikace routeru, chybné konfigurace, architektura aplikace nebo její kódování atp.), ale bez viditelnosti do sítě je velmi těžké je řešit. Na tomto principu staví APM nástroje získávající informace o výkonnosti aplikace z analýzy síťového provozu. Tyto nástroje monitorují a analyzují provoz mezi uživateli, aplikační infrastrukturou a databázovým serverem. Stejně jako agenti poskytují network-based monitoring nástroje informace o skutečné výkonnosti aplikací tak, jak ji „zažívají“ jejich uživatelé. Není přitom nutné zasahovat do aplikace agenty nebo rekonfigurovat servery. Daný přístup je navíc nezávislý na operačním systému a nijak aplikaci nezatěžuje. Jedná se o pasivní monitoring odchytávající pakety, kterým přiděluje časové známky a analyzuje jejich obsah.

Nástroje založené na tomto principu, například Flowmon APM, navíc vidí i do aplikačních protokolů a komunikace mezi aplikačním serverem a databází. Lze tak velmi rychle a přesně určit „kde má aplikace problém“, což se hodí nejen v případech, kdy se na tom síťový, aplikační a databázový administrátor nedokáží shodnout. Na základě toho lze získat klíčové informace o celkovém chování aplikace, od severu přes síťovou infrastrukturu až po aplikační protokoly a výkonnost specifických operací/transakcí.

Monitoring výkonnosti aplikace skrze znalost sítě je poměrně novou metodou s velkým potenciálem. V druhém díle tohoto seriálu se proto podrobněji zaměříme na technické parametry, které jím lze získat.

Artur Kane Autor článku působí jako Lead Educational Specialist společnosti Flowmon Networks. Na své pozici je zodpovědný za vzdělávání obchodního kanálu společnosti a šíření povědomí o Flowmon technologiích.