google plus
Tematické sekce
 
Branžové sekce
Přehledy
 
Tematické seriály
Nové!

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 
Nové!

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 

Komplexní svět eIDAS

O nařízení eIDAS již bylo mnoho řečeno i napsáno. A proto jediné, o čem...

články >>

 

Trendy v CRM

Systémy pro řízení vztahů se zákazníky (CRM) prochází v posledních letech výraznou změnou. Zatímco dříve...

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 

Pokročilá analýza provozu datových sítí

V tomto čtyřdílném seriálu vás seznámíme s různými metodami a přístupy...

1. až 4. díl >>

 

Cesta k efektivnímu identity managementu

Správa identit a přístupů (IAM) je klíčová oblast pro zaručení bezpečnosti...

1. až 9. díl >>

Co chtít od monitoringu výkonosti aplikace

FlowmonInvestice do webových podnikových portálů, online aplikací a informačních systémů jsou dnes zcela běžné. Pomáhají zvýšit efektivitu procesů, budovat značku, zvyšovat tržby. Měření jejich výkonnosti se tak stalo nutností a firmy hledají způsoby, jak tuto oblast efektivně pokrýt.


Jak už jsem uvedl v prvním díle tohoto seriálu, moderním způsobem monitorování aplikací je analýza výkonnosti pomocí tzv. network-based přístupu. Ten představuje hybridní technologii, která přináší výsledky nástrojů kategorie Application Performance Monitoring (APM) při jednoduchosti implementace známé z oblasti Network Performance Monitoring (NPM). Řešení pracující na tomto principu jsou neinvazivní, cenově dostupné a poskytují vše potřebné pro efektivní správu aplikace. Eliminují též některé nedostatky jiných přístupů, jako je náročnost údržby, nedostatečná identifikace místa problému, nebo potenciální ohrožení výkonu a bezpečnosti aplikace.

Co by moderní APM řešení této kategorie mělo splňovat?

Viditelnost do všech komponentů (napříč aplikační architekturou)

Většina aplikačních systémů sleduje trend standardizace. V praxi to znamená odklon od využívání proprietárních protokolů a naopak příklon k podpoře webových protokolů. Moderní aplikace sestávající se z vice komponent, webového serveru (HTTP/S v 1.1 či 2.0) a databázového serveru (MSSQL, MariaDB, Oracle a jiné), jsou v případě rozsáhlých systémů distribuované přes větší množství serverů. V tomto modelu, kdy uživatel přistoupí k webové aplikaci, je jeho požadavek load-balancerem předán ke zpracování nejvhodnějšímu webovému serveru. Ten, aby poskytl požadovaná data, zase pošle požadavek na databázový server a teprve takový balíček dat “obohacený” o informace z databáze poskytne uživateli.

Pro odhalení konkrétní příčiny problému proto musíme zpoždění měřit ve všech bodech - jak na síti, tak i na všech webových a databázových serverech. Network-based APM nástroje by toto měly umět. Měly by přirozeně poskytovat informace ze síťových vrstev i vhled do aplikačních protokolů vrstvy L7 a komunikace mezi aplikačním serverem a databází. Díky takové viditelnosti napříč aplikační architekturou je pak možné rychle identifikovat problém a přesně určit místo jeho vzniku. Eliminují se tak situace, kdy si administrátoři na jednotlivých úrovních přehazují problém mezi sebou.

Real-time notifikace

Řada webových aplikací je dnes ve firmách považována za kritické (business critical). Je proto nezbytné, aby nástroj pro aplikační monitoring zprostředkovával informace v reálném čase. A to včetně notifikací a upozornění okamžitě informujících administrátora o problému. Nástroj by také měl podporovat definování vlastní sady reportů, jejich pravidelné zasílání e-mailem, manažerské reportování, okamžité notifikace zhoršení výkonu aplikace na základě stanoveného SLA atd.

Připravenost na vysokorychlostní provoz a podpora rozsáhlých prostředí

S tím, jak roste objem a náročnost přenášeného obsahu, se 1G sítě pomalu stávají minulostí. Klíčovým požadavkem na monitorovací řešení je tak podpora vysokorychlostních sítí, typicky na 10Gbps linkách.

S velikostí firmy obvykle roste také komplexnost její infrastruktury, včetně budování dislokovaných poboček. APM nástroj proto musí podporovat centrální dohled a „umět“ reportovat výkonnost aplikace tak, jak ji vnímá každý uživatel napříč rozsáhlým prostředím.

Neinvazivní a univerzální nasazení

Jednou z hlavních předností network-based přístupu k sledování výkonnosti aplikace je jeho jednoduché nasazení a údržba. Technologie nijak nezasahuje do aplikace a zároveň je nezávislá na operačním systému a použitém aplikačního serveru. Ve světě neustálých aktualizací, updatů a záplatování z ní tyto vlastnosti činí skutečně moderní nástroj, který „prostě funguje“ bez složité údržby. Zásadně se tak liší od instalace agentů na servery. Ti jsou velmi běžnou metodou monitorování výkonnosti aplikací, především v segmentu velkých společností. Agenti však mohou potenciálně negativně ovlivňovat výkon i zabezpečení serveru. Jejich nasazení také není zdaleka nejrychlejší a údržba se komplikuje s každým dalším měřeným serverem, vzhledem k nutnosti agenta instalovat a konfigurovat.

Rozlišení mezi infrastrukturním versus aplikačním zpožděním

Často užívané technologie pro měření aplikačního výkonu, tzv. syntetičtí uživatelé, sledují v podstatě jedinou metriku. Tou je celková odezva aplikace, a to ještě navíc jen pro velmi omezenou množinu transakcí. Tato metoda tedy nevěnuje pozornost tomu, jestli zpoždění vzniklo na webovém, či aplikačním serveru, popřípadě na síti. Pokud nasadíme technologii, které je schopná měřit odezvu na všech komponentách (serverech) aplikace, je možné snadno odlišit zpoždění způsobeného aplikací a zpoždění způsobené sítí. V takovém případě je nesmírně důležité měřit následující metriky.

Server Response Time - doba mezi přijetím požadavku uživatele a odpovědí serveru. Tato metrika tedy vyjadřuje, jak dlouho trvalo aplikaci zpracovat požadavek a poskytnout odpověď. Při měření této metriky pro webový server je třeba počítat s faktem, že část této doby způsobilo čekání na databázový server. Znovu se tedy ukazuje, že je třeba aplikaci měřit ve všech bodech, abychom odlišili zpoždění webového a aplikačního serveru.

Network Transport Time - doba potřebná pro přenos požadavku po síti, indikuje nesprávné fungování infrastruktury. Stejně jako u SRT je třeba měřit jak transakce mezi uživatelem a webovým serverem, tak mezi webovým serverem a databází. A to v obou směrech (požadavek – odpověď).

Artur Kane 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.