Ein Monitor, der ständig falschen Alarm schlägt, ist schlimmer als keiner. Nach ein paar Fehlalarmen liest niemand die Benachrichtigungen mehr, und der echte Alarm erntet dasselbe Achselzucken. Diese Anleitung erklärt, woher Fehlalarme kommen und was Sie dagegen tun können.

Zuerst eine Definition. Ein Fehlalarm ist eine Benachrichtigung über ein Problem, das Ihre Besucher nicht hatten. Er ist nicht dasselbe wie ein kurzer echter Ausfall: Eine Website, die zwei Minuten lang nicht erreichbar war, war wirklich down, und die Benachrichtigung war berechtigt.

Woher Fehlalarme kommen

Ein Aussetzer zwischen Monitor und Website

Die Prüfung läuft über das öffentliche Internet. Ein unterwegs verlorenes Paket, eine überlastete Leitung oder ein kurzes Routing-Problem kann eine Prüfung fehlschlagen lassen, während die Website für ihre Besucher völlig gesund ist. Das ist die häufigste Ursache, und sie vergeht von allein.

Der Monitor wird blockiert

Firewalls, Bot-Schutz und Ratenbegrenzungen sind dafür gebaut, automatisierte Anfragen zu stoppen, und ein Monitor sendet automatisierte Anfragen. Beantwortet Ihr Schutz eine Prüfung mit einer Challenge-Seite oder einem 403 Forbidden, sieht der Monitor einen Fehler, während echte Menschen durchkommen.

UptimeWire wertet jede endgültige Antwort außerhalb des Bereichs 200 bis 399 als fehlgeschlagene Prüfung. Das schließt 401 und 403 ein. Zeigt Ihre Website diese Antwort automatisierten Besuchern, geben Sie den Monitor frei. Zum Zeitpunkt der Veröffentlichung geben sich die Anfragen von UptimeWire als UptimeWireBot/1.0 zu erkennen.

Eine langsame Seite

Eine Prüfung wartet nur begrenzte Zeit auf eine Antwort. Bei UptimeWire gibt eine Prüfung nach 15 Sekunden auf. Eine Seite, die manchmal länger braucht, zum Beispiel während sich ein Cache aufwärmt, lässt diese Prüfungen fehlschlagen, obwohl ein geduldiger Besucher eine Seite bekäme.

Überwachen Sie eine Adresse, die schnell antwortet, etwa eine einfache Seite oder eine Health-Seite, statt einer aufwendigen Such- oder Berichtsseite.

Zu viele Weiterleitungen

UptimeWire folgt bis zu fünf Weiterleitungen. Eine längere Kette oder eine Schleife zwischen zwei Adressen gilt als Fehler, mit dem Grund „mehr als 5 Weiterleitungen“. Auch Browser sind begrenzt, eine so lange Kette ist also ein echter Fehler, zeigt sich aber unter Umständen nur in einem Monitor.

Eine zu strenge Seitentext-Regel

Eine Seitentext-Regel lässt die Prüfung fehlschlagen, wenn der erwartete Text fehlt oder verbotener Text erscheint. UptimeWire liest das rohe HTML der Seite, bis zu 1 MB, und gleicht den Text ohne Beachtung der Groß- und Kleinschreibung ab. Skripte führt es nicht aus. Text, den der Browser per JavaScript hinzufügt, steht nicht in diesem HTML, eine Regel darauf schlägt also bei einer gesunden Seite fehl.

Geplante Arbeiten

Ein Deployment, eine Datenbankmigration oder ein Serverneustart lässt die Website absichtlich ausfallen. Weiß der Monitor nichts davon, meldet er einen echten Ausfall, den Sie selbst verursacht haben. Falsch im Sinne von unwahr ist das nicht, aber es ist Rauschen, und geplante Wartungsfenster gibt es, um es zu beseitigen.

Wie wiederholte Prüfungen das Rauschen verringern

Die einfachste Verteidigung ist, einem einzelnen Fehler nicht zu glauben. Schlägt eine Prüfung fehl, prüft UptimeWire erneut. Ein Vorfall wird erst nach drei fehlgeschlagenen Prüfungen in Folge im Abstand von etwa 20 Sekunden eröffnet. Er wird nach zwei erfolgreichen Prüfungen geschlossen.

Stehen mehrere Prüfstandorte zur Verfügung, muss ein Fehler außerdem von mehr als der Hälfte der Standorte gesehen werden, die geantwortet haben. Steht nur ein Standort zur Verfügung, kann vor der Eröffnung des Vorfalls ein zweiter Server um seine Einschätzung gebeten werden, sofern einer eingerichtet ist. Ohne diese zweite Einschätzung kann ein Vorfall aufgrund der drei Fehler von einem einzigen Ort eröffnet werden.

Die Abwägung ist klar. Das Wiederholen einer Prüfung kostet ein wenig Zeit, grob 40 Sekunden zusätzlich zum Prüfintervall. Dafür sinkt die Zahl der Fehlalarme deutlich. Eine sofortige Erkennung bekommen Sie dadurch nicht, und das gibt keine Einstellung her.

Geplante Wartungsfenster

Für Arbeiten, die sich vorhersehen lassen, sagen Sie dem Monitor vorab Bescheid. In UptimeWire planen Sie für eine Website ein geplantes Wartungsfenster. Die Prüfungen laufen weiter, und der Verlauf zeigt die Fehler, aber:

  • Benachrichtigungen zu Vorfällen, die innerhalb des Fensters beginnen, werden zurückgehalten. Endet der Ausfall innerhalb des Fensters, werden die Benachrichtigungen verworfen. Dauert er über das Ende hinaus, werden sie am Ende des Fensters gesendet.
  • Die Zeit innerhalb des Fensters bleibt in der Berechnung der Verfügbarkeit unberücksichtigt.
  • Warnungen zu Zertifikat, Domain und DNS werden vom Fenster nicht zurückgehalten.

Ein Fenster muss rechtzeitig eingerichtet werden, und für seine Länge und Anzahl gelten Grenzen. Es ist ein Werkzeug für angekündigte Arbeiten, kein Weg, einen Ausfall zu verbergen.

Was Sie einstellen, in dieser Reihenfolge

  1. Lesen Sie die Fehlergründe. Der Vorfallverlauf zeigt, warum jede Prüfung fehlschlug: Zeitüberschreitung, abgelehnte Verbindung, nicht aufgelöster Name, Zertifikatsfehler oder ein Statuscode. Ein Muster in den Gründen benennt meist die Ursache.
  2. Geben Sie den Monitor in Ihrem Schutz frei, wenn der Grund 403 oder eine Challenge ist.
  3. Wählen Sie eine leichtere Adresse, wenn der Grund eine Zeitüberschreitung ist.
  4. Überprüfen Sie Seitentext-Regeln. Stellen Sie sicher, dass der Text im rohen HTML steht.
  5. Nutzen Sie Wartungsfenster für geplante Arbeiten.
  6. Legen Sie fest, wohin Benachrichtigungen gehen. Senden Sie die erste Benachrichtigung an einen Ort, an dem ein Mensch sie sieht, und heben Sie sich die lauten Kanäle für das Wichtige auf.
  7. Senden Sie eine Test-Benachrichtigung, um zu bestätigen, dass der Weg funktioniert. So sehen Sie auch, wie die Benachrichtigung um 3 Uhr nachts aussieht.

Was Sie nicht tun sollten

  • Verlängern Sie das Prüfintervall nicht, um Benachrichtigungen zu verringern. Das verzögert nur die Erkennung echter Ausfälle.
  • Ignorieren Sie kein wiederkehrendes Muster. Schlägt ein Monitor jede Nacht zur gleichen Zeit fehl, passiert zu dieser Zeit etwas. Vielleicht ein Backup, das den Server bremst.
  • Schalten Sie keinen Monitor ab, um das Rauschen zu beenden. Beheben Sie die Ursache.

Wenn die Benachrichtigung echt, aber kurz ist

Ein kurzer Ausfall kann echt sein und sich trotzdem wie Rauschen anfühlen, etwa ein Neustart, der eine Minute dauert. Kehrt er wieder, ist es ein echtes Problem mit kleinem Ausmaß. Zählen Sie ihn mit. Der Vorfallverlauf hält Anfang und Ende fest, sodass Sie sehen, wie oft er auftritt und wie lange.

Außerdem kann eine HTTP-Prüfung nicht jede Art von Fehler erkennen. Eine Antwort 200 beweist nicht, dass der Checkout funktioniert, und Schweigen eines Monitors ist kein Beweis, dass alles in Ordnung ist. Überwachung der Website-Verfügbarkeit erklärt, was eine Prüfung misst und was ihr entgeht.

Checkliste

  • Enthalten die Benachrichtigungen einen Grund? Lesen Sie ihn.
  • Ist der Monitor durch Bot-Schutz und Ratenbegrenzungen freigegeben?
  • Antwortet die überwachte Adresse deutlich innerhalb von 15 Sekunden?
  • Basieren Seitentext-Regeln auf dem rohen HTML?
  • Sind geplante Änderungen durch ein Wartungsfenster abgedeckt?
  • Geht die erste Benachrichtigung an jemanden, der darauf reagiert?