Мониторинг портов выявляет скрытые сбои, напрямую проверяя сервисы, стоящие за вашим сайтом: базы данных, кэши, очереди, почтовые релеи и точки передачи файлов. HTTP-проверки видят только то, что возвращает фронтенд, а фронтенд может ещё долго отдавать закэшированные страницы или поверхностный health-эндпоинт после отказа зависимости. Отслеживание TCP- и UDP-портов вместе со временем соединения позволяет обнаружить такие сбои за минуты или даже часы до того, как их заметят пользователи или HTTP-мониторы.
Почему HTTP-проверки остаются зелёными во время реальных сбоев
HTTP-монитор задаёт один вопрос: вернул ли этот URL ожидаемый ответ вовремя? Ответ может быть «да», даже когда система уже не работает:
- Закэшированные ответы. CDN или обратный прокси отдаёт устаревшие страницы, пока порт PostgreSQL или Redis за origin-сервером отклоняет соединения.
- Поверхностные health-эндпоинты. Маршрут
/health, возвращающий 200 без обращения к базе данных, доказывает лишь то, что веб-процесс жив. - Сервисы без HTTP-интерфейса. Фоновые воркеры, брокеры сообщений, SMTP-релеи и SFTP-серверы могут полностью отказать, никак не изменив веб-ответы.
- Резервные узлы. Реплика или узел отказоустойчивости может упасть, пока основной узел продолжает обслуживать трафик, и ваш запас прочности незаметно исчезает.
Во всех этих случаях пользовательский слой выглядит нормально, поэтому никто не получает оповещения, пока не истечёт кэш или основной узел не откажет при отсутствии резерва.
Сигналы, которые мониторинг портов замечает раньше
Порты зависимостей перестают отвечать
TCP-проверка портов 5432, 6379, 5672 или 25 подтверждает, что сервис принимает соединения, независимо от веб-слоя. Когда база данных или брокер перестаёт слушать порт, проверка падает при следующем запуске — обычно в пределах интервала 30–60 секунд.
Рост времени TCP-соединения
Когда accept backlog или SYN-очередь сервера заполняется, TCP-рукопожатие замедляется ещё до того, как начнёт завершаться ошибкой. Рост времени соединения с базового уровня 5 мс до 200 мс и выше часто опережает HTTP-таймауты на несколько минут. Оповещение об устойчивом отклонении — например, три проверки подряд выше трёхкратного базового значения — позволяет поймать насыщение, пока ещё есть время масштабироваться или сбросить нагрузку.
Дрейф конфигурации и правил файрвола
Изменение security group или правила файрвола может закрыть не-HTTP-порт, на который полагаются партнёры или внутренние системы. Сравнение состояния портов с известным эталоном сразу фиксирует закрытие, а также выявляет неожиданные сервисы на портах, которые должны быть закрыты.
Реалистичная хронология скрытого сбоя
Возьмём e-commerce-стек с CDN на входе, слоем приложений, PostgreSQL и очередью задач на базе Redis.
| Время | Событие | HTTP-монитор | Монитор портов |
|---|---|---|---|
| 09:00 | У Redis начинается нехватка памяти | 200 OK | Время соединения растёт с 4 мс до 90 мс |
| 09:12 | Redis перестаёт принимать соединения | 200 OK (страницы из кэша) | Порт 6379 недоступен, оповещение отправлено |
| 09:15 | Задачи подтверждения заказов копятся в очереди | 200 OK | Сбой продолжается |
| 09:40 | Истекает TTL кэша, ошибки при оформлении заказа | Ошибки 502 | Расследование уже идёт |
Монитор портов дал команде примерно 28 минут форы и сразу указал на Redis.
Чего не скажут проверки портов
Открытый порт означает, что сервис принимает соединения, но не гарантирует, что запросы возвращают корректные данные, вход в систему работает, а заказ оформляется. База данных может принимать TCP-соединения, пока каждый запрос завершается по таймауту из-за блокировки. Проверка ответов с учётом протокола и идентификация сервисов сокращают этот разрыв, но не заменяют проверки на уровне приложения.
Практичный подход — многоуровневый мониторинг:
- Проверки портов для каждой критичной зависимости, включая реплики и не-HTTP-сервисы.
- HTTP- и API-проверки с валидацией содержимого или кода ответа для пользовательских сценариев.
- Глубокие health-эндпоинты, которые действительно задействуют соединения с базой данных и кэшем.
- Базовые уровни времени соединения с оповещениями об устойчивом дрейфе, а не о единичных всплесках.
Подробнее о механике проверок читайте в нашем руководстве о том, как работает мониторинг портов.
Настройка без лавины оповещений
Мониторинг портов UpScanX выполняет TCP- и UDP-проверки из более чем 15 точек по всему миру, отслеживает время соединения и задержку ответа, определяет сервисы с распознаванием версий и фиксирует изменения состояния относительно эталонной конфигурации. Оповещения приходят по электронной почте, в Slack, Telegram, Microsoft Teams или через Webhook.
Чтобы оповещениям можно было доверять, подтверждайте сбой как минимум из двух точек перед отправкой оповещения и разделяйте публичные порты и внутренние, которые должны быть доступны только внутри вашей сети.
Ключевые выводы
- HTTP-проверки видят фронтенд; проверки портов видят зависимости, которые первыми выходят из строя без видимых признаков.
- Рост времени TCP-соединения — ранний признак насыщения очереди соединений.
- Отслеживайте порты реплик, воркеров, почты и SFTP, а не только основной веб-сервис.
- Проверки портов подтверждают доступность, а не корректность работы, поэтому сочетайте их с HTTP-проверками и глубокими health-проверками.