Как настроить проверку TCP-порта (полное руководство)

Url / Domain / IP

Введите цель как host:port, например example.com:22 для SSH или example.com:465 для SMTPS - порт является частью адреса, а не отдельным полем. Вы также можете дать монитору короткое имя, которое будет показываться в оповещениях, отчетах и любых виджетах статуса.

Основные настройки

Отдельного скриншота этого раздела именно для типа проверки Port нет, но он использует ту же группу Main Settings, что и любой другой тип проверки, так что каждый элемент управления ниже - это ровно то, что вы увидите в форме:

• Мониторинг включен: приостанавливает или возобновляет проверку без ее удаления.
• Расписание по интервалу / Расписание по cron: запуск с фиксированным интервалом (ползунок работает от 1 минуты до 24 часов) либо по cron-выражению для паттерна, который шкала интервала выразить не может.
• Теги: метки через запятую для фильтрации и поиска по списку мониторов. Чисто организационная штука - на саму проверку они не влияют.
• Полный лог: сохраняет каждый отдельный результат проверки вместо группировки подряд идущих одинаковых результатов.
• Открытая статистика: делает страницу статистики и лога этого монитора доступной для людей без входа в ваш аккаунт.
• Прикрепленные мониторы - DNSBL: выполняет проверку DNS-блеклиста для того же домена по собственному 12-часовому расписанию, независимому от интервала проверки порта. Обнаруженное плохое состояние оповещает согласно подпискам Down/Repeat в Alert Subscriptions.
• Прикрепленные мониторы - Web Risk: выполняет проверку Google Web Risk на вредоносное ПО/фишинг для домена, тоже по собственному расписанию. Зависит от тарифа.

Настройка запроса

• Connect over TLS/SSL: по умолчанию выключено, то есть проверка открывает обычный TCP-сокет. Включите, чтобы обернуть соединение в TLS-рукопожатие перед чтением ответа - правильный выбор для служб в стиле HTTPS, SMTPS или слушателя базы данных, требующего TLS. Включение этой опции также открывает подгруппу TLS Handshake в разделе Response Validation (ниже) с политиками проверки сертификата. Подсказка на экране для этого переключателя упоминает "обычную службу TCP (или UDP)", но выбора протокола нигде в этой форме нет: каждая проверка Port открывает именно TCP. Если вам нужно мониторить UDP-службу, этот тип проверки сейчас такой возможности не предоставляет.
• DNS Server Selection: тот же выпадающий список, что и у других типов проверок. «DNS-серверы по умолчанию в локациях» разрешает хост через собственные публичные DNS-серверы каждой локации мониторинга, следуя местным правилам. «Публичный DNS» разрешает через публичный пул DNS, с опциональным списком исключаемых резолверов. «Custom» позволяет указать собственные IP DNS-серверов, по одному на строку. На аккаунте, с которого сделан этот скриншот, «Публичный DNS» и «Custom» оба заблокированы баннером апгрейда, что является лимитом тарифа, а не отсутствующей функцией.

Проверка ответа

По умолчанию проверка проходит успешно, когда соединение устанавливается - а при включенном TLS/SSL еще и когда завершается рукопожатие. Элементы управления здесь позволяют требовать больше:

• Response Pattern: опциональное регулярное выражение, которому должен соответствовать ответ. При заданном значении проверка читает до 1 МБ ответа TCP (или TLS, если включено) и проваливается, если шаблон не совпал; оставьте пустым, чтобы судить только по самому соединению. (В более старой документации это называлось "шаблон поиска в TCP-ответе"; текущий интерфейс называет это Response Pattern.) Поскольку читается только первый 1 МБ, размещайте текст, который вы ищете, ближе к началу того, что отправляет служба - хорошо подходит баннер или строка приветствия; содержимое, которое служба отправляет позже в длинном ответе, увидено не будет.
• TLS Handshake (виден только при включенном Connect over TLS/SSL): четыре независимых переключателя, оценивающих само рукопожатие. Require valid SSL certificate chain проваливает проверку при истекшем, самоподписанном, не совпадающем по имени или неверно собранном сертификате. Require strong TLS protocol (1.2 or higher) проваливает сервер, предлагающий только TLS 1.0/1.1 или SSL. Block weak ciphers (128-bit or lower) проваливает проверку, когда согласованный набор шифров - 128 бит или слабее. Check SSL certificate revocation выполняет онлайн-запрос CRL/OCSP во время рукопожатия и проваливает при отозванном сертификате; это отдельное право тарифа от остальных трех.
• Expected IPs Validation: включите это, чтобы дополнительно требовать, чтобы DNS разрешал ваш хост в один из указанных вами IP-адресов, по одному на строку. Если хост начинает разрешаться в другое место - перехват DNS, устаревшая запись, миграция, для которой вы забыли обновить это поле, - проверка проваливается, даже если новый адрес по-прежнему отвечает.

Подписки на оповещения

• Подписать все контакты на события Up/Down: одним движением подписывает всех контактов вашего аккаунта на оповещения Up и Down.
• Переключатели Down / Up / Repeat для каждого контакта: Down срабатывает при переходе в проваленное состояние, Up срабатывает при восстановлении, а Repeat повторно отправляет уведомление Down по расписанию, пока монитор остается в Down.
• Search contacts: фильтрует список по имени или адресу.

Подписки на отчеты

• Подписать все контакты на еженедельные/ежемесячные отчеты: подписывает всех контактов на обе периодичности сразу.
• Переключатели Daily / Weekly / Monthly для каждого контакта: выберите, какое регулярное письмо со сводкой аптайма получает каждый контакт, отдельно от оповещений в реальном времени выше.

Локации мониторинга

• Дерево локаций: выберите, какие локации мониторинга выполняют эту проверку - по континенту, стране или весь мир; «Copy locations from another task» клонирует набор существующего монитора.
• Стратегия перепроверки: как подтверждается смена состояния. По умолчанию - голосование большинством среди локаций перепроверки; альтернативы - конкретное число, подтверждающее Down (ползунок от 1 до 7, по размеру пула перепроверки), вообще без перепроверки, полное согласие всех локаций перепроверки, либо полное согласие для Down при том, что для Up достаточно большинства.
• Если выбранные локации недоступны: «Только выбранные локации» (по умолчанию) ждет возвращения выбранной локации; «Ближайшие локации» вместо этого перезапускает проверку из ближайших доступных; «Любая локация» переключается на любую доступную локацию по всему миру.

Разобранный пример

Мониторинг почтового релея SMTPS на порту 465: установите в Url / Domain / IP значение mail.example.com:465, включите Connect over TLS/SSL, и включите Require valid SSL certificate chain плюс Require strong TLS protocol в TLS Handshake, чтобы истекающий или пониженный сертификат оповестил вас раньше, чем клиенты заметят отскочившую почту. Оставьте Response Pattern пустым, если только у службы нет узнаваемого баннера, который вы хотите подтверждать. Выберите три-четыре локации мониторинга, разбросанные по регионам, оставьте стратегию перепроверки по умолчанию (голосование большинством), подпишите вашего контакта из операционной команды на Down и Up с включенным Repeat, и добавьте подписку на еженедельный отчет для регулярной сводки по аптайму.

Диагностика

• Нет опции UDP: несмотря на то что подсказка Connect over TLS/SSL упоминает UDP, эта форма всегда открывает только TCP-соединение. Если ваша целевая служба работает только по UDP, проверка Port сегодня для этого не подходит.
• Порт доступен, но проверка все равно проваливается при включенном TLS: проверьте переключатели TLS Handshake по одному. Сертификат, технически валидный, но самоподписанный, либо сервер, все еще предлагающий TLS 1.0/1.1, провалит соответственно Require valid SSL certificate chain или Require strong TLS protocol, даже если обычное соединение прошло бы успешно.
• Response Pattern никогда не совпадает: помните, что читается только первый 1 МБ ответа. Шаблон, встречающийся только глубоко в длинном ответе, или служба, отправляющая большую полезную нагрузку перед искомым текстом, никогда не совпадут - держите шаблон на том, что служба отправляет в начале.
• Порт заблокирован на файрволе, а не в службе: проверка, проваливающаяся, даже когда служба прекрасно работает локально, часто означает правило группы безопасности или файрвола, блокирующее именно этот порт для локаций мониторинга HostTracker, а не проблему самой службы - убедитесь, что порт открыт для внешнего трафика, а не только что процесс запущен.
• Expected IPs устаревает после миграции: если вы используете Expected IPs Validation и затем переносите службу на новый хост или IP, обновите список - иначе вы получите ложные Down, даже если служба доступна по новому адресу.

Связанные материалы

• Распределенный мониторинг доступности - страница продукта, охватывающая проверки TCP-порта.
• Бесплатная проверка порта - проверьте пару host:port один раз, мгновенно, без создания монитора.
• Проверка Ping: полное руководство по настройке - более простая проверка доступности, когда не нужно тестировать конкретный порт или службу.
• Режим ассертов: полный справочник по проверке ответа - язык правил проверки ответа, используемый и в других типах проверок.
• Как проверить, открыт ли порт - разовая версия этой проверки, плюс команды nc и nmap за ней.
• Все руководства по мониторингу - руководство по настройке для каждого другого типа проверки.