Milyen portokat tudok monitorozni?

Bármely TCP port az 1 és 65535 között. Gyakori esetek: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), adatbázisok figyelő portjai (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), alkalmazás egyedi portjai.

Ellenőrzi a monitor, hogy a szolgáltatás egészséges vagy csak elérhető?

Csak az elérhetőséget – a monitor TCP kapcsolatot nyit és ellenőrzi, hogy a démon elfogadja-e. Nincs protokollszintű kézfogás. Ha protokolltudatos ellenőrzés kell (pl. SMTP banner ellenőrzése vagy adatbázis lekérdezés válasza), használj HTTP checket (HTTP-s szolgáltatásokhoz) vagy saját hostolt heartbeat agentet.

Mennyi a port checkek időtúllépése?

Alapértelmezett 10 másodperc. Monitoronként testreszabható. Ha a TCP kapcsolat nem jön létre a timeout ablakban, a check "connection timeout" hibával megbukik. A távoli kapcsolatok (pl. ázsiai szerver ellenőrzése Európából) hosszabb timeoutot igényelhetnek.

Tudok UDP portokat is monitorozni?

Jelenleg nem. Az UDP kapcsolat nélküli – nincs "connection accepted" megfelelője, amit ellenőrizni lehetne. Az UDP alapú szolgáltatások tipikusan protokollspecifikus probe-ot igényelnek (pl. DNS kérdés az 53-as porton, SNMP get a 161-es porton). Használj helyette heartbeat monitoringot.

Számít a portmonitorozás a TLS/SSL figyelmeztetésekhez?

Nem – a port checkek csak a tiszta TCP elérhetőséget mérik. Ha TLS tanúsítvány érvényességét is ellenőrizni szeretnéd a porton, használj HTTPS checket porttal az URL-ben (pl. https://api.example.com:8443/), ami egyszerre vizsgálja az elérhetőséget ÉS a tanúsítványt.

TCP portfigyelés — adatbázisok, levelezés, szolgáltatások

Győződjön meg róla, hogy a kritikus szolgáltatások figyelnek — ne csak a webszerver. Figyeljen bármely TCP portot bármely gépen.

HTTP-n kívül: a stack többi részének monitorozása

Az üzletmenetet biztosító szolgáltatások többsége nem web szerver. Az adatbázisok a 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis) portokon figyelnek. Az e-mailek a 25, 465, 587, 993, 995 portokon közlekednek. SSH a 22-es porton. Játékszerverek az adott kiadó által választott portokon. Belső mikroszolgáltatások a tűzfal mögött – azon, amit a platformcsapat beállított. Egyik sem beszél HTTP-n. Egyiket sem látod az uptime eszközben. És mindegyik, ha abbahagyja a figyelést, magával visz valami láthatót.

A portmonitorozás ezt a rést tömi be. Megadsz a monitornak egy hostot és portot, minden ellenőrzésnél TCP kapcsolatot nyit, hogy ellenőrizze, figyel-e a szolgáltatás. Ha a kapcsolat meghiúsul – mert a daemon leállt, a tűzfal módosult, a host elérhetetlen, a hálózat sérült közben – értesítést kapsz.

Mit tudsz monitorozni

Adatbázisok: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
Levelezőszerverek: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
Távoli elérés: 22 (SSH), 3389 (RDP), 5900 (VNC).
Fájlátvitel: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
Egyedi vagy belső: GraphQL gateway-ek, gRPC, sorok (RabbitMQ 5672, Kafka 9092), keresés (Elasticsearch 9200, Solr 8983), játékszerverek, IoT eszközök.

Hogyan működik az ellenőrzés

A monitor nyers TCP kapcsolatot nyit a host:port páron 5 másodperces timeouttal. Ha SYN/ACK válas jön vissza – a port elérhető és a szolgáltatás figyel, check up. Ha a kapcsolat elutasított, timeout vagy nincs útvonal – check down, és az eredményben a kernel hibája van elmentve ("connection refused", "operation timed out", "no route to host") – a triázs is egyszerűbb.

A monitor nem próbál az alkalmazás protokollján kommunikálni – nem küld SQL lekérdezést vagy SMTP HELO-t. Ez gyorssá és mellékhatásmentessé teszi az ellenőrzést, ami számít, ha 100 szolgáltatást akarsz percenként nézni. Ha alkalmazásszintű verifikációra van szükséged, párosítsd a portmonitorozást heartbeat vagy egyedi API monitorral.

HTTP és ping kombinálása

Minden nyilvános szolgáltatás esetén három monitor tiszta diagnosztikai létrát ad. A ping megerősíti, hogy a host elérhető a hálózaton. A portmonitor – a szolgáltatás figyel. HTTP / API monitoring – a szolgáltatás helyesen válaszol. Amikor valami leáll, a leálló réteg azonnal megmutatja, hol keresd a hibát. Csak a HTTP hal le – az alkalmazás összeomlott. A port is lehal – a daemon is meghibásodott. Ping is elmegy – a gép eltűnt vagy a hálózat halt meg.

Beállítás

Nyisd meg az eszközt, kattints a "Monitor hozzáadása" gombra, válaszd a „TCP port” típust, illeszd be a hostot (protokoll nélkül), írd be a port számát (1-65535) és állítsd be az intervallumot. Mentsd el. A monitor a következő ciklustól minden percben TCP kapcsolatot nyit, rögzíti a round-trip időt, és riaszt a port zárásának pillanatában – e-mail, Telegram, Slack, Discord vagy SMS útján, ugyanazokkal a megerősítési és éjszakai csendre vonatkozó szabályokkal.

Gyakran ismételt kérdések

Milyen portokat tudok monitorozni?
Bármely TCP port az 1 és 65535 között. Gyakori esetek: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), adatbázisok figyelő portjai (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), alkalmazás egyedi portjai.
Ellenőrzi a monitor, hogy a szolgáltatás egészséges vagy csak elérhető?
Csak az elérhetőséget – a monitor TCP kapcsolatot nyit és ellenőrzi, hogy a démon elfogadja-e. Nincs protokollszintű kézfogás. Ha protokolltudatos ellenőrzés kell (pl. SMTP banner ellenőrzése vagy adatbázis lekérdezés válasza), használj HTTP checket (HTTP-s szolgáltatásokhoz) vagy saját hostolt heartbeat agentet.
Mennyi a port checkek időtúllépése?
Alapértelmezett 10 másodperc. Monitoronként testreszabható. Ha a TCP kapcsolat nem jön létre a timeout ablakban, a check "connection timeout" hibával megbukik. A távoli kapcsolatok (pl. ázsiai szerver ellenőrzése Európából) hosszabb timeoutot igényelhetnek.
Tudok UDP portokat is monitorozni?
Jelenleg nem. Az UDP kapcsolat nélküli – nincs "connection accepted" megfelelője, amit ellenőrizni lehetne. Az UDP alapú szolgáltatások tipikusan protokollspecifikus probe-ot igényelnek (pl. DNS kérdés az 53-as porton, SNMP get a 161-es porton). Használj helyette heartbeat monitoringot.
Számít a portmonitorozás a TLS/SSL figyelmeztetésekhez?
Nem – a port checkek csak a tiszta TCP elérhetőséget mérik. Ha TLS tanúsítvány érvényességét is ellenőrizni szeretnéd a porton, használj HTTPS checket porttal az URL-ben (pl. https://api.example.com:8443/), ami egyszerre vizsgálja az elérhetőséget ÉS a tanúsítványt.

Portfigyelés