Monitorizare porturi

Dincolo de HTTP: monitorizarea restului stack-ului

Majoritatea serviciilor care susțin afacerea nu sunt servere web. Bazele de date ascultă pe 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Mail-ul circulă prin 25, 465, 587, 993, 995. SSH pe 22. Serverele de jocuri pe porturile alese de editor. Microservicii interne, dincolo de firewall – pe orice a configurat platform team-ul. Niciunul dintre aceste servicii nu vorbește HTTP. Niciunul nu apare în instrumentele clasice de uptime pentru site-uri. Și fiecare, când încetează să mai asculte, provoacă o problemă vizibilă.

Monitorizarea porturilor astupă această gaură. Îi dai monitorului un host și un port, iar la fiecare verificare se deschide o conexiune TCP pentru a verifica dacă serviciul ascultă. Dacă conexiunea eșuează – pentru că daemonul a căzut, firewall-ul s-a schimbat, hostul este indisponibil, rețeaua dintre noi și serviciu este deteriorată – primești un alert.

Ce poți monitoriza

• Baze de date: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
• Servere de poștă: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
• Acces remote: 22 (SSH), 3389 (RDP), 5900 (VNC).
• Transfer fișiere: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
• Personalizate sau interne: gateways GraphQL, gRPC, cozi (RabbitMQ 5672, Kafka 9092), search (Elasticsearch 9200, Solr 8983), servere de jocuri, dispozitive IoT.

Cum funcționează verificarea

Monitorul deschide o conexiune raw TCP către host:port cu timeout de 5 secunde. Dacă primește SYN/ACK – portul e accesibil și serviciul ascultă, check up. Dacă primește connection refused, timeout sau no route – check down, iar în rezultat se salvează eroarea de la kernel ("connection refused", "operation timed out", "no route to host") – pentru triere mai ușoară.

Monitorul nu încearcă să comunice pe protocolul aplicației – nu trimite query SQL sau SMTP HELO. Acest lucru face ca verificarea să fie rapidă și fără efecte secundare, lucru esențial dacă verifici 100 de servicii pe minut. Dacă ai nevoie de verificare la nivel de aplicație, combină monitorizarea portului cu heartbeat sau cu propriul tău monitor API.

Combinarea cu HTTP & ping

Pentru orice serviciu public trei monitoare oferă o scară de diagnosticare clară. Ping confirmă că hostul răspunde în rețea. Monitorizarea portului – serviciul ascultă. Monitorizarea HTTP/API – serviciul răspunde corect. Când ceva cade, stratul care cade spune imediat unde să cauți problema. Doar HTTP cade – aplicația s-a crash-uit. Și portul cade – daemonul a cedat. Și ping cade – cutia a dispărut sau rețeaua a căzut.

Configurare

Deschide instrumentul, apasă pe "Adaugă monitor", alege tipul "TCP port", lipește hostul (fără protocol), introdu numărul portului (1-65535) și setează intervalul. Salvează. De la următorul ciclu monitorul deschide la fiecare minut o conexiune TCP, salvează round-trip-ul, iar dacă portul se închide alarmează instant – prin Email, Telegram, Slack, Discord sau SMS, cu aceleași reguli de prag pentru confirmare și ore silențioase.

Întrebări frecvente

• Ce porturi pot monitoriza?

  Orice port TCP de la 1 la 65535. Cazuri comune: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), listenere baze de date (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), porturi aplicații custom.

• Monitorul verifică dacă serviciul este sănătos sau doar disponibil?

  Doar disponibilitatea – monitorul deschide o conexiune TCP și vede dacă daemonul o acceptă. Fără handshake la nivel de protocol. Dacă ai nevoie de check-uri conștiente de protocol (ex. verificare banner SMTP, răspuns query bază de date), folosește un check HTTP (pentru servicii HTTP) sau un agent heartbeat self-hosted.

• Care este timeout-ul pentru check-urile portului?

  Implicit 10 secunde. Se poate configura per monitor. Dacă conexiunea TCP nu se realizează în fereastra de timeout, check-ul eșuează cu "connection timeout". Conexiuni de lungă durată (de exemplu, testarea unui server din Asia din Europa) pot necesita timeouts mai mari.

• Pot monitoriza porturi UDP?

  Momentan nu. UDP e fără conexiune – nu există echivalent pentru "connection accepted" ce poate fi verificat. Serviciile bazate pe UDP au nevoie de probe specifice protocolului (ex. query DNS pentru portul 53, SNMP get pentru 161). Folosește monitorizarea heartbeat în schimb.

• Monitorizarea portului include și alerte TLS/SSL?

  Nu – checkurile de port verifică doar disponibilitatea TCP. Dacă vrei validare certificat TLS pe port, folosește un check HTTPS cu portul în URL (de exemplu https://api.example.com:8443/) care face atât disponibilitatea cât și verificarea certificatului.