Алерты

Представьте, что на сервере закончилось место на диске, и ваше приложение больше не может обрабатывать запросы. Или про ваш интернет-магазин написал известный блогер и к вам пришло небывалое количество посетителей, но сайт не справился с подскочившим трафиком и «лег».

Как вы бы хотели узнать об этом — из ленты новостей? Или от недовольных пользователей? Как можно оперативно отслеживать подобные проблемы или еще лучше — узнавать о них заранее? На прошлых уроках вы познакомились с сервисом Yandex Monitoring. Но мониторинг требует постоянного активного внимания — кто-то (вы или ваши коллеги) постоянно должен быть на дежурстве, чтобы отслеживать значения метрик и предпринимать меры, когда эти значения приближаются к критическим. Если же дежурного нет, то скорее всего вы узнаете о проблеме только когда она уже случится.

Хорошо бы передать контроль автоматике — пока все показатели в норме, система молча следит за ними, но как только какой-то показатель начинает вызывать тревогу, автоматика срабатывает и «будит» человека. Такие сигналы называются алертами.Алерты — обязательный элемент мониторинга.

Как только вы начинаете мониторить какой-то сервис или приложение, вам стоит сразу же настроить один или несколько алертов.Фактически алерт — это функция, которая регулярно вызывается и вычисляет значение метрики. В Yandex Monitoring значения метрик проверяются раз в минуту. Результатом работы функции будет статус:

• OK — если значение метрики укладывается в пределы установленной нормы,
• Warning — если значение метрики достигло порога предупреждения,
• Alarm — если значение метрики достигло критического порога.

Есть еще два возможных статуса: NoData (не хватает данных для расчета) и Error (невозможно вычислить значение).

Обработка пиковых значений

Иногда метрики могут резко возрастать до пиковых значений, а затем снова возвращаться в норму. Такие всплески нагрузки не считаются опасными.Например, в кластере ресурсы одной виртуальной машины закончились. При этом была автоматически создана еще одна виртуальная машина, нагрузка была распределена между ними, и уровень утилизации ресурсов на каждой машине снова стал укладываться в норму.

При таком сценарии отправлять алерт администратору не стоит, автоматика устранила проблему без вмешательства человека.Чтобы исключить  лишние алерты, можно использовать функции агрегации. Например, для алерта вычисляется средний уровень утилизации ресурса за период в 5 минут. Если в течение 5 минут автоматика устранила проблему, то средний уровень утилизации ресурса будет укладываться в норму, и алерт не отправляется.

Если же критический уровень нагрузки сохраняется дольше 5 минут, это означает, что автоматика не справляется и нужно вмешательство администратора. Тогда ему отправляется алерт на почту, в виде SMS или push-уведомления в браузере.

На следующей практической работе мы посмотрим, как настраивается алерт и в каком виде его получает администратор.