Виды мониторинга

Зачем нужны разные типы мониторинга

Один и тот же сервер может выглядеть исправным на уровне сети, но при этом не отдавать сайт, API или базу данных. Поэтому Upvisor разделяет проверки по слоям: сеть, веб, порт, DNS, контент и входящие heartbeat-сигналы. Так проще понять, что именно сломалось: хост, сервис, DNS-зона, сертификат или фоновая задача.

При создании проверки достаточно выбрать тип и указать цель. Если пользователь вводит домен вместо IP, Upvisor сам резолвит адрес там, где это нужно для выполнения проверки. Для HTTP/S можно указать домен без протокола: адрес будет приведен к корректному URL автоматически.

Ping-мониторинг

Ping использует ICMP и отвечает на простой вопрос: виден ли хост из внешнего региона проверки. Это хороший первый слой контроля для VPS, выделенных серверов, сетевых устройств и IP-адресов, где важно понимать, есть ли вообще сетевой ответ.

У Ping есть важное ограничение: успешный ICMP-ответ не означает, что приложение на сервере работает. Например, сервер может отвечать на ping, но веб-сервер, база данных или почтовый сервис уже недоступны. Поэтому для production-сервисов Ping лучше использовать вместе с HTTP/S или TCP-проверкой.

• Когда использовать.
  Контроль доступности IP, VPS, роутера, балансировщика или внешнего узла.
• Что учитывать.
  ICMP может быть отключен firewall-ом или провайдером. В таком случае лучше проверить HTTP/S или TCP-порт.

HTTP/S-мониторинг

HTTP/S-проверка подходит для сайтов, API, личных кабинетов, webhook endpoints и любых сервисов, которые отвечают по HTTP или HTTPS. Upvisor делает запрос из выбранных регионов, измеряет время ответа, сохраняет код ответа и определяет состояние монитора по заданным правилам.

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

Для HTTP/S можно включить контроль медленного ответа. Это не полная недоступность, а деградация: сервис отвечает, но делает это дольше заданного порога. Такой сигнал полезен, когда проблема уже влияет на пользователей, но еще не превратилась в полный outage.

Мониторинг ключевых слов

Проверка ключевых слов работает поверх HTTP/S: Upvisor загружает ответ страницы и анализирует тело ответа. Этот тип подходит, когда важно не просто получить HTTP 200, а убедиться, что на странице или в API-ответе есть ожидаемый текст.

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

Такой мониторинг удобен для контроля страницы оплаты, статуса очереди, наличия фразы в JSON-ответе, отсутствия текста ошибки, проверки публичной страницы статуса или контроля изменений контента.

• Текст найден.
  Проверка успешна, если в ответе есть нужная строка или совпадение по regex.
• Текста нет.
  Проверка успешна, если в ответе отсутствует запрещенная фраза, например “fatal error” или “maintenance”.

Проверка TCP-портов

TCP-мониторинг проверяет, можно ли открыть соединение с указанным портом. Он подходит для сервисов, у которых нет HTTP-интерфейса: базы данных, SMTP, IMAP, SSH, Redis, RabbitMQ, PostgreSQL, MySQL и внутренних API, опубликованных на отдельном порту.

Если соединение установилось быстрее заданного тайм-аута, проверка считается успешной. Если порт закрыт, соединение сброшено, сервис завис или firewall не пропускает трафик из региона проверки, Upvisor отметит ошибку и сможет создать инцидент после достижения порогов.

Для TCP важно указывать именно тот порт, который должен быть доступен снаружи. Если сервис намеренно закрыт для внешней сети, лучше использовать внутренний мониторинг или heartbeat-сценарий.

Мониторинг DNS

DNS-проверки следят за записями домена и помогают быстро заметить изменения, которые могут повлиять на доступность сервиса. Это особенно важно для A, AAAA, CNAME, MX, TXT и NS-записей: ошибка в них может уронить сайт, почту, подтверждение домена или интеграцию с внешним сервисом.

В отдельном DNS-мониторе можно выбрать тип записи и ожидаемое значение. Если ответ DNS перестает совпадать с настройкой, проверка становится неуспешной. Для HTTP/S-монитора можно дополнительно включить контроль A-записи: он будет отображаться внутри текущего монитора как связанный блок.

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

Heartbeat / Cron-мониторинг

Heartbeat работает наоборот: не Upvisor ходит к вашему сервису, а ваша задача сама отправляет запрос в Upvisor. Такой подход подходит для cron-задач, ночных бэкапов, очередей, воркеров, синхронизаций, парсеров и других процессов, которые не имеют публичного URL.

После создания heartbeat-монитора вы получаете уникальные URL. Их можно вызвать из cron, CI/CD, воркера или скрипта. Если сигнал не пришел вовремя, либо задача явно отправила ошибку, Upvisor создаст инцидент и отправит уведомления в каналы этого монитора.

curl -fsS https://upvisor.online/heartbeat/hb_xxx/start
curl -fsS https://upvisor.online/heartbeat/hb_xxx/success
curl -fsS https://upvisor.online/heartbeat/hb_xxx/fail

SSL, срок домена и DNS A внутри HTTP/S

В Upvisor SSL-сертификат, срок регистрации домена и DNS A-запись не создаются как отдельные пользовательские мониторы. Они включаются внутри HTTP/S-монитора и показываются отдельными блоками в его карточке. Это не расходует лимит проверок тарифа.

Срок регистрации проверяется по базовому домену. Если в проекте уже есть монитор для smmlift.ru, а позже добавлен cdn.smmlift.ru, проверка срока домена не дублируется. При этом SSL и A-запись остаются отдельными для каждого хоста, потому что сертификат и IP у поддомена могут отличаться.

Медленные ответы и деградация

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

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

Как выбрать правильный тип проверки

• 1
  Сайт или API.
  Начните с HTTP/S. Если важно содержание ответа, добавьте проверку ключевого слова.
• 2
  Сервер или IP.
  Используйте Ping как базовый сигнал сети, но не полагайтесь на него как на проверку приложения.
• 3
  Конкретная служба.
  Для базы, почты, SSH или любого сервиса на порту используйте TCP-проверку.
• 4
  DNS и доменная инфраструктура.
  Для записей используйте DNS-мониторинг, а для срока домена и SSL включайте связанные блоки внутри HTTP/S.
• 5
  Фоновая задача.
  Если сервис не имеет публичного адреса, используйте Heartbeat и отправляйте сигнал из самой задачи.