KeyHelp: Dienst- und Portüberwachung auf dem Dashboard nutzen und Servermeldungen auswerten
Was die Dienst-/Portüberwachung im KeyHelp-Dashboard wirklich prüft, wie schnell sie einen Ausfall zeigt, wie Sie eigene Ports ergänzen, Dienste neu starten und warum keine Benachrichtigung kommt.
Geprüft am 01.10.2026 · für KeyHelp 26.1.1
Mit KI erstellt – redaktionelle Prüfung ausstehend
WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu
Ein ausgefallener FTP-Server oder ein hängender Mailserver fällt oft erst auf, wenn Kunden anrufen. KeyHelp zeigt auf dem Dashboard eine Dienst-/Portüberwachung, die genau das früher sichtbar machen soll. Diese Anleitung zeigt, was die Anzeige wirklich prüft, wie schnell sie einen Ausfall meldet, wie Sie eigene Ports ergänzen, wo Sie Dienste im Panel neu starten und welche Spuren ein Ausfall in den Servermeldungen hinterlässt. Den Ausfall haben wir in einer Test-VM real herbeigeführt, indem wir ProFTPD gestoppt haben. Das wichtigste Ergebnis vorweg: KeyHelp zeigt den Ausfall an, verschickt aber keine Benachrichtigung. Grundlage ist ein Server wie in KeyHelp installieren und absichern.
Voraussetzungen
- KeyHelp-Server mit Admin-Zugang, getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.15.
- Root-Zugang per SSH oder Konsole, um Dienste zu prüfen und einen Ausfall zu simulieren.
- Für den Test eines Ausfalls einen Dienst, den gerade niemand braucht. Wir haben ProFTPD gewählt.
Schritt 1: Die Anzeige auf dem Dashboard lesen
Auf dem Dashboard steht der Kasten „Dienst-/Portüberwachung“ mit den Spalten „Dienst“, „Status“ und „Port“. Ab Werk enthält er FTP (21), SSH (22), DNS (53), HTTP (80), HTTPS (443), SMTP (587), IMAP (993), POP3 (995) und MariaDB/MySQL (3306), alle als TCP. Beachten Sie: „SMTP“ steht hier für Port 587, Port 25 ist ab Werk nicht in der Liste.
Wir haben ProFTPD auf der Konsole gestoppt:
date -u +%T; systemctl stop proftpd; systemctl is-active proftpd; ss -ltn "sport = :21" | tail -n +2 | wc -l; date -u +%T21:40:25
inactive
0
21:40:25Das danach neu geladene Dashboard zeigte „FTP Offline 21 TCP“, alle anderen Dienste „Online“.
Verifizieren: Prüfen Sie den angezeigten Zustand auf der Konsole mit systemctl is-active und ss -ltn. Im Test stimmten beide mit der Anzeige überein.
Schritt 2: Wissen, wie oft und von wo geprüft wird
Die Prüfung stößt das geöffnete Dashboard an. Das Skript der Seite fragt den Status per AJAX ab und wiederholt das alle 30 Sekunden:
sed -n 150,173p /home/keyhelp/www/keyhelp/theme/bulma/assets/js/page_admin_dashboard.js // Continue to call the update.
var serviceStatusTimer = setInterval(updateServiceStatus, 30000);Gemessen bei geöffnetem Dashboard: Nach systemctl start proftpd um 21:45:51 Uhr sprang FTP nach 14 Sekunden auf „Online“, nach systemctl stop proftpd um 21:46:11 Uhr nach 24 Sekunden auf „Offline“. Beide Werte liegen innerhalb des 30-Sekunden-Takts. Ist kein Dashboard offen, löst dieses Skript keine Prüfung aus.
Wichtig für die Bewertung: Die Prüfung läuft vom Server selbst aus. Wir haben für den Eintrag „Testdienst“ (Port 8081) einen kleinen Webserver gestartet, der nur auf 127.0.0.1 lauscht:
systemd-run --unit=porttest8081 python3 -m http.server 8081 --bind 127.0.0.1; sleep 2; ss -ltn | grep ":8081 "LISTEN 0 5 127.0.0.1:8081 0.0.0.0:*Das Dashboard zeigte daraufhin „Testdienst Online 8081 TCP“, obwohl der Dienst von außen gar nicht erreichbar ist. „Online“ bedeutet also nur: Auf dem Server lauscht etwas auf diesem Port. Ob eine Firewall den Port nach außen sperrt oder ob der Dienst sinnvoll antwortet, prüft die Anzeige nicht.
Verifizieren: Lassen Sie das Dashboard offen, stoppen Sie einen unkritischen Dienst und zählen Sie bis zum Wechsel auf „Offline“. Laut Seitenskript sollten es nicht mehr als 30 Sekunden sein.
Schritt 3: Eigene Dienste und Ports ergänzen
Klicken Sie unter dem Kasten auf „Konfigurieren“ oder öffnen Sie „Konfiguration“, „Dienst-/Portüberwachung (Dashboard)“. Die Seite hat zwei Bereiche: „Dienst-/Portüberwachung aktivieren“ mit dem Haken „Aktiviert“ („Wenn aktiviert, wird die Dienst-/Portüberwachung auf dem Dashboard angezeigt.“) und „Überwachte Dienste“ mit je einer Zeile aus Name, Port, „TCP“ oder „UDP“ und „Entfernen“.
„Dienst hinzufügen“ fügt eine leere Zeile oben in die Liste ein, nicht unten. Wir haben ManageSieve (Port 4190) ergänzt und mit „Speichern“ übernommen. Die Meldung lautete „Die Einstellungen wurden aktualisiert.“, auf dem Dashboard stehen eigene Einträge danach am Ende der Liste.
Gespeichert wird die Liste als JSON in der KeyHelp-Datenbank:
mysql keyhelp -N -e "select name,left(value,400) from settings where name like \"%service%\" or category like \"%service%\""status_config [{"name":"FTP","port":21,"protocol":"tcp"},{"name":"SSH","port":22,"protocol":"tcp"},{"name":"DNS","port":53,"protocol":"tcp"},{"name":"HTTP","port":80,"protocol":"tcp"},{"name":"HTTPS","port":443,"protocol":"tcp"},{"name":"SMTP","port":587,"protocol":"tcp"},{"name":"IMAP","port":993,"protocol":"tcp"},{"name":"POP3","port":995,"protocol":"tcp"},{"name":"MariaDB\\/MySQL","port":3306,"protocol":"tcp"
is_monitoring_enabled 1Verifizieren: Der neue Eintrag erscheint auf dem Dashboard, ManageSieve zeigte „Online“. Gegenprobe auf der Konsole: ss -ltn listete 0.0.0.0:4190.
Schritt 4: Dienste im Panel neu starten
Die Dashboard-Anzeige hat keine Schaltfläche zum Neustarten. Dafür gibt es unter „Systemstatus“ die „Server-Dienst-Verwaltung“: „Hier können Sie Ihre Serverdienste verwalten, überprüfen, ob ein Dienst ausgeführt wird, detaillierte Statusinformationen anzeigen und sie starten, neu starten oder stoppen.“ Laut Seitentext können Sie dort auch eigene Dienste hinzufügen. Unter „Webhosting-Dienste“ zeigte ProFTPD „Inaktiv“. Nicht jede Aktion steht für jeden Dienst bereit: Im Screenshot sind bei Apache und PHP-FPM alle Aktionssymbole ausgegraut, bei MariaDB ist nur der Neustart aktiv.
Die Aktionen heißen „Anzeigen“, „Dienst starten“, „Dienst stoppen“ und „Dienst neu starten“. Nach „Dienst starten“ meldete KeyHelp „Der Dienst wurde gestartet.“, nach „Dienst stoppen“ „Der Dienst wurde gestoppt.“.
Verifizieren: systemctl is-active proftpd lieferte danach active, das Journal zeigte „Started proftpd.service - ProFTPD FTP Server.“.
Schritt 5: Servermeldungen auswerten
Zwei Stellen kommen für Meldungen in Frage: „Benachrichtigungen“ und „Ereignis-Protokolle“. Für einen Dienstausfall half im Test keine von beiden.
- „Benachrichtigungen“ listet Ereignisse in den Gruppen „Konto-Verwaltung“, „Ressourcen-Nutzung“, „Domains“, „Backup“ und „Server“. Unter „Server“ stehen nur „Ein Lizenzproblem ist aufgetreten“, „Ein Antiviren-Scan wurde durchgeführt“, „Das Control Panel wurde aktualisiert“ und „Die Größe der E-Mail-Warteschlange hat einen kritischen Schwellenwert überschritten“. Ein Ereignis für einen ausgefallenen Dienst oder Port gibt es nicht.
- Keine Mail: Zwischen dem Stoppen um 21:40:25 Uhr und der Kontrolle acht Minuten später hat Postfix keine einzige Mail zugestellt, auch nicht an die Admin-Adresse. Die Zählung im Mail-Journal ergab
0. - „Ereignis-Protokolle“ (Spalten „Datum“, „Stufe“, „Nachricht“, „Benutzer“, „IP-Adresse“, „Kanal“) enthielt für den Stopp auf der Konsole keinen Eintrag. Einträge entstanden im Test nur für Aktionen in der Oberfläche:
mysql keyhelp -N -e "select date,level_name,message,channel from event_logs where message like \"Service %\""2026-10-01 21:48:27.516446 NOTICE Service ftp stopped. User Interface
2026-10-01 21:48:42.769636 NOTICE Service ftp stopped. User Interface
2026-10-01 21:48:47.318590 NOTICE Service ftp stopped. User InterfaceAuffällig: Um 21:48:27 und 21:48:47 Uhr haben wir den Dienst im Panel gestartet, nur um 21:48:42 Uhr gestoppt. Das Journal bestätigt das:
2026-10-01T21:48:27+0000 server.example.de systemd[1]: Started proftpd.service - ProFTPD FTP Server.
2026-10-01T21:48:42+0000 server.example.de systemd[1]: Stopped proftpd.service - ProFTPD FTP Server.
2026-10-01T21:48:47+0000 server.example.de systemd[1]: Started proftpd.service - ProFTPD FTP Server.KeyHelp 26.1.1 protokolliert also auch einen Start als „Service ftp stopped.“. Werten Sie das Ereignis-Protokoll für Dienstaktionen deshalb immer zusammen mit dem Journal (journalctl -u DIENST) aus.
Verifizieren: Änderungen an der Überwachungsliste erscheinen im Ereignis-Protokoll als „Service/port monitoring settings updated.“ mit Kanal „User Interface“.
Typische Fehler
- Ungültiger Port wird gespeichert: Port 70000 (gültig sind bis 65535) nahm KeyHelp mit „Die Einstellungen wurden aktualisiert.“ an. Das Dashboard zeigte den Eintrag als „Offline“. Prüfen Sie neue Einträge nach dem Speichern auf dem Dashboard.
- Zeile ohne Namen verschwindet: Eine Zeile mit Port 8082, aber leerem Namen wurde beim Speichern ohne Hinweis verworfen, obwohl die Meldung „Die Einstellungen wurden aktualisiert.“ lautete.
- „Online“ als Erreichbarkeit verstanden: Ein Dienst, der nur auf
127.0.0.1lauscht, steht trotzdem auf „Online“. Für die Erreichbarkeit von außen brauchen Sie eine externe Prüfung. - Auf Mails gewartet: Ein Dienstausfall löste im Test mit KeyHelp 26.1.1 keine Benachrichtigung aus. Ohne offenes Dashboard bemerkt ihn niemand.
Häufige Fragen
Startet KeyHelp einen ausgefallenen Dienst selbst neu?
Im Test nicht. ProFTPD blieb nach dem Stopp um 21:40:25 Uhr gut fünf Minuten aus, bis wir ihn um 21:45:51 Uhr selbst gestartet haben. Die systemd-Unit hat Restart=no.
Was ist mit „Monitoring“ unter „Systemstatus“?
Der Eintrag „Monitoring“ ist in unserer Installation als „Pro-Feature“ markiert. Ob er Benachrichtigungen bei Ausfällen bietet, konnten wir ohne Professional-Lizenz nicht prüfen.
Kann ich UDP-Ports überwachen?
Die Auswahl „UDP“ gibt es je Zeile. Getestet haben wir nur TCP-Einträge.
Wie bekomme ich trotzdem eine Meldung bei Ausfällen?
In unserer Installation ohne Pro-Lizenz nicht. Nutzen Sie einen externen Dienst, der Ports oder Websites von außen prüft. Das haben wir hier nicht getestet.
Testumfang
Wir haben in KeyHelp 26.1.1 ProFTPD per Konsole und per „Server-Dienst-Verwaltung“ gestoppt und gestartet, die Reaktionszeit des Dashboards gemessen, eigene Ports ergänzt und Benachrichtigungen, Ereignis-Protokoll und Mail-Journal ausgewertet. Auffällig: keine Benachrichtigung bei Ausfall, Starts erscheinen im Protokoll als „stopped“, Prüfung nur lokal. Nicht geprüft: UDP, das Pro-Feature „Monitoring“ und Ausfälle anderer Dienste. Richten Sie zusätzlich eine externe Überwachung ein.
Fazit
Die Dienst-/Portüberwachung ist eine schnelle Sichtprüfung für das offene Dashboard, mehr nicht. Sie meldete einen gestoppten Dienst im Test nach 24 Sekunden, prüft aber nur lokal und schickt keine Benachrichtigung. Ergänzen Sie fehlende Ports wie 4190, starten Sie Dienste über die „Server-Dienst-Verwaltung“ neu und kontrollieren Sie Dienstaktionen im Journal, nicht nur im Ereignis-Protokoll. Für echte Alarmierung brauchen Sie eine externe Überwachung.
