Παρακολούθηση θυρών

Πέρα από το HTTP: παρακολούθηση του υπόλοιπου stack

Οι περισσότερες υπηρεσίες που κρατούν ζωντανή μια επιχείρηση δεν είναι web servers. Οι βάσεις δεδομένων ακούνε στη 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Το email περνάει από 25, 465, 587, 993, 995. Το SSH στη θύρα 22. Οι game servers στις θύρες που έχει διαλέξει ο εκδότης. Τα εσωτερικά μικροservices πίσω από το firewall — οτιδήποτε έχει ρυθμίσει η ομάδα της πλατφόρμας. Καμία από αυτές δεν μιλάει μέσω HTTP. Καμία δεν θα εμφανιστεί σε ένα εργαλείο uptime ιστοσελίδων. Και κάθε μία, όταν σταματήσει να ακούει, αποσύρει κάτι που είναι ορατό.

Η παρακολούθηση θυρών καλύπτει αυτό το κενό. Βάζεις στον monitor τον host και τη θύρα και σε κάθε έλεγχο ανοίγεται μια σύνδεση TCP για να ελεγχθεί αν η υπηρεσία ακούει. Αν η σύνδεση αποτύχει — επειδή ο daemon έπεσε, άλλαξε το firewall, ο host είναι κάτω, το δίκτυο μεταξύ εμάς και της υπηρεσίας έχει πρόβλημα — λαμβάνεις ειδοποίηση.

Τι μπορείς να παρακολουθήσεις

• Βάσεις δεδομένων: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
• Mail servers: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
• Απομακρυσμένη πρόσβαση: 22 (SSH), 3389 (RDP), 5900 (VNC).
• Μεταφορά αρχείων: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
• Εξατομικευμένες ή εσωτερικές: GraphQL gateways, gRPC, queues (RabbitMQ 5672, Kafka 9092), search (Elasticsearch 9200, Solr 8983), game servers, IoT συσκευές.

Πώς λειτουργεί ο έλεγχος

Ο monitor ανοίγει μια raw TCP σύνδεση προς τον host:port με timeout 5 δευτερόλεπτα. Αν λάβει SYN/ACK — η θύρα είναι προσβάσιμη και η υπηρεσία ακούει, ο έλεγχος θεωρείται επιτυχής. Αν υπάρξει connection refused, timeout ή no route — ο έλεγχος αποτυγχάνει, και το αποτέλεσμα καταγράφει το kernel error ("connection refused", "operation timed out", "no route to host") — ευκολότερη διάγνωση.

Ο monitor δεν προσπαθεί να μιλήσει με πρωτόκολλο εφαρμογής — δεν στέλνει SQL query ούτε SMTP HELO. Αυτό κρατάει τον έλεγχο γρήγορο και χωρίς παρενέργειες, κάτι που μετράει όταν ελέγχεις 100 υπηρεσίες ανά λεπτό. Αν χρειάζεσαι application-level επαλήθευση, συνδύασε την παρακολούθηση θύρας με heartbeat ή δικό σου API monitor.

Συνδυασμός με HTTP και ping

Για κάθε δημόσια υπηρεσία, τρεις monitors δίνουν μια καθαρή διαγνωστική αλυσίδα. Το ping επιβεβαιώνει ότι ο host είναι ενεργός στο δίκτυο. Η παρακολούθηση θύρας — η υπηρεσία ακούει. Monitoring HTTP / API — η υπηρεσία απαντά σωστά. Όταν κάτι καταρρέει, η πτώση του αντίστοιχου layer λέει αμέσως πού να κοιτάξεις. Μόνο το HTTP πέφτει — η εφαρμογή κρασάρει. Αν πέσει και η θύρα — ο daemon έπεσε. Αν πέσει και το ping — το μηχάνημα εξαφανίστηκε ή το δίκτυο έπεσε.

Ρύθμιση

Άνοιξε το εργαλείο, κάνε κλικ στο "Προσθήκη monitor", επίλεξε τύπο "TCP port", επικόλλησε τον host (χωρίς το πρωτόκολλο), συμπλήρωσε τον αριθμό θύρας (1-65535) και όρισε το διάστημα. Κάνε αποθήκευση. Από τον επόμενο κύκλο, ο monitor κάθε λεπτό ανοίγει TCP σύνδεση, καταγράφει round-trip, και ειδοποιεί τη στιγμή που κλείνει η θύρα — μέσω Email, Telegram, Slack, Discord ή SMS, με τους ίδιους κανόνες επιβεβαίωσης και νυχτερινής σιγής.

Συχνές ερωτήσεις

• Ποιες θύρες μπορώ να παρακολουθώ;

  Οποιαδήποτε TCP θύρα από 1 έως 65535. Συνηθισμένες περιπτώσεις: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), listeners βάσεων δεδομένων (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), custom θύρες εφαρμογών.

• Ο monitor ελέγχει αν η υπηρεσία είναι υγιής ή μόνο αν είναι διαθέσιμη;

  Μόνο διαθεσιμότητα — ο monitor ανοίγει TCP σύνδεση και ελέγχει αν ο daemon τη δέχεται. Χωρίς handshake πρωτοκόλλου. Αν χρειάζεσαι ελέγχους επιπέδου πρωτοκόλλου (π.χ. επαλήθευση SMTP banner, απάντηση σε ερώτημα βάσης), χρησιμοποίησε HTTP check (για HTTP υπηρεσίες) ή self-hosted heartbeat agent.

• Ποιο είναι το timeout για τους ελέγχους θυρών;

  Προεπιλογή 10 δευτερόλεπτα. Προσαρμόζεται ανά monitor. Αν η TCP σύνδεση δεν πετύχει μέσα στο διάστημα του timeout, ο έλεγχος αποτυγχάνει με "connection timeout". Long-haul συνδέσεις (π.χ. έλεγχος server στην Ασία από Ευρώπη) μπορεί να χρειάζονται μεγαλύτερο timeout.

• Μπορώ να παρακολουθώ UDP θύρες;

  Προς το παρόν όχι. Το UDP είναι χωρίς σύνδεση — δεν υπάρχει "connection accepted" για έλεγχο. Οι υπηρεσίες με βάση το UDP συνήθως χρειάζονται probes ειδικά για το εκάστοτε πρωτόκολλο (π.χ. DNS query για θύρα 53, SNMP get για 161). Χρησιμοποίησε heartbeat monitoring αντ' αυτού.

• Η παρακολούθηση θύρας ελέγχει και για TLS/SSL προειδοποιήσεις;

  Όχι — οι έλεγχοι θύρας αφορούν καθαρή TCP διαθεσιμότητα. Αν θες επικύρωση TLS πιστοποιητικού στη θύρα, χρησιμοποίησε HTTPS check με τη θύρα στη διεύθυνση URL (π.χ. https://api.example.com:8443/) που δοκιμάζει και διαθεσιμότητα ΚΑΙ έλεγχο πιστοποιητικού.