Nadzor vrat

Poleg HTTP: spremljanje preostalega sklada

Večina storitev, ki poganjajo posel, niso spletni strežniki. Baze poslušajo na 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Pošta teče preko 25, 465, 587, 993, 995. SSH na 22. Igre na vnaprej določenih vratih, ki jih izbere založnik. Interni mikrostoritve za požarnim zidom – na čemerkoli nastavi platformna ekipa. Nobena ne govori prek HTTP. Nobene ne vidiš v orodju uptime spletnih strani. In vsaka, ko preneha poslušati, s seboj odnese nekaj vidnega.

Spremljanje portov zapolni to vrzel. Monitorju podaš gostitelja in port, pri vsakem preverjanju pa se odpre TCP povezava, ki preveri, ali storitev posluša. Če povezava spodleti – ker je demon ugasnil, se je spremenil požarni zid, je gostitelj nedosegljiv, ali je omrežje med nami in storitvijo poškodovano – prejmeš opozorilo.

Kaj lahko spremljaš

• Baze podatkov: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
• Poštni strežniki: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
• Oddaljeni dostop: 22 (SSH), 3389 (RDP), 5900 (VNC).
• Prenos datotek: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
• Nestandardni ali interni: GraphQL prehodi, gRPC, vrste (RabbitMQ 5672, Kafka 9092), iskanje (Elasticsearch 9200, Solr 8983), strežniki iger, IoT naprave.

Kako deluje preverjanje

Monitor odpre surovo TCP povezavo do host:port s 5-sekundnim časovnim zamikom. Če dobi SYN/ACK – port je dosegljiv in storitev posluša, pregled uspe. Če connection refused, timeout ali no route – pregled spodleti in kot rezultat se zabeleži napaka sistema ("connection refused", "operation timed out", "no route to host") – lažje je diagnosticirati.

Monitor ne poskuša komunicirati v aplikacijskem protokolu – ne pošlje SQL poizvedbe ali SMTP HELO. Tako ostane preverjanje hitro in brez stranskih učinkov, kar je pomembno, če imaš recimo 100 storitev na minuto. Če potrebuješ preverjanje na aplikacijski ravni, združi spremljanje portov z heartbeatom ali lastnim API monitorjem.

Povezava z HTTP in ping

Za vsako javno storitev trije monitorji ustvarijo jasno diagnostiko. Ping potrdi, da strežnik živi v omrežju. Spremljanje porta – storitev posluša. HTTP / API monitoring – storitev vrača pravilne odgovore. Ko nekaj odpove, odpovedana plast takoj pove, kje iskati napako. Če odpove le HTTP – aplikacija se sesuje. Če odpove tudi port – demon je ugasnil. Če odpove tudi ping – železo ali omrežje je izginilo.

Nastavitev

Odpri orodje, klikni "Dodaj monitor", izberi tip "TCP port", prilepi gostitelja (brez protokola), vpiši številko porta (1-65535) in nastavi interval. Shrani. Od naslednjega cikla monitor vsako minuto odpre TCP povezavo, izmeri round-trip, in sporoči alarm v sekundi, ko je port zaprt – po e-pošti, Telegramu, Slacku, Discordu ali SMS, z istimi pravili za potrditveni prag in nočni mir.

Pogosta vprašanja

• Katere porte lahko spremljam?

  Katerikoli TCP port od 1 do 65535. Pogosti primeri: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), poslušalci podatkovnih baz (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), prilagojeni porti aplikacij.

• Ali monitor preverja, ali je storitev zdrava, ali le dosegljiva?

  Samo dosegljivost — monitor odpre TCP povezavo in preveri, ali jo demon sprejme. Brez protokolnega handshake-a. Če potrebuješ preglede, ki poznajo protokol (npr. preverjanje SMTP bannerja, odgovor podatkovne baze), uporabi HTTP pregled (za HTTP storitve) ali self-hosted heartbeat agenta.

• Kakšen je timeout za preglede portov?

  Privzeto 10 sekund. Nastavljivo za vsak monitor posebej. Če se TCP povezava ne vzpostavi znotraj okna timeouta, pregled pade z "connection timeout". Dolge povezave (npr. preverjanje strežnika v Aziji iz Evrope) lahko zahtevajo daljše timeoute.

• Ali lahko spremljam UDP porte?

  Trenutno ne. UDP je brez povezave — nima ekvivalenta "connection accepted" za preverjanje. Storitve na UDP običajno potrebujejo za protokol specifične probe (npr. DNS poizvedba na port 53, SNMP get na 161). Namesto tega uporabi monitoring heartbeat.

• Ali spremljanje portov velja za opozorila TLS/SSL?

  Ne — pregledi porta pomenijo zgolj TCP dosegljivost. Če želiš preverjanje TLS certifikata na portu, uporabi HTTPS pregled s portom v URL (npr. https://api.example.com:8443/), ki izvede tako dosegljivost kot preverjanje certifikata.