Jistě to znáte z praxe. Za všechno může síť. Pokud si uživatel stěžuje na odezvu aplikace, většinou to končí rozepří mezi správcem sítě a aplikací/serverů o příčině problému. Nástroj, který by tento spor rozhodl, chybí. Jako obvykle se pravda ukrývá v paketech, pakety totiž nelžou.

Na úrovni datové sítě lze sledovat základní parametry jako je RTT (Round Trip Time), tedy cesta paketu od klienta k serveru a zpět, nebo SRT (Server Response Time), tedy zpoždění aplikace jako takové. Právě tyto parametry ukazují, zda je problém na úrovni sítě nebo na úrovni aplikace. Jejich měření označujeme zkratkou NPM (Network Performance Monitoring) a opět platí, že jde o funkci, kterou najdeme v moderních řešeních pro monitorování provozu na základě datových toků. Vše se totiž odvíjí od časování jednotlivých paketů, jakým způsobem prochází aktivním prvkem nebo monitorovací sondou. Funkci NPM najdeme rovněž v moderních přepínačích a směrovačích, aktivní prvky společnosti Cisco například nabízí funkci AVC (Application Visibility and Control). Výhodou je, že můžeme kontinuálně sledovat výkonové parametry veškeré datové komunikace bez ohledu na použitou aplikaci, jediným omezením je protokol TCP, bez kterého se neobejdeme.

Round Trip Time

RTT měříme v komunikaci od klienta k serveru. Při navazování spojení (tzv. TCP handshake) je změřena doba mezi SYN paketem a ACK paketem, kterým klient zahájí komunikaci, resp. potvrdí navázání spojení. Tato doba odpovídá právě cestě paketu od klienta k serveru a zpět. SRT měříme v komunikaci od serveru ke klientovi mezi posledním potvrzením přijetí požadavku (ACK) a prvním datovým paketem odpovědi. Pro další pakety měříme prodlevy mezi pakety, které označujeme jako zpoždění (delay), ze kterého odvozujeme rozptyl zpoždění (jitter). Právě rozptyl zpoždění, tedy kolísání zpoždění, může způsobovat problémy ve videokonferencích nebo VoIP hovorech, například na rozdíl od přenášení velkých objemů dat, na které prakticky nemá vliv.

Obr. 1 Princip měření výkonových parametrů datové sítě

Mimo uvedených výkonových parametrů můžeme měřit počet retransmisí a tzv. out-of-order paketů. Tyto ukazatele indikují problémy s přenosem dat. Retransmise jsou samo-korekčním mechanismem protokolu TCP při ztrátě nebo poškození dat při přenosu, jejichž výskyt indikuje problémy na komunikační lince. Podobně out-of-order pakety znamenají, že k doručení paketů došlo v jiném pořadí, než v jakém byly odeslány. Taková situace může nastat, pokud pakety cestují různými trasami nebo v případě problémů na komunikačních linkách. Zejména na základě zvyšujícího se počtu retransmisí lze detekovat zhoršující se kvalitu komunikační linky a vysvětlit tak klesající rychlosti datových přenosů.

Pojďme se podívat na příklad využití RTT. Tato informace je v případě moderních řešení součástí statistik o provozu datové sítě. Jsme tak schopni se kolektoru dotázat na průměrnou hodnotu RTT pro jednotlivé klientské stanice komunikující se serverem informačního systému. Snadno tím odlišíme stanice, které se připojují vzdáleně, např. přes VPN (segment 192.168.3.0/24), stanice připojené přes wifi (192.168.0.32) a stanice připojené přes lokální síť ethernet (ostatní stanice). Tento příklad ilustruje obrázek 2. 

Obr. 2 Příklad statistiky RTT, klientské stanice jsou seřazeny sestupně podle nejvyšší (nejhorší) průměrné hodnoty RTT naměřené při komunikaci se serverem informačního systému.

Monitorování výkonu aplikací

Zatím jsme se pohybovali pouze na třetí a čtvrté síťové vrstvě a měřili výkonové parametry bez jakékoliv vazby na konkrétní aplikaci. Pokud chceme sledovat výkon aplikací pohledem jejich uživatelů, tedy sledovat, jak se jednotlivé aplikace opravdu „chovají“ k jejich uživatelům, musíme opět na aplikační vrstvu. Díky tomu je možné sledovat rychlost odezvy aplikace pro všechny uživatele v souladu s logikou obchodních procesů, např. přihlášení do internetového bankovnictví, založení účtu, vygenerování výpisů atd. V reálném čase tak odhalíme, který uživatel, skupina uživatelů, pobočka, která transakce a za jakých podmínek měli problém.

Tuto oblast označujeme jako APM (Application Performance Monitoring) a tradičně se jedná o doménu velmi nákladných řešení renomovaných výrobců, kteří nabízí sadu monitorovacího software ve formě agentů instalovaných na jednotlivé servery. Přitom odpovědi na otázky ohledně výkonu aplikace se opět ukrývají v provozu datové sítě. Lze tak bez jakéhokoliv zásahu do aplikací (například instalace agentů či rekonfigurace serverů) monitorovat dobu odezvy a dobu přenosu požadavku i odpovědi, což jsou hlavní metriky, které nás zajímají. Tento bez-agentní přístup navíc umožňuje nasadit monitoring aplikace v řádu minut, neboť opět nepotřebujete prakticky nic jiného než viditelnost do síťového provozu. Dodejme, že metoda je použitelná pro aplikace, které využívají standardizované komunikační protokoly, tedy je možné takto monitorovat elektronické bankovnictví, e-shop nebo podnikový systém, který s uživatelem komunikuje prostřednictvím internetového prohlížeče. U proprietárních aplikací s tlustými klienty a uzavřenými binárními protokoly tento přístup bohužel aplikovat nelze.

Princip fungování APM vyžaduje záznam provozu dané aplikace v plném rozsahu (vzpomeňme na druhý díl tohoto seriálu o záchytu paketů a paketové analýze), rekonstrukci TCP spojení a vzájemného párování požadavků a odpovědí. Znamená to tedy, že je možné měřit jak tradiční model požadavek-odpověď, tak i asynchronní komunikaci, kdy klient zadá i několik požadavků najednou, aniž by čekal vždy na dokončení zpracování požadavku a vrácení odpovědi. Sledované parametry jsou RT (response time), tedy doba zpracování požadavku na straně aplikace a TT (transport time), tedy doba strávená na transportní vrstvě přenosem odpovědi.

Obr. 3 Princip měření výkonových parametrů aplikace

Rozdíl mezi RT a TT nám podobně jako v případě sledování výkonových parametru sítě ukazuje, zda se problém nachází v aplikaci nebo v komunikační infrastruktuře. Pokud si bude uživatel stěžovat na pomalé odezvy, jsme schopni na základě normální hodnoty RT a vysoké hodnoty TT ihned jeho stížnost posoudit jako neoprávněnou a vysvětlit mu, že z druhého konce světa přes mobilní připojení a VPN to opravdu rychlejší nebude a vy jako správce aplikace s tím nic neuděláte.

Na základě měření doby odezvy lze kontinuálně měřit výkonnost aplikace. Můžete si definovat požadovanou kvalitu služby (tzv. SLA) a sledovat, kolik požadavků tuto úroveň SLA splňuje. Moderní APM systémy umožňují měřit výkon aplikace jediným výsledným indexem, který vzniká právě jako vážený průměr počtu uživatelských transakcí splňujících SLA a transakcí, které toto SLA násobně překračují a mění se v čase. Je tak možné notifikovat snížení výkonu aplikace jako celku a následně identifikovat, zda se problém týká konkrétní části aplikace nebo konkrétní skupiny uživatelů, případně zda se projevuje plošně. Již tato základní diagnostika v řadě případů ukáže správci aplikace nebo jejím vývojářům přesně na místo problému. Nemluvě o tom, že lze tak sledovat a srovnat změny v dobách odezvy aplikace po nasazení nové verze nebo po navýšení výpočetních zdrojů.

Obr. 4 Příklad výstupů APM, levý graf ukazuje dobu odezvy v čase (průměrná hodnota, medián, 95-percentil, 99-percentil), pravý graf ukazuje počet uživatelů souběžně pracujících s aplikací.

Díky viditelnost do sedmé vrstvy je možné identifikovat uživatele nejen IP adresou, ale např. z parametru v URL nebo z cookie. Stejně tak je možné sledovat URL v plném rozsahu včetně parametrů, typ a verzi internetového prohlížeče klienta (to je vhodné např. při řešení problémů s kompatibilitou) nebo návratové hodnoty požadavků, zejména chybové kódy. Pokud je použit šifrovaný přenosový protokol HTTPS, je nezbytné provoz před analýzou dešifrovat. S tím musí systém APM počítat a umožnit vložení šifrovacího klíče pro převod provozu do nešifrované podoby. Technicky to ale nepředstavuje žádný problém nebo omezení.

Odpovědi se ukrývají v datovém provozu

V tomto článku jsme se seznámili s problematikou monitorování výkonu na úrovni datové sítě a na úrovni aplikace. Opět platí, že všechny odpovědi na naše otázky se ukrývají v datovém provozu a moderní monitorovací nástroje nám je umí poskytnout. V rámci čtyř dílů našeho seriálu jsme pokryli témata monitorování provozu prostřednictvím datových toků, záchyt provozu v plném rozsahu a analýzu paketů, spojení výhod obou přístupů do monitorovacího systému a nakonec oblast sledování výkonových parametrů. Cílem seriálu bylo seznámit IT manažery, bezpečnostní manažery, správce sítí i aplikací s aktuálními možnosti v oblasti monitorování IT infrastruktury a vysvětlit principy jejich fungování tak, aby mohli získané informace využít při návrhu strategie monitoringu IT infrastruktury a doplnění chybějících funkcí ve stávajícím konceptu. Nebo prostě jen inspirovat a rozšířit obzory.

RNDr. Pavel Minařík, PhD. Autor článku se oblastí kybernetické bezpečnosti zabývá od roku 2006. Účastnil se řady výzkumných projektů v oblasti analýzy provozu datových sítí a detekci pokročilých hrozeb jako výzkumný pracovník Ústavu výpočetní techniky Masarykovy univerzity. Během posledních čtyř let se účastnil několika desítek projektů nasazení řešení pro monitorování provozu a detekci pokročilých hrozeb. V současné době pracuje jako technologický ředitel ve společnosti INVEA-TECH zodpovědný za návrh a vývoj produktů pro Flow Monitoring a Network Behavior Analysis.