För databasadministratörer som ansvarar för att svara på SQL Server-varningar under alla timmar på dygnet, förvärras sannolikt känslan av att vara överbelastad av den ständiga störtfloden av meddelanden om att något behöver din uppmärksamhet. RÄTT. NU.
SQL Server-övervakning är avgörande för att upprätthålla hög tillgänglighet och spåra prestandaproblem i ditt system, och varningar är helt enkelt det mest effektiva sättet att ta reda på att det finns ett problem. Men det går att få för mycket av det goda.
Som ordspråket säger, "När allt är en prioritet, är ingenting en prioritet." Varningströtthet är verklig och kan leda till att du ignorerar eller avfärdar händelser som påverkar dina användare negativt.
När du ställer in din SQL Server-prestandaövervakning är det viktigt att konfigurera larm medvetet och på ett sätt som styr när, varför och hur ofta du får aviseringar. Här är fyra sätt att hantera varningar som hjälper till att lindra varningsöverbelastning och rädda det som finns kvar av ditt förstånd.
1. Stäng av de larm du inte behöver
För många DBA:er är detta lättare sagt än gjort. Det finns ett litet element av skräck vid tanken på att välja vilka varningar som inte ska tas emot. Lyckligtvis finns det några bästa praxis du kan implementera som kan göra din FOMO lite mindre smärtsam.
En av de enklaste sakerna du kan göra är att granska varningsloggarna och stänga av varningar som är kroniskt falska larm eller falska positiva. Oddsen är goda att du inte missar ett verkligt problem, och din hjärna kommer att uppskatta pausen från att reagera på onödiga meddelanden.
En annan strategi kommer från Googles webbplatstillförlitlighetsingenjörer (SRE). SRE är ansvariga för tillgänglighet, latens, prestanda, effektivitet, förändringshantering, övervakning, nödsituationer och kapacitetsplanering.
SRE-teamen har ett varnings-/biljett-/loggsystem på plats för att minimera varningsöverbelastning genom att tilldela ett svar på en händelse som är baserat på hur snabbt mänskligt ingripande krävs. De tre möjliga svaren inkluderar:
- Varning:En varning skickas endast om en person omedelbart måste vidta åtgärder.
- Biljett:Om evenemanget kräver åtgärd av en person, men det kan vänta till normal kontorstid, skickas en biljett in och går via de vanliga kanalerna.
- Logg:Om ingen åtgärd krävs loggas händelsen för diagnostik.
2. Använd smarta larm för att snabbt komma till grundorsaken till en varning
När din telefon exploderar med aviseringar klockan 03.00 vill du inte spendera en timme på att leta runt för att åtgärda problemet.
Smarta larm berättar inte bara att du har ett problem utan föreslår också sätt att åtgärda det och hjälper dig att identifiera grundorsaken. Smarta larm ger också historisk information om händelsen så att du vet vad som hände omedelbart före och efter att varningen utlöstes.
3. Prioritera dina varningar för att identifiera de mest akuta problemen
Alla varningar skapas inte lika, så det är viktigt att konfigurera ditt SQL Server-prestandaövervakningsverktyg så att det bara skickar varningar för de viktigaste problemen. Genom att prioritera varningar baserat på svårighetsgrad, påverkan på verksamheten eller kunderna, och om omedelbara åtgärder krävs, eliminerar du en del av det brus som genereras av varningar som inte är kritiska.
Fokusera på att ställa in varningar för problem som kan få dina servrar att gå offline, allvarligt korrupta data eller leda till betydande dataförlust (t.ex. allvarlighetsgrad 17 eller högre och felmeddelanden 823, 824 och 825).
4. Hantera larm genom att tillämpa specifika trösklar och regler
Att ställa in trösklar och regler är en enorm förnuftsbesparing eftersom det hjälper dig att undvika att bli bombarderad av flera varningar på kort tid.
När du definierar prestandatrösklar väntar SQL Server med att meddela dig tills ett värde för ett angivet mått når en relevant nivå - till exempel är ledigt diskutrymme eller lediga fysiska minnesnivåer farligt låga. Detta frigör DBA:er för att arbeta med andra uppgifter utan att ständigt övervaka mätvärden.
Genom att ställa in regler för varningar kan du anpassa åtgärder, till exempel hur ofta du vill bli meddelad. Du kan till exempel ställa in SQL Server att endast skicka ett meddelande när en angiven varning har utlösts fyra gånger eller om varningen innehåller ett visst databasobjekt eller användarnamn.
När DBA:er börjar navigera i en ny och mycket annorlunda affärsmiljö efter COVID-19, kommer stressnivåerna säkert att stiga. Att upprätthålla hög tillgänglighet och se till att dina SQL Server-system är säkra och fungerar optimalt kommer att förbli en stor prioritet. Men nu är det ett bra tillfälle att anlita SQL Server-övervakningsfunktioner för att ta kontroll över dina varningskonfigurationer och bli av med det onödiga bruset.