For databaseadministratorer, der er ansvarlige for at reagere på SQL Server-advarsler på alle tidspunkter af dagen og natten, forværres følelsen af at være overbelastet sandsynligvis af den konstante byge af meddelelser om, at noget kræver din opmærksomhed. RET. NU.
SQL Server-overvågning er afgørende for at opretholde høj tilgængelighed og sporing af ydeevneproblemer i dit system, og advarsler er den mest effektive måde at finde ud af, at der er et problem på. Men det er muligt at få for meget af det gode.
Som man siger, "Når alt er en prioritet, er intet en prioritet." Alerttræthed er reel og kan føre til, at du ignorerer eller afviser begivenheder, der påvirker dine brugere negativt.
Når du opsætter din SQL Server-ydelsesovervågning, er det vigtigt at konfigurere alarmer med omhu og på en måde, der styrer hvornår, hvorfor og hvor ofte du modtager meddelelser. Her er fire måder at administrere advarsler på, som vil hjælpe med at lindre overbelastning af advarsler og redde det, der er tilbage af din fornuft.
1. Sluk for de alarmer, du ikke har brug for
For mange DBA'er er dette lettere sagt end gjort. Der er et lille element af rædsel ved tanken om at vælge, hvilke advarsler der ikke skal modtages. Heldigvis er der nogle bedste praksisser, du kan implementere, som kan gøre din FOMO en smule mindre smertefuld.
En af de nemmeste ting, du kan gøre, er at gennemgå advarselsloggene og slukke for advarsler, der er kronisk falske alarmer eller falske positive. Der er gode chancer for, at du ikke går glip af et reelt problem, og din hjerne vil sætte pris på pausen fra at reagere på unødvendige notifikationer.
En anden strategi kommer fra Googles webstedspålidelighedsingeniører (SRE'er). SRE'er er ansvarlige for tilgængelighed, latens, ydeevne, effektivitet, ændringsstyring, overvågning, nødberedskab og kapacitetsplanlægning.
SRE-holdene har et alarm-/billet-/logsystem på plads for at minimere overbelastning af alarmer ved at tildele et svar til en hændelse, der er baseret på, hvor hurtigt menneskelig indgriben er påkrævet. De tre mulige svar inkluderer:
- Advarsel:En advarsel sendes kun, hvis en person straks skal handle.
- Billet:Hvis begivenheden kræver handling fra en person, men den kan vente til normal åbningstid, indsendes en billet og går gennem de normale kanaler.
- Log:Hvis ingen handling er påkrævet, logges hændelsen til diagnostik.
2. Brug smarte alarmer til hurtigt at finde årsagen til en alarm
Når din telefon blæser op med meddelelser klokken 03.00, vil du ikke bruge en time på at finde rundt for at løse problemet.
Smarte alarmer fortæller dig ikke kun, at du har et problem, men foreslår også måder at løse det på og hjælper dig med at identificere årsagen. Smarte alarmer giver også historiske data om begivenheden, så du ved, hvad der skete umiddelbart før og efter, at alarmen blev udløst.
3. Prioriter dine alarmer for at identificere de mest presserende problemer
Alle advarsler er ikke oprettet ens, så det er vigtigt at konfigurere dit SQL Server-ydelsesovervågningsværktøj, så det kun sender advarsler om de vigtigste problemer. Ved at prioritere advarsler baseret på sværhedsgrad, indvirkning på virksomheden eller kunder, og om øjeblikkelig handling er påkrævet, eliminerer du noget af den støj, der genereres af advarsler, der ikke er kritiske.
Fokuser på at konfigurere advarsler for problemer, der kan få dine servere til at gå offline, alvorligt korrupte data eller resultere i betydeligt datatab (f.eks. sværhedsgrad 17 eller højere og fejlmeddelelser 823, 824 og 825).
4. Administrer alarmer ved at anvende specifikke tærskler og regler
At indstille tærskler og regler er en enorm fornuftsbesparelse, fordi det vil hjælpe dig med at undgå at blive bombarderet af flere advarsler på kort tid.
Når du definerer ydeevnetærskler, holder SQL Server ud med at give dig besked, indtil en værdi for en specificeret metrik når et relevant niveau - for eksempel er ledig diskplads eller ledig fysisk hukommelsesniveauer farligt lave. Dette frigør DBA'er til at arbejde med andre opgaver uden konstant at overvåge metrics.
Indstilling af regler for underretninger giver dig mulighed for at tilpasse handlinger, såsom hvor ofte du vil have besked. For eksempel kan du indstille SQL Server til kun at sende en meddelelse, når en specificeret advarsel er blevet udløst fire gange, eller hvis advarslen indeholder et bestemt databaseobjekt eller brugernavn.
Efterhånden som DBA'er begynder at navigere i et nyt og meget anderledes forretningsmiljø efter COVID-19, vil stressniveauet med sikkerhed stige. Opretholdelse af høj tilgængelighed og sikring af, at dine SQL Server-systemer er sikre og yder optimalt, vil fortsat være en stor prioritet. Men nu er det et godt tidspunkt at få SQL Server-overvågningskapacitet til at tage kontrol over dine alarmkonfigurationer og slippe af med den unødvendige støj.