Portüberwachung

Jenseits von HTTP: Überwachung des restlichen Stacks

Die meisten Dienste, die ein Unternehmen am Laufen halten, sind keine Webserver. Datenbanken lauschen auf 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). E-Mails laufen über 25, 465, 587, 993, 995. SSH auf 22. Gameserver auf Ports, die vom Anbieter gewählt wurden. Interne Microservices hinter der Firewall – auf beliebigen Ports, die das Plattform-Team konfiguriert hat. Keiner davon spricht HTTP. Keinen davon wirst du im Uptime-Tool für Websites sehen. Und jeder dieser Dienste, wenn er nicht mehr lauscht, verursacht sichtbare Probleme.

Die Portüberwachung schließt diese Lücke. Du gibst dem Monitor Host und Port an, und bei jeder Prüfung wird eine TCP-Verbindung geöffnet, um zu überprüfen, ob der Dienst lauscht. Wenn die Verbindung fehlschlägt – weil der Daemon abgestürzt ist, die Firewall geändert wurde, der Host ausgefallen ist oder das Netz zwischen uns und dem Dienst gestört ist – erhältst du einen Alarm.

Was du überwachen kannst

• Datenbanken: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
• Mailserver: 25 (SMTP), 465 (SMTPS), 587 (Submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
• Remote-Zugriff: 22 (SSH), 3389 (RDP), 5900 (VNC).
• Dateiübertragung: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
• Individuelle oder interne Dienste: GraphQL-Gateways, gRPC, Warteschlangen (RabbitMQ 5672, Kafka 9092), Suche (Elasticsearch 9200, Solr 8983), Gameserver, IoT-Geräte.

Wie der Check funktioniert

Der Monitor öffnet eine rohe TCP-Verbindung zu host:port mit einem Timeout von 5 Sekunden. Wenn SYN/ACK zurückkommt – Port ist erreichbar und der Dienst lauscht, Check ist up. Kommt eine Verbindungsablehnung, ein Timeout oder "no route" – Check ist down und es wird der Kernel-Fehler aufgezeichnet ("connection refused", "operation timed out", "no route to host") – das erleichtert die Fehlersuche.

Der Monitor versucht nicht, auf Anwendungsebene zu sprechen – es wird keine SQL-Anfrage oder ein SMTP HELO gesendet. Das hält die Prüfung schnell und ohne Nebeneffekte, was wichtig ist, wenn du 100 Dienste pro Minute prüfst. Falls du eine Anwendungsebene-Überprüfung brauchst, kombiniere die Portüberwachung mit Heartbeat-Monitoring oder einem eigenen API-Monitor.

Kombination mit HTTP und Ping

Für jeden öffentlichen Dienst bieten drei Monitore eine saubere Diagnosetreppe. Ein Ping bestätigt, dass der Host im Netzwerk erreichbar ist. Portüberwachung – der Dienst lauscht. HTTP/API-Monitoring – der Dienst antwortet korrekt. Fällt etwas aus, verrät die betroffene Schicht sofort, wo man suchen muss. Nur HTTP fällt aus – die Anwendung crasht. Port fällt auch aus – Daemon abgestürzt. Ping fällt auch aus – Hardware verschwunden oder Netzwerk ausgefallen.

Konfiguration

Öffne das Tool, klicke auf „Monitor hinzufügen“, wähle den Typ „TCP-Port“, füge den Host ein (ohne Protokoll), trage die Portnummer ein (1-65535) und stelle das Intervall ein. Speichern. Ab dem nächsten Zyklus öffnet der Monitor jede Minute eine TCP-Verbindung, speichert die Round-Trip-Zeit und schlägt beim Schließen des Ports in Sekunden Alarm – per E-Mail, Telegram, Slack, Discord oder SMS, mit denselben Schwellen- und Nachtruhe-Regeln.

Häufig gestellte Fragen

• Welche Ports kann ich überwachen?

  Jeder TCP-Port von 1 bis 65535. Typische Fälle: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), Datenbank-Listener (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), benutzerdefinierte Anwendungsports.

• Prüft der Monitor die Gesundheit des Dienstes oder nur die Erreichbarkeit?

  Nur die Erreichbarkeit — der Monitor öffnet eine TCP-Verbindung und prüft, ob der Daemon sie akzeptiert. Kein Application Layer Handshake. Wenn du protokollbewusste Checks brauchst (z. B. SMTP-Bannerprüfung, Datenbank-Antwort), nutze einen HTTP-Check (für HTTP-Dienste) oder einen selbst gehosteten Heartbeat-Agenten.

• Wie lang ist das Timeout für Port-Checks?

  Standardmäßig 10 Sekunden. Konfigurierbar pro Monitor. Wenn die TCP-Verbindung nicht innerhalb des Timeout-Fensters aufgebaut werden kann, schlägt der Check mit „connection timeout“ fehl. Verbindungen über große Entfernungen (z. B. von Europa zu einem Server in Asien) können längere Timeouts erfordern.

• Kann ich auch UDP-Ports überwachen?

  Derzeit nicht. UDP ist verbindungslos – es gibt kein „connection accepted“ wie bei TCP. Dienste, die auf UDP basieren, benötigen in der Regel protokollspezifische Probes (z. B. DNS-Anfrage für Port 53, SNMP-Get für 161). Verwende hierfür Heartbeat-Monitoring.

• Zählt die Portüberwachung bei TLS/SSL-Warnungen?

  Nein — Port-Checks testen nur die reine TCP-Erreichbarkeit. Wenn du ein TLS-Zertifikat auf dem Port validieren möchtest, nutze einen HTTPS-Check mit dem Port in der URL (z. B. https://api.example.com:8443/), welcher sowohl die Erreichbarkeit als auch die Zertifikatsprüfung vornimmt.