Milliseid porte saan monitoorida?

Iga TCP port vahemikus 1 kuni 65535. Levinumad juhud: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), andmebaasi listenerid (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), kohandatud rakenduse pordid.

Kas monitor kontrollib teenuse tervist või ainult saadavust?

Ainult saadavust – monitor avab TCP ühenduse ja kontrollib, kas deemon võtab selle vastu. Protokollitasandi handshake’i ei tehta. Kui vajad protokolliteadlikumaid kontrolle (nt SMTP bannerri kontroll, andmebaasipäringu vastus), kasuta HTTP kontrolli (HTTP teenustele) või self-hosted heartbeat agenti.

Mis on pordikontrollide timeout?

Vaikimisi 10 sekundit. Seadistatav monitori kaupa. Kui TCP ühendus ei avane timeout aknas, kontroll kukub veaga "connection timeout". Pika maaühendustega (nt serveri kontroll Aasias Euroopast) võib vaja minna pikemat timeouti.

Kas saan UDP porte monitoorida?

Praegu mitte. UDP on ühenduseta – pole olemas ekvivalenti “ühendus aksepteeritud” signaalist. UDP-põhised teenused vajavad tavaliselt spetsiifilisi protokollipõhiseid teste (nt DNS päring porti 53, SNMP get porti 161). Kasuta selle asemel heartbeat monitooringut.

Kas pordimonitooring arvestab TLS/SSL hoiatusi?

Ei – pordikontrollid annavad puhta TCP saadavuse. Kui soovid TLS sertifikaadi valideerimist pordil, kasuta HTTPS kontrolli koos porti URL-is (nt https://api.example.com:8443/), mis teeb nii saadavuse kui ka sertifikaadi kontrolli korraga.

TCP pordi jälgimine — andmebaasid, e-post, teenused

Kinnita, et olulised teenused töötavad — mitte ainult sinu veebiserver. Jälgi ükskõik millist TCP porti ükskõik millisel masinal.

Väljaspool HTTP: ülejäänud stacki monitoorimine

Enamik äri toetavaid teenuseid ei ole veebiserverid. Andmebaasid kuulavad porti 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). E-post liigub läbi 25, 465, 587, 993, 995. SSH töötab portis 22. Mänguserverid kasutavad neile määratud porte. Sisevõrgu mikroteenused tulemüüri taga – mis iganes platvormitiim on seadistanud. Ükski neist ei räägi HTTP-d. Ühtegi neist ei näe tavalises uptime-analüüsis. Ja igaüks neist, kui lõpetab kuulamise, võtab endaga midagi olulist kaasa.

Pordimonitooring katab selle augu. Annad monitorile hosti ja pordi ning iga kontrolli ajal avatakse TCP ühendus, et veenduda teenuse kuulamises. Kui ühendus ebaõnnestub – deemon on maas, tulemüür muutunud, host ei vasta, võrk on katki – saad koheselt teavituse.

Mida saad monitoorida

Andmebaasid: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
Meiliserverid: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
Kaugjuurdepääs: 22 (SSH), 3389 (RDP), 5900 (VNC).
Failiedastus: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
Kohandatud või sisemised: GraphQL gatewayd, gRPC, järjekorrad (RabbitMQ 5672, Kafka 9092), otsing (Elasticsearch 9200, Solr 8983), mänguserverid, IoT seadmed.

Kuidas kontroll töötab

Monitor avab toore TCP ühenduse aadressile host:port 5-sekundilise ajapiiranguga. Kui tuleb SYN/ACK – port on kättesaadav ja teenus kuulab, kontroll edukas. Kui toimub connection refused, timeout või no route – kontroll ebaõnnestub ning logisse salvestatakse operatsioonisüsteemi veateade ("connection refused", "operation timed out", "no route to host") – lihtsam triagida.

Monitor ei ürita rääkida rakenduse protokollis – ei saada SQL päringut ega SMTP HELO-t. Kontroll on kiire ja kõrvalmõjudeta, mis loeb siis, kui jälgid 100 teenust iga minuti järel. Kui vajad rakendusetasandi kontrolli, kombineeri pordimonitooringut heartbeat’i või omaenda API monitoriga.

Ühendamine HTTP ja pingiga

Iga avaliku teenuse jaoks loovad kolm monitori korras diagnostikaredeli. Ping kinnitab, et host on võrgus elus. Pordimonitooring – teenus kuulab. HTTP / API monitooring – teenus vastab korrektselt. Kui midagi kukub, kukkuv kiht ütleb kohe, kust otsida. Vaid HTTP kukub – rakendus on maas. Port samuti ei tööta – deemon kukkus. Ka ping puudub – masin kadus või võrk on maas.

Seadistamine

Ava tööriist, klõpsa “Lisa monitor”, vali tüüp “TCP port”, sisesta host (ilma protokollita), kirjuta pordi number (1-65535) ja määra intervall. Salvesta. Järgmise tsükli jooksul monitor avab iga minut TCP ühenduse, salvestab round-tripi, ja teavitab sekundiga pordi sulgemisest – meili, Telegrami, Slacki, Discordi või SMS-i kaudu, samade kinnitus- ja öörahu reeglitega.

Korduma kippuvad küsimused

Milliseid porte saan monitoorida?
Iga TCP port vahemikus 1 kuni 65535. Levinumad juhud: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), andmebaasi listenerid (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), kohandatud rakenduse pordid.
Kas monitor kontrollib teenuse tervist või ainult saadavust?
Ainult saadavust – monitor avab TCP ühenduse ja kontrollib, kas deemon võtab selle vastu. Protokollitasandi handshake’i ei tehta. Kui vajad protokolliteadlikumaid kontrolle (nt SMTP bannerri kontroll, andmebaasipäringu vastus), kasuta HTTP kontrolli (HTTP teenustele) või self-hosted heartbeat agenti.
Mis on pordikontrollide timeout?
Vaikimisi 10 sekundit. Seadistatav monitori kaupa. Kui TCP ühendus ei avane timeout aknas, kontroll kukub veaga "connection timeout". Pika maaühendustega (nt serveri kontroll Aasias Euroopast) võib vaja minna pikemat timeouti.
Kas saan UDP porte monitoorida?
Praegu mitte. UDP on ühenduseta – pole olemas ekvivalenti “ühendus aksepteeritud” signaalist. UDP-põhised teenused vajavad tavaliselt spetsiifilisi protokollipõhiseid teste (nt DNS päring porti 53, SNMP get porti 161). Kasuta selle asemel heartbeat monitooringut.
Kas pordimonitooring arvestab TLS/SSL hoiatusi?
Ei – pordikontrollid annavad puhta TCP saadavuse. Kui soovid TLS sertifikaadi valideerimist pordil, kasuta HTTPS kontrolli koos porti URL-is (nt https://api.example.com:8443/), mis teeb nii saadavuse kui ka sertifikaadi kontrolli korraga.

Pordi jälgimine