За администраторите на бази данни, които отговарят на сигналите на SQL Server по всяко време на деня и нощта, усещането за претоварване вероятно се влошава от постоянния залп от известия, че нещо се нуждае от вашето внимание. НАД. СЕГА.
Мониторингът на SQL Server е от решаващо значение за поддържане на висока наличност и проследяване на проблеми с производителността във вашата система, а сигналите са най-ефективният начин да разберете, че има проблем. Но е възможно да има твърде много добро нещо.
Както се казва:"Когато всичко е приоритет, нищо не е приоритет." Умората от предупреждения е реална и може да доведе до игнориране или отхвърляне на събития, които влияят негативно на потребителите ви.
Когато настройвате мониторинг на производителността на SQL Server, важно е да конфигурирате алармите внимателно и по начин, който контролира кога, защо и колко често получавате известия. Ето четири начина за управление на сигнали, които ще помогнат за облекчаване на претоварването на сигналите и ще спестите това, което е останало от разума ви.
1. Изключете алармите, от които не се нуждаете
За много DBA това е по-лесно да се каже, отколкото да се направи. Има малък елемент на ужас при мисълта да изберете кои сигнали да не получавате. За щастие има някои най-добри практики, които можете да приложите, които могат да направят вашия FOMO малко по-малко болезнен.
Едно от най-лесните неща, които можете да направите, е да прегледате регистрационните файлове за предупреждения и да изключите сигналите, които са хронично фалшиви аларми или фалшиви положителни резултати. Шансовете са добри, че няма да пропуснете истински проблем и мозъкът ви ще оцени почивката от реакция на ненужни известия.
Друга стратегия идва от инженерите за надеждност на сайтовете (SREs) на Google. SRE отговарят за наличността, забавянето, производителността, ефективността, управлението на промените, наблюдението, реакцията при спешни случаи и планирането на капацитета.
Екипите на SRE разполагат със система за предупреждение/билет/регистрация, за да сведат до минимум претоварването с предупреждения чрез присвояване на отговор на събитие, който се основава на това колко бърза е необходима човешка намеса. Трите възможни отговора включват:
- Сигнал:Сигнал се изпраща само ако човек трябва незабавно да предприеме действия.
- Билет:Ако събитието изисква действие от лице, но може да изчака до нормалното работно време, билетът се изпраща и преминава през нормалните канали.
- Регистър:Ако не се изисква действие, събитието се записва за диагностика.
2. Използвайте интелигентни аларми, за да стигнете бързо до основната причина за сигнал
Когато телефонът ви избухне с известия в 3 часа сутринта, не искате да прекарвате час в ровене, за да отстраните проблема.
Интелигентните аларми не само ви казват, че имате проблем, но и предлагат начини за отстраняването му и ви помагат да идентифицирате основната причина. Интелигентните аларми също предоставят исторически данни за събитието, така че да знаете какво се е случило непосредствено преди и след задействането на сигнала.
3. Дайте приоритет на сигналите си, за да идентифицирате най-спешните проблеми
Всички сигнали не са създадени еднакви, така че е важно да конфигурирате инструмента за наблюдение на производителността на SQL Server, така че да изпраща сигнали само за най-важните проблеми. Чрез приоритизиране на сигналите въз основа на ниво на сериозност, въздействие върху бизнеса или клиентите и дали са необходими незабавни действия, вие премахвате част от шума, генериран от сигнали, които не са критични.
Съсредоточете се върху настройването на сигнали за проблеми, които могат да доведат до изключване на сървърите ви в режим офлайн, сериозно повреда на данни или до значителна загуба на данни (т.е. сериозност 17 или по-висока и съобщения за грешка 823, 824 и 825).
4. Управлявайте алармите чрез прилагане на специфични прагове и правила
Задаването на прагове и правила е огромно спестяване на здравия разум, защото ще ви помогне да избегнете бомбардиране от множество сигнали за кратък период от време.
Когато дефинирате прагове на производителност, SQL Server спира да ви уведомява, докато стойност за определен показател достигне тревожно ниво – например нивата на свободно дисково пространство или свободна физическа памет са опасно ниски. Това освобождава DBA да работят по други задачи, без постоянно да наблюдават показателите.
Задаването на правила за сигнали ви позволява да персонализирате действия, като например колко често искате да получавате известия. Например, можете да настроите SQL Server да изпраща известие само когато определено предупреждение е било задействано четири пъти или ако предупреждението съдържа определен обект на база данни или потребителско име.
Тъй като DBA започват да се ориентират в нова и много различна бизнес среда след COVID-19, нивата на стрес със сигурност ще се повишат. Поддържането на висока наличност и гарантирането, че вашите SQL Server системи са защитени и работят оптимално, ще остане голям приоритет. Но сега е подходящ момент да включите възможностите за наблюдение на SQL Server, за да поемете контрола над вашите конфигурации за предупреждение и да се отървете от ненужния шум.
