Portu uzraudzība

Papildus HTTP: pārējās kaudzes monitorings

Lielākā daļa uzņēmuma pakalpojumu nav tīmekļa serveri. Datu bāzes klausās uz 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Pasts darbojas pa 25, 465, 587, 993, 995. SSH uz 22. Spēļu serveri uz portiem, ko izvēlējies izdevējs. Iekšējie mikropakalpojumi aiz ugunsmūra – uz jebkura porta, ko izveidojusi platformas komanda. Neviens no tiem nerunā pa HTTP. Nevienu no tiem neredzēsi lapu uptime rīkā. Un katrs no tiem, kad pārstāj klausīties, paņem līdzi kaut ko redzamu.

Portu monitorings aizlāpa šo caurumu. Tu norādi monitoram hostu un portu, un katras pārbaudes laikā tiek atvērts TCP savienojums, pārbaudot, vai pakalpojums klausās. Ja savienojums neizdodas – jo dēmons “nokritis”, ugunsmūra noteikumi mainīti, hosts nedarbojas, tīkls starp mums un pakalpojumu bojāts – tu saņem brīdinājumu.

Ko vari monitorēt

• Datu bāzes: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
• Pasta serveri: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
• Attālinātā piekļuve: 22 (SSH), 3389 (RDP), 5900 (VNC).
• Datņu pārraide: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
• Nestandarta vai iekšējie: GraphQL vārtejas, gRPC, rindas (RabbitMQ 5672, Kafka 9092), meklēšana (Elasticsearch 9200, Solr 8983), spēļu serveri, IoT ierīces.

Kā darbojas pārbaude

Monitors atver neapstrādātu TCP savienojumu uz host:port ar 5 sekunžu noildzi. Ja atgriežas SYN/ACK – ports ir sasniedzams un pakalpojums klausās, pārbaude veiksmīga. Ja “connection refused”, noildze vai “no route” – pārbaude neveiksmīga un rezultātā tiek saglabāta kodola kļūda (“connection refused”, “operation timed out”, “no route to host”) – vieglāka diagnostika.

Monitors nemēģina sarunāties pēc lietotnes protokola – nesūta SQL vaicājumu vai SMTP HELO. Tas padara pārbaudi ātru un bez blakusefektiem, kas ir svarīgi, monitorējot 100 pakalpojumus minūtē. Ja tev nepieciešama aplikācijas līmeņa pārbaude, apvieno portu monitoringu ar heartbeat vai savu API monitoru.

Savienošana ar HTTP un ping

Katrai publiskai pakalpojumu instancei trīs monitori veido skaidru diagnostikas kāpnīti. Ping apstiprina, ka hosts ir sasniedzams tīklā. Portu monitorings – pakalpojums klausās. HTTP / API monitorings – pakalpojums sniedz pareizu atbildi. Kad kas salūzt, bojātā kārta uzreiz norāda, kur meklēt. Ja krīt tikai HTTP – lietotne avarē. Krīt arī ports – dēmons “nokritis”. Krīt arī ping – serveris pazudis vai tīkls nefunkcionē.

Konfigurācija

Atver rīku, klikšķini “Pievienot monitoru”, izvēlies veidu “TCP ports”, ielīmē hostu (bez protokola), ievadi porta numuru (1–65535) un iestati intervālu. Saglabā. Sākot ar nākamo ciklu monitors katru minūti atver TCP savienojumu, ieraksta round-trip, un signalizē portam aizveroties sekundes laikā – caur e-pastu, Telegram, Slack, Discord vai SMS ar tādiem pašiem apstiprinājuma un nakts klusuma noteikumiem kā citi monitori.

Biežāk uzdotie jautājumi

• Kādus portus varu monitorēt?

  Jebkuru TCP portu no 1 līdz 65535. Izplatīti gadījumi: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), datu bāžu listeneri (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), lietotņu pielāgoti porti.

• Vai monitors pārbauda, vai serviss ir vesels, vai tikai pieejams?

  Tikai pieejamību — monitors atver TCP savienojumu un pārbauda, vai dēmons to akceptē. Bez protokola līmeņa handshake. Ja nepieciešamas protokola līmeņa pārbaudes (piemēram, SMTP bannera verifikācija, datu bāzes vaicājuma atbilde), izmanto HTTP pārbaudi (HTTP servisiem) vai pašuzturētu heartbeat aģentu.

• Kāds ir porta pārbaudēm noildzes laiks?

  Noklusēti 10 sekundes. Konfigurējams katram monitoram. Ja TCP savienojums šajā noildzes logā nenotiek, pārbaude neizdodas ar “connection timeout”. Ilgstoši savienojumi (piemēram, servera pārbaude no Eiropas uz Āziju) var prasīt garāku noildzi.

• Vai varu monitorēt UDP portus?

  Pašlaik nevar. UDP ir bezsavienojuma – nav “connection accepted” analoga, ko pārbaudīt. UDP pamatotie pakalpojumi parasti prasa konkrētam protokolam īpašas pārbaudes (piemēram, DNS vaicājums uz portu 53, SNMP get uz 161). Izmanto heartbeat monitoringu tā vietā.

• Vai portu monitorings nosedz TLS/SSL brīdinājumus?

  Nē — portu pārbaudes ir tīra TCP pieejamība. Ja vēlies TLS sertifikāta validāciju uz konkrēta porta, izmanto HTTPS pārbaudi ar portu URL (piemēram, https://api.example.com:8443/), kas pārbauda gan pieejamību, gan sertifikātu.