Wie Sie eine REST-API auf Verfügbarkeit und Antwortzeit überwachen

Die Überwachung einer REST-API unterscheidet sich grundlegend von der Überwachung einer Website. Ein erfolgreicher HTTP 200 von deiner API garantiert nicht, dass die Antwort korrekt ist, die Antwortzeit akzeptabel ist oder die Authentifizierung noch funktioniert. Dieser Leitfaden behandelt, was ein API-Monitor tatsächlich prüfen sollte, welche Schwellenwerte Probleme frühzeitig erkennen, ohne lästig zu sein, und welche stillen Fehler einfache Ping-Checks übersehen.

Die vier Dinge, die ein API-Monitor prüfen sollte

Ein nützlicher API-Monitor prüft vier Dinge bei jedem Test. Jeder erfasst eine andere Fehlerklasse, die die anderen übersehen.

Statuscode: Hat die API 200 zurückgegeben oder 500, 502 oder 503? Antwortzeit: Hat die API innerhalb eines akzeptablen Zeitfensters geantwortet? Body-Inhalt: Enthält die Antwort die erwarteten Felder? Authentifizierungsstatus: Akzeptiert die API noch die Anmeldedaten, die sie gestern akzeptiert hat? Ein Monitor, der alle vier prüft, erfasst Fehlverhalten, das ein einzelner Check übersehen würde.

Die Endpoints, die es zu überwachen lohnt

Nicht jeder API-Endpoint braucht einen Monitor. Drei Kategorien decken den Großteil des Nutzens ab.

• Ein Health-Endpoint: normalerweise /health oder /status. Er sollte 200 mit einem kleinen JSON-Payload zurückgeben, der die Datenbankverbindung und alle kritischen Abhängigkeiten bestätigt. Einfach zu überwachen, schnell fehlschlagend, wenn etwas nicht in Ordnung ist.
• Der am häufigsten genutzte echte Endpoint: derjenige, der den Großteil der Anfragen erhält. Falls dein /users/me-Endpoint 80% der Anfragen bedient, überwache ihn direkt. Wenn er ausfällt, bemerken deine Kunden das sofort.
• Der umsatzstärkste echte Endpoint: derjenige, der Zahlungen, Abonnements oder alles verwaltet, das sich direkt in Geld übersetzt. Gleicher Monitor, höhere Warnpriorität.

Antwortzeit-Schwellenwerte ohne Fehlalarme setzen

Antwortzeit-Warnungen sind die einfachste Art, einen lärmenden Monitor zu erzeugen. Ein einzelner langsamer Test während eines Deployments ist kein Signal; zehn langsame Tests hintereinander schon. Die Schwellenwert-Strategie, die funktioniert, ist perzentilbasiert, nicht absolut.

Messe die p95-Antwortzeit deines Endpoints über eine normale Woche. Stelle den Alarmschwellenwert auf das 2-fache des p95. Warnung nur, wenn drei aufeinanderfolgende Tests ihn überschreiten. Das Ergebnis ist ein Monitor, der normale Abweichungen ignoriert, aber echte Verschlechterungen erfasst. Passe den Multiplikator und die Schwellenwertanzahl im ersten Monat an, dann lass es in Ruhe.

Die stillen Fehlerzustände, die einfache Ping-Checks übersehen

Eine API kann HTTP 200 zurückgeben und trotzdem kaputt sein. Vier häufige stille Fehler zeigen sich in echten Incidents.

• Zwischengespeicherte Fehlerantworten: Die API gibt korrekt 500 zurück, wird auf einem CDN zwischengespeichert und serviert dann eine 200 mit einem veralteten Fehlerkörper.
• Falscher Content-Type: Die API gibt HTML statt JSON zurück, weil eine Debug-Middleware aktiviert blieb. Status ist 200, Body ist nicht zu parsen.
• Leerer Erfolg: Die API gibt 200 mit einem leeren Ergebnis zurück, weil die zugrunde liegende Abfrage einen Join bei einer Migration verloren hat.
• Authentifizierungsdrift: Die API gibt 200 zurück, weil der Rate-Limiter die nicht authentifizierte Anfrage elegant handhabt, aber der Body sagt « bitte anmelden ».

Authentifizierte Überwachung ohne Anmeldedaten-Lecks

Viele APIs erfordern Authentifizierung bei jedem Endpoint. Der Monitor benötigt Anmeldedaten. Zwei Muster funktionieren gut; ein häufiges Muster ist ein ernsthaftes Sicherheitsrisiko.

Gut: ein dedizierter, schreibgeschützter API-Schlüssel mit dem engstmöglichen Umfang, vierteljährlich rotiert, verschlüsselt im Überwachungstool gespeichert. Besser: eine Webhook-Signatur oder HMAC statt eines Bearer-Tokens, damit der Monitor keinen Benutzer imitieren kann. Schlecht: ein langlebiger Bearer-Token für den Produktions-Admin-Benutzer, der in die Monitor-Konfiguration eingefügt wird. Das dritte Muster erzeugt eigene Vorfälle, wenn die Anmeldedaten des Monitors austreten.

Das Basis-Setup für eine API

Fügen Sie drei Monitore pro API hinzu. Ein /health-Monitor mit 60-Sekunden-Rhythmus und 500-ms-Antwortzeitschwelle. Ein Monitor auf dem am häufigsten verwendeten echten Endpoint mit 60-Sekunden-Rhythmus und Body-Content-Assertion. Ein Monitor auf dem umsatzstärksten Endpoint mit 30-Sekunden-Rhythmus mit derselben Body-Assertion plus strafferer Antwortzeitschwelle. Gesamtmonitore: drei. Gesamtabdeckung: das meiste, was zählt. Fügen Sie spezifische Monitore für Grenzfälle hinzu, wenn sie in echten Vorfällen auftreten, nicht präventiv.