«У вас сайт не открывается» — плохой способ узнавать об аварии. К моменту такого сообщения часть посетителей уже ушла, реклама продолжает расходовать бюджет, а владелец ещё выясняет, когда началась проблема. При этом на его компьютере главная страница может спокойно открываться из кэша.
Сократить эту задержку помогает Uptime Kuma — бесплатная программа для проверки доступности сайтов и отправки уведомлений. Она работает на сервере, обращается к нужным адресам по расписанию и сообщает о сбоях, например в Telegram. Но пользу определяет не только установка: важно, откуда выполняются проверки, что именно они проверяют и кто получает тревогу.
Почему мониторинг нужно вынести с сервера сайта
Представьте: интернет-магазин и Uptime Kuma запущены на одном VPS. Пока ломается только приложение магазина, монитор ещё может сообщить об ошибке. Если же зависнет сам VPS или пропадёт сеть, остановятся оба. Сообщение о падении отправлять будет некому.
Поэтому мониторинг размещают отдельно. Причём второй VPS в том же дата-центре защищает лишь от части проблем: общий сбой питания или сети способен отключить и сайт, и наблюдателя. Для большей независимости выбирают другую площадку, а для критичного проекта — ещё и другого провайдера.
Для нескольких сайтов разумно начать с небольшого VPS HSTQ на Linux. Мощный сервер для обычных HTTP-проверок не нужен; важнее стабильная связь и размещение отдельно от проверяемых проектов. Если сайты уже находятся в HSTQ, при подборе VPS сразу обсудите с поддержкой, как разнести их по площадкам и добавить внешний контроль самого мониторинга.
Есть и география пользователей. Проверка из Европы не доказывает, что сайт доступен из всех российских сетей. Если аудитория находится в нескольких странах, стоит иметь дополнительные точки проверки в нужных регионах.
Что проверять, кроме главной страницы
Сервер может отвечать на ping, пока на сайте не работает база данных. А главная — возвращать код 200 OK, хотя вместо каталога посетителю показывается пустой шаблон. Поэтому для магазина или рабочего сервиса одной зелёной отметки недостаточно.
Начните с обычной HTTPS-проверки публичного адреса. Она покажет, удаётся ли установить соединение и получить допустимый ответ. Затем добавьте проверку содержимого: в Uptime Kuma для этого есть тип HTTP(s) — Keyword. Программа будет искать заданную строку в ответе сайта.
Выбирайте фразу, которая присутствует на нужной рабочей странице и отсутствует на странице ошибки. Общее название компании в подвале — слабый вариант: подвал может остаться и при поломке основного содержимого. Если текст появляется только после выполнения JavaScript, обычная HTTP-проверка его не увидит.
У приложений полезен отдельный адрес проверки состояния, например /health. Его должен подготовить разработчик: ответ должен зависеть от доступности действительно нужных компонентов, включая базу данных, если без неё сервис не работает. Постоянная надпись «OK» в статическом файле состояние приложения не проверяет.
Проверку оформления заказа лучше выделить в отдельный сценарий. Загрузка страницы корзины ещё не подтверждает, что товар добавляется, заказ сохраняется и оплата проходит.
Установка Uptime Kuma на отдельный VPS
Ниже — вариант для нового Linux-сервера с уже установленным Docker Engine. Если не хочется заниматься консолью, этот этап можно передать поддержке HSTQ: администрирование бесплатное, установку и настройку специалисты выполнят за вас.
Подключитесь к VPS по SSH и запустите контейнер:
sudo docker volume create uptime-kuma
sudo docker run -d \ --name uptime-kuma \ --restart unless-stopped \ -p 127.0.0.1:3001:3001 \ -v uptime-kuma:/app/data \ louislam/uptime-kuma:2Данные сохраняются в отдельном томе uptime-kuma. Параметр перезапуска позволяет контейнеру подняться после перезагрузки сервера, если Docker запускается вместе с системой. Сам том храните на локальном диске VPS; сетевой каталог NFS для этой схемы не подходит.
Порт 3001 здесь доступен только внутри сервера. Чтобы открыть интерфейс с компьютера, создайте SSH-туннель в отдельном окне терминала:
ssh -N -L 13001:127.0.0.1:3001 USER@SERVER_IPВместо USER и SERVER_IP укажите своего пользователя SSH и адрес VPS. Пока соединение открыто, интерфейс доступен в браузере компьютера по адресу http://127.0.0.1:13001. Создайте учётную запись администратора и включите двухфакторную аутентификацию.
Для постоянного доступа можно настроить отдельный поддомен с HTTPS через Nginx или Caddy. Прокси должен поддерживать WebSocket, иначе интерфейс может терять соединение. Открывать порт 3001 всему интернету для работы проверок не требуется.
Как настроить проверку доступности сайта
Добавьте монитор HTTP(s), дайте ему понятное имя, например «Магазин — каталог», и укажите полный адрес нужной страницы с https. Имя попадёт в уведомление, поэтому «Монитор 1» быстро станет неудобным, когда проектов несколько.
Для начала можно использовать такие настройки:
- Интервал проверки — 60 секунд.
- Тайм-аут ответа — 15 секунд.
- Повторных попыток — 2.
- Интервал между повторными попытками — 20 секунд.
- Допустимые коды ответа — 200–299.
Это стартовый вариант для обычного сайта, а не универсальный норматив. Повторные попытки отсекут часть коротких сетевых сбоев, но увеличат время до тревоги. Уведомление не обязано прийти ровно через минуту: нужно учесть момент следующей проверки, ожидание ответа и повторы.
Не добавляйте ошибки 500–599 в допустимые ответы ради зелёного статуса. Проверку TLS-сертификата тоже лучше оставить включённой: просроченный или неверный сертификат мешает посетителю попасть на сайт. Дополнительно включите предупреждение об истечении сертификата.
Если перед сайтом стоит CDN, отдельно подумайте о проверке приложения за ним. Кэш может продолжать отдавать главную страницу, пока исходный сервер уже недоступен. Для такого случая пригодится согласованный с разработчиком адрес проверки состояния, который не кэшируется.
Мониторинг сайта в Telegram: как подключить уведомления
Для личных уведомлений достаточно отдельного Telegram-бота. Использовать существующего бота магазина или поддержки для этой задачи необязательно.
- Откройте в Telegram официальный аккаунт @BotFather, отправьте команду /newbot и создайте бота. Сохраните полученный токен.
- Перейдите в чат со своим новым ботом и нажмите «Запустить» или отправьте /start.
- В Uptime Kuma откройте настройку уведомлений, выберите Telegram и вставьте токен в поле Bot Token.
- Рядом с Chat ID нажмите Auto Get. Убедитесь, что выбран нужный чат. Если идентификатор не найден, отправьте боту ещё одно сообщение и повторите попытку.
- Отправьте тестовое уведомление, проверьте его получение и сохраните настройку.
- Включите созданное уведомление в каждом нужном мониторе. Само наличие бота в настройках ещё не привязывает его ко всем проверкам.
Токен даёт доступ к управлению ботом: не публикуйте его в скриншотах и открытых обсуждениях. Для рабочих уведомлений проверьте также звук и режим «Не беспокоить» на телефоне. Сообщение, которое пришло в отключённый чат, не поможет быстро отреагировать.
Для важных проектов добавьте второй канал, например почту, и настройте повторные уведомления о продолжающемся сбое. Повторная проверка сайта и повторная отправка тревоги — разные настройки.
Как убедиться, что тревога действительно придёт
Кнопка «Тест» проверяет доставку сообщения, но не всю цепочку от ошибки сайта до уведомления. После настройки стоит провести небольшую проверку без остановки рабочего проекта.
Создайте временный монитор типа HTTP(s) — Keyword для своей страницы. В качестве ожидаемого текста укажите заведомо отсутствующую строку, подключите Telegram и дождитесь сообщения DOWN. Затем замените строку на текст, который действительно есть в ответе страницы. Должно прийти уведомление UP.
Так вы проверите обнаружение ошибки, задержку перед тревогой и сообщение о восстановлении. После теста временный монитор можно удалить. Если тестовое сообщение приходит, а DOWN — нет, сначала проверьте привязку уведомления к монитору и настройки повторных попыток.
Что делать после сообщения о падении
Сохраните время и текст ошибки. «Сайт не работает» и «с 14:32 каталог возвращает HTTP 502» — очень разные обращения в поддержку. Во втором случае инженеру проще сопоставить событие с журналами и изменениями на сервере.
При ошибке DNS сначала проверяют, во что разрешается домен. При тайм-ауте — доступность сервера и сетевой маршрут. Ответ 502 или 503 требует проверки веб-сервера и приложения за ним. Если страница открывается, но пропало контрольное слово, возможны изменение шаблона, ответ защиты от ботов или реальная поломка содержимого.
Проверьте сайт ещё из одной сети, например через мобильный интернет. Один внешний монитор видит только свой путь до проекта. Если у посетителей всё работает, а тревога идёт с одной точки, нужно разбираться с маршрутом или блокировкой этой точки, а не сразу перезагружать сервер.
И заранее договоритесь, кто реагирует на сообщение. Общий чат без ответственного легко превращается в место, где все увидели аварию, но каждый решил, что ею уже занимается коллега.
В HSTQ настройку этой системы можно полностью поручить поддержке. Администрирование бесплатное: специалисты установят Uptime Kuma, настроят доступ к панели, добавят проверки сайтов, подключат Telegram и проверят доставку уведомлений. Помогут разобраться и с сообщениями об ошибках. Для запуска достаточно передать список проектов и объяснить, какие страницы и функции для вас критичны.
Кто будет следить за самим мониторингом
У отдельного VPS тоже может закончиться место на диске или пропасть связь. Поэтому самой Uptime Kuma нужна внешняя проверка: например, второй сервис может следить за её защищённым веб-адресом и сообщать о недоступности. Это обнаружит часть сбоев, хотя само открытие панели ещё не доказывает, что выполняются все проверки. Контрольный тест уведомлений нужно периодически повторять.
Сохраните резервную копию данных мониторинга вне его VPS. Перед обновлениями особенно важно иметь копию, из которой можно восстановить список сайтов и настройки уведомлений.
После смены бота, получателя уведомлений или настроек сети повторите контрольную тревогу. Проверка считается законченной, когда сообщение действительно пришло человеку, который должен на него отреагировать.
