Базовый мониторинг и полезное оповещение

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

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

Внешняя точка наблюдения

Проверяющий узел должен находиться отдельно от обслуживаемого сервера. Иначе при отказе VPS одновременно исчезнет сайт и его наблюдатель. Это может быть сервис проверки или собственная подготовленная машина. Конкретный выбор зависит от необходимой независимости и доступных инструментов. В нашей учебной схеме наблюдатель обращается к https://example.com обычным способом, проходя DNS и TLS, как посетитель.

Для начала выберем три запроса: health.json, старую статью и специально отсутствующий адрес. Первый показывает доступность небольшого ресурса и номер выпуска. Второй проверяет значимый материал. Третий должен получить 404, то есть у него другая норма. Если ожидать от всех запросов 200, проверка неизвестного пути будет сигналить о правильном поведении, а ошибочный переход на главную станет выглядеть успехом.

Учебные условия
/health.json: 200, узнаваемое поле release
/my/legacy/first.php: 200, контрольная фраза статьи
/monitoring-not-found: 404, оформление ошибки
TLS: доверенная цепочка, нужное имя, достаточный запас срока

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

Пример модуля проверки

Один из подходящих инструментов — Prometheus Blackbox Exporter. Он умеет описывать HTTP-проверку, ожидаемый статус и условия по телу. Ниже дан фрагмент конфигурации модуля, а не законченная установка Prometheus и доставки уведомлений. Компонент не запускался; читатель выберет совместимую версию и свяжет модуль с целевым URL в собственном стенде. Официальная конфигурация Blackbox Exporter.

modules:
  release_health:
    prober: http
    timeout: 5s
    http:
      method: GET
      valid_status_codes: [200]
      fail_if_not_ssl: true
      fail_if_body_not_matches_regexp:
        - '"release"\s*:\s*"[^" ]+"'

Регулярное выражение проверяет узнаваемую форму, а не строгое соответствие JSON-схеме. Для более сильного контроля применяют проверку JSON подходящим инструментом. На сегодняшний день нам достаточно отличить индикатор от обычной HTML-ошибки. Не отключаем проверку сертификата ради успешного результата. Таймаут в пять секунд — учебный выбор для маленького файла; реальное значение согласуют с ожиданиями и наблюдаемым сетевым путём.

Когда посылать сигнал

Одна неудачная попытка может быть кратким сетевым событием. Если она сразу создаёт срочное уведомление, владелец постепенно перестаёт читать сообщения. Вместо этого правило учитывает повторяемость: например, сигнал после нескольких последовательных неудач при минутном опросе. Это пример, не универсальный порог. Чем дольше подтверждение, тем позже узнаем о настоящем отказе; чем короче, тем выше чувствительность к случайным сбоям.

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

Сигнал должен содержать имя сайта, время, проверенный URL, ожидаемый и полученный результат. Желательно добавить ссылку на журнал изменений, чтобы увидеть недавний выпуск. Сообщение «ошибка сервера» заставляет начинать диагностику заново. Сообщение «старая статья вместо 200 получила 404 после кандидата r2» уже задаёт направление: сопоставить паспорт, корень и наличие файла.

Проверить сам путь уведомления

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

Уведомление о восстановлении полезно, если оно связано с прежним событием. Оно показывает, что проверяемый адрес снова соответствует норме, но не объясняет причину автоматически. Если владелец выполнил откат, это отмечают в журнале. Если сайт восстановился сам, событие всё равно может потребовать краткого разбора: повторяющиеся краткие отказы способны оставаться незаметными за зелёным итоговым индикатором.

Ограничения базового набора

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

Внутренние метрики дополняют внешний набор. Для VPS полезны место, память и состояние служб; для Beget часть сведений доступна через инструменты площадки. Устанавливать на виртуальном хостинге собственный системный сборщик без соответствующих прав не требуется. Сначала определяют, какую проблему нужно обнаружить, затем выбирают доступный источник. График ради самого графика не делает сопровождение понятнее.

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

Этим уроком завершается основной блок. У нас есть модель выпуска, подготовка площадки, staging, публикация, возврат, копия и наблюдение. В следующей части появятся приложения и постоянные данные: они добавят состояния, которые уже нельзя обслуживать только чтением HTML из выбранного каталога.