Než se pustíte do sledování nástroje pro monitorování SQL serveru, zamyslete se nad svým konkrétním prostředím:
- Kolik instancí chcete sledovat?
- Jsou na jednom místě nebo jsou rozptýlené?
- Potřebujete sledovat operační systém a/nebo hypervizor?
- Kolik historie potřebujete, abyste získali přesný obrázek o hranicích fungování vaší instance?
- Jsou všechny on-premise nebo jsou některé v cloudu?
- Jsou vaše týmy rozděleny?
- Nakupujete software v rámci rozpočtu na kapitálové nebo provozní výdaje?
- Můžete si dovolit investovat jednorázovou částku předem do infrastruktury a licence, nebo dáváte přednost rozložení nákladů v čase?
- Máte k dispozici infrastrukturu a instance databáze, které můžete věnovat monitorovacímu nástroji?
- Máte čas na vybudování monitorovací infrastruktury?
- Máte ve svém týmu trvale vysokou odbornost?
- Využíváte pro počáteční třídění juniorské zdroje nebo se ve všem spoléháte na své odborníky?
- Máte interně čas nebo zdroje na údržbu infrastruktury monitorování?
Měl bych to udělat sám?
Zde mohu prohlásit naši zaujatost. Quest Software vytváří nástroje pro monitorování výkonu posledních 20 let. Existuje skvělý důvod, proč jsme my a mnoho dalších jako my zůstali v tomto segmentu tak dlouho a proč máme rostoucí zákaznickou základnu. Dobře provedené monitorování výkonu není snadné!
Existuje skutečně několik skvělých způsobů, jak shromáždit metriky ze serveru SQL Server pomocí PerfMon, trasování, DMV a XEvents, abychom zmínili alespoň některé. Udělat to jednorázově pro jeden problém je dobré a dobré – pokud máte čas investovat do zkoumání, kde a jak shromáždit data pro daný problém. Jakmile se problémy začnou hromadit a počet instancí se zvýší, rychle se to stane neškálovatelné.
Existuje několik stovek dostupných metrik, které stojí za to sledovat, abyste získali úplný obrázek o stavu výkonu vašeho SQL Serveru. Kromě toho existuje kód SQL, který se spouští, a plány dotazů spojené s každým spuštěním téhož. Některé metriky by měly být shromažďovány každou sekundu, některé každou hodinu a některé na základě toho, kdy se kód spustí. Některé metody sběru mohou ovlivnit monitorovanou instanci a je třeba se jim vyhnout.
Každá metrika bude mít jiné prahové hodnoty, které definují její stav. Konkrétní případy mohou mít úrovně, které jsou nestandardní. To vše pak musíte uložit. Objem dat narůstá VELMI rychle. Budete muset zavést strategii pravidelného čištění podrobných dat a poté, je-li to nutné pro sledování trendů, tato data agregovat pro vytváření přehledů.
Je to HODNĚ práce… a samozřejmě pokaždé, když vyjde nová verze SQL Serveru, musíte se vypořádat s regresní bolestí hlavy. Pokud skutečně nechcete prodat monitorovací nástroj, důrazně nedoporučuji používat vlastní, pokud není objem problémů nízký a problémy, které musíte vyřešit, jsou velmi specifické.
A co bezplatné nástroje?
Bezplatné nástroje často stojí za zvážení, zejména pro menší týmy s méně kritickými instancemi. Berte to jako další krok v žebříčku škálovatelnosti po tom, co si „rozhodíte vlastní“. Mnoho komerčních nástrojů pro monitorování SQL serveru základní úrovně by mělo mít podobné úvahy. Zvažte následující:
- Pokrývá nástroj dostatečnou šíři metrik, aby vám poskytl dostatečné pokrytí pro všechny případy použití ve vašich monitorovaných instancích? Mnoho bezplatných nástrojů poskytne určitý druh „přizpůsobení“ pro přidání vlastních metrik. Když se „přizpůsobení“ používá k vyplnění mezer ve funkčnosti, pak rychle zjistíte, že váš tým končí „svá vlastní“ s nezbytným rozptýlením a bolestmi hlavy z údržby.
- Podporuje nástroj upozornění? Je to předkonfigurováno? Konfigurace upozornění může být časově velmi náročná. Upozornění před odesláním je nutností, aby se zabránilo mnoha ztraceným pracovním hodinám při konfiguraci nástroje někoho jiného. Mělo by také usnadnit přizpůsobení výstrah pro okrajové případy, které neodpovídají výchozím nastavením.
- Jak a kde jsou data uložena? Většina bezplatných nástrojů ponechává správu ukládání dat o výkonu na vás. Dávejte si pozor na „bezplatné“ monitorování od cloudových dodavatelů. Účtují si za úložiště, a to se může rychle stát velké a drahé!
Takže v každém případě využijte bezplatné nástroje, které jsou k dispozici. Buďte si vědomi jejich omezení a dávejte si pozor na klasické anti-vzorce ve vašem týmu, jako jsou:
- Více času stráveného opravou nebo údržbou nástroje než jeho používáním k řešení problémů
- Více peněz vynaložených na infrastrukturu a úložiště
- Spousta dat, ale žádné statistiky
- Diagnostika není dostatečná pro řešení problémů
- Není dostatečně škálovatelné, aby vyhovovalo vašim potřebám
Pokud si všimnete čehokoli z výše uvedeného, mělo by to poukazovat na potřebu upgradu na robustnější řešení.
Typická architektura monitorovacího systému SQL Server
Při zvažování, zda zvolit tradiční místní řešení nebo řešení hostovaný software jako služba (SaaS), je užitečné zvážit architekturu monitorovací aplikace. Zde je shrnutí klíčových architektonických komponent.
Klíčová odchylka mezi SaaS a on-premises souvisí s tím, kde jsou uložena data o výkonu a kdo spravuje toto úložiště. U on-premise řešení je to odpovědností koncového uživatele. Tato úložiště se mohou rychle zvětšit, takže je třeba je pečlivě spravovat. Infrastrukturu je třeba plánovat a rozpočtovat (více níže).
V řešení SaaS pro monitorování SQL serverů jsou tyto klíčové součásti infrastruktury hostovány a spravovány za vás.
| Tradiční místní řešení | Řešení SaaS |
|
|
Pro více podrobností se podívejte na náš blog, Database Monitoring System Architecture.