Poortbewaking

Buiten HTTP: monitoring van de rest van de stack

De meeste diensten die essentieel zijn voor het bedrijfsleven zijn geen webservers. Databases luisteren op 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). E-mail verloopt via 25, 465, 587, 993, 995. SSH op 22. Gameservers op poorten die door de uitgever zijn gekozen. Interne microservices achter de firewall – op alles wat het platformteam heeft ingesteld. Geen van deze spreekt HTTP. Je zult ze niet zien in website uptime tools. En elke, zodra die stopt met luisteren, zorgt ervoor dat iets zichtbaars verdwijnt.

Port monitoring dicht dit gat. Je geeft de monitor een host en poort, en bij elke controle wordt een TCP-verbinding geopend om te verifiëren of de dienst luistert. Als de verbinding faalt – omdat de demon is gecrasht, de firewall gewijzigd is, de host uit is, of het netwerk tussen ons en de dienst kapot is – ontvang je een alert.

Wat kun je monitoren

• Databases: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
• Mailservers: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
• Remote toegang: 22 (SSH), 3389 (RDP), 5900 (VNC).
• Bestandsoverdracht: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
• Aangepast of intern: GraphQL gateways, gRPC, queues (RabbitMQ 5672, Kafka 9092), search (Elasticsearch 9200, Solr 8983), gameservers, IoT-apparaten.

Hoe werkt de check

De monitor opent een ruwe TCP-verbinding naar host:poort met een timeout van 5 seconden. Als er een SYN/ACK terugkomt – de poort is bereikbaar en de dienst luistert, check up. Als verbinding geweigerd wordt, timeout of geen route – check down, en de fout van de kernel (“connection refused”, “operation timed out”, “no route to host”) wordt opgeslagen – gemakkelijker voor triage.

De monitor probeert niet te communiceren via het applicatieprotocol – stuurt geen SQL-query of SMTP HELO. Dit houdt de check snel en zonder bijwerkingen, wat telt als je 100 services per minuut checkt. Heb je applicatieniveau verificatie nodig, combineer port monitoring met heartbeat monitoring of een eigen API-monitor.

Koppelen met HTTP en ping

Voor elke publieke service geven drie monitors een helder diagnostisch pad. Ping bevestigt dat de host in het netwerk leeft. Poortmonitoring – de dienst luistert. HTTP- / API-monitoring – de dienst reageert correct. Valt er iets uit, dan maakt de uitgevallen laag direct duidelijk waar je moet zoeken. Alleen HTTP valt uit – de applicatie crasht. Poort ook uit – daemon is uitgevallen. Ping ook weg – de box is verdwenen of het netwerk is uitgevallen.

Configuratie

Open het hulpmiddel, klik op "Monitor toevoegen", kies het type "TCP-poort", plak de host (zonder protocol), vul het poortnummer in (1-65535) en stel het interval in. Sla op. Vanaf de volgende cyclus opent de monitor elke minuut een TCP-verbinding, logt de round-trip en waarschuwt zodra de poort wordt gesloten – via Email, Telegram, Slack, Discord of SMS, met dezelfde bevestigings- en nachtstilte regels.

Veelgestelde vragen

• Welke poorten kan ik monitoren?

  Elke TCP-poort van 1 tot 65535. Veelvoorkomende gevallen: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), database listeners (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), aangepaste applicatiepoorten.

• Controleert de monitor of de dienst gezond is of alleen beschikbaar?

  Alleen beschikbaarheid — de monitor opent een TCP-verbinding en kijkt of de daemon deze accepteert. Zonder protocol-level handshake. Als je protocolbewuste checks nodig hebt (bijv. SMTP banner verificatie, database-query antwoord), gebruik dan een HTTP-check (voor HTTP-diensten) of een zelf-gehoste heartbeat agent.

• Wat is de timeout voor poortchecks?

  Standaard 10 seconden. Instelbaar per monitor. Als de TCP-verbinding niet tot stand komt binnen het timeout-venster, faalt de check met "connection timeout". Long-haul verbindingen (bijv. servercheck in Azië vanuit Europa) kunnen langere timeouts vereisen.

• Kan ik UDP-poorten monitoren?

  Op dit moment niet. UDP is connectionless — er is geen "connection accepted" equivalent om te checken. Diensten op UDP vereisen meestal protocolspecifieke probes (bijvoorbeeld DNS-query voor poort 53, SNMP get voor 161). Gebruik in plaats daarvan heartbeat monitoring.

• Telt poortmonitoring mee voor TLS/SSL-waarschuwingen?

  Nee — poortchecks zijn pure TCP-beschikbaarheid. Wil je TLS-certificaatvalidatie op een poort, gebruik dan een HTTPS-check, met poort in de URL (bijvoorbeeld https://api.example.com:8443/) die zowel beschikbaarheid als certificaatverificatie doet.