Der er et voksende antal fantastiske systemer til overvågning af databaseydeevne derude. For nylig har de mere traditionelle lokale løsninger fået selskab af software as a service (SaaS) løsninger.
Denne blog kontrasterer den typiske arkitektur for en lokal løsning med den for en SaaS-løsning. Selvfølgelig vil komponenter variere i navn og struktur fra den ene leverandør til den anden, men de nøglebegreber, der diskuteres her, vil være repræsenteret på en eller anden form.
Forskelle mellem lokale og SaaS-løsninger
Overordnet set er her nogle af nøglekomponenterne i hver løsning:
Traditionel løsning på stedet
- Dataindsamlingsproces.
- Kortsigtet ydeevne [diagnostik]-lager.
- Langsigtet analyse-/rapporteringslager.
- Windows- eller browserklient.
- Enhver failover-infrastruktur, der kræves til overvågningsinfrastrukturen.
SaaS-løsning
- Dataindsamlingsproces (for lokale mål).
- Browserklient.
- Mobilapp.
- SaaS-leverandøren administrerer applikationen og back-end-datalagringen.
Bemærk, at navnene på de forskellige komponenter vil variere fra den ene løsning til den anden. I nogle tilfælde kan funktionaliteten være opdelt på tværs af flere tjenester eller datakilder.
On-Premises-løsninger
Dataindsamlingsproces
Dataindsamleren er typisk en lokal, agentløs tjeneste, der indsamler data fra ethvert lokalt overvåget slutpunkt. Denne proces orkestrerer, hvordan og hvornår data indsamles. Det bør være i stand til at indsamle data ved forskellige frekvenser for at balancere behovet for flere detaljer med indvirkning på den overvågede arbejdsbyrde. Indsamlingsfrekvenser og alarmtærskler bør være forudkonfigurerede på tværs af hver metric.
Alle vil have en "støjende" instans, der ikke overholder standardtærsklerne. Dette kan resultere i en masse falske positiver. For at håndtere dette bør systemet have mulighed for at skabe regler på instansniveau til at håndtere ekstraordinære omstændigheder. Dette undgår "alarmtræthed" fra falske positiver.
I nogle tilfælde orkestrerer denne tjeneste også advarsler og meddelelser. I store organisationer med hundredvis af overvågede tilfælde kan det være nødvendigt at balancere belastningen ved at "føderere" på tværs af en række dataindsamlere. Federation synkroniserer samlinger og konfiguration på tværs af et spredt system.
Short-Term Diagnostics Repository
Det er her detaljerede data gemmes. Dette vil omfatte data fra DMV'er, logfiler, XEvents og andre SQL Server-datakilder. Kilder, der kunne udøve pres på de overvågede tilfælde, bør undgås, f.eks. er de fleste spor uegnede til overvågning i realtid.
Fordi indsamlingsfrekvenser kan være lige så ofte som hver anden og større datastykker såsom TSQL og planer indsamles, kan dette lager hurtigt blive stort. Som følge heraf vil de fleste systemer typisk begrænse historikken til mellem en uge og en måned (disse begrænsninger gælder ikke for en SaaS-løsning). Dette lager er meget transaktionsbaseret.
Langtidsrapportering/Analytics-lager
Ved slutningen af et foruddefineret tidsrum aggregeres disse detaljerede data og lagres i et rapporteringslager til analyse og trending på højt niveau. Mængden af bevarede detaljer vil have en væsentlig indflydelse på den eventuelle størrelse af dette depot og den beregningskapacitet, som man med rimelighed kan forvente, at en bruger stiller til rådighed for at analysere det. Dette har en tendens til at variere betydeligt fra den ene løsning til den næste. Løsninger, der understøtter dybere analyser, vil have understøttende arkitekturer og kan bruge OLAP-arkitekturer til at lette multidimensionel analyse.
Skalering af en overvågningsløsning på stedet
Mere sofistikerede løsninger vil blive designet til at lette en distribueret arkitektur af nøglekomponenterne for at understøtte skala. Dataindsamlingstjenesten vil have et højere antal overvågede forbindelser, den kan understøtte. Når denne grænse er nået, bør en ekstra dataindsamler "fødereres" for at koordinere dataindsamling og orkestrere lagringen af dataene.
Selve præstationsdatalagrene kan dele én instans eller kan være spredt over flere instanser for at understøtte skalering. Den lagring, de har brug for, vil være direkte proportional med antallet af overvågede forbindelser og mængden af data, der opbevares. Strukturen og arkitekturen af analyselageret vil også påvirke den samlede kapacitet.
Brugeroplevelse
De fleste lokale værktøjer vil have en Windows-frontend. Nogle har browser-frontends baseret på en lokalt hostet implementering. Fjernadgang til disse kan være indviklet og kræver typisk VPN. De understøtter sjældent mobilapps.
Høj tilgængelighed
Overvågningssoftware, der overvåger missionskritiske arbejdsbelastninger, skal være robust i sig selv. Der bør træffes foranstaltninger til at håndtere katastrofesituationer, der kan sætte overvågningsstrukturen offline. Dette bør også overvejes ud fra et arkitektur- og omkostningsperspektiv.
SaaS-løsninger
Dataindsamlingsproces
Selvom et SaaS-tilbud primært er hostet, vil det ofte opretholde en lokal dataindsamler for lokale arbejdsbelastninger. Dette hjælper med at løse ydeevne- og sikkerhedsbegrænsninger. På denne måde oprettes alle forbindelser på instansniveau via den lokale samler, som derefter videresender de overvågede databaseydelsesdata til skyindgangstjenesten. Alle data skal være krypteret under overførsel.
Diagnostik og rapportering/analytikopbevaring
Den gode nyhed her er, at SaaS-leverandøren håndterer al din datalagring. Du behøver ikke at bekymre dig om at opstille forekomster for diagnostiklagrene, rapporteringslagre, udskylning af diagnoselageret eller mange af de andre hovedpine, der er forbundet med en lokal implementering.
Hostede løsninger vil trække på forskellige lagringsstrategier i bagenden for at lette en blanding af transaktions- og analytisk aktivitet efter behov. De kan trække på cloud-ressourcer til at håndtere større datamængder og den nødvendige behandling, der kræves til analyser; f.eks. opbevarer Spotlight Cloud et års detaljerede data. Så du kan ikke kun rapportere et år tilbage i tiden, men du kan også afspille din arbejdsbyrde op til et år i fortiden. Dette er en virkelig kraftfuld egenskab.
En SaaS-løsning til overvågning af databaseydeevne kan bruge en række forskellige back-end-lagringsstrategier, ikke kun for at passe til den mere transaktionelle karakter af diagnostik og overvågning, men også for at lette den høj-intensitets-talknusning, der er forbundet med langsigtede analyser. SaaS-leverandøren kan trække på betydelige stordriftsfordele til at bruge langt mere kraftfuld infrastruktur, som vil være til rådighed for individuelle organisationer.
Sådan skalerer du en SaaS-løsning
Skalering af en SaaS-løsning er leverandørens og ikke brugerens ansvar. Enhver SaaS-løsning til overvågning af databaseydeevne skal bygges til at skalere fra dag ét, og som følge heraf har den en tendens til at håndtere skalaen i sit skridt.
Brugeroplevelse
SaaS-applikationer vil som standard bruge en browser Ux, og mange vil også have omfattende mobilapps. Dette letter spredte og fjerntliggende teams.
Sikkerhed og overholdelse
De fleste SaaS-løsninger vil blive bygget på en af de førende cloud-infrastrukturer, såsom Azure eller Amazon. Mange af de førende leverandører har sofistikerede sikkerhedsinfrastrukturer på plads. De er stærkt investeret i at understøtte deres kunders overholdelsesbehov.
Høj tilgængelighed
Den gode nyhed her er igen, at dette er leverandørens ansvar. Det er værd at tjekke med din leverandør for at finde ud af, hvad de har lavet med hensyn til failover og høj tilgængelighed. SaaS-applikationer bør bygges til at være meget modstandsdygtige. De forskellige tjenester, der udgør en SaaS-applikation, er typisk designet til at være individuelt modstandsdygtige. Der kan også tages hensyn til datacenterafbrydelser, hvor applikationen ville fejle fra et datacenter til et andet i tilfælde af datacenterudfald.