- Přehledy IS
- APS (20)
- BPM - procesní řízení (22)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (33)
- CRM (51)
- DMS/ECM - správa dokumentů (20)
- EAM (17)
- Ekonomické systémy (68)
- ERP (77)
- HRM (27)
- ITSM (6)
- MES (32)
- Řízení výroby (36)
- WMS (29)
- Dodavatelé IT slueb a řeení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (39)
- Dodavatelé CRM (33)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (71)
- Informační bezpečnost (50)
- IT řeení pro logistiku (45)
- IT řeení pro stavebnictví (26)
- Řeení pro veřejný a státní sektor (27)
ERP systémy
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údrby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tisk![]() | |
| Přihlaste se k odběru newsletteru SystemNEWS, který kadý týden přináí výběr článků z oblasti podnikové informatiky | |
![]() | |
Co chtít od monitoringu výkonosti aplikace
Investice 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, zvyovat trby. 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). Řeení pracující na tomto principu jsou neinvazivní, cenově dostupné a poskytují ve potřebné pro efektivní správu aplikace. Eliminují té některé nedostatky jiných přístupů, jako je náročnost údrby, nedostatečná identifikace místa problému, nebo potenciální ohroení výkonu a bezpečnosti aplikace.
Co by moderní APM řeení této kategorie mělo splňovat?
Viditelnost do vech komponentů (napříč aplikační architekturou)
Větina 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í mnoství serverů. V tomto modelu, kdy uivatel přistoupí k webové aplikaci, je jeho poadavek load-balancerem předán ke zpracování nejvhodnějímu webovému serveru. Ten, aby poskytl poadovaná data, zase pole poadavek na databázový server a teprve takový balíček dat obohacený o informace z databáze poskytne uivateli.
Pro odhalení konkrétní příčiny problému proto musíme zpodění měřit ve vech bodech - jak na síti, tak i na vech 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 moné 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 povaová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í okamitě 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, manaerské reportování, okamité notifikace zhorení 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 poadavkem na monitorovací řeení 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á kadý uivatel 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 údrba. Technologie nijak nezasahuje do aplikace a zároveň je nezávislá na operačním systému a pouité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 sloité údrby. 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 vak mohou potenciálně negativně ovlivňovat výkon i zabezpečení serveru. Jejich nasazení také není zdaleka nejrychlejí a údrba se komplikuje s kadým dalím měřeným serverem, vzhledem k nutnosti agenta instalovat a konfigurovat.
Rozliení mezi infrastrukturním versus aplikačním zpoděním
Často uívané technologie pro měření aplikačního výkonu, tzv. syntetičtí uivatelé, sledují v podstatě jedinou metriku. Tou je celková odezva aplikace, a to jetě navíc jen pro velmi omezenou mnoinu transakcí. Tato metoda tedy nevěnuje pozornost tomu, jestli zpodě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 vech komponentách (serverech) aplikace, je moné snadno odliit zpodění způsobeného aplikací a zpodění způsobené sítí. V takovém případě je nesmírně důleité měřit následující metriky.
Server Response Time - doba mezi přijetím poadavku uivatele a odpovědí serveru. Tato metrika tedy vyjadřuje, jak dlouho trvalo aplikaci zpracovat poadavek 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 vech bodech, abychom odliili zpodění webového a aplikačního serveru.
Network Transport Time - doba potřebná pro přenos poadavku po síti, indikuje nesprávné fungování infrastruktury. Stejně jako u SRT je třeba měřit jak transakce mezi uivatelem a webovým serverem, tak mezi webovým serverem a databází. A to v obou směrech (poadavek odpověď).
![]() |
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. |
Formulář pro přidání akce











