Denk aan uw specifieke omgeving voordat u naar een hulpprogramma voor het bewaken van SQL-servers gaat kijken:
- Hoeveel instanties wilt u controleren?
- Bevinden deze zich op één locatie of verspreid?
- Moet je het besturingssysteem en/of de hypervisor in de gaten houden?
- Hoeveel geschiedenis heeft u nodig om een nauwkeurig beeld te krijgen van de werkingsgrenzen van uw instantie?
- Zijn ze allemaal on-premises of zijn sommige in de cloud?
- Zijn uw teams verdeeld?
- Koopt u software met een budget voor kapitaaluitgaven of operationele uitgaven?
- Kunt u het zich veroorloven om vooraf een forfaitair bedrag te investeren in infrastructuur en licenties of wilt u uw kosten liever spreiden over de tijd?
- Heeft u infrastructuur- en database-instances beschikbaar voor een monitoringtool?
- Heeft u tijd om een monitoring-infrastructuur te bouwen?
- Heeft u een consistent hoge expertise in uw team?
- Gebruik je junior resources voor de eerste triage of ben je voor alles afhankelijk van je experts?
- Heeft u intern tijd of middelen om de monitoring-infrastructuur te onderhouden?
Moet ik mijn eigen rollen?
Ik kan hier onze vooringenomenheid verklaren. Quest Software bouwt al 20 jaar prestatiebewakingstools. Er is een uitstekende reden waarom wij en vele anderen zoals wij zo lang in dit segment zijn gebleven en waarom we een groeiend klantenbestand hebben. Prestatiemonitoring goed gedaan is niet eenvoudig!
Er zijn inderdaad enkele geweldige manieren om metrische gegevens van SQL Server te verzamelen met behulp van PerfMon, traces, DMV's en XEvents, om er maar een paar te noemen. Dit eenmalig doen voor een enkel probleem is goed en wel, als u de tijd heeft om te investeren in onderzoek waar en hoe u de gegevens voor dat probleem kunt verzamelen. Zodra de problemen beginnen op te lopen en het aantal instanties toeneemt, wordt dit snel onschaalbaar.
Er zijn honderden statistieken beschikbaar die het waard zijn om te volgen om een volledig beeld te krijgen van de prestatiestatus van uw SQL Server. Daarnaast is er de SQL-code die wordt uitgevoerd en de queryplannen die bij elke uitvoering ervan horen. Sommige statistieken moeten elke seconde worden verzameld, sommige elk uur en sommige op basis van wanneer de code wordt uitgevoerd. Sommige verzamelmethoden kunnen van invloed zijn op de gecontroleerde instantie en moeten worden vermeden.
Elke statistiek heeft verschillende drempels die de status bepalen. Bepaalde instanties kunnen niveaus hebben die niet standaard zijn. Dan moet je dit allemaal bewaren. De hoeveelheid gegevens loopt ZEER snel op. U moet een strategie opzetten om regelmatig gedetailleerde gegevens op te schonen en deze gegevens vervolgens, indien nodig voor trending, samen te voegen voor rapportage.
Het is VEEL werk ... en natuurlijk heb je elke keer als er een nieuwe SQL Server-versie uitkomt, regressiehoofdpijn om mee om te gaan. Tenzij u daadwerkelijk een monitoringtool wilt verkopen, raad ik u ten zeerste af om uw eigen tool te gebruiken, tenzij het aantal problemen laag is en de problemen die u moet oplossen zeer specifiek zijn.
Hoe zit het met gratis tools?
Gratis tools zijn vaak het overwegen waard, vooral voor kleinere teams met minder kritieke instanties. Zie het als de volgende stap op de schaal van schaalbaarheid na 'rol je eigen'. Veel van de commerciële SQL-serverbewakingstools op instapniveau zouden vergelijkbare overwegingen moeten hebben. Overweeg het volgende:
- Dekt de tool voldoende metrische gegevens om u voldoende dekking te bieden voor alle gebruiksscenario's in uw gecontroleerde instanties? Veel gratis tools bieden een soort van "aanpassing" om uw eigen statistieken toe te voegen. Wanneer 'maatwerk' wordt gebruikt om leemten in de functionaliteit op te vullen, zult u snel merken dat uw team 'hun eigen weg gaat' met de nodige afleiding en onderhoudshoofdpijn.
- Ondersteunt de tool waarschuwingen? Is het voorgeconfigureerd? Het configureren van waarschuwingen kan erg tijdrovend zijn. Out-of-box alerting is een must om veel verloren manuren te voorkomen bij het configureren van andermans tool. Het zou ook de aanpassing van waarschuwingen moeten vergemakkelijken voor de randgevallen die niet voldoen aan de standaardinstellingen.
- Hoe en waar worden de gegevens opgeslagen? De meeste gratis tools laten het aan u over om de opslag van prestatiegegevens te beheren. Pas op voor 'gratis' monitoring door cloudleveranciers. Ze brengen wel kosten in rekening voor de opslag, en dit kan snel groot en duur worden!
Maak dus in ieder geval gebruik van de gratis tools die er zijn. Houd rekening met hun beperkingen en let op de klassieke anti-patronen binnen uw team, zoals:
- Meer tijd besteed aan het repareren of onderhouden van de tool dan aan het oplossen van problemen
- Meer geld uitgegeven aan infrastructuur en opslag
- Veel gegevens maar geen inzichten
- Onvoldoende diepgang in diagnostiek om problemen op te lossen
- Niet schaalbaar genoeg om aan uw behoeften te voldoen
Als u een van de bovenstaande punten opmerkt, zou dit moeten wijzen op de noodzaak om te upgraden naar een robuustere oplossing.
Typische architectuur van een SQL Server-bewakingssysteem
Bij het overwegen of u kiest voor een traditionele on-premises oplossing of een gehoste software-as-a-service (SaaS)-oplossing, is het nuttig om de architectuur van de monitoringapplicatie te overwegen. Hier is een samenvatting van de belangrijkste architecturale componenten.
De belangrijkste afwijking tussen SaaS en on-premises heeft betrekking op waar de prestatiegegevens worden opgeslagen en wie deze repository beheert. Voor een on-premises oplossing is dit de verantwoordelijkheid van de eindgebruiker. Deze repositories kunnen snel groot worden, dus ze moeten zorgvuldig worden beheerd. De infrastructuur moet worden gepland en begroot (meer hieronder).
In een SaaS-oplossing voor SQL-serverbewaking worden deze belangrijke infrastructuurcomponenten voor u gehost en beheerd.
| Traditionele on-premises oplossing | SaaS-oplossing |
|
|
Bekijk voor meer informatie onze blog, Database Monitoring System Architecture.