Monitorování portů

Mimo HTTP: monitoring zbytku stacku

Většina služeb podporujících podnikání nejsou webové servery. Databáze naslouchají na 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Pošta běží přes 25, 465, 587, 993, 995. SSH na 22. Herní servery na portech, které zvolil vydavatel. Interní mikroslužby za firewallem – na čemkoli, co nakonfiguroval platformní tým. Ani jedna z nich nemluví přes HTTP. Žádnou neuvidíš v nástroji pro kontrolu dostupnosti webu. A každá, když přestane naslouchat, způsobí nějaký viditelný problém.

Monitoring portů zalepuje tuto díru. Zadáš monitoru hostitele a port a při každé kontrole je otevřeno TCP spojení pro ověření, zda služba naslouchá. Pokud spojení selže – protože spadl démon, změnil se firewall, hostitel je nedostupný nebo je síť mezi námi a službou poškozená – dostaneš upozornění.

Co můžeš monitorovat

• Databáze: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
• Poštovní servery: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
• Vzdálený přístup: 22 (SSH), 3389 (RDP), 5900 (VNC).
• Přenos souborů: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
• Nestandardní nebo interní: GraphQL brány, gRPC, fronty (RabbitMQ 5672, Kafka 9092), hledání (Elasticsearch 9200, Solr 8983), herní servery, IoT zařízení.

Jak funguje kontrola

Monitor otevře surové TCP spojení na host:port s 5vteřinovým timeoutem. Pokud přijde SYN/ACK – port je dostupný a služba naslouchá, check je pozitivní. Pokud „connection refused“, timeout nebo „no route“ – check selhal a do výsledku je zapsaná chyba z jádra („connection refused“, „operation timed out“, „no route to host“) – jednodušší triage.

Monitor se nesnaží mluvit aplikačním protokolem – neposílá SQL dotazy ani SMTP HELO. Tím je kontrola rychlá a bez vedlejších efektů, což je důležité pokud kontrolujete 100 služeb každou minutu. Potřebuješ-li aplikační verifikaci, spoj monitoring portu s heartbeat nebo vlastním API monitorem.

Kombinace s HTTP a pingem

Pro každou veřejnou službu tři monitory tvoří čistý diagnostický žebřík. Ping potvrzuje, že hostitel žije v síti. Monitoring portu – služba naslouchá. HTTP / API monitoring – služba správně odpovídá. Když něco padá, padající vrstva hned ukáže, kde hledat. Padá pouze HTTP – aplikace padá. Padá i port – padl démon. Padá i ping – zmizel server nebo padla síť.

Konfigurace

Otevři nástroj, klikni na „Přidat monitor“, zvol typ „TCP port“, vlož hostitele (bez protokolu), zadej číslo portu (1-65535) a nastav interval. Ulož. Od dalšího cyklu bude monitor každou minutu otevírat TCP spojení, zapisovat round-trip a v případě nedostupnosti portu okamžitě alarmuje – přes Email, Telegram, Slack, Discord nebo SMS, se stejnými pravidly potvrzovacích prahů a nočního ticha.

Nejčastější dotazy

• Jaké porty mohu monitorovat?

  Každý TCP port od 1 do 65535. Běžné případy: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), databázové listenery (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), vlastní porty aplikací.

• Kontroluje monitor zdraví služby nebo jen dostupnost?

  Pouze dostupnost — monitor otevře TCP spojení a ověří, zda ho démon akceptuje. Bez handshake na úrovni protokolu. Potřebujete-li kontrolu rozumějící protokolu (např. ověření SMTP banneru, odpověď databázového dotazu), použij kontrolu HTTP (pro HTTP služby) nebo self-hosted heartbeat agenta.

• Jaký je timeout pro portové kontroly?

  Výchozí je 10 sekund. Nastavitelné pro každý monitor. Pokud se TCP spojení během timeoutového okna nenaváže, kontrola selže s „connection timeout“. Dlouhé spoje (např. kontrola serveru v Asii z Evropy) mohou vyžadovat delší timeouty.

• Mohu monitorovat UDP porty?

  V tuto chvíli ne. UDP je bezspojový — neexistuje ekvivalent „connection accepted“, který by šlo ověřit. UDP služby obvykle vyžadují protokolově specifické testy (např. DNS dotaz na port 53, SNMP get na 161). Použij místo toho heartbeat monitoring.

• Počítá se port monitoring pro TLS/SSL varování?

  Ne — portové kontroly jsou čistě o TCP dostupnosti. Pokud chceš ověřit platnost TLS certifikátu na portu, použij HTTPS kontrolu s portem v URL (např. https://api.example.com:8443/), která ověří jak dostupnost, tak certifikát.