Monitoring portów

Poza HTTP: monitoring reszty stacka

Większość usług utrzymujących biznes to nie są web serwery. Bazy słuchają na 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Poczta lata przez 25, 465, 587, 993, 995. SSH na 22. Serwery gier na portach jakie wybrał wydawca. Wewnętrzne mikroserwisy za firewallem - na czymkolwiek skonfigurował platform team. Żadna z nich nie mówi po HTTP. Żadnej nie zobaczysz w narzędziu uptime stron. I każda, gdy przestanie nasłuchiwać, zabiera ze sobą coś widocznego.

Monitoring portów łata tę dziurę. Dajesz monitorowi hosta i port, a przy każdym sprawdzeniu otwierane jest połączenie TCP weryfikujące, czy usługa nasłuchuje. Jeśli połączenie zawiedzie - bo daemon padł, firewall się zmienił, host jest down, sieć między nami a usługą jest uszkodzona - dostajesz alert.

Co możesz monitorować

• Bazy danych: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
• Serwery pocztowe: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
• Zdalny dostęp: 22 (SSH), 3389 (RDP), 5900 (VNC).
• Transfer plików: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
• Niestandardowe lub wewnętrzne: bramki GraphQL, gRPC, kolejki (RabbitMQ 5672, Kafka 9092), search (Elasticsearch 9200, Solr 8983), serwery gier, urządzenia IoT.

Jak działa sprawdzenie

Monitor otwiera surowe połączenie TCP do host:port z 5-sekundowym timeoutem. Jeśli wraca SYN/ACK - port jest osiągalny i usługa nasłuchuje, check up. Jeśli connection refused, timeout lub no route - check down, a w wyniku zapisany jest błąd z jądra ("connection refused", "operation timed out", "no route to host") - łatwiejszy triage.

Monitor nie próbuje rozmawiać po protokole aplikacji - nie wysyła zapytania SQL ani SMTP HELO. To trzyma sprawdzenie szybkim i bez efektów ubocznych, co liczy się gdy sprawdzasz 100 usług co minutę. Jeśli potrzebujesz weryfikacji aplikacyjnej, połącz monitoring portu z heartbeat lub własnym monitorem API.

Łączenie z HTTP i ping

Dla każdej publicznej usługi trzy monitory dają czystą drabinkę diagnostyczną. Ping potwierdza że host żyje w sieci. Monitoring portu - usługa nasłuchuje. Monitoring HTTP / API - usługa odpowiada poprawnie. Gdy coś pada, padająca warstwa od razu mówi gdzie szukać. Tylko HTTP pada - aplikacja crashuje. Port też pada - daemon padł. Ping też pada - pudełko zniknęło lub sieć padła.

Konfiguracja

Otwórz narzędzie, kliknij "Dodaj monitor", wybierz typ "TCP port", wklej hosta (bez protokołu), wpisz numer portu (1-65535) i ustaw interwał. Zapisz. Od następnego cyklu monitor co minutę otwiera połączenie TCP, zapisuje round-trip, a alarmuje w sekundzie zamknięcia portu - przez Email, Telegram, Slack, Discord lub SMS, z tymi samymi regułami progu potwierdzenia i ciszy nocnej.

Najczęściej zadawane pytania

• Jakie porty mogę monitorować?

  Każdy port TCP od 1 do 65535. Powszechne przypadki: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), listenery baz danych (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), customowe porty aplikacji.

• Czy monitor sprawdza czy usługa jest zdrowa czy tylko dostępna?

  Tylko dostępność — monitor otwiera połączenie TCP i sprawdza czy demon je akceptuje. Bez handshake'a na poziomie protokołu. Jeśli potrzebujesz checków świadomych protokołu (np. weryfikacja banneru SMTP, odpowiedź zapytania bazy danych), użyj checka HTTP (dla usług HTTP) lub self-hosted agenta heartbeat.

• Jaki jest timeout dla checków portu?

  Domyślnie 10 sekund. Konfigurowalny per monitor. Jeśli połączenie TCP nie nawiązuje się w oknie timeout, check zawodzi z "connection timeout". Połączenia long-haul (np. sprawdzanie serwera w Azji z Europy) mogą wymagać dłuższych timeoutów.

• Czy mogę monitorować porty UDP?

  Obecnie nie. UDP jest bezpołączeniowy — nie ma odpowiednika "connection accepted" do sprawdzenia. Usługi oparte na UDP typowo wymagają probe'ów specyficznych dla protokołu (np. zapytanie DNS dla portu 53, SNMP get dla 161). Użyj monitoringu heartbeat zamiast tego.

• Czy monitoring portu liczy się dla ostrzeżeń TLS/SSL?

  Nie — checki portu to czysta dostępność TCP. Jeśli chcesz walidacji certyfikatu TLS na porcie, użyj checka HTTPS z portem w URL (np. https://api.example.com:8443/) który robi i dostępność I sprawdzenie certyfikatu.