В двух словах
Мониторинг нужен там, где уже определены критичные точки: продление домена, автопродление SSL и стабильность DNS-инфраструктуры.
Хороший мониторинг нужен не для красивых графиков, а для того, чтобы проблемы замечали вы, а не пользователи. Для VPN-сайта этого особенно хочется избежать: если ломается DNS, истекает сертификат или падает кабинет, цена запоздалой реакции быстро становится заметной. Минимальный зрелый мониторинг — это контроль DNS, HTTPS, срока действия сертификатов и базовой доступности ключевых хостов.
В каких случаях это всплывает сразу
- если сайт уже боевой и на нём завязаны продажи, поддержка или кабинет;
- если у проекта есть несколько важных хостов: сайт, `app`, `api`, help, support;
- если вы не хотите узнавать о проблеме из тикета пользователя или скриншота в чате.
Что именно стоит мониторить
Мониторинг сайта должен включать не только сертификат: отдельно проверяют делегацию, TTL и резервные NS, иначе часть аварий останется невидимой.
DNS
Мониторинг DNS полезен не только после миграций. Важно понимать:
- правильно ли резолвятся ключевые хосты;
- не изменилась ли делегация;
- не отдают ли разные резолверы неожиданные ответы;
- не сломались ли MX, TXT или другие критические записи.
SSL
Сертификаты должны не просто «существовать», а быть:
- неистёкшими;
- применёнными на нужных хостах;
- согласованными по SAN и цепочке;
- стабильными в реальном HTTPS-контуре.
Uptime
Под uptime имеет смысл понимать не только «сервер отвечает на ping», а доступность по реальному пользовательскому сценарию:
- главная открывается по HTTPS;
- кабинет отвечает;
- API жив, если он публичен;
- нет неожиданных редиректов на старую среду или ошибочные хосты.
Почему одного мониторинга главной страницы мало
Выбор DNS-провайдера и хостинга влияет на то, что вообще можно мониторить автоматически: у зрелой схемы из DNS-провайдера и хостинга меньше слепых зон.
Очень частая ошибка — следить только за корневым доменом. У проекта может быть зелёный статус на главной, но при этом:
- не работает кабинет;
- истёк сертификат на поддомене;
- сломалась support-форма;
- API отвечает 500, хотя лендинг живёт.
Для VPN-сервиса такая слепая зона особенно неприятна, потому что пользователи часто взаимодействуют не только с главной страницей, а с набором хостов и сценариев.
Практика без лишней теории
Минимальный набор проверок можно строить вокруг таких запросов:
```bash
dig example.com +short
curl -I https://example.com
curl -I https://app.example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
```
Что смотреть:
- домен резолвится правильно;
- ключевые URL отвечают по HTTPS;
- сертификат не подходит к истечению;
- критические поддомены не забыты.
Таблица: что мониторить обязательно, а что желательно
| Элемент | Обязательно | Желательно |
|---|---|---|
| Главный домен по HTTPS | Да | — |
| Критические поддомены | Да | — |
| Срок действия SSL | Да | — |
| DNS-ответы и NS | Да | — |
| MX / support mail | Для проектов с почтой — да | — |
| Отдельные пользовательские сценарии | — | Да |
| Внешние региональные проверки | — | Да |
Срок действия сертификата не должен всплывать только после ошибки в браузере: отдельный алерт должен проверять, что SSL продлился и корректно отдаётся на сайте.
Как это выглядит в реальном проекте
У проекта был настроен базовый uptime-мониторинг главной страницы, и команда считала, что этого достаточно. Позже выяснилось, что кабинет недоступен почти полдня, а support-форма указывает на старый адрес. Главная всё это время оставалась зелёной. После этого мониторинг перестроили вокруг пользовательских путей, а не вокруг одной страницы.
Контрольный чек
Проверьте, можете ли вы быстро ответить:
1. какие три хоста для проекта самые критичные;
2. кто получит алерт при падении;
3. есть ли предупреждение до истечения сертификата;
4. замечаете ли вы ошибку DNS до того, как её видят пользователи.
Если ответы неточные, мониторинг пока декоративный.
Одна успешная проверка ещё не показывает весь сервис
Главная страница может отвечать 200, а кабинет, API, почта или SSL на поддомене уже сломаны. Такой мониторинг создаёт ложное спокойствие: формально сайт жив, но пользовательский сценарий не проходит. Для VPN-проекта нужно наблюдать не только URL лендинга, а цепочку: DNS-ответ, HTTPS, срок сертификата, ключевые поддомены, API и внешнюю доступность из нескольких точек.
Минимальный набор проверок лучше собирать не по удобству настройки, а по пользовательскому пути: главная страница, кабинет или API, DNS-ответ, срок сертификата, HTTPS на ключевых поддоменах и внешний ответ из нескольких точек. Тогда мониторинг ловит не только падение лендинга, но и тихие сбои, которые пользователь замечает раньше команды.
Жалобы пользователей показывают слепую зону мониторинга
Такой симптом почти всегда означает, что мониторинг смотрит не тот сценарий. Он проверяет главную страницу, а пользователи входят в кабинет. Он ходит из одного региона, а проблема видна в другом. Он не проверяет DNS или сертификат поддомена. Решение — добавить проверки именно тех точек, где пользователь сталкивается с сервисом, а не только технически удобного URL.
FAQ
Нужно ли мониторить только аптайм сайта?
Нет. DNS, SSL и критические поддомены не менее важны.
Сколько проверок нужно минимум?
Хотя бы главная, кабинет или API, срок сертификата и базовый DNS-контур.
Можно ли обойтись без внешнего мониторинга?
Можно на старте, но внешние проверки часто замечают то, чего не видно из вашей локальной сети.
Почему алерт нужно привязывать к конкретному слою?
После алерта важно не просто открыть сайт вручную. Нужно понять, какой слой сработал: DNS, SSL, HTTP, приложение или сеть. Если мониторинг показал SSL-ошибку, проверяют сертификат и цепочку. Если упал DNS, смотрят авторитетные NS. Если HTTP-код изменился, открывают логи приложения или proxy. Такой порядок помогает не тушить все слои сразу и не создавать новую ошибку.
