Existuje rostoucí počet skvělých systémů pro monitorování výkonu databáze. V poslední době se k tradičnějším on-premise řešením připojila řešení softwaru jako služba (SaaS).
Tento blog staví do kontrastu typickou architekturu místního řešení a řešení SaaS. Komponenty se samozřejmě budou lišit v názvech a struktuře od jednoho dodavatele k druhému, ale klíčové koncepty zde diskutované budou zastoupeny na jednom nebo druhém formuláři.
Rozdíly mezi místními řešeními a řešeními SaaS
Celkově jsou zde některé z klíčových součástí každého řešení:
Tradiční místní řešení
- Proces shromažďování dat.
- Úložiště krátkodobého výkonu [diagnostiky].
- Dlouhodobé úložiště analýz/přehledů.
- Windows nebo klient prohlížeče.
- Jakákoli infrastruktura převzetí služeb při selhání požadovaná pro infrastrukturu monitorování.
Řešení SaaS
- Proces shromažďování dat (pro místní cíle).
- Klient prohlížeče.
- Mobilní aplikace.
- Dodavatel SaaS spravuje aplikaci a úložiště dat na back-endu.
Upozorňujeme, že názvy různých komponent se budou u jednotlivých řešení lišit. V některých případech může být funkce rozdělena mezi více služeb nebo zdrojů dat.
Místní řešení
Proces shromažďování dat
Sběrač dat je obvykle místní služba bez agenta, která shromažďuje data z jakéhokoli místního monitorovaného koncového bodu. Tento proces řídí, jak a kdy jsou data shromažďována. Měl by být schopen shromažďovat data v různých frekvencích, aby se vyrovnala potřeba více podrobností s dopadem na monitorovanou pracovní zátěž. Frekvence shromažďování a prahové hodnoty upozornění by měly být u každé metriky předem nakonfigurovány.
Každý bude mít „hlučnou“ instanci, která neodpovídá standardním prahovým hodnotám. To může mít za následek mnoho falešně pozitivních výsledků. Aby se s tím vypořádal, měl by mít systém schopnost vytvářet pravidla na úrovni instance pro řešení výjimečných okolností. Vyhnete se tak „poplachové únavě“ z falešných poplachů.
V některých případech tato služba také organizuje výstrahy a oznámení. Ve velkých organizacích se stovkami monitorovaných instancí může být nutné vyvážit zátěž „sdružováním“ mezi řadou sběračů dat. Federace synchronizuje kolekce a konfiguraci napříč rozptýleným systémem.
Úložiště krátkodobé diagnostiky
Zde jsou uložena podrobná data. To by zahrnovalo data z DMV, soubory protokolu, události XEvents a další zdroje dat SQL Server. Je třeba se vyhnout zdrojům, které by mohly vyvíjet tlak na monitorované instance, např. většina tras je nevhodná pro monitorování v reálném čase.
Protože frekvence shromažďování může být tak často, jako každou sekundu a shromažďují se větší datové bloky, jako je TSQL a plány, může se toto úložiště rychle zvětšit. Výsledkem je, že většina systémů obvykle omezí historii na týden až měsíc (tato omezení se nevztahují na řešení SaaS). Toto úložiště má vysoce transakční povahu.
Úložiště dlouhodobých výkazů/analytik
Na konci předem definovaného času jsou tato podrobná data agregována a uložena v úložišti sestav pro analýzu a sledování trendů na vysoké úrovni. Množství uchovávaných detailů bude mít významný dopad na případnou velikost tohoto úložiště a výpočetní kapacitu, kterou lze rozumně očekávat, že ji uživatel zpřístupní k analýze. To má tendenci se značně lišit od jednoho řešení k druhému. Řešení, která podporují hlubší analýzu, budou mít podpůrné architektury a mohou používat architektury OLAP k usnadnění vícerozměrné analýzy.
Škálování místního řešení monitorování
Budou navržena sofistikovanější řešení pro usnadnění distribuované architektury klíčových komponent pro podporu škálování. Služba sběru dat bude mít vyšší počet monitorovaných připojení, které může podporovat. Po dosažení tohoto limitu by měl být „federován“ další sběrač dat, aby koordinoval sběr dat a organizoval ukládání dat.
Samotná úložiště dat o výkonu mohou sdílet jednu instanci nebo mohou být rozdělena do několika instancí pro podporu škálování. Úložiště, které potřebují, bude přímo úměrné počtu monitorovaných připojení a objemu uchovávaných dat. Struktura a architektura analytického úložiště také ovlivní celkovou kapacitu.
Uživatelská zkušenost
Většina místních nástrojů bude mít rozhraní Windows. Některé mají rozhraní prohlížeče založené na lokálně hostovaném nasazení. Vzdálený přístup k nim může být komplikovaný a obvykle vyžaduje VPN. Zřídka podporují mobilní aplikace.
Vysoká dostupnost
Monitorovací software, který monitoruje kritické pracovní zátěže, musí být sám o sobě odolný. Mělo by být přijato opatření pro řešení katastrofických situací, které mohou odstavit monitorovací strukturu do režimu offline. To by mělo být také zvažováno z hlediska architektury a nákladů.
Řešení SaaS
Proces shromažďování dat
Přestože je nabídka SaaS primárně hostovaná, často bude udržovat místní sběrač dat pro místní úlohy. To pomáhá řešit omezení výkonu a zabezpečení. Tímto způsobem jsou všechna připojení na úrovni instance vytvářena prostřednictvím místního kolektoru, který pak předává data o výkonu monitorované databáze do cloudové vstupní služby. Všechna data by měla být při přenosu šifrována.
Úložiště diagnostiky a hlášení/analytiky
Dobrou zprávou je, že dodavatel SaaS zpracovává veškeré vaše datové úložiště. Nemusíte si dělat starosti se zakládáním instancí pro úložiště diagnostiky, vytvářením hlášení o úložištích, proplachováním úložiště diagnostiky nebo s mnoha dalšími problémy spojenými s místním nasazením.
Hostovaná řešení budou využívat různé strategie úložiště v back-endu, aby se usnadnila kombinace transakční a analytické činnosti podle potřeby. Mohou čerpat z cloudových zdrojů, aby zvládli vyšší objemy dat a nezbytné zpracování potřebné pro analýzu; např. Spotlight Cloud uchovává podrobné údaje po dobu jednoho roku. Nejenže tedy můžete hlásit rok zpět v čase, ale můžete si také přehrát své pracovní vytížení až o rok v minulosti. Toto je opravdu výkonná schopnost.
Řešení SaaS pro monitorování výkonu databáze může využívat různé strategie back-endového úložiště nejen proto, aby vyhovovalo transakční povaze diagnostiky a monitorování, ale také aby usnadnilo vysoce intenzivní křupání čísel spojené s dlouhodobou analýzou. Prodejce SaaS může využít značných úspor z rozsahu při použití mnohem výkonnější infrastruktury, kterou by měly k dispozici jednotlivé organizace.
Jak škálovat řešení SaaS
Za škálování řešení SaaS je odpovědný prodejce, nikoli uživatel. Jakékoli řešení SaaS pro monitorování výkonu databáze musí být vytvořeno tak, aby bylo možné škálovat od prvního dne, a v důsledku toho má tendenci zvládat škálování ve svém kroku.
Uživatelská zkušenost
Aplikace SaaS budou mít jako výchozí prohlížeč Ux a mnoho z nich bude mít také komplexní mobilní aplikace. To usnadňuje rozptýlené a vzdálené týmy.
Zabezpečení a dodržování předpisů
Většina řešení SaaS bude postavena na jedné z předních cloudových infrastruktur, jako je Azure nebo Amazon. Mnoho předních dodavatelů má zavedené sofistikované bezpečnostní infrastruktury. Hodně investují do podpory požadavků svých klientů na dodržování předpisů.
Vysoká dostupnost
Dobrou zprávou opět je, že za to odpovídá prodejce. Vyplatí se ověřit si u svého dodavatele, jaká opatření učinil z hlediska převzetí služeb při selhání a vysoké dostupnosti. Aplikace SaaS by měly být navrženy tak, aby byly velmi odolné. Různé služby, které tvoří aplikaci SaaS, jsou obvykle navrženy tak, aby byly individuálně odolné. Lze také zajistit výpadky datového centra, kdy by aplikace v případě výpadku datového centra přešla z jednoho datového centra do druhého.