Які порти я можу моніторити?

Будь-який TCP-порт від 1 до 65535. Типові випадки: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), прослуховувачі баз даних (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), кастомні порти додатків.

Чи монітор перевіряє чи сервіс справний, чи лише його доступність?

Лише доступність — монітор відкриває TCP-з'єднання і перевіряє, чи демон приймає його. Без handshake на рівні протоколу. Якщо потрібні перевірки з протокольною усвідомленістю (наприклад, перевірка банера SMTP, відповідь на SQL-запит), використай HTTP-перевірку (для HTTP-сервісів) чи власного агента heartbeat.

Який таймаут для перевірок порту?

За замовчуванням 10 секунд. Можна налаштувати для кожного монітора. Якщо TCP-з'єднання не встановлюється за цей час, перевірка неуспішна з "connection timeout". Для далеких підключень (наприклад, перевірка сервера в Азії з Європи) можуть знадобитися довші таймаути.

Чи можу я моніторити порти UDP?

Поки що ні. UDP — це протокол без з'єднання, немає еквіваленту "connection accepted" для перевірки. Сервіси на UDP зазвичай потребують специфічних probe для протоколу (наприклад, DNS-запит на порт 53, SNMP get на 161). Використовуй моніторинг heartbeat замість цього.

Чи портовий моніторинг враховує попередження TLS/SSL?

Ні — портові перевірки це чиста доступність TCP. Якщо потрібно перевіряти TLS-сертифікат на порту, використовуй HTTPS-перевірку з портом у URL (наприклад, https://api.example.com:8443/), яка виконує і перевірку доступності, і перевірку сертифіката.

Моніторинг TCP-портів — бази даних, пошта, сервіси

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

Поза HTTP: моніторинг іншої частини стеку

Більшість сервісів, які забезпечують роботу бізнесу, — це не вебсервери. Бази даних слухають на 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Пошта проходить через 25, 465, 587, 993, 995. SSH на 22. Ігрові сервери — на портах, які вибрав видавець. Внутрішні мікросервіси за фаєрволом — на будь-яких, які налаштувала platform team. Жоден із них не говорить по HTTP. Жоден не відображається у інструменті аптайму сайтів. І кожен, коли перестає слухати порт, забирає з собою щось важливе.

Моніторинг портів покриває цю дірку. Ти задаєш монітору хост і порт, і при кожній перевірці відкривається TCP-з'єднання для перевірки чи сервіс слухає порт. Якщо з'єднання не вдається встановити — бо демон впав, змінився фаєрвол, хост не працює, мережа між вами і сервісом пошкоджена — ти отримуєш сповіщення.

Що можна моніторити

Бази даних: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
Поштові сервери: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
Віддалений доступ: 22 (SSH), 3389 (RDP), 5900 (VNC).
Передача файлів: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
Нетипові або внутрішні: шлюзи GraphQL, gRPC, черги (RabbitMQ 5672, Kafka 9092), search (Elasticsearch 9200, Solr 8983), ігрові сервери, пристрої IoT.

Як працює перевірка

Монітор відкриває raw TCP-з'єднання до host:port із таймаутом 5 секунд. Якщо повертається SYN/ACK — порт доступний і сервіс слухає, перевірка пройдена. Якщо connection refused, timeout або no route — перевірка неуспішна, а у результаті зберігається помилка ядра ("connection refused", "operation timed out", "no route to host") — простіше локалізувати проблему.

Монітор не намагається говорити по протоколу додатку — не надсилає SQL-запит чи SMTP HELO. Це тримає перевірку швидкою і без побічних ефектів, що важливо коли ти перевіряєш 100 сервісів щохвилини. Якщо потрібна прикладна верифікація, поєднуй моніторинг порту з heartbeat або власним монітором API.

Поєднання з HTTP і ping

Для кожного публічного сервісу три монітори дають просту діагностичну сходинку. Пінг підтверджує, що хост у мережі. Моніторинг порту — що сервіс слухає. Моніторинг HTTP / API — що сервіс правильно відповідає. Коли щось падає, одразу видно на якому рівні сталася проблема. Лише HTTP падає — впав додаток. Порт теж падає — демон помер. Пінг також не проходить — сервер зник або мережа відсутня.

Налаштування

Відкрий інструмент, натисни "Додати монітор", вибери тип "TCP port", встав хост (без протоколу), введи номер порту (1-65535) і встанови інтервал. Збережи. Починаючи з наступного циклу, монітор кожні хвилину відкриває TCP-з'єднання, зберігає round-trip, а сигналізує у момент закриття порту — через Email, Telegram, Slack, Discord або SMS, з тими ж правилами підтвердження порога і нічного режиму.

Часті питання

Які порти я можу моніторити?
Будь-який TCP-порт від 1 до 65535. Типові випадки: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), прослуховувачі баз даних (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), кастомні порти додатків.
Чи монітор перевіряє чи сервіс справний, чи лише його доступність?
Лише доступність — монітор відкриває TCP-з'єднання і перевіряє, чи демон приймає його. Без handshake на рівні протоколу. Якщо потрібні перевірки з протокольною усвідомленістю (наприклад, перевірка банера SMTP, відповідь на SQL-запит), використай HTTP-перевірку (для HTTP-сервісів) чи власного агента heartbeat.
Який таймаут для перевірок порту?
За замовчуванням 10 секунд. Можна налаштувати для кожного монітора. Якщо TCP-з'єднання не встановлюється за цей час, перевірка неуспішна з "connection timeout". Для далеких підключень (наприклад, перевірка сервера в Азії з Європи) можуть знадобитися довші таймаути.
Чи можу я моніторити порти UDP?
Поки що ні. UDP — це протокол без з'єднання, немає еквіваленту "connection accepted" для перевірки. Сервіси на UDP зазвичай потребують специфічних probe для протоколу (наприклад, DNS-запит на порт 53, SNMP get на 161). Використовуй моніторинг heartbeat замість цього.
Чи портовий моніторинг враховує попередження TLS/SSL?
Ні — портові перевірки це чиста доступність TCP. Якщо потрібно перевіряти TLS-сертифікат на порту, використовуй HTTPS-перевірку з портом у URL (наприклад, https://api.example.com:8443/), яка виконує і перевірку доступності, і перевірку сертифіката.

Моніторинг портів