Мониторинг портов регулярно подключается к конкретному хосту и порту, например db01:5432, чтобы убедиться, что сервис действительно принимает соединения. Он находится между ping и HTTP-проверками и отвечает на один вопрос: слушает ли процесс порт, доступен ли он по сетевому пути и достаточно ли быстро принимает соединения? Для надёжности сети это важно, потому что многие сбои происходят, когда хост ещё работает, и заметить их может только проверка на уровне порта.
Как работает проверка порта
Проверка TCP-порта устанавливает соединение так же, как это сделал бы клиент: SYN, SYN-ACK, ACK, затем закрытие. Результат попадает в одно из трёх состояний:
- Open: рукопожатие завершено, значит, сервис слушает порт и доступен.
- Closed: хост ответил сбросом (RST) — он доступен, но к этому порту ничего не привязано.
- Filtered: до истечения таймаута ответ не пришёл; обычно это значит, что межсетевой экран, security group или ACL молча отбросили пакет.
У UDP нет рукопожатия, поэтому проверка отправляет пробную датаграмму и считает корректный ответ успехом. Сообщение ICMP «port unreachable» означает, что порт закрыт, а тишина неоднозначна. Поэтому UDP-проверки лучше всего работают с полезной нагрузкой конкретного протокола, например с настоящим DNS-запросом на порт 53.
Важно и время соединения: если рукопожатие вдруг занимает 800 мс вместо 20 мс, это ранний сигнал, даже если порт по-прежнему открыт.
Место мониторинга портов между ping и HTTP
Рассматривайте три типа проверок как уровни: хост, сервис, приложение.
| Проверка | На какой вопрос отвечает | Типичная слепая зона |
|---|---|---|
| Ping (ICMP) | Доступен ли хост в сети? | Сервис упал, а ОС продолжает отвечать |
| Порт (TCP/UDP) | Принимает ли сервис соединения? | Приложение возвращает ошибки после подключения |
| HTTP/HTTPS | Возвращает ли приложение правильный ответ? | Сервисы без HTTP: базы данных, SMTP, MQTT |
Для сервисов, которые не работают по HTTP, таких как PostgreSQL, Redis, SMTP, SSH или RabbitMQ, проверка порта часто оказывается самым прямым внешним сигналом доступности.
Какие сбои выявляет мониторинг портов
Эти инциденты проходят мимо ping и проявляются только на уровне порта:
- Сервис упал, хост работает. Базу данных завершил OOM killer, но ядро продолжает отвечать на ping. Порт переходит в состояние closed за один интервал проверки.
- Изменение межсетевого экрана или security group. Изменение в инфраструктуре как коде блокирует трафик на порт 5432. Хост по-прежнему отвечает на ping, а порт становится filtered.
- Слушатель привязан не к тому интерфейсу. Сервис слушает
127.0.0.1вместо0.0.0.0. Локально всё выглядит нормально, но удалённые проверки видят порт закрытым. - Медленный accept или исчерпание портов. Переполненная очередь accept, накопление соединений в TIME_WAIT или насыщенный пул приводят к зависанию рукопожатий. Рост времени соединения часто становится первым симптомом.
- Неожиданные сервисы. Порт, который должен быть закрыт, например отладочный интерфейс, вдруг оказывается открытым — это проблема и надёжности, и безопасности.
Чего мониторинг портов не обнаружит
Открытый порт не доказывает, что сервис исправен. Веб-сервер может принимать соединения и возвращать ошибки 500, база данных — принимать соединения и отклонять запросы из-за заполненного диска, а TLS-слушатель — отдавать просроченный сертификат. О медленных запросах и корректности данных проверки портов тоже ничего не говорят. Сочетайте их с проверками HTTP, API и SSL для верхних уровней и с ping для сети ниже.
Практические рекомендации по настройке
- Отслеживайте каждый доступный извне порт сервиса, а также внутренние порты, от которых зависят критичные цепочки.
- Для продакшн-сервисов используйте интервалы 30–60 секунд; для менее критичных систем обычно достаточно 1–5 минут.
- Задавайте таймауты около 5–10 секунд и настраивайте оповещения, когда время соединения заметно превышает базовый уровень, а не только при отказе.
- Подтверждайте сбои из нескольких локаций перед отправкой оповещения, чтобы проблема на одном сетевом маршруте не вызвала ложную тревогу.
- Ведите базовую конфигурацию: какие порты должны быть открыты, а какие закрыты, — и оповещайте об отклонениях в обе стороны.
Мониторинг портов UpScanX поддерживает проверки TCP и UDP, идентификацию сервисов (fingerprinting) с определением версии, проверку ответов с учётом протокола и отслеживание времени соединения из более чем 15 точек по всему миру. UpScanX также сравнивает состояние портов с базовой конфигурацией, чтобы выявлять неожиданные сервисы, и отправляет оповещения через Email, Slack, Telegram, Microsoft Teams или Webhook. Подробнее читайте в статье как работает мониторинг портов.
Ключевые выводы
- Мониторинг портов проверяет, что конкретный сервис принимает соединения, а не только то, что хост доступен.
- Он выявляет упавшие процессы, изменения межсетевого экрана, неправильные адреса привязки и насыщение соединений, которые пропускает ping.
- Состояния open, closed и filtered указывают на разные первопричины, что ускоряет диагностику.
- Он не проверяет поведение приложения, поэтому для полного покрытия сочетайте его с проверками ping, HTTP и SSL.