Статус-страницу на сервере: частые ошибки и решения

MAATRIX

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

Главная ошибка: страница на том же сервере

Самый распространённый и самый болезненный промах — разместить статус-страницу на той же машине, что и мониторимые сервисы. Логика кажется удобной: всё в одном месте. Но когда сервер падает, вместе с сайтом ложится и статус-страница — ровно в тот момент, когда пользователи бегут на неё узнать, что случилось. Вместо честного «известная проблема, чиним» они видят недоступную страницу и идут в поддержку.

Решение одно: статус-страница живёт на отдельном, независимом сервере. В идеале — в другой сети и даже у другого провайдера, чтобы падение основной инфраструктуры её не задело. Это недорого — под статус-страницу хватает самого лёгкого VPS, а страховка окупается первой же аварией.

Если вы уже поставили страницу локально, перенесите её на отдельный VPS. Для Uptime Kuma это просто: скопируйте том с данными на новый сервер и запустите контейнер там. Проверить независимость легко — мысленно спросите: «если основной сервер выключить прямо сейчас, статус-страница останется доступной?». Если нет — она бесполезна во время аварии.

Ложные инциденты и флапающие компоненты

Статус-страница показывает сбой, хотя сервис работает, — и доверие к ней падает. Пользователи, увидев ложную тревогу пару раз, перестают ей верить. Причины ложных инцидентов те же, что у любого мониторинга доступности.

• Короткий таймаут. Сервис иногда отвечает медленно, а порог времени отклика жёсткий — получаем ложный сбой. Увеличьте таймаут и порог времени.
• Нет повторных проверок. Одиночный сетевой сбой сразу рисуется как инцидент. Настройте 2–3 повтора перед объявлением проблемы.
• Проверка тяжёлой страницы. Мониторьте лёгкий health-эндпоинт, а не главную с полной отрисовкой.

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

Здесь есть тонкий баланс между двумя видами ошибок. Слишком чувствительная страница кричит о сбоях, которых нет, и её перестают воспринимать всерьёз. Слишком «толстая» настройка с большими таймаутами и множеством повторов, наоборот, покажет проблему с опозданием, когда пользователи уже всё заметили. Золотая середина — быстрые проверки с 2–3 повторами и порогами, откалиброванными под реальное поведение ваших сервисов: посмотрите на типичное время отклика за нормальный день и ставьте порог с запасом над ним, а не наугад. Раз в пару месяцев стоит пересматривать эти пороги, потому что сервисы меняются, и вчерашняя норма сегодня может давать ложные срабатывания.

Страница недоступна по домену

Вы настроили status.вашсайт.ру, но он не открывается. Разберём по шагам, где обычно рвётся.

Сначала проверьте DNS — резолвится ли поддомен в нужный IP:

dig +short status.вашсайт.ру

Если ответа нет или IP чужой — проблема в DNS-записи, добавьте A-запись на IP сервера статус-страницы и подождите обновления. Если DNS верный, но страница не грузится, проверьте, что Nginx работает и слушает 80/443:

systemctl status nginx
ss -tlnp | grep -E ':(80|443)'

Дальше — firewall: порты 80 и 443 должны быть открыты. И убедитесь, что reverse-proxy проксирует на правильный локальный порт приложения (3001 для Uptime Kuma, 8080 для Gatus). Классическая ошибка — Nginx настроен, но приложение слушает только localhost на другом порту, и proxy_pass указывает не туда. Проверьте связку локально: curl http://127.0.0.1:3001.

Нет HTTPS или сертификат просрочен

Статус-страница по «голому» HTTP или с просроченным сертификатом выглядит несерьёзно и отпугивает — браузер показывает предупреждение безопасности как раз на странице, которая должна внушать доверие. Причина обычно в том, что сертификат не выпущен или автообновление Let's Encrypt не работает.

Выпустите сертификат через certbot, если ещё не сделали:

certbot --nginx -d status.вашсайт.ру

Сертификаты Let's Encrypt живут 90 дней и должны обновляться автоматически. Проверьте, что таймер обновления активен, и прогоните тестовое обновление:

systemctl status certbot.timer
certbot renew --dry-run

Если dry-run проходит без ошибок — автообновление настроено, и сертификат не протухнет. Частая причина сбоя автообновления — закрытый порт 80, через который Let's Encrypt проверяет владение доменом; держите его открытым даже при работе по 443. Ещё полезно завести отдельный монитор на срок действия самого сертификата статус-страницы: иронично, но страница, следящая за здоровьем сервисов, сама нередко падает из-за протухшего сертификата, о котором никто не вспомнил. Пусть система сама предупредит вас за две недели до истечения — этого хватит, чтобы спокойно разобраться, если автообновление вдруг сломалось.

Страница не обновляется или тормозит

Инцидент устранён, а страница всё ещё показывает сбой — или, наоборот, грузится медленно. Если статус завис, дело обычно в кэшировании: reverse-proxy или CDN отдаёт старую версию. Настройте разумные заголовки кэша, чтобы статус обновлялся быстро, но статика кэшировалась.

Если тормозит сама панель (актуально для Uptime Kuma с большой историей), причина — разросшаяся база проверок. Uptime Kuma хранит каждую проверку, и за месяцы данных накапливается много. В настройках задайте период хранения истории (Retention) поменьше, если не нужна глубокая история. Следите за диском и ресурсами:

docker stats --no-stream
df -h

Стабильная и быстрая статус-страница требует надёжного независимого сервера. MAATRIX даёт отдельный VPS под статус-страницу с оплатой картой РФ, СБП или криптой, без иностранной карты, — он остаётся онлайн, даже когда основная инфраструктура лежит, и поднимается за пару минут.

Частые вопросы