Website-Monitoring aus Deutschland

Woran erkennt LIVCK, dass eine Website kaputt ist?

An Bedingungen, die Du formulierst. Ohne Zutun gilt genau eine: Statuscode ab 400 bedeutet Ausfall. Darüber hinaus lässt sich auf Antwortzeit, Textinhalt, JSON-Felder, Antwort-Header, gefolgte Weiterleitungen, Antwortgröße, Protokollversion und die End-URL prüfen — jede Bedingung wahlweise als „Ausfall“ oder als „Beeinträchtigt“.

Der Unterschied entscheidet in der Praxis mehr als die Prüfhäufigkeit. Eine Anwendung, deren Datenbank weg ist, liefert selten einen ehrlichen Fehler: Der Reverse-Proxy zeigt seine eigene Seite mit Status 200, das CDN liefert eine gecachte Version von vorgestern, das Framework fängt die Ausnahme ab und rendert eine leere Seite. Alle drei Fälle sind für eine Prüfung, die nur „antwortet der Server?“ fragt, grün.

Eine einzige Inhaltsbedingung schließt diese Lücke: ein Text, der nur auf der funktionierenden Seite steht — der Name des angemeldeten Nutzers, die Überschrift des Warenkorbs, ein Feld in der JSON-Antwort. Fehlt er, ist die Seite kaputt, egal welchen Statuscode sie sendet.

Zwei Schweregrade statt einem: „Ausfall“ bedeutet, der Dienst ist nicht nutzbar. „Beeinträchtigt“ bedeutet, er antwortet, aber nicht richtig — zu langsam, über zu viele Weiterleitungen, ohne den erwarteten Header. Beides löst aus, aber nicht dasselbe: Ein beeinträchtigter Dienst muss nicht um drei Uhr nachts jemanden anrufen.

Was, wenn der Endpunkt Anmeldung, eigene Header oder mTLS verlangt?

Dann wird er genau so konfiguriert. LIVCK schickt jede HTTP-Methode, beliebige eigene Header, einen Anfrage-Body und wahlweise Bearer-Token, Basic-Auth oder einen API-Key-Header. Für Endpunkte hinter gegenseitiger TLS-Authentifizierung lässt sich ein Client-Zertifikat hinterlegen, für interne Zertifizierungsstellen ein eigenes CA-Bündel.

Der letzte Punkt sieht unscheinbar aus und ist teuer. Ein Host mit AAAA-Eintrag, dessen IPv6-Adresse nicht antwortet, gilt bei den meisten Prüfdiensten als erreichbar — sie fallen still auf IPv4 zurück, genau wie die meisten Browser. Für den Teil der Besucher, der über einen reinen IPv6-Anschluss kommt, ist die Seite trotzdem tot, und niemand erfährt es. Mit eingeschalteter Dual-Stack-Erkennung wird daraus ein sichtbarer Zustand statt eines blinden Flecks.

Client-Zertifikate werden als PEM eingefügt oder als .p12- beziehungsweise .pfx-Datei hochgeladen, mit optionaler Passphrase. Der private Schlüssel wird verschlüsselt abgelegt und verlässt den Server nie im Klartext. Hinterlegte Zertifikate werden zusätzlich auf ihr Ablaufdatum überwacht — die Erinnerung kommt, bevor der Prüflauf wegen eines abgelaufenen Client-Zertifikats scheinbar einen Ausfall meldet.

Wer eine interne Zertifizierungsstelle betreibt, lädt deren Bündel als CA hoch. Danach vertraut die Probe diesem Aussteller, ohne dass die Zertifikatsprüfung insgesamt abgeschaltet werden muss — der Unterschied zwischen „ich vertraue dieser CA“ und „ich prüfe gar nicht mehr“.

Methode und Body

GET, POST, PUT, DELETE, PATCH, HEAD oder OPTIONS, dazu ein Anfrage-Body bis 10.000 Zeichen — genug, um eine echte Abfrage abzusetzen statt nur an die Tür zu klopfen.

Eigene Header

Beliebig viele. Die Werte werden verschlüsselt gespeichert und in der Oberfläche nie wieder im Klartext gezeigt: Feld leer lassen behält den Wert, ein neuer Wert ersetzt ihn.

Authentifizierung

Bearer-Token, Basic-Auth oder ein API-Key in einem frei gewählten Header. Auch diese Geheimnisse liegen verschlüsselt.

Weiterleitungen

Folgen oder nicht folgen. Wer nicht folgt, prüft die erste Antwort — die einzige Art, eine Weiterleitung selbst zum Prüfgegenstand zu machen.

Zertifikatsprüfung

Abschaltbar, damit auch ein Endpunkt mit selbstsigniertem Zertifikat überwacht werden kann, ohne die Prüfung dauerhaft rot zu färben.

IP-Version

auto, nur IPv4 oder nur IPv6. „auto“ meldet erreichbar, sobald eine der beiden Familien antwortet.

Kluge Dual-Stack-Erkennung

Bietet der Host beide Familien an, ist aber nur eine erreichbar, meldet LIVCK „Beeinträchtigt“ statt „erreichbar“.

Wie werden Fehlalarme verhindert?

In vier Stufen: Wiederholung am Standort, Bestätigung über die Zeit, Mehrheit über die Standorte — und der Grundsatz, dass nichts von selbst öffentlich wird. Erst wenn alle vier greifen, entsteht ein Vorfall, und selbst dann bleibt er zunächst intern.

Die letzte Stufe ist die, die am meisten Ärger erspart und in Produktvergleichen nie auftaucht. Ein Erkennungssystem, das automatisch veröffentlicht, macht aus jedem Fehlalarm eine öffentliche Störungsmeldung an alle Abonnenten — und die lässt sich nicht zurückholen. Bei LIVCK ist automatisches Veröffentlichen ab Werk aus.

Alle Schwellen sind Voreinstellungen, keine Naturgesetze. Sie stehen in einer Erkennungs-Richtlinie, die für einen einzelnen Dienst, für alle Dienste mit einem bestimmten Tag oder für die ganze Organisation gelten kann. Wer einen Dienst überwacht, der ohnehin nur aus einem Land erreichbar sein soll, dreht die Mehrheitsregel entsprechend — ohne für alle anderen etwas zu ändern.

Wiederholung

Schlägt eine Prüfung fehl, wird sie sofort wiederholt, bevor das Ergebnis überhaupt zählt. Voreingestellt sind zwei Versuche, einstellbar je Dienst.

Bestätigung

Drei aufeinanderfolgende fehlerhafte Ergebnisse, sonst kein Vorfall. Ein einzelner Aussetzer verpufft.

Mehrheit

Mehr als die Hälfte der messenden Standorte muss dasselbe sehen. Ein Netzknoten mit Problemen erzeugt keinen Vorfall — er erzeugt eine auffällige Zeile in der Auswertung.

Rückkehr

Für „wieder da“ reichen zwei Bestätigungen. Die Flatter-Erkennung fängt Dienste ab, die im Minutentakt zwischen erreichbar und weg springen, statt jedes Mal neu zu alarmieren.

Veröffentlichung

Ein automatisch erkannter Vorfall ist ein interner Vorgang. Ob er auf die öffentliche Statuspage geht und Abonnenten benachrichtigt werden, entscheidet ein Mensch.

Warum war die Seite langsam?

Weil LIVCK jede Anfrage in ihre Phasen zerlegt: DNS-Auflösung, Verbindungsaufbau, TLS-Handschlag, Wartezeit bis zum ersten Byte und Übertragung. Erst diese Aufteilung sagt, ob das Problem im Netz, im Zertifikat oder in der Anwendung liegt.

Ein Mittelwert von 85 Millisekunden ist keine Diagnose. Die Aufschlüsselung im Bild darunter ist eine: 45 Millisekunden entfallen auf den TLS-Handschlag, 24 auf die Wartezeit bis zum ersten Byte, 12 auf den Verbindungsaufbau, 3 auf DNS und eine einzige auf die Übertragung. Die Anwendung ist hier also nicht der Engpass — mehr als die Hälfte der Zeit vergeht, bevor sie überhaupt gefragt wird.

Verschiebt sich das Bild, verschiebt sich die Ursache. Wächst die Wartezeit, denkt der Server zu lange. Wächst der DNS-Anteil, liegt es am Resolver oder an zu kurzen TTLs. Wächst der Verbindungsaufbau, deutet das auf Paketverlust oder eine schlechtere Route. Wächst der TLS-Anteil, hat sich am Zertifikat oder an der Kette etwas geändert. Ohne diese Trennung bleibt nur die Feststellung, dass es langsamer geworden ist.

Dieselbe Zerlegung gibt es je Standort über die Zeit. Eine Linie, die sich von den anderen löst, ist ein Weg-Problem; steigen alle gemeinsam, liegt es an der Anwendung.

Was steht nach zwei Wochen in der Auswertung?

Verfügbarkeit, Antwortzeit im Mittel sowie als 95. und 99. Perzentil, das Verhältnis von Ausreißer zu Mittel, dazu die Prozesskennzahlen MTTR, MTTA und MTBF, der längste zusammenhängende Ausfall, die Verfügbarkeit je Standort und die Verteilung der Fehlerursachen.

Mittel, P95 und P99

Der Mittelwert verschweigt Ausreißer. Erst das 95. und 99. Perzentil zeigen, was das langsamste Zwanzigstel und das langsamste Hundertstel der Anfragen erlebt hat.

Tail (P99 geteilt durch Mittel)

Ein Wert von 1,7 heißt: Die langsamsten Anfragen dauern knapp doppelt so lang wie der Durchschnitt. Steigt er, ohne dass der Mittelwert steigt, ist die Anwendung ungleichmäßig geworden — der klassische Vorbote.

MTTR, MTTA, MTBF

Mittlere Zeit bis zur Behebung, bis zur Bestätigung durch einen Menschen und zwischen zwei Vorfällen. Die drei Zahlen, nach denen in einem Review gefragt wird.

Verfügbarkeit je Standort

Eine ganze Spalte rot bedeutet globaler Ausfall. Eine einzelne Zeile rot bedeutet: nur dieser Standort — und dann liegt es meist am Weg dorthin, nicht an Deiner Seite.

Fehlerursachen und Statuscodes

Warum Prüfungen fehlgeschlagen sind, nach Ursache gruppiert, dazu die Verteilung aller Antwort-Statuscodes im Zeitraum.

Was liegt vor, wenn es kaputt war?

Die Antwort selbst. Schlägt eine Prüfung fehl, speichert LIVCK den Antworttext und die Antwort-Header genau so, wie die Probe sie in diesem Moment gesehen hat — mitsamt Standort, Uhrzeit und dem Zustandswechsel, der dazu gehört.

Das ist der Unterschied zwischen „die Seite war um 3:12 Uhr weg“ und „die Seite lieferte um 3:12 Uhr aus Warschau eine 502-Seite des Reverse-Proxys aus, mit einem Header, der auf den falschen Backend-Pool zeigt“. Ohne diesen Beleg beginnt die Fehlersuche am nächsten Morgen mit dem Versuch, den Zustand nachzustellen. Der ist vorbei, und meistens bleibt es bei einer Vermutung.

Aufbewahrt werden diese Belege sieben Tage im Solo-, dreißig im Team- und neunzig Tage im Business-Tarif. Der Free-Tarif speichert keine.

Wer wird geweckt, und wann?

Das entscheidet eine Eskalations-Richtlinie: Stufen mit Zeitabstand, je Stufe ein Ziel, und eine Bestätigung, die die Kette anhält. Reagiert niemand, läuft sie weiter zur nächsten Stufe — bis jemand bestätigt.

Als Ziel kann eine Person stehen, ein Team, eine Rufbereitschaft mit Rotation oder ein Chat-Kanal. Die Rufbereitschaft löst dabei erst im Moment des Alarms auf, wer gerade Dienst hat — eine Vertretung, die eine Stunde vorher eingetragen wurde, gilt.

Über welchen Weg jemand erreicht wird, entscheidet die Person selbst: E-Mail, SMS, Sprachanruf, WhatsApp. Organisationsweite Kanäle gibt es für Slack, Microsoft Teams, Telegram, Discord und beliebige Webhooks.

Und nicht jeder Dienst verdient denselben Lärm. Die Dringlichkeit steht je Dienst auf „immer hoch“, „immer niedrig“ oder „nach Zeitplan“. Ein Testsystem, dessen Ausfall nachts niemanden interessiert, bekommt eine Mail statt eines Anrufs — ohne dass man dafür die Überwachung abschalten müsste.

Und wie wird daraus eine Statuspage?

Aus denselben Daten. Ein überwachter Dienst kann als Komponente auf einer öffentlichen Statuspage stehen; erkannte Vorfälle, geplante Wartungen und die Verläufe von Verfügbarkeit und Antwortzeit erscheinen dort, sobald sie freigegeben sind.

Das ist der Grund, warum Überwachung und Statuspage bei LIVCK ein Werkzeug sind und nicht zwei. Wer sie trennt, pflegt im Ernstfall zweimal denselben Sachverhalt — einmal im Überwachungssystem, einmal von Hand auf der Statusseite, unter Zeitdruck und meist unvollständig.

Eine eigene Domain ist in jedem Tarif enthalten, auch im kostenlosen. Abonnenten können einzelne Komponenten abonnieren statt der ganzen Seite, und sie werden erst benachrichtigt, wenn ein Vorfall veröffentlicht ist.