Uptime-Monitore

Monitore prüfen Dinge von außerhalb Ihrer App nach einem Zeitplan und alarmieren, wenn sich ihr Zustand ändert. Sieben Arten teilen sich die Uptime-Seite. Keine davon braucht Code außer Heartbeats, die Ihr Job anpingt.

1Art wählen

HTTP: 2xx oder 3xx gilt als online, optional mit einem Schlüsselwort im Body und einem Antwortzeit-Limit. Heartbeat: Ihr Cron-Job pingt eine geheime URL; zu spät bedeutet offline. SSL: TLS-Handshake mit host:port, die Kette muss vertrauenswürdig sein, zeigt Aussteller und Ablauf. Domain: Registrierungsablauf über RDAP, zeigt den Registrar. TCP: Verbindung zu host:port aufbauen und schließen. DNS: A, AAAA, CNAME, MX oder TXT über 1.1.1.1 und 8.8.8.8, optional mit erwartetem Wert. Browser: eine Liste von Schritten, die in headless Chromium laufen.

2Intervalle

HTTP alle 1, 3, 5, 10, 30 oder 60 Minuten. Heartbeats von 1 Minute bis 24 Stunden mit einer Toleranz von 1 bis 60 Minuten. SSL und Domain alle 1, 6, 12 oder 24 Stunden. Browser-Checks alle 5 bis 60 Minuten.

3Schritte eines Browser-Checks

Bis zu 20 Schritte als Daten, nie als Code. Schritt 1 muss goto sein. Aktionen: goto (url), click (selector), fill (selector, value), expect_text (text), expect_selector (selector), wait (ms). Selektoren und Text bis 300 Zeichen, Werte 500, Wartezeiten je 10 s und 30 s insgesamt, der gesamte Lauf 60 s. Bei einem Fehlschlag wird ein Screenshot der Seite unter der Zeile aufbewahrt. Verwenden Sie ein Testkonto für fill-Werte; sie werden im Klartext gespeichert.

json
[
  { "action": "goto", "url": "https://shop.example.com/login" },
  { "action": "fill", "selector": "#email", "value": "monitor@example.com" },
  { "action": "fill", "selector": "#password", "value": "test-only" },
  { "action": "click", "selector": "button[type=submit]" },
  { "action": "expect_text", "text": "Your orders" }
]

4Wie „offline“ entschieden wird

Ein fehlgeschlagener Check wird nach 20 Sekunden wiederholt, und eine Region gilt erst beim zweiten Fehlschlag in Folge als fehlgeschlagen. Ein Monitor mit mehreren Regionen ist nur offline, wenn eine absolute Mehrheit fehlschlägt (1 von 1, 2 von 2, 2 von 3). Domain- und Browser-Checks verwenden eine Region. Jeder Ausfall und jede Erholung erzeugt einen Alert über Ihre Kanäle oder an die Inhaber.

Gut zu wissen

  • Limits pro Plan: HTTP, SSL, Domain, TCP und DNS teilen sich einen Pool von 10 (Free), 25 (Solo), 100 (Team), 500 (Scale); Heartbeats haben dieselben Zahlen in einem eigenen Pool; Browser-Checks sind 0, 3, 20 und 100.
  • Zusätzliche Hinweise: monitor.slow und monitor.fast, wenn das p95 der letzten 10 HTTP-Checks das Antwortzeit-Limit über- oder unterschreitet; monitor.expiring 14, 7 und 1 Tag vorher bei Zertifikaten und 30 und 7 Tage bei Domains, einmal pro Schwelle.
  • Private und interne Adressen (localhost, 10.x, .local, .internal und so weiter) werden beim Speichern abgelehnt. Registries ohne RDAP, etwa .io, bleiben online und melden, dass das Ablaufdatum nicht verfügbar ist.
  • Die Verfügbarkeit wird für 24 Stunden und 30 Tage angezeigt. Rohe Check-Ergebnisse werden 3 Tage aufbewahrt. Die Heartbeat-URL wird einmal angezeigt und kann ersetzt werden.

Kommen Sie nicht weiter? Schreiben Sie an support@blipit.io. Schlüssel und den genauen DSN jedes Projekts finden Sie unter API-Schlüssel in app.blipit.io.