Det finns ett växande antal fantastiska databasprestandaövervakningssystem där ute. Nyligen har de mer traditionella lokala lösningarna fått sällskap av SaaS-lösningar (Software as a Service).
Den här bloggen kontrasterar den typiska arkitekturen för en lokal lösning med den för en SaaS-lösning. Naturligtvis kommer komponenter att variera i namn och struktur från en leverantör till en annan, men de nyckelbegrepp som diskuteras här kommer att representeras i en eller annan form.
Skillnader mellan lokala och SaaS-lösningar
Sammantaget är här några av nyckelkomponenterna i varje lösning:
Traditionell lokal lösning
- Datainsamlingsprocess.
- Kortsiktigt prestandaförråd [diagnostik].
- Långsiktigt analys-/rapporteringsarkiv.
- Windows eller webbläsarklient.
- All failover-infrastruktur som krävs för övervakningsinfrastrukturen.
SaaS-lösning
- Datainsamlingsprocess (för lokala mål).
- Webbläsarklient.
- Mobilapp.
- SaaS-leverantören hanterar applikationen och back-end-datalagringen.
Observera att namnen på de olika komponenterna kommer att variera från en lösning till en annan. I vissa fall kan funktionalitet delas mellan flera tjänster eller datakällor.
Lokala lösningar
Datainsamlingsprocess
Datainsamlaren är vanligtvis en lokal, agentlös tjänst som samlar in data från alla övervakade slutpunkter på plats. Denna process orkestrerar hur och när data samlas in. Den bör kunna samla in data vid olika frekvenser för att balansera behovet av mer detaljer med inverkan på den övervakade arbetsbelastningen. Insamlingsfrekvenser och varningströsklar bör vara förkonfigurerade för varje mätvärde.
Alla kommer att ha en "bullrig" instans som inte överensstämmer med standardtröskelvärden. Detta kan resultera i många falska positiva resultat. För att hantera detta bör systemet ha förmågan att skapa regler på instansnivå för att hantera exceptionella omständigheter. Detta undviker "larmtrötthet" från falska positiva.
I vissa fall orkestrerar den här tjänsten även varningar och aviseringar. I stora organisationer med hundratals övervakade instanser kan det vara nödvändigt att balansera belastningen genom att "federera" mellan ett antal datainsamlare. Federation synkroniserar samlingar och konfiguration över ett spritt system.
Short-Term Diagnostics Repository
Det är här detaljerad data lagras. Detta skulle inkludera data från DMV, loggfiler, XEvents och andra SQL Server-datakällor. Källor som kan utöva tryck på de övervakade instanserna bör undvikas, t.ex. är de flesta spår olämpliga för realtidsövervakning.
Eftersom insamlingsfrekvenser kan vara lika ofta som varannan och större databitar som TSQL och planer samlas in, kan detta förråd bli stort snabbt. Som ett resultat kommer de flesta system vanligtvis att begränsa historiken till mellan en vecka och en månad (dessa begränsningar gäller inte för en SaaS-lösning). Detta förråd är mycket transaktionellt till sin natur.
Långtidsrapportering/Analytics Repository
Vid slutet av en fördefinierad tid aggregeras denna detaljerade data och lagras i ett rapporteringslager för analys och trender på hög nivå. Mängden detaljer som behålls kommer att ha en betydande inverkan på den slutliga storleken på detta förvar och den beräkningskapacitet som man rimligen kan förvänta sig att en användare gör tillgänglig för att analysera den. Detta tenderar att variera avsevärt från en lösning till en annan. Lösningar som stöder djupare analyser kommer att ha stödjande arkitekturer och kan använda OLAP-arkitekturer för att underlätta multidimensionell analys.
Skala en lokal övervakningslösning
Mer sofistikerade lösningar kommer att utformas för att underlätta en distribuerad arkitektur av nyckelkomponenterna för att stödja skalan. Datainsamlingstjänsten kommer att ha ett övre antal övervakade anslutningar som den kan stödja. När denna gräns har nåtts bör ytterligare en datainsamlare "federeras" för att koordinera datainsamling och orkestrera lagringen av data.
Själva prestandadataarkiven kan dela en instans eller kan vara spridda över flera instanser för att stödja skalning. Den lagring de behöver kommer att vara direkt proportionell mot antalet övervakade anslutningar och mängden data som lagras. Strukturen och arkitekturen för analysförvaret kommer också att påverka den totala kapaciteten.
Användarupplevelse
De flesta lokala verktyg kommer att ha ett Windows-gränssnitt. Vissa har webbläsargränssnitt baserat på en lokalt värd distribution. Fjärråtkomst till dessa kan vara förvirrad och kräver vanligtvis VPN. De stöder sällan mobilappar.
Hög tillgänglighet
Övervakningsprogramvara som övervakar verksamhetskritiska arbetsbelastningar måste vara motståndskraftig i sin egen rätt. Åtgärder bör vidtas för att hantera katastrofsituationer som kan sätta övervakningsstrukturen offline. Detta bör också ses ur ett arkitektur- och kostnadsperspektiv.
SaaS-lösningar
Datainsamlingsprocess
Även om ett SaaS-erbjudande huvudsakligen är värd, kommer det ofta att ha en lokal datainsamlare för lokala arbetsbelastningar. Detta hjälper till att hantera prestanda- och säkerhetsbegränsningar. På detta sätt görs alla anslutningar på instansnivå via den lokala samlaren, som sedan vidarebefordrar övervakad databasprestandadata till molninträngningstjänsten. All data bör krypteras under överföring.
Diagnostik och rapportering/analysarkiv
Den goda nyheten här är att SaaS-leverantören hanterar all din datalagring. Du behöver inte oroa dig för att ställa upp instanser för diagnostikförrådet, rapporteringsförråd, tömning av diagnostikförrådet eller många andra huvudvärk som är förknippade med en lokal distribution.
Hosted-lösningar kommer att använda olika lagringsstrategier i backend för att underlätta en blandning av transaktions- och analytisk aktivitet efter behov. De kan utnyttja molnresurser för att hantera högre datavolymer och den nödvändiga bearbetningen som krävs för analys; t.ex. Spotlight Cloud behåller ett års detaljerad data. Så du kan inte bara rapportera ett år tillbaka i tiden, utan du kan också spela upp din arbetsbelastning upp till ett år i det förflutna. Detta är en riktigt kraftfull funktion.
En SaaS-lösning för övervakning av databasprestanda kan använda en mängd olika back-end-lagringsstrategier, inte bara för att passa den mer transaktionella karaktären av diagnostik och övervakning, utan också för att underlätta den högintensiva siffran som är förknippad med långsiktig analys. SaaS-leverantören kan dra avsevärda stordriftsfördelar för att använda mycket kraftfullare infrastruktur som skulle stå till enskilda organisationers förfogande.
Hur man skalar en SaaS-lösning
Att skala en SaaS-lösning är leverantörens ansvar och inte användaren. Alla SaaS-lösningar för övervakning av databasprestanda måste byggas för att skala från dag ett, och som ett resultat tenderar den att hantera skalan i sin takt.
Användarupplevelse
SaaS-applikationer kommer som standard att använda en webbläsare Ux och många kommer också att ha omfattande mobilappar. Detta underlättar utspridda och avlägsna team.
Säkerhet och efterlevnad
De flesta SaaS-lösningar kommer att byggas på en av de ledande molninfrastrukturerna, som Azure eller Amazon. Många av de ledande leverantörerna har sofistikerad säkerhetsinfrastruktur på plats. De satsar hårt på att stödja sina kunders efterlevnadsbehov.
Hög tillgänglighet
Den goda nyheten här igen är att detta är säljarens ansvar. Det är värt att kolla med din leverantör för att ta reda på vad de har gjort när det gäller failover och hög tillgänglighet. SaaS-applikationer bör utformas för att vara mycket motståndskraftiga. De olika tjänsterna som utgör en SaaS-applikation är vanligtvis utformade för att vara individuellt motståndskraftiga. Åtgärder kan också göras för datacenteravbrott där applikationen skulle misslyckas från ett datacenter till ett annat i händelse av ett datacenteravbrott.