Valg af et SQL Server-overvågningsværktøj, der passer til dine behov

Før du begynder at se på et SQL-serverovervågningsværktøj, så tænk på dit specifikke miljø:

• Hvor mange forekomster vil du overvåge?
• Er disse på ét sted eller spredt?
• Har du brug for at overvåge operativsystemet og/eller hypervisoren?
• Hvor meget historik skal du bruge for at få et præcist billede af grænserne for driften af ​​din instans?
• Er de alle på stedet eller er nogle i skyen?
• Er dine hold fordelt?
• Køber du software under et anlægs- eller driftsbudget?
• Har du råd til at investere et engangsbeløb på forhånd i infrastruktur og licens, eller foretrækker du at sprede dine omkostninger over tid?
• Har du tilgængelige infrastruktur- og databaseinstanser til at dedikere til et overvågningsværktøj?
• Har du tid til at bygge en overvågningsinfrastruktur?
• Har du konsekvent høj ekspertise på tværs af dit team?
• Bruger du juniorressourcer til indledende triage eller er du afhængig af dine eksperter til alt?
• Har du tid eller ressourcer internt til at vedligeholde overvågningsinfrastrukturen?

Skal jeg køre min egen?

Jeg kan erklære vores partiskhed her. Quest Software har bygget værktøjer til overvågning af ydeevne i de sidste 20 år. Der er en fremragende grund til, at vi og mange andre som os er blevet i dette segment så længe, ​​og hvorfor vi har en voksende kundebase. Ydeevneovervågning udført godt er ikke let!

Der er faktisk nogle gode måder at indsamle metrics fra SQL Server ved hjælp af PerfMon, spor, DMV'er og XEvents, for at nævne nogle få. At gøre dette på en engangsbasis for et enkelt problem er godt og godt - hvis du har tid til at investere i at undersøge, hvor og hvordan du indsamler data for det pågældende problem. Når først problemerne begynder at stige, og antallet af forekomster stiger, bliver dette hurtigt uskalerbart.

Der er flere hundrede metrics tilgængelige, som er værd at spore for at få et komplet billede af din SQL Servers ydeevne. Ud over det er der SQL-koden, der kører, og forespørgselsplanerne, der er knyttet til hver udførelse af samme. Nogle metrics bør indsamles hvert sekund, nogle hver time, og nogle baseret på, hvornår koden udføres. Nogle indsamlingsmetoder kan påvirke den overvågede instans og bør undgås.

Hver metrik vil have forskellige tærskler, som vil definere dens status. Særlige tilfælde kan have niveauer, der ikke er standard. Så skal du gemme alt dette. Mængden af ​​data stiger MEGET hurtigt. Du bliver nødt til at indføre en strategi for at rense detaljerede data på regelmæssig basis og derefter, hvis det er nødvendigt for trending, samle disse data til rapportering.

Det er MEGET arbejde ... og selvfølgelig, hver gang en ny SQL Server-version kommer ud, har du en regressionshovedpine at håndtere. Medmindre du rent faktisk ønsker at sælge et overvågningsværktøj, vil jeg kraftigt fraråde at rulle dit eget, medmindre mængden af ​​problemer er lav, og de problemer, du skal løse, er meget specifikke.

Hvad med gratis værktøjer?

Gratis værktøjer er ofte værd at overveje, især for mindre teams med mindre kritiske tilfælde. Tænk på det som det næste trin i skalerbarhedsstigen efter "rulle dit eget". Mange af de kommercielle SQL-serverovervågningsværktøjer på begynderniveau bør have lignende overvejelser. Overvej følgende:

• Dækker værktøjet en tilstrækkelig bredde af metrics til at give dig tilstrækkelig dækning for alle use cases på tværs af dine overvågede forekomster? Mange gratis værktøjer vil give en form for "tilpasning" for at tilføje dine egne metrics. Når "tilpasning" bliver brugt til at udfylde huller i funktionalitet, vil du hurtigt opdage, at dit team ender med at "rulle deres eget" med den nødvendige distraktion og vedligeholdelseshovedpine.
• Understøtter værktøjet alarmering? Er det prækonfigureret? Konfiguration af alarmer kan være meget tidskrævende. Out-of-box alarmering er et must for at forhindre mange tabte mandetimer i at konfigurere en andens værktøj. Det bør også lette tilpasningen af ​​advarsler for kantsager, der ikke overholder standarder.
• Hvordan og hvor opbevares dataene? De fleste gratis værktøjer overlader det til dig at administrere lagringen af ​​ydeevnedata. Vær på vagt over for "gratis" overvågning fra cloud-leverandører. De opkræver betaling for opbevaringen, og det kan hurtigt blive stort og dyrt!

Så udnyt med alle midler de gratis værktøjer, der er derude. Bare vær opmærksom på deres begrænsninger og hold øje med de klassiske anti-mønstre i dit team, såsom:

• Mere tid brugt på at reparere eller vedligeholde værktøjet end at bruge det til at løse problemer
• Flere penge brugt på infrastruktur og opbevaring
• Masser af data, men ingen indsigt
• Ikke nok dybde i diagnostik til at løse problemer
• Ikke skalerbar nok til at passe til dine behov

Hvis du bemærker noget af ovenstående, bør det pege på behovet for at opgradere til en mere robust løsning.

Typisk arkitektur for et SQL Server-overvågningssystem

Når du overvejer, om du skal vælge en traditionel lokal løsning eller en hostet software as a service (SaaS) løsning, er det nyttigt at overveje overvågningsapplikationsarkitekturen. Her er en oversigt over de vigtigste arkitektoniske komponenter.

Nøgleafvigelsen mellem SaaS og on-premises relaterer sig til, hvor ydeevnedataene er gemt, og hvem der administrerer dette lager. For en lokal løsning er dette slutbrugerens ansvar. Disse lagre kan hurtigt blive store, så de skal administreres omhyggeligt. Infrastrukturen skal planlægges og budgetteres (mere nedenfor).

I en SaaS-løsning til SQL-serverovervågning hostes og administreres disse nøgleinfrastrukturkomponenter for dig.

For flere detaljer, tjek vores blog, Database Monitoring System Architecture.