Nadzor portova

Izvan HTTP-a: nadzor ostatka stacka

Većina servisa koji održavaju poslovanje nisu web poslužitelji. Baze slušaju na 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Pošta putuje kroz 25, 465, 587, 993, 995. SSH na 22. Poslužitelji igara na portovima koje je odabrao izdavač. Interni mikroservisi iza firewall-a – na bilo kojem portu kojeg je postavio platform team. Nijedan od njih ne koristi HTTP. Nijedan se ne prikazuje u alatima za uptime web stranica. A svaki, kad prestane slušati, uzrokuje nešto vidljivo.

Nadzor portova premošćuje tu rupu. Daješ monitoru host i port, i pri svakoj provjeri se otvara TCP veza koja provjerava sluša li servis. Ako veza zakaže – jer je daemon pao, firewall je izmijenjen, host je nedostupan, mreža između nas i servisa je oštećena – dobivaš upozorenje.

Što možeš nadzirati

• Baze podataka: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
• Mail serveri: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
• Remote pristup: 22 (SSH), 3389 (RDP), 5900 (VNC).
• Prijenos datoteka: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
• Nestandardni ili interni: GraphQL gateway-i, gRPC, queue-ovi (RabbitMQ 5672, Kafka 9092), search (Elasticsearch 9200, Solr 8983), game serveri, IoT uređaji.

Kako radi provjera

Monitor otvara raw TCP vezu na host:port s timeout-om od 5 sekundi. Ako se vrati SYN/ACK – port je dostupan i servis sluša, provjera uspjela. Ako je connection refused, timeout ili no route – provjera nije uspjela, a kao rezultat zapisuje se kernel greška ("connection refused", "operation timed out", "no route to host") – lakši troubleshooting.

Monitor ne pokušava govoriti aplikacijskim protokolom – ne šalje ni SQL upit, niti SMTP HELO. To čini provjeru brzom i bez nuspojava, što je bitno kad nadzireš 100 servisa svake minute. Ako trebaš aplikacijsku validaciju, spoji nadzor porta sa heartbeat provjerom ili vlastitim API monitoringom.

Povezivanje s HTTP i ping

Za svaki javni servis tri monitora daju ti jasnu dijagnostičku ljestvicu. Ping potvrđuje da host postoji na mreži. Nadzor porta – servis sluša. HTTP/API monitoring – servis ispravno odgovara. Kada nešto ne radi, sloj koji pada odmah pokazuje gdje tražiti uzrok. Pada samo HTTP – aplikacija pada. Pada i port – daemon je pao. Pada i ping – uređaj je nestao ili je mreža u prekidu.

Konfiguracija

Otvori alat, klikni "Dodaj monitor", odaberi tip "TCP port", zalijepi host (bez protokola), upiši broj porta (1-65535) i postavi interval. Spremi. Od sljedećeg ciklusa monitor svake minute otvara TCP vezu, bilježi round-trip i alarmira istog trena kada je port zatvoren – putem Email-a, Telegram-a, Slack-a, Discord-a ili SMS-a, uz ista pravila potvrde praga i noćne tišine.

Najčešća pitanja

• Koje portove mogu nadzirati?

  Bilo koji TCP port od 1 do 65535. Najčešći slučajevi: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), listeneri baza podataka (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), custom portovi aplikacija.

• Provjerava li monitor je li servis zdrav ili samo dostupan?

  Samo dostupnost — monitor otvara TCP vezu i provjerava prihvaća li je demon. Bez handshake-a na razini protokola. Ako trebaš provjere svjesne protokola (npr. provjera SMTP bannera, SQL odgovor baze), koristi HTTP check (za HTTP servise) ili self-hosted heartbeat agenta.

• Koji je timeout za provjere porta?

  Zadano 10 sekundi. Podesivo po monitoru. Ako se TCP veza ne uspostavi u timeout prozoru, provjera pada s "connection timeout". Long-haul konekcije (npr. provjera servera iz Azije iz Europe) mogu zahtijevati dulji timeout.

• Mogu li nadzirati UDP portove?

  Trenutno ne. UDP je bez konekcije — nema "connection accepted" ekvivalenta za provjeru. Servisi temeljeni na UDP-u obično zahtijevaju protokolskom specifične probe-ove (npr. DNS upit za port 53, SNMP get za 161). Koristi heartbeat monitoring umjesto toga.

• Računa li se nadzor porta za TLS/SSL upozorenja?

  Ne — provjere portova su čista TCP dostupnost. Ako želiš validaciju TLS certifikata na portu, koristi HTTPS check s portom u URL-u (npr. https://api.example.com:8443/) koji radi i dostupnost i provjeru certifikata.