После переноса общего HTTPS-входа на веб-сервер возник следующий вопрос: как узнавать о проблемах, не открывая каждый сервис вручную? Сайт и веб-почта могут работать сегодня, но это не гарантирует, что завтра всё останется в порядке.

Для мониторинга домашней лаборатории я использую Uptime Kuma. В ней собраны проверки сайта, почтовых служб и других сервисов. Она регулярно проверяет их доступность, сохраняет историю результатов и отправляет уведомления при изменении состояния.

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

Сервер доступен. А приложение?

У доступности несколько уровней. Ответ на ping показывает, что узел отвечает на сетевой запрос. Открытый TCP-порт означает, что соединение удалось установить. Ответ веб-страницы позволяет проверить уже HTTP или HTTPS.

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

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

Две проверки одного сервиса могут отвечать на разные вопросы

После переноса HTTPS-входа в Uptime Kuma сохранили локальную проверку почтового приложения и добавили отдельную HTTPS-проверку веб-почты через новый обратный прокси.

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

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

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

Сертификат — часть работоспособности

HTTPS нужен не только для получения страницы. Важно, чтобы сертификат был действующим, соответствовал имени сайта и проходил проверку доверия.

Отключать проверку сертификата ради зелёного индикатора — значит скрывать часть проблемы. В нашей истории с переносом входа ошибка соединения исчезла после исправления настройки проверки цепочки сертификатов. Саму проверку TLS сохранили.

Также полезно контролировать срок действия сертификата и получать предупреждение заранее. Такое предупреждение оставляет время на проверку автоматического продления, пока сайт ещё доступен посетителям. Само наличие HTTPS-монитора не означает, что предупреждения о сроке уже настроены: это нужно проверять отдельно.

Уведомления должны помогать

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

Для новых проверок в нашей лаборатории принят ориентир: интервал 60 секунд и две повторные попытки. Это отправная точка. Для разных сервисов допустимое время обнаружения и настройки повторов могут отличаться.

Уведомления подключаются через общий профиль. Но наличие выбранного профиля ещё не доказывает, что сообщение дойдёт. Правильная проверка включает тестовую отправку и получение сообщения владельцем. Затем полезно проверить и сообщение о восстановлении.

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

Закрытый сервис можно проверять внутри сети

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

Базу данных, слушающую только localhost, проверяют локально. Для более глубокой проверки используют учётную запись с минимальными необходимыми правами. Пароли, токены и приватные адреса не должны попадать в публичную страницу состояния или примеры статьи.

Что дала эта настройка

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

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