Uptime-Monitoring

Uptime-Monitoring ist der grundlegendste Check in Hoppla. Er schickt HTTP- oder HTTPS-Anfragen an deine URL und prüft, ob die Antwort passt -- richtiger Statuscode, akzeptable Antwortzeit und optional bestimmte Schlüsselwörter im Antworttext.

Funktionsweise

Bei jedem Prüfzyklus schickt Hoppla eine HTTP-Anfrage an die URL deines Monitors vom primären Standort aus. Dabei werden Statuscode und Antwortzeit erfasst; falls konfiguriert, werden Header und Antworttext gegen deine Regeln geprüft.

Dual-Check-Verifizierung

Um Fehlalarme durch kurzzeitige Netzwerkprobleme auszuschließen, nutzt Hoppla eine Dual-Check-Verifizierung. Schlägt ein Uptime-Check vom primären Standort fehl, wird automatisch ein zweiter Check von einem anderen geografischen Standort ausgelöst. Ein Vorfall entsteht nur, wenn der Check von beiden Standorten fehlschlägt.

Heißt konkret: Du wirst niemals um 3 Uhr nachts geweckt, nur weil es einen kurzzeitigen Routing-Aussetzer zwischen Hopplas primärem Standort und deinem Server gab.

Konnektivitäts-Canary

Hoppla führt außerdem einen Konnektivitäts-Canary aus -- eine leichtgewichtige Prüfung gegen einen garantiert erreichbaren Endpunkt. Schlägt der Canary gleichzeitig mit deinem Check fehl, geht Hoppla davon aus, dass das Problem im eigenen Netzwerk liegt, und markiert deinen Check als ok statt einen Fehlalarm auszulösen.

Konfiguration

Einstellung	Standard	Beschreibung
Erwarteter Statuscode	Beliebiger 2xx/3xx	Der HTTP-Statuscode, den deine URL zurückgeben soll. Setz ihn auf 200 für eine strikte Prüfung, oder lass ihn leer, um jede erfolgreiche Antwort (200-399) zu akzeptieren.
HTTP-Methode	GET	Die HTTP-Methode. Unterstützt werden GET, POST, PUT und HEAD.
Timeout	10s	Maximale Wartezeit auf eine Antwort in Sekunden (1-60).
Schwelle für langsame Antworten	Aus	Eine korrekte Antwort, die mindestens so viele Millisekunden (1-60000) dauert, gilt als langsam: Der Check zeigt dann eine Warnung statt OK und zählt weiter als erreichbar. Standardmäßig senden zwei langsame Ergebnisse in Folge warning.slow_response. Lässt du das Feld leer, löst die Antwortzeit nie eine Warnung aus. Du kannst den Wert beim Anlegen des Monitors setzen oder später in den Einstellungen des Checks.
Prüfintervall	60s	Wie oft der Check läuft (30s bis 24h).
Weiterleitungen folgen	Ja	Ob HTTP-Weiterleitungen automatisch verfolgt werden.
Max. Weiterleitungen	5	Maximale Anzahl der verfolgten Weiterleitungen (gedeckelt bei 20).
Erwartete Ziel-URL	(keine)	Falls gesetzt, schlägt der Check fehl, sofern die Anfrage nach allen Weiterleitungen nicht auf genau dieser URL landet. Abschließende Schrägstriche werden ignoriert.
SSL verifizieren	Ja	Ob das SSL-Zertifikat bei der Anfrage geprüft wird.
Schlüsselwort vorhanden	(keines)	Ein Text, der im Antworttext vorkommen muss. Wird er nicht gefunden, schlägt der Check fehl. Groß-/Kleinschreibung wird ignoriert. Maximal 500 Zeichen.
Schlüsselwort abwesend	(keines)	Ein Text, der im Antworttext NICHT vorkommen darf. Wird er gefunden, schlägt der Check fehl. Groß-/Kleinschreibung wird ignoriert. Maximal 500 Zeichen.
Eigene Request-Header	(keine)	Zusätzliche HTTP-Header, die mit jeder Anfrage gesendet werden -- etwa ein Authorization-Bearer-Token, ein API-Schlüssel oder ein eigener User-Agent.
HTTP-Basic-Auth	(keine)	Ein Benutzername und ein Passwort, die als HTTP-Basic-Authentifizierung gesendet werden. Nur für diese Prüfung: Ohne Angabe verwendet die Uptime-Prüfung den Website-Zugang des Monitors, den jede Prüfung des Monitors verwendet.
Query-Parameter	(keine)	Zusätzliche Query-String-Parameter, die an die Anfrage-URL angehängt werden.
Request-Body	(keiner)	Ein Body, der mit POST- oder PUT-Anfragen gesendet wird -- nützlich für Endpunkte, die eine Nutzlast erwarten.
Origin-IP-Pinning	(keines)	Bindet die DNS-Auflösung an eine bestimmte IP-Adresse, sodass die Anfrage immer einen gewählten Origin erreicht und den öffentlichen DNS-Eintrag umgeht.

Schlüsselwort-Checks

Schlüsselwort-Checks sind super praktisch, um sicherzustellen, dass deine Anwendung wirklich läuft und nicht nur eine generische Fehlerseite mit Statuscode 200 ausliefert. Ein paar Beispiele:

• Setz Schlüsselwort vorhanden auf Willkommen bei MeineApp, um zu prüfen, dass deine Startseite korrekt gerendert wird.
• Setz Schlüsselwort abwesend auf Error oder Maintenance, um zu erkennen, wenn deine App eine Fehlerseite anzeigt.

Beide Einstellungen lassen sich auch kombinieren.

Antwort-Verifizierungsregeln

Für eine präzisere Prüfung als die einfachen Schlüsselwort-Abkürzungen kannst du mehrere Regeln hinterlegen, die Antworttext und Header untersuchen. Jede Regel hat eine Bedingung, die festlegt, wie ihr Wert verglichen wird:

Bedingung	Trifft zu, wenn
contains	Der Text im Ziel vorkommt (Groß-/Kleinschreibung wird ignoriert).
not_contains	Der Text im Ziel nicht vorkommt.
equals	Das Ziel exakt dem Wert entspricht.
matches	Das Ziel dem Wert als regulärer Ausdruck entspricht.

Body-Regeln (response_body_rules) -- jede Regel ist { condition, value } und wird gegen den Antworttext geprüft.

Header-Regeln (response_header_rules) -- jede Regel ist { header, condition, value } und wird gegen den benannten Antwort-Header geprüft (die Header-Suche ignoriert Groß-/Kleinschreibung). Fehlt der Header, schlägt die Regel fehl.

Schlägt eine Regel fehl, wird der Check-Status auf fail gesetzt. Die einfachen Einstellungen Schlüsselwort vorhanden / Schlüsselwort abwesend bleiben als Abkürzung für den häufigsten Einzeltext-Fall verfügbar.

Ergebnisse

Jedes Uptime-Check-Ergebnis enthält:

• Status -- ok, fail oder warning
• Antwortzeit -- Gesamtdauer der Anfrage in Millisekunden (inklusive DNS-Auflösung, TCP-Verbindung, TLS-Handshake und Datenübertragung)
• Statuscode -- Der HTTP-Statuscode deines Servers
• Zeitmessung im Detail -- DNS-Auflösung, TCP-Verbindung, TLS-Handshake und Time-to-First-Byte
• Größe des Antworttexts und die IP-Version (IPv4 oder IPv6), über die die Antwort kam

Auf der Monitor-Detailseite siehst du ein Diagramm der Antwortzeiten im Zeitverlauf. So erkennst du Leistungstrends und kannst Verlangsamungen mit Deployments oder Vorfällen in Verbindung bringen.

Alarme

Vorfallerstellung

Ein Vorfall wird erstellt, wenn:

1. Der Uptime-Check vom primären Standort fehlschlägt.
2. Ein Verifizierungs-Check vom sekundären Standort ebenfalls fehlschlägt.
3. Die Anzahl der aufeinanderfolgenden Fehlschläge die Bestätigungsschwelle erreicht (Standard: 1).
4. Kein Wartungsfenster für den Monitor aktiv ist.

Der Vorfall bekommt den Titel "Uptime check failed" und den Schweregrad major.

Automatische Lösung

Vorfälle werden automatisch gelöst, wenn der Check eine konfigurierte Anzahl aufeinanderfolgender Erfolge erreicht (die Erholungsschwelle, Standard: 1). Zum Vorfall wird dann die Meldung hinzugefügt: "Check recovered -- uptime restored."

Benachrichtigungsereignisse

Ereignis	Zeitpunkt
incident.created	Uptime-Check von beiden Standorten fehlgeschlagen
incident.resolved	Uptime-Check ist wieder erfolgreich
warning.slow_response	Standardmäßig: zwei Ergebnisse in Folge waren korrekt, aber langsamer als die Schwelle für langsame Antworten (nur wenn eine Schwelle gesetzt ist)
warning.partial_outage	Standardmäßig: zwei Ergebnisse in Folge haben die Website über eine IP-Version (IPv4 oder IPv6) erreicht, über die andere nicht
warning.cleared	Eine Warnung, über die du benachrichtigt wurdest, besteht nicht mehr. Wird nur für angekündigte Warnungen gesendet, und nur an die Channels, die sie erhalten haben