Server-Erreichbarkeit prüfen: Ping reicht nicht

Ein Dienst fällt selten mit lautem Knall aus. Meistens antwortet er nur langsamer, liefert einen Fehlercode oder ist von einem bestimmten Netz aus nicht mehr erreichbar. Wer das erst merkt, wenn sich Nutzer melden, hat den Ausfall bereits bezahlt. Eine einfache Erreichbarkeitsprüfung kostet wenig und schließt genau diese Lücke.

Was „erreichbar" konkret bedeutet

Der Begriff ist unpräzise, und daran scheitern viele Überwachungen. Sinnvoll ist eine Prüfung in Stufen, weil jede Stufe eine andere Fehlerklasse aufdeckt:

1. Namensauflösung: Liefert der DNS überhaupt eine Adresse? Abgelaufene Einträge und falsch gesetzte Datensätze fallen hier auf.
2. Netzwerkschicht: Antwortet der Host auf ein Ping? Viele Server blockieren das inzwischen, ein fehlendes Ping ist also kein Beweis für einen Ausfall.
3. Portprüfung: Nimmt der Dienst auf seinem Port Verbindungen an? Das trifft die Frage schon deutlich besser.
4. Anwendungsprüfung: Liefert die Anwendung den erwarteten Statuscode und den erwarteten Inhalt? Nur diese Stufe erkennt eine Seite, die zwar antwortet, aber eine Fehlermeldung ausgibt.
5. Zertifikatsprüfung: Wie lange ist das TLS-Zertifikat noch gültig? Ein abgelaufenes Zertifikat legt einen Dienst genauso lahm wie ein abgestürzter Prozess.

Die häufigste Fehlkonfiguration: Es wird nur geprüft, ob der Server antwortet, nicht ob er das Richtige antwortet. Ein Webserver, der auf jede Anfrage eine Fehlerseite mit Statuscode 200 ausliefert, gilt dann als gesund.

Intervall, Schwellenwert und Fehlalarm

Ein zu enges Intervall erzeugt Last und Fehlalarme, ein zu weites verschleppt die Erkennung. Für die meisten Anwendungen ist ein Prüfintervall von ein bis fünf Minuten praktikabel. Entscheidend ist der Schwellenwert: Erst nach zwei oder drei aufeinanderfolgenden Fehlversuchen sollte eine Meldung ausgelöst werden. Sonst weckt jede kurze Paketverlustphase den Bereitschaftsdienst.

Genauso wichtig ist der Blickwinkel. Eine Prüfung, die auf demselben Server läuft wie der überwachte Dienst, meldet einen Totalausfall nie, weil sie mit ausfällt. Die Prüfung gehört an einen anderen Ort, im Zweifel an mehrere.

Selbst bauen oder Dienst nutzen

Für einen einzelnen Server genügt ein kleines Skript, das in festem Takt eine Anfrage stellt und bei Abweichung eine Nachricht verschickt. Wer mehrere Systeme betreut, fährt mit einer fertigen Überwachungslösung besser, weil Historie, Wartungsfenster und Eskalationswege bereits eingebaut sind.

Was in die Benachrichtigung gehört

Eine Warnmeldung mit dem Inhalt „Server down" ist wertlos. Brauchbar wird sie mit vier Angaben: welches System, welche Prüfstufe fehlgeschlagen ist, seit wann, und was zuletzt anders war. Der letzte Punkt ist der wichtigste, weil die meisten Ausfälle unmittelbar auf eine Änderung folgen.

Erreichbarkeit ist nicht Geschwindigkeit

Ein Dienst kann durchgehend antworten und trotzdem unbrauchbar sein, wenn die Antwortzeit auf mehrere Sekunden steigt. Deshalb gehört die Antwortzeit in dieselbe Aufzeichnung wie der Status. Erst der zeitliche Verlauf zeigt, ob ein Ausfall ein plötzliches Ereignis war oder das Ende einer langsamen Verschlechterung.

Für die Auswertung auf der Anwendungsseite lohnt sich ein Blick auf Webanalyse-Werkzeuge, die Ladezeiten pro Seite erfassen. Welche davon datenschutzseitig unproblematisch sind, behandelt der Vergleich Google Analytics und Matomo.

Passende Werkzeuge

Für die technische Seite genügen oft Bordmittel und kleine Helfer, wie sie in der Übersicht Windows-Freeware-Tools beschrieben sind. Wer Skripte und Prüfungen automatisch verketten will, findet im Bereich Software fürs Business die passenden Automatisierungswerkzeuge.