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

Предполагается, что мониторинг уже настроен. Если нет, начните с руководства Как следить за доступностью сайта.

О чём говорит проверка доступности

Проверка доступности по расписанию запрашивает один адрес и смотрит на ответ. Она сообщает, ответил ли адрес, как ответил сервер и сколько на это ушло времени. Она не сообщает, что именно сломалось.

Отслеживаемый адрес — это один точный URL. Если вы отслеживаете https://shop.example.com/, проверяется только эта страница. Оформление заказа, страница входа и API по другому адресу не охвачены, пока вы не добавите их как отдельные сайты.

Иллюстративный сбой

Далее выдуманный пример, а не история клиента. Небольшой магазин отслеживает https://shop.example.com/ каждые 3 минуты, а оповещения приходят в общий почтовый ящик, который читает владелец.

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

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

Как читать оповещение

Оповещение о сбое сообщает, что отслеживаемый адрес перестал отвечать правильно и что сбой подтверждён. Почему — оно не сообщает. Зато даёт отправную точку:

  • Какой сайт. В оповещении указан отслеживаемый адрес.
  • Когда началось. У инцидента есть время начала, которое помогает сопоставить его с развёртыванием, резервным копированием или уведомлением провайдера.
  • Что увидела проверка. Статус ошибки, превышение времени ожидания или полное отсутствие ответа указывают на разные места, куда смотреть. Распространённые коды объясняет статья Коды ответа HTTP.

Оповещения по почте и в Telegram доступны на любом тарифе. Вебхук, Discord, Slack и Teams тоже передают сообщения о сбое и восстановлении, в зависимости от тарифа. Какой тариф включает какой канал, смотрите на странице «Тарифы».

Что проверять в первую очередь

UptimeWire не определяет причину, поэтому первые минуты за вами. Короткий порядок, который подходит для большинства небольших сайтов:

  1. Откройте адрес сами в приватном окне браузера. Если он загружается, проблема может быть краткой или касаться только части посетителей.
  2. Посмотрите, какой статус возвращает ваш сервер. Ошибка 5xx указывает на сервер или приложение. Превышение времени ожидания указывает на сеть или перегруженный сервер.
  3. Проверьте хостинг-провайдера. Поищите уведомление о состоянии или перезапуск.
  4. Проверьте, что менялось. Развёртывание, обновление плагина или изменение конфигурации незадолго до инцидента — частая причина.
  5. Убедитесь в восстановлении после ваших действий и дождитесь сообщения о нём.

Note

UptimeWire сообщает, что проблема есть. Он не находит причину и ничего не исправляет.

История после восстановления

Когда инцидент закончился, история превращает один плохой час в информацию:

  • Начало и продолжительность. Как долго сайт был недоступен, чтобы сравнить с ожиданиями.
  • Закономерности. Сбои в одно и то же время суток наводят на мысль о чём-то запланированном, например о резервном копировании или тяжёлой задаче.
  • Время ответа вокруг инцидента. Сайт, который тормозил перед сбоем, указывает скорее на нехватку ресурсов, чем на внезапную поломку.

Сколько дней истории вы видите, зависит от тарифа. Как считаются эти показатели, объясняют статьи глоссария «Доступность» и «Простой», а калькулятор доступности показывает, сколько простоя допускает заданный процент.

Что мониторинг доступности не охватывает

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

  • Нормальный ответ — не работающий сайт. Страница может отвечать нормально, пока оформление заказа, вход или серверная служба сломаны. Можно добавить правило, которое ищет на странице заданный текст; оно сужает разрыв, но не закрывает его.
  • Один адрес — не весь сайт. Другим страницам, поддоменам и API нужны собственные записи.
  • Обнаружение не мгновенно. Интервал задаёт, как часто запрашивается адрес. Подтверждение и доставка добавляют время.
  • Проверок в браузере нет. UptimeWire не проходит пользовательские сценарии вроде добавления товара в корзину.
  • Анализа первопричины нет. Оповещение сообщает, что вышло из строя и когда, но не почему.

Когда это подходит

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