Drei Fragen, die ich mir stelle
Zuerst prüfe ich, ob der Dienst wirklich erreichbar ist. Dafür teste ich die HTTP-Antwort der Anwendung und verlasse mich nicht allein auf Ping oder einen offenen Port.
Danach schaue ich mir CPU, Arbeitsspeicher, Speicherauslastung und Fehlerquoten an. Ich will Veränderungen erkennen, statt Zahlen ohne Vergleichswerte zu interpretieren.
Wenn ein Check fehlschlägt, nutze ich Logs und Ereignisse zur Diagnose. Ich möchte aber zusätzlich wissen, ob der Dienst für Nutzer tatsächlich funktioniert.
Ich prüfe zuerst den Dienst, dann die Ursache
Wenn ein Host auf Ping antwortet, die Webanwendung aber einen Fehler liefert, würde ein reiner Host-Check für mich grün bleiben. Deshalb prüfe ich den Anwendungsendpunkt und bewerte, was Nutzer tatsächlich erreichen können.
Ich trenne die Frage nach der Verfügbarkeit von der Suche nach der Ursache. Mit Uptime Kuma prüfe ich gezielt die Erreichbarkeit; Zabbix nutze ich für ergänzende Zustände und Metriken. Ich wähle dabei das Signal nach der Frage aus – nicht nach der Optik des Dashboards.
Ich will mit einem Alarm etwas anfangen können
Bevor ich eine Benachrichtigung einrichte, möchte ich drei Dinge beantworten: Was bedeutet das Signal? Ab wann ist es wirklich relevant? Und was kann ich nach dem Alarm überprüfen oder tun?
Wenn ich diese Fragen nicht beantworten kann, bekomme ich schnell eine Flut von Meldungen, die ich irgendwann ignoriere. Ich setze deshalb lieber auf wenige zuverlässige Checks als auf Kennzahlen ohne Konsequenz.