Як налаштувати перевірку TCP-порту (повний посібник)

Url / Domain / IP

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

Main Settings

Скриншота цього розділу саме для типу перевірки Port немає, але він використовує ту саму групу Main Settings, що й будь-який інший тип перевірки, тож кожен елемент керування нижче - точно те, що ви побачите у формі:

• Monitoring enabled: призупиняє чи відновлює перевірку без її видалення.
• Interval schedule / Cron schedule: запускайте з фіксованим інтервалом (повзунок охоплює від 1 хвилини до 24 годин) або за cron-виразом для патерну, який шкала інтервалу виразити не може.
• Tags: мітки через кому для фільтрування й пошуку за списком моніторів. Суто організаційне - на саму перевірку вони не впливають.
• Full Log: зберігає кожен окремий результат перевірки замість групування послідовних однакових результатів.
• Open Stats: робить сторінку статистики й логу цього монітора доступною для людей без входу у ваш акаунт.
• Прикріплені монітори - DNSBL: виконує перевірку DNS-чорного списку для того самого домену за власним 12-годинним розкладом, незалежним від інтервалу перевірки порту. Виявлений поганий стан сповіщає згідно з підписками Down/Repeat у розділі Alert Subscriptions.
• Прикріплені монітори - Web Risk: виконує перевірку Google Web Risk на шкідливе ПЗ/фішинг для домену, теж за власним розкладом. Залежить від тарифу.

Request Configuration

• Connect over TLS/SSL: вимкнено за замовчуванням, тобто перевірка відкриває звичайний TCP-сокет. Увімкніть, щоб обгорнути з'єднання в TLS-рукостискання перед читанням відповіді - правильний вибір для служб у стилі HTTPS, SMTPS чи слухача бази даних, що вимагає TLS. Увімкнення цього також відкриває підгрупу TLS Handshake під Response Validation (нижче) з політиками перевірки сертифіката. Підказка біля цього перемикача згадує "простий сервіс TCP (чи UDP)", але вибору протоколу в цій формі ніде немає: кожна перевірка Port набирає саме TCP. Якщо вам потрібно моніторити UDP-службу, цей тип перевірки наразі такого варіанту не пропонує.
• DNS Server Selection: той самий розкривний список, що й в інших типів перевірок. Default DNS servers at locations розв'язує хост через власні публічні DNS-сервери кожної локації моніторингу, за місцевими правилами. Public DNS розв'язує через публічний пул DNS, з опційним списком виключених резолверів. Custom дає змогу вказати власні IP DNS-серверів, по одному на рядок. На акаунті, з якого зроблено цей скриншот, Public і Custom заблоковані банером апгрейду, що є обмеженням тарифу, а не відсутньою функцією.

Response Validation

За замовчуванням перевірка проходить успішно, коли з'єднання завершується - а якщо 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, застарілий запис, переїзд, який ви забули тут оновити, - перевірка провалюється, навіть якщо нова адреса й далі відповідає.

Alert Subscriptions

• Subscribe all contacts to Up/Down events: підписує всіх контактів вашого акаунта на сповіщення Up і Down одним рухом.
• Перемикачі Down / Up / Repeat для кожного контакту: Down спрацьовує при переході в стан збою, Up спрацьовує при відновленні, а Repeat повторно надсилає сповіщення Down за розкладом, поки монітор лишається в Down.
• Search contacts: фільтрує список за ім'ям чи адресою.

Report Subscriptions

• Subscribe all contacts to Weekly/Monthly reports: підписує всіх контактів на обидві періодичності одразу.
• Перемикачі Daily / Weekly / Monthly для кожного контакту: оберіть, який регулярний лист зі зведенням аптайму отримує кожен контакт, окремо від сповіщень у реальному часі вище.

Monitoring Locations

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

Розібраний приклад

Моніторинг поштового релею SMTPS на порту 465: встановіть в Url / Domain / IP значення mail.example.com:465, увімкніть Connect over TLS/SSL, а під TLS Handshake увімкніть Require valid SSL certificate chain разом із Require strong TLS protocol, щоб сертифікат, який спливає чи знижується в рівні, сповістив вас раніше, ніж клієнти помітять недоставлену пошту. Лишіть Response Pattern порожнім, якщо тільки служба не надсилає розпізнаваний банер, який ви хочете підтвердити. Оберіть три-чотири Monitoring Locations, розкидані по регіонах, лишіть Recheck strategy на голосуванні більшістю за замовчуванням, підпишіть вашого контакта з операційної команди на 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, навіть якщо служба досяжна за новою адресою.

Пов'язане

• Distributed Availability Monitoring - сторінка продукту, що охоплює перевірки TCP Port.
• Безкоштовна перевірка порту - перевірте пару host:port один раз, миттєво, без створення монітора.
• Перевірка Ping: повний посібник з налаштування - простіша перевірка досяжності, коли не потрібно тестувати конкретний порт чи службу.
• Режим тверджень: повний довідник з перевірки відповіді - мова правил перевірки відповіді, що використовується й в інших типах перевірок.
• Як перевірити, чи відкритий порт - разова версія цієї перевірки, плюс команди nc і nmap за нею.
• Усі посібники з моніторингу - посібник з налаштування для кожного іншого типу перевірки.