Для администраторов баз данных, отвечающих за реагирование на предупреждения SQL Server в любое время дня и ночи, ощущение перегрузки, вероятно, усугубляется постоянным потоком уведомлений о том, что что-то требует вашего внимания. ВЕРНО. СЕЙЧАС ЖЕ.
Мониторинг SQL Server имеет решающее значение для поддержания высокой доступности и отслеживания проблем с производительностью в вашей системе, а оповещения - это самый эффективный способ обнаружить проблему.
Как говорится: «Когда все в приоритете, ничто не в приоритете». Усталость от предупреждений реальна и может привести к игнорированию или отклонению событий, которые негативно влияют на ваших пользователей.
При настройке мониторинга производительности SQL Server важно осознанно настраивать сигналы тревоги таким образом, чтобы контролировать, когда, почему и как часто вы получаете уведомления. Вот четыре способа управления предупреждениями, которые помогут уменьшить перегрузку предупреждений и сохранить то, что осталось от вашего рассудка.
1. Отключите ненужные алерты.
Для многих администраторов баз данных это легче сказать, чем сделать. При мысли о выборе предупреждений, которые не следует получать, есть небольшой элемент ужаса. К счастью, есть несколько передовых методов, которые вы можете применить, чтобы сделать FOMO менее болезненным.
Одна из самых простых вещей, которую вы можете сделать, - это просмотреть журналы предупреждений и отключить предупреждения, которые являются хроническими ложными тревогами или ложными срабатываниями. Велики шансы, что вы не пропустите реальную проблему, и ваш мозг оценит перерыв от реакции на ненужные уведомления.
Другая стратегия исходит от инженеров по надежности сайтов (SRE) Google. SRE отвечают за доступность, задержку, производительность, эффективность, управление изменениями, мониторинг, реагирование на чрезвычайные ситуации и планирование емкости.
Команды SRE имеют систему предупреждений / заявок / журналов , чтобы минимизировать перегрузку предупреждений, назначая реакцию на событие в зависимости от того, насколько быстро требуется вмешательство человека. Три возможных ответа включают:
- Оповещение: оповещение отправляется только в том случае, если человек должен немедленно принять меры.
- Тикет: если событие требует действий со стороны человека, но может подождать до обычных рабочих часов, заявка отправляется и проходит через обычные каналы.
- Журнал: если никаких действий не требуется, событие регистрируется для диагностики.
2. Используйте интеллектуальные сигналы тревоги, чтобы быстро найти первопричину оповещения.
Когда ваш телефон взрывается уведомлениями в 3 часа ночи, вы не хотите тратить час на поиски решения проблемы.
Умные алерты не только сообщают вам о проблеме, но и предлагают способы ее решения и помогают определить первопричину. Smart Alarms также предоставляет исторические данные о событии, чтобы вы знали, что произошло непосредственно до и после срабатывания предупреждения.
3. Расставьте приоритеты для оповещений, чтобы выявить самые срочные проблемы.
Все предупреждения не одинаковы, поэтому важно настроить инструмент мониторинга производительности SQL Server таким образом, чтобы он отправлял предупреждения только для наиболее важных проблем. Распределяя приоритеты предупреждений на основе уровня серьезности, влияния на бизнес или клиентов и необходимости немедленных действий, вы устраняете часть шума, создаваемого предупреждениями, которые не являются критическими.
Сосредоточьтесь на настройке предупреждений о проблемах, которые могут вызвать отключение серверов, серьезное повреждение данных или привести к значительной потере данных (например, уровень серьезности 17 или выше и сообщения об ошибках 823, 824 и 825).
4. Управляйте алертами, применяя определенные пороговые значения и правила.
Установка пороговых значений и правил - это огромная экономия на рассудке, потому что это поможет вам избежать множества предупреждений за короткий промежуток времени.
Когда вы определяете пороги производительности, SQL Server не уведомляет вас до тех пор, пока значение указанной метрики не достигнет опасного уровня - например, уровень свободного дискового пространства или свободной физической памяти опасно низок. Это освобождает администраторов баз данных для работы над другими задачами без постоянного мониторинга показателей.
Установка правил для предупреждений позволяет настраивать действия, например, как часто вы хотите получать уведомления. Например, вы можете настроить SQL Server на отправку уведомления только тогда, когда указанное предупреждение было инициировано четыре раза или если предупреждение содержит определенный объект базы данных или имя пользователя.
По мере того как администраторы баз данных начинают ориентироваться в новой и совершенно иной бизнес-среде после COVID-19, уровень стресса наверняка возрастет. Поддержание высокой доступности и обеспечение безопасности и оптимальной работы ваших систем SQL Server останется большим приоритетом. Но сейчас хорошее время, чтобы задействовать возможности мониторинга SQL Server, чтобы взять под контроль ваши конфигурации предупреждений и избавиться от ненужного шума.