Überwachen Sie zuerst Ihre kundenorientierten Endpunkte
Jedes SaaS-Produkt hat Endpunkte, mit denen Benutzer direkt interagieren. Diese haben die höchste Überwachungspriorität.
Beginnen Sie mit Ihrem App-Dashboard. Wenn Benutzer sich bei app.ihrunternehmen.de anmelden, überwachen Sie diese URL. Fügen Sie dann Ihren Authentifizierungs-Endpunkt hinzu. Wenn sich Benutzer nicht anmelden können, spielt der Rest Ihrer Überwachung keine Rolle.
Fügen Sie Ihre primären API-Endpunkte hinzu. Wenn Ihr Produkt eine REST-API hat, die Kunden integrieren, überwachen Sie die Endpunkte, die sie am häufigsten aufrufen. Ein /v1/health-Endpunkt ist in Ordnung, aber er kann 200 zurückgeben, während Ihre eigentlichen Datenendpunkte 500-Fehler werfen. Überwachen Sie die Endpunkte, die Ihre Benutzer tatsächlich treffen.
Fügen Sie Ihren Abrechnungs- und Zahlungsablauf hinzu. Wenn Stripe- oder Paddle-Webhooks nicht mehr ankommen oder Ihr Abonnementverwaltungs-Endpunkt ausfällt, verlieren Sie Geld. Überwachen Sie die Endpunkte, die den Umsatz berühren.
Prüfen Sie Ihre Hintergrundjobs
Ihr Server läuft. Ihre API gibt 200 zurück. Ihr Dashboard lädt. Alles sieht gut aus. Aber Ihre nächtliche Datenbanksicherung scheitert seit zwei Wochen stillschweigend. Ihre E-Mail-Warteschlange hat 8.000 unzustellbare Nachrichten. Ihre Datenexport-Pipeline ist vor drei Tagen stehen geblieben.
Das ist die Überwachungslücke, die die meisten Teams erwischt. Uptime-Überwachung deckt den Anfrage-Antwort-Pfad ab. Sie deckt keine geplanten Aufgaben, Hintergrund-Worker oder asynchronen Pipelines ab.
Heartbeat-Überwachung schließt diese Lücke. Jede geplante Aufgabe erhält eine eindeutige URL. Wenn die Aufgabe erfolgreich läuft, pingt sie diese URL an. Wenn der Ping nicht innerhalb des erwarteten Zeitfensters eintrifft, erhalten Sie eine Warnung. Die Einrichtung ist ein einziger curl-Befehl am Ende Ihres Cron-Skripts.
Überwachen Sie mindestens diese Jobs:
- Datenbanksicherungen
- E-Mail-Zustellwarteschlangen
- Abrechnung und Rechnungserstellung
- Datensynchronisationen und -exporte
- Log-Rotation und Bereinigung
- Zertifikatserneuerungsautomatisierung
Erfahren Sie mehr über Heartbeat-Überwachung und wie sie erfasst, was Uptime-Prüfungen übersehen.
Wählen Sie das richtige Prüfintervall
Nicht jeder Endpunkt benötigt dieselbe Prüffrequenz. Richten Sie Ihre Intervalle an den geschäftlichen Auswirkungen von Ausfallzeiten aus.
30-Sekunden-Prüfungen sind für umsatzkritische Endpunkte: Ihren Checkout-Ablauf, Ihre primäre API, Ihren Authentifizierungsdienst. Wenn diese ausfallen, verlieren Sie Geld oder sperren Benutzer aus. Sie müssen so schnell wie möglich Bescheid wissen.
1-Minuten-Prüfungen funktionieren für die meisten Produktionsdienste. Ihr App-Dashboard, sekundäre APIs, Status-Endpunkte. Schnell genug, um echte Probleme zu erkennen, langsam genug, um Fehlalarme zu vermeiden.
5-Minuten-Prüfungen sind für Endpunkte mit niedrigerer Priorität in Ordnung: Marketingseiten, Dokumentationsseiten, interne Tools. Wenn die Marketingseite 4 Minuten offline ist, sind die geschäftlichen Auswirkungen gering.
Je schneller Ihre Prüfungen, desto früher wissen Sie Bescheid. Aber schnellere Prüfungen bedeuten auch mehr Daten, mehr Rauschen und potenziell höhere Kosten. Passen Sie das Intervall an die Auswirkungen an.
Richten Sie Alarmierung ein, die Ihr Team nicht ausbrennt
Alarmmüdigkeit ist der stille Killer der Überwachung. Wenn jeder kleine Aussetzer eine Benachrichtigung auslöst, hört Ihr Team auf, darauf zu achten. Sie stummschalten den Kanal. Sie ignorieren die E-Mails. Dann passiert ein echter Vorfall und niemand bemerkt es.
Verwenden Sie Alarmeskalationsschwellen. Fordern Sie 2 oder 3 aufeinanderfolgende Fehler, bevor ein Alarm ausgelöst wird. Das filtert vorübergehende Netzwerkprobleme heraus, die sich in Sekunden von selbst lösen. Eine einzelne fehlgeschlagene Prüfung ist kein Vorfall. Drei in Folge sind es.
Leiten Sie Alarme nach Schweregrad weiter. Kritische Monitore gehen an PagerDuty oder Bereitschaftstelefone. Monitore auf Warnstufe gehen an einen Slack-Kanal. Informative Monitore gehen an E-Mail oder ein Dashboard. Senden Sie nicht alles an denselben Ort.
Verwenden Sie Ruhezeiten für Wartungsarbeiten. Wenn Sie jeden Dienstag um 2 Uhr morgens deployen, unterdrücken Sie Alarme für betroffene Monitore während dieses Zeitfensters. Ihr Team weiß von dem Deployment. Es muss nicht benachrichtigt werden, weil die App neu gestartet wurde.
Trennen Sie Alarmkanäle von Diskussionskanälen. Ihr #alerts-Kanal sollte nur automatisierte Alarmmeldungen enthalten. Menschliche Diskussionen finden in #ops oder #engineering statt. Das hält den Alarm-Feed sauber und überschaubar.
Erstellen Sie eine Statusseite, die Ihre Benutzer tatsächlich aufrufen
Ihre Statusseite ist nicht nur ein Kästchen zum Abhaken. Sie ist ein Kommunikationswerkzeug, das die Support-Last während Vorfällen reduziert.
Platzieren Sie sie auf Ihrer eigenen Domain (status.ihrunternehmen.de). Passen Sie sie mit Ihrem Branding an. Verlinken Sie von Ihrer App-Fußzeile, Ihrer Support-Dokumentation und Ihren Fehlerseiten darauf.
Wenn ein Vorfall passiert, veröffentlichen Sie Updates. „Wir untersuchen Berichte über erhöhte API-Fehler” ist besser als Schweigen. „Das Problem wurde als Datenbankverbindungspool-Erschöpfung identifiziert. Wir skalieren hoch.” sagt den Benutzern, dass Sie wissen, was falsch ist. „Wir überwachen die Wiederherstellung. Die API-Latenz ist wieder normal.” schließt den Kreis.
Eine Statusseite, die automatisch aus Ihren Überwachungsdaten aktualisiert wird, bedeutet, dass Sie während eines Vorfalls keine Schalter manuell umlegen müssen. Die Seite spiegelt die Realität wider. Sie konzentrieren sich auf die Problemlösung. Erfahren Sie mehr über PingWatchdog-Statusseiten.
Überprüfen Sie Ihre Vorfälle
Verbringen Sie nach jedem Vorfall 10 Minuten damit, zu überprüfen, was passiert ist. Sehen Sie sich die Zeitleiste an. Wie lange hat es gedauert, bis es erkannt wurde? Wie lange bis zur Reaktion? Wie lange bis zur Behebung?
Diese drei Zahlen sind Ihre Kernzuverlässigkeitskennzahlen: Mean Time to Detect (MTTD), Mean Time to Respond (MTTR) und Mean Time to Resolve (MTTResolve). Verfolgen Sie sie über die Zeit. Werden Sie schneller? Langsamer?
Nutzen Sie Vorfallsdaten, um Verbesserungen zu rechtfertigen. Wenn 40 % Ihrer Vorfälle durch Datenbankverbindungsprobleme verursacht werden, ist das ein Signal, in Connection Pooling oder Read Replicas zu investieren. Wenn SSL-Zertifikatsablauf alle 90 Tage Vorfälle verursacht, automatisieren Sie die Zertifikatserneuerung.
PingWatchdog erstellt automatisch Vorfälle, wenn Monitore ausfallen, und löst sie automatisch auf, wenn Dienste sich erholen. Sie erhalten eine vollständige Zeitleiste ohne manuelle Arbeit. Erfahren Sie mehr über Vorfallsmanagement.
Schichten Sie Ihre Überwachung
Ein Tool kann nicht alles abdecken. Verwenden Sie PingWatchdog für die externe Überwachung: Uptime, SSL, Heartbeat, Statusseiten. Verwenden Sie Application Performance Monitoring (APM)-Tools wie Datadog oder Sentry für interne Metriken. Verwenden Sie Log-Aggregation für das Debugging.
Die externe Ansicht sagt Ihnen, ob Benutzer Ihren Dienst erreichen können. Die interne Ansicht sagt Ihnen, warum. Beides ist wichtig.
Überwachungstools vergleichen, um den richtigen Stack für Ihr Team zu finden.