Мониторинг доступности (аптайма) сайта снова и снова отвечает на один вопрос: доступен ли мой сайт прямо сейчас? Монитор по расписанию запрашивает ваш сайт, записывает ответ и сообщает, когда ответ меняется. В этом руководстве объясняется, как это работает, что результаты могут и не могут сказать и как решить, что вам нужно.

Речь идёт о методе. Определения см. в статьях доступность и простой в глоссарии. Практическую настройку см. в статье Как следить за доступностью сайта.

Что такое мониторинг доступности сайта

Мониторинг — это цикл из четырёх частей:

  1. Проверка. Система вне вашего сайта запрашивает выбранный вами адрес.
  2. Оценка. Она решает, считать ли ответ рабочим.
  3. Оповещение. Если ответ плохой, она сообщает людям, которых вы назвали.
  4. Запись. Каждый результат сохраняется, чтобы можно было оглянуться назад.

Первые две части определяют, насколько полезны остальные. Монитор, который проверяет не тот адрес или принимает не те ответы, будет докладывать, что всё спокойно, пока ваши посетители видят ошибки.

Почему важна доступность

Когда сайт недоступен, посетители не могут купить, войти, прочитать или связаться с вами. Большинство владельцев узнают о сбое от клиента, коллеги или по пропавшему заказу. Всё это приходит поздно и ничего не говорит о том, когда проблема началась.

Мониторинг меняет две вещи. Вы узнаёте о проблеме, когда она начинается, и сохраняете запись о том, сколько она длилась. Запись полезна и потом: она показывает, единичный ли это случай или закономерность.

Как работает HTTP-мониторинг

Большинство мониторов сайтов говорят по HTTP, на том же языке, что и браузеры. При каждой проверке монитор:

  1. Находит адрес в DNS.
  2. Открывает соединение, а для адресов https:// — защищённое TLS-соединение.
  3. Отправляет HTTP-запрос, обычно GET.
  4. Читает код ответа.

Код ответа — это вердикт. 200 говорит, что сервер обработал запрос. 503 говорит, что сервер работает, но не может его обслужить. Полное отсутствие ответа, потому что DNS не сработал или соединение превысило время ожидания, тоже сбой.

Для перенаправлений нужно правило. Если http://example.com отправляет посетителей на https://www.example.com, монитор может пройти по перенаправлению и оценить конечный ответ либо оценить само перенаправление. UptimeWire следует за ограниченным числом перенаправлений и оценивает конечный ответ: конечный код от 200 до 399 считается доступностью, любой другой — сбоем. Цепочка, которая никогда не завершается, тоже сбой.

Что на самом деле измеряет проверка

Проверка измеряет один запрос к одному адресу из одного места в один момент. Это уже, чем кажется:

  • Она измеряет адрес, который вы ей дали, а не весь ваш сайт. Монитор на главной странице ничего не говорит о /checkout/.
  • Она измеряет ответ, а не то, что страница делает в браузере. Скрипты, изображения и сторонние виджеты не выполняются.
  • Она измеряет один момент. То, что произошло между проверками, не видно.

Проверка также записывает, сколько времени занял ответ. О том, что входит в это число и почему оно различается в разных инструментах, см. статью время ответа.

Выбор интервала мониторинга

Интервал — это время между проверками. Чем он короче, тем раньше находятся проблемы, потому что сбой может заметить только проверка, которая выполняется, пока он происходит.

Интервал Что это значит на практике
1 минута Проблема замечается примерно за минуту-две. Подходит для сайтов, где минуты стоят денег.
5 минут Разумное значение по умолчанию для большинства сайтов компаний.
От 15 до 30 минут Достаточно для сайтов с малым трафиком, где короткая недоступность допустима.
1 час и больше Ловит только долгие сбои. Короткий сбой может пройти между двумя проверками незамеченным.

Две оговорки. Во-первых, интервал — это не время обнаружения: подтверждение (следующий раздел) добавляет немного. Во-вторых, короче не всегда лучше. Если проверка ещё и запускает тяжёлую работу на вашем сервере, выполняйте её реже или направьте на более лёгкий адрес.

Тарифы ограничивают, насколько коротким может быть интервал. В UptimeWire самый короткий — 5 минут на тарифе Free, 3 на Starter и 1 на Business и Agency.

Подтверждение недоступности

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

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

Note

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

Мониторинг снаружи

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

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

Эти два подхода дополняют друг друга. Внешние проверки говорят: «посетители не могут добраться до сайта». Внутренние метрики помогают объяснить почему.

Время ответа

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

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

Сертификаты, домены и DNS

Сайт может отказать не по вине веб-сервера. Должны продолжать работать три отдельные вещи:

  • SSL/TLS-сертификат. Когда он истекает, браузеры показывают предупреждение на весь экран. См. Как не допустить истечения SSL-сертификата.
  • Регистрация домена. Если продление пропущено, домен перестаёт работать и может быть потерян.
  • Разрешение DNS. Если имя больше не разрешается, посетители не могут найти сервер, каким бы исправным он ни был.

Они ломаются медленно, а потом внезапно. Им нужны собственные проверки по собственному расписанию, потому что HTTP-проверка заранее не предупредит. Сертификат, который истекает завтра, сегодня всё ещё отвечает 200.

UptimeWire проверяет сертификат, дату окончания срока действия домена и разрешение DNS для каждого сайта отдельно от проверки доступности. Предупреждения о сертификате, домене и DNS отправляются по почте и в Telegram.

История инцидентов и страницы статуса

Инцидент — это период подтверждённого сбоя, от первой подтверждённой плохой проверки до восстановления. История инцидентов отвечает на вопросы, которые возникают позже: когда это началось, сколько длилось, как часто происходит?

Страница статуса — это публичная страница, показывающая посетителям, работает ли ваш сервис. Она экономит время поддержки во время сбоя и укрепляет доверие после него. Нужна ли она вам, зависит от аудитории. Магазину или SaaS-продукту, чьи клиенты ждут ответов, она полезна. Личному блогу — нет.

Чего мониторинг не может

Чётко понимайте пределы, чтобы спокойная панель не принималась за доказательство того, что всё хорошо.

  • 200 — это не «работает». Сервер может ответить 200, когда база данных недоступна, оформление заказа сломано или страница показывает сообщение об ошибке. Простая проверка запроса этого не видит. Чтобы это обнаружить, монитору нужно искать в ответе что-то конкретное, либо нужно следить за более глубоким адресом, например за страницей проверки работоспособности.
  • Отслеживаются только настроенные адреса. Один адрес — это один адрес. Мониторинг example.com не охватывает shop.example.com или /api/. Добавьте каждый важный.
  • Он не заменяет внутренний мониторинг. Он сообщает, что сайт недоступен, но не какой компонент отказал.
  • Он не является договорным доказательством. Цифры из инструмента мониторинга — оценка, сделанная из одной точки наблюдения. Они полезны для ваших записей, но соглашение об уровне обслуживания (SLA) определяет собственный способ измерения. См. SLA.
  • Проверки выбирают моменты времени. Минутная недоступность между двумя пятиминутными проверками может так и не быть замечена.

Выбор того, за чем следить

Начинайте с того, что причинит больше всего вреда, если сломается, а не с того, что легче проверить.

  1. Составьте список адресов, от которых зависят посетители. Главная страница, страница входа, оформление заказа, конечная точка API. Каждый из них может отказать независимо.
  2. Выберите интервал для каждого. Чем быстрее растёт цена недоступности, тем короче интервал.
  3. Решите, кого и как оповещать. Почта доходит до всех; чат быстрее доходит до дежурного. Убедитесь, что оповещение получит тот, кто его увидит.
  4. Добавьте медленные сбои. Окончание срока действия сертификата и домена, а также DNS должны быть в списке.
  5. Решите, нужна ли посетителям страница статуса.

Практический чек-лист

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

Когда будете готовы всё настроить, руководство Как следить за доступностью сайта пройдёт по шагам в UptimeWire.