Монитор, который поднимает ложную тревогу, хуже, чем его отсутствие. После нескольких ложных срабатываний люди перестают читать оповещения, и настоящее встречают тем же пожатием плеч. В этом руководстве объясняется, откуда берутся ложные оповещения и что с ними можно сделать.

Начнём с определения. Ложное оповещение — это оповещение о проблеме, которой у ваших посетителей не было. Это не то же самое, что короткая настоящая недоступность: сайт, который две минуты был недоступен, действительно не работал, и оповещение было верным.

Откуда берутся ложные оповещения

Кратковременный сбой между монитором и сайтом

Проверка идёт по публичному интернету. Потерянный по дороге пакет, перегруженный канал или короткая проблема с маршрутизацией могут привести к тому, что одна проверка не пройдёт, хотя для посетителей сайт совершенно исправен. Это самая частая причина, и она проходит сама.

Монитор заблокирован

Файрволы, защита от ботов и ограничения частоты запросов созданы, чтобы останавливать автоматические запросы, а монитор отправляет именно такие. Если ваша защита отвечает на проверку страницей с проверочным заданием или 403 Forbidden, монитор видит сбой, в то время как реальные люди проходят.

UptimeWire считает неудачной проверкой любой конечный ответ вне диапазона от 200 до 399. Это включает 401 и 403. Если ваш сайт показывает такой ответ автоматическим посетителям, разрешите монитор. На момент написания запросы UptimeWire представляются как UptimeWireBot/1.0.

Медленная страница

Проверка ждёт ответа ограниченное время. В UptimeWire проверка сдаётся через 15 секунд. Страница, которая иногда отвечает дольше, например пока прогревается кеш, будет проваливать такие проверки, хотя терпеливый посетитель страницу бы получил.

Следите за адресом, который отвечает быстро, например за простой страницей или страницей проверки работоспособности, а не за тяжёлым поиском или страницей отчёта.

Слишком много перенаправлений

UptimeWire следует не более чем за пятью перенаправлениями. Более длинная цепочка или цикл между двумя адресами считается сбоем с причиной «более 5 перенаправлений». Браузеры тоже ограничены, так что такая длинная цепочка — настоящая неисправность, но показать себя она может только в мониторе.

Слишком строгое правило по тексту страницы

Правило по тексту страницы не пропускает проверку, если ожидаемого текста нет или если появляется запрещённый. UptimeWire читает необработанный HTML страницы, до 1 МБ, и сопоставляет текст без учёта регистра. Скрипты он не выполняет. Текст, который браузер добавляет с помощью JavaScript, в этом HTML отсутствует, поэтому правило, построенное на нём, будет проваливаться на исправной странице.

Плановые работы

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

Как повторные проверки уменьшают шум

Самая простая защита — не верить единичному сбою. Когда проверка не проходит, UptimeWire проверяет снова. Инцидент открывается только после трёх неудачных проверок подряд с интервалом около 20 секунд. Закрывается он после двух успешных проверок.

Если доступно больше одной точки проверки, сбой должны увидеть ещё и больше половины из тех точек, что ответили. Если доступна только одна точка, перед открытием инцидента можно спросить мнение второго сервера, если он настроен. Без второго мнения инцидент может открыться по трём сбоям из одного места.

Компромисс очевиден. Повтор проверки стоит немного времени, примерно 40 секунд сверх интервала проверки. Взамен ложных оповещений становится гораздо меньше. Мгновенного обнаружения это не даёт, как и любая другая настройка.

Окна планового обслуживания

О работах, которые можно предвидеть, сообщайте монитору заранее. В UptimeWire для сайта назначается окно планового обслуживания. Проверки продолжают выполняться, и история показывает сбои, но:

  • Оповещения об инцидентах, начавшихся внутри окна, удерживаются. Если недоступность заканчивается внутри окна, оповещения отменяются. Если она длится дольше конца окна, оповещения отправляются, когда окно заканчивается.
  • Время внутри окна не учитывается при расчёте доступности.
  • Предупреждения о сертификате, домене и DNS окном не удерживаются.

Окно нужно настроить заранее, и на его длину и количество действуют ограничения. Это инструмент для работ, о которых вы объявляете, а не способ скрыть недоступность.

Что настраивать, по порядку

  1. Читайте причины сбоев. История инцидентов показывает, почему каждая проверка не прошла: превышено время ожидания, отказ в соединении, неразрешённое имя, ошибка сертификата или код ответа. Закономерность в причинах обычно называет источник.
  2. Пропустите монитор через вашу защиту, если причина — 403 или проверочное задание.
  3. Выберите более лёгкий адрес, если причина — превышение времени ожидания.
  4. Пересмотрите правила по тексту страницы. Убедитесь, что текст есть в необработанном HTML.
  5. Используйте окна обслуживания для плановых работ.
  6. Выберите, куда приходят оповещения. Первое оповещение отправляйте туда, где его увидит человек, а шумные каналы оставьте для важного.
  7. Отправьте тестовое уведомление, чтобы убедиться, что маршрут работает. Оно также покажет, как выглядит оповещение в 3 часа ночи.

Чего делать не стоит

  • Не увеличивайте интервал проверки, чтобы получать меньше оповещений. Это лишь задерживает обнаружение настоящих сбоев.
  • Не игнорируйте повторяющуюся закономерность. Если монитор срабатывает в одно и то же время каждую ночь, в это время что-то происходит. Возможно, резервное копирование замедляет сервер.
  • Не отключайте монитор, чтобы прекратить шум. Устраните причину.

Когда оповещение настоящее, но короткое

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

Кроме того, HTTP-проверка не видит всех видов сбоев. Ответ 200 не доказывает, что оформление заказа работает, а молчание монитора не доказывает, что всё в порядке. Что измеряет проверка и что она упускает, объясняется в руководстве Мониторинг доступности сайта.

Чек-лист

  • Указана ли в оповещениях причина? Прочитайте её.
  • Пропускает ли монитор защита от ботов и ограничения частоты запросов?
  • Отвечает ли отслеживаемый адрес с большим запасом до 15 секунд?
  • Основаны ли правила по тексту страницы на необработанном HTML?
  • Покрыты ли плановые изменения окном обслуживания?
  • Приходит ли первое оповещение тому, кто на него отреагирует?