Välja ett SQL Server-övervakningsverktyg som passar dina behov

Innan du börjar titta på ett SQL-serverövervakningsverktyg, tänk på din specifika miljö:

• Hur många instanser vill du övervaka?
• Finns dessa på en plats eller spridda?
• Behöver du övervaka operativsystemet och/eller hypervisorn?
• Hur mycket historik behöver du för att få en korrekt bild av driftgränserna för din instans?
• Är de alla på plats eller finns några i molnet?
• Är dina lag fördelade?
• Köper du programvara under en investerings- eller driftsbudget?
• Har du råd att investera en klumpsumma i förväg på infrastruktur och licens eller föredrar du att fördela dina kostnader över tiden?
• Har du infrastruktur- och databasinstanser tillgängliga att dedikera till ett övervakningsverktyg?
• Har du tid att bygga en övervakningsinfrastruktur?
• Har du konsekvent hög expertis i hela ditt team?
• Använder du juniorresurser för inledande triage eller är du beroende av dina experter för allt?
• Har du tid eller resurser internt för att underhålla övervakningsinfrastrukturen?

Ska jag göra mitt eget?

Jag kan förklara vår partiskhet här. Quest Software har byggt verktyg för prestandaövervakning under de senaste 20 åren. Det finns en utmärkt anledning till varför vi och många andra som vi har stannat kvar i detta segment så länge och till varför vi har en växande kundbas. Prestandaövervakning gjord bra är inte lätt!

Det finns verkligen några bra sätt att samla in mätvärden från SQL Server med PerfMon, spår, DMV:er och XEvents, för att nämna några. Att göra detta på en engångsbasis för en enskild fråga är bra – om du har tid att investera i att undersöka var och hur man samlar in data för den frågan. När problemen börjar växa upp och antalet instanser ökar, blir detta snabbt omöjligt.

Det finns flera hundra mätvärden tillgängliga som är värda att spåra för att få en komplett bild av din SQL Servers prestandatillstånd. Utöver det finns SQL-koden som körs och frågeplanerna som är associerade med varje exekvering av densamma. Vissa mätvärden bör samlas in varje sekund, en del varje timme och en del baserat på när koden körs. Vissa insamlingsmetoder kan påverka den övervakade instansen och bör undvikas.

Varje mätvärde kommer att ha olika trösklar som skulle definiera dess status. Särskilda fall kan ha nivåer som inte är standard. Då måste du lagra allt detta. Datavolymen ökar mycket snabbt. Du måste införa en strategi för att rensa detaljerad data regelbundet och sedan, om det krävs för trender, samla dessa data för rapportering.

Det är MYCKET arbete ... och naturligtvis, varje gång en ny SQL Server-version kommer ut, har du en regressionshuvudvärk att hantera. Om du inte faktiskt vill sälja ett övervakningsverktyg, skulle jag starkt avråda från att rulla ditt eget såvida inte volymen av problem är låg och problemen du måste lösa är mycket specifika.

Vad sägs om gratisverktyg?

Gratis verktyg är ofta värda att överväga, särskilt för mindre team med mindre kritiska instanser. Se det som nästa steg i skalbarhetsstegen efter "rulla din egen". Många av de kommersiella SQL-serverövervakningsverktygen på nybörjarnivå bör ha liknande överväganden. Tänk på följande:

• Täcker verktyget en tillräcklig bredd av mätvärden för att ge dig tillräcklig täckning för alla användningsfall i dina övervakade instanser? Många gratisverktyg ger någon form av "anpassning" för att lägga till dina egna mätvärden. När "anpassning" används för att fylla luckor i funktionalitet, kommer du snabbt att upptäcka att ditt team "rullar sitt eget" med den nödvändiga distraktionen och underhållshuvudvärken.
• Har verktyget stöd för varningar? Är den förkonfigurerad? Att konfigurera varning kan vara mycket tidskrävande. Out-of-box varning är ett måste för att förhindra att många förlorade mantimmar konfigurerar någon annans verktyg. Det bör också underlätta anpassningen av varningar för kantfall som inte överensstämmer med standardinställningarna.
• Hur och var lagras data? De flesta gratisverktyg överlåter åt dig att hantera lagringen av prestandadata. Var försiktig med "gratis" övervakning från molnleverantörer. De tar betalt för lagringen, och det här kan snabbt bli stort och dyrt!

Så, för all del, utnyttja de kostnadsfria verktygen som finns där ute. Var bara medveten om deras begränsningar och se upp för de klassiska antimönstren inom ditt team, som:

• Mer tid åt att fixa eller underhålla verktyget än att använda det för att åtgärda problem
• Mer pengar spenderas på infrastruktur och lagring
• Mycket data men inga insikter
• Inte tillräckligt djup i diagnostik för att lösa problem
• Inte tillräckligt skalbar för att passa dina behov

Om du märker något av ovanstående bör det peka på behovet av att uppgradera till en mer robust lösning.

Typisk arkitektur för ett SQL Server-övervakningssystem

När man överväger om man ska välja en traditionell lokal lösning eller en SaaS-lösning (hosted software as a service), är det bra att överväga övervakningsapplikationsarkitekturen. Här är en sammanfattning av de viktigaste arkitektoniska komponenterna.

Nyckelavvikelsen mellan SaaS och lokalt hänför sig till var prestandadata lagras och vem som hanterar detta arkiv. För en lokal lösning är detta slutanvändarens ansvar. Dessa förråd kan bli stora snabbt, så de måste hanteras noggrant. Infrastrukturen måste planeras och budgeteras för (mer nedan).

I en SaaS-lösning för SQL-serverövervakning är dessa viktiga infrastrukturkomponenter värd och hanteras åt dig.

För mer information, kolla in vår blogg, Database Monitoring System Architecture.