Документация

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

Для чего подходит

Для чего не подходит

Проверка порта говорит, что дверь открывается. Что за ней — она не говорит:

Почему TCP и UDP — это не одна и та же проверка

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

У UDP рукопожатия нет. Отправка датаграммы — локальная операция: пакет ушёл, и сеть никому ничего не должна рассказывать о его судьбе. Поэтому UDP-монитор не может узнать ничего одной только отправкой. Он должен послать то, на что сервис ответит, и дождаться ответа. Ответ — это и есть всё доказательство.

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

Что делает TCP-проверка

1. Открывает соединение с хостом и портом.
2. Записывает время установки соединения как время отклика.
3. По желанию читает баннер — приветствие, которое многие сервисы шлют сразу после подключения, например строку с версией SSH или SMTP.
4. Закрывает соединение. Монитор ничего не отправляет сервису: даже при чтении баннера он только слушает.

Если чтение баннера включено, монитор читает до 1024 байт, декодирует их как текст и сохраняет вместе с проверкой. Баннера он ждёт не дольше 5 секунд и меньше, если от таймаута монитора осталось мало, — но не меньше одной секунды.

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

Что делает UDP-проверка

1. Резолвит имя хоста. У этого шага свой предел — 5 секунд или таймаут монитора, если он меньше.
2. Отправляет одну датаграмму с полезной нагрузкой.
3. Ждёт ответ до истечения таймаута, если ожидание не выключено.
4. По желанию сверяет ответ с ожидаемой строкой и записывает, сколько байт пришло.

Если нагрузка не задана, монитор выбирает её по порту:

Для всего, кроме DNS и NTP, рассчитывайте писать нагрузку самостоятельно. Сервис сам решает, что достойно ответа, и заглушка по умолчанию обычно им не является.

UDP-монитору нужен явный порт в адресе. Никакого порта по умолчанию не подставляется: адрес без порта сразу проваливает проверку с соответствующим сообщением, потому что угаданный порт молча мониторил бы не то.

Если выключить ожидание ответа

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

Что означает молчание

Таймаут — единственный результат, который на двух протоколах читается по-разному, и полезно понимать, с каким молчанием вы имеете дело.

В TCP молчание нетипично. Живой хост, на котором порт никем не занят, обычно сразу отказывает в соединении, и монитор записывает этот отказ. Молчание вместо отказа обычно значит, что файрвол не отклоняет пакеты, а выбрасывает их, — или что самого хоста больше нет.

В UDP молчание — обычный способ вас проигнорировать. Ответа нет — значит, сервис лежит, или файрвол выбросил запрос, или ответ потерялся на обратном пути, или сервис просто не счёл вашу нагрузку достойной ответа. Различить это монитор не может, поэтому UDP-монитор с таймаутом говорит «ответа нет», а не «сервис лежит». Иногда операционная система всё же получает ICMP-сообщение о недоступности порта — тогда проверка падает с этой ошибкой, а не по таймауту, но дойдёт ли такое сообщение, решает сеть по пути.

Практический вывод такой: UDP-монитор достоверен ровно настолько, насколько правильна отправляемая нагрузка. Угадали с нагрузкой — получили настоящую проверку. Не угадали — получили вечную аварию на здоровом сервисе.

Логика статусов

Состояния деградации у этих мониторов нет. Порогов по времени отклика у TCP и UDP тоже нет — результат либо «работает», либо «не работает», либо «таймаут».

DOWN и TIMEOUT считаются простоем и открывают инцидент — после порога подтверждения, по умолчанию это три неудачные проверки подряд, чтобы один потерянный пакет никого не будил.

Настройки

В форме TCP есть поле «Ожидаемый ответ»: если его заполнить, проверка читает баннер и требует в нём этот текст; если оставить пустым — проверяется только то, что порт принимает подключения. Нагрузки UDP и её ожидаемого ответа в форме по-прежнему нет — их задают через REST API или инструменты MCP на том же мониторе, который вы создали в интерфейсе.

Ключевые возможности

• Один тип монитора на любой порт TCP или UDP, на цель ничего ставить не надо
• TCP записывает время установки соединения и, по запросу, баннер сервера
• Необязательное ключевое слово в баннере для TCP и ожидаемый текст ответа для UDP — несовпадение проваливает проверку
• Готовые UDP-нагрузки для DNS и NTP, для всего остального — своя нагрузка
• Отказ, таймаут и недоступный порт записываются как разные ошибки, поэтому на странице монитора видно, что именно произошло