API-Überwachung

Warum Ihr API eigenes Monitoring benötigt

Ein API ist nicht einfach nur eine Seite unter /api/. Es ist ein Vertrag. Die HTTP-Methode ist wichtig – GET vs. POST ändert die Semantik. Header transportieren Authentifizierung, Content-Negotiation, Idempotenzschlüssel. Der Request-Body ist die Eingabe. Der Antwortcode ist entscheidend (401 vs. 403 vs. 422 – jeder erzählt eine andere Geschichte). Der Response-Body hat eine Struktur – JSON-Pfade, auf die sich Integratoren verlassen. Ein reiner Uptime-Check, der nur die URL per GET abruft, übersieht die meisten Wege, wie ein API ausfallen kann: fehlerhaftes JSON, das trotzdem 200 zurückgibt, ein Authentifizierungs-Endpoint, der falsche Daten akzeptiert, ein Webhook mit defektem Payload-Schema, ein Endpoint, der 200, aber mit "status": "error" im Inneren zurückgibt.

API-Monitoring löst das, indem es Ihnen die Kontrolle über jeden Teil der Anfrage und jeden Teil der Antwortüberprüfung gibt. Sie konfigurieren genau denselben Call, wie Ihre Integratoren ihn auslösen – dieselbe Methode, dieselben Header, derselbe Body, dieselbe Authentifizierung – und genau das, was als Erfolg gilt: exakte Codes, Werte unter JSON-Pfaden, Schwellen für Antwortzeit, Größenlimits.

Konfiguration des Requests

Für jeden API-Monitor in DiagnoSEO Uptime Monitoring können Sie konfigurieren:

• HTTP-Methode: GET, POST, PUT, PATCH, DELETE, HEAD. Wählen Sie die Methode, die Ihre Integratoren nutzen.
• Eigene Header: als JSON-Objekt, z.B. {"Authorization": "Bearer eyJ...", "X-API-Version": "2024-01-15"}. Standard zum Testen von OAuth, JWT, API-Keys, Content-Negotiation.
• Request-Body: Beliebiger String – JSON, XML, form-encodiert, Klartext. Wird bei POST/PUT/PATCH/DELETE gesendet.
• Basic Auth: Benutzername und Passwort, falls der Endpoint so geschützt ist.
• Erwartete Statuscodes: Liste oder Bereich. Standard ist 200-399, Sie können aber auch auf einen Code beschränken (z.B. genau 201 für Create-Endpoint) oder bestimmte erlauben (z.B. 200,202,204).

Der Check folgt bis zu maximal 5 Redirects, dekodiert gzip, analysiert Content-Type zur Erkennung von JSON. Jeder Check speichert den tatsächlichen Code, die Antwortzeit, die Größe und etwaige Fehler. Mehrere aufeinander folgende Fehler (konfigurierbar, standardmäßig 2) lösen einen Vorfall aus.

JSON-Path-Assertions

Statuscodes allein reichen für viele APIs nicht aus. Ein Health-Endpoint kann 200 mit einem Body {"status": "degraded", "db": "down"} zurückgeben – immer noch 200, aber das wollen Sie definitiv wissen. Ein Preis-API kann 200 zurückgeben, bei dem data.price auf null gefallen ist. Eine Such-API kann 200 mit results: [] liefern, weil der Index ausgefallen ist.

Für solche Fälle konfigurieren Sie eine JSON-Path-Assertion. Legen Sie den Pfad fest (z.B. data.status oder health.checks.db) und den erwarteten Wert (z.B. healthy, true oder eine konkrete Zahl). Bei jedem Check wird die Antwort als JSON dekodiert und der Wert unter dem Pfad verglichen. Ein Mismatch beendet den Check mit Fail, unabhängig vom HTTP-Status.

Die Pfadsyntax ist Punktnotation mit Klammern: data.items[0].id funktioniert, ebenso users.john.email. Der asserierte Wert wird als String verglichen, sodass "true" zu bool true passt und Zahlen sowohl als String als auch als Zahl passen.

Authentifizierungs-Muster

Zwei häufigste Authentifizierungsarten funktionieren direkt out of the box. Für Bearer Tokens (OAuth, JWT, API-Keys) nutzen Sie das Header-Feld: {"Authorization": "Bearer eyJhbGciOi..."}. Der Token wird in der Monitor-Konfiguration gespeichert und bei jedem Check gesendet. Für Basic Auth nutzen Sie die dedizierten Felder Benutzer/Passwort – diese werden gespeichert und zu einem Standard-Header kombiniert.

Falls Authentifizierung pro Request signiert oder das Token erneuert werden muss, ist es komplexer. Zwei sinnvolle Muster: (1) Stellen Sie einen langlebigen Service-Account-Token speziell fürs Monitoring aus, oder (2) bieten Sie einen unauthentifizierten Health-Endpoint an, der den Status des eigentlichen geschützten Endpoints widerspiegelt und diesen überwachen Sie. Die meisten modernen APIs haben das bereits standardmäßig integriert.

Empfohlene Muster

• Ein Monitor pro kritischem Endpoint. Testen Sie nicht jeden – wählen Sie 5–10, deren Ausfall echten Schaden anrichten würde.
• Verwenden Sie exakte Codes. Default 200–399 ist zu großzügig für APIs. Der Create-Endpoint sollte exakt 201 liefern; idempotente exakt 200; Login-Endpunkt exakt 200 (Erfolg) oder 401 (wohlgeformter Fehler – nicht 500).
• Kombinieren Sie Status mit JSON-Assertion. Gemeinsam erkennen sie Regressionen der Transport- und Content-Schicht. Status allein fängt keine Content-Fehler; alleinige JSON-Assertion ist fragil bei Redirects.
• Setzen Sie eine Schwelle für Antwortzeit. API-Degradation ist ein Frühindikator für Abhängigkeits-Probleme. Ein Monitor mit rt_threshold_ms = 800 warnt, dass das API langsamer wird, bevor es ausfällt.
• Halten Sie den Body klein. Checks laufen jede Minute – große Bodys vergeuden Bandbreite auf beiden Seiten. Repräsentative, aber minimale Payloads reichen vollkommen.

Kombinieren Sie mit anderen Monitortypen

Für jeden API-Endpoint prüft ein API-Monitor, dass der Call funktioniert. Ein separater Ping- oder Portmonitor prüft, ob der Host erreichbar ist. SSL-/Domain-Checks auf denselben Hostnamen erkennen Probleme mit Zertifikat und Registrierung. Ein DNS-Submonitor überwacht Veränderungen von Records, die auf eine Manipulation hindeuten könnten. Zusammen geben vier Monitore pro API ein vollständiges Bild bei minimaler Überschneidung.

Konfiguration

Öffnen Sie das Tool, klicken Sie auf "Monitor hinzufügen", wählen Sie den Typ "API". Fügen Sie die URL ein. Öffnen Sie den Bereich "Erweitert". Wählen Sie die Methode, fügen Sie Header als JSON ein, Body wenn nötig, richten Sie Basic Auth ein, wenn Sie dies verwenden, geben Sie die erwarteten Codes an (z.B. 200 oder 200,201). Fügen Sie eine JSON-Path-Assertion hinzu, falls erforderlich. Stellen Sie Intervall und Bestätigungsgrenze ein. Speichern. Ab dem nächsten Zyklus prüft der Monitor Ihr API genauso, wie es ein Integrator tun würde, validiert die Antwort und alarmiert im Moment einer Regression.

Häufig gestellte Fragen

• Welche HTTP-Methoden kann ich für API-Monitoring verwenden?

  GET, POST, PUT, DELETE, PATCH und HEAD. Konfigurieren Sie die Methode pro Monitor – für Write-Endpoints (POST/PUT/PATCH) ist der Request-Body ebenfalls als JSON-String oder Formdaten konfigurierbar.

• Wie funktionieren JSON-Assertions?

  Sie geben einen JSON-Pfad an (z.B. data.status oder results[0].id) und den erwarteten Wert. Der Monitor holt die Antwort, parsed sie als JSON, extrahiert den Pfad und vergleicht mit dem erwarteten Wert. Bei Abweichung schlägt der Check mit dem Fehler "assertion failed" fehl und zeigt den tatsächlichen Wert an.

• Kann ich Authentifizierungs-Header senden?

  Ja. Eigene HTTP-Header sind pro Monitor konfigurierbar – Authorization-Token, API-Keys, Content-Type, was auch immer. Headerwerte werden in der Datenbank verschlüsselt gespeichert. Für Basic Auth gibt es ein eigenes Feld für Benutzername/Passwort, das die Anfrage automatisch signiert.

• Was, wenn mein API 200 mit einem Fehler-Payload zurückgibt?

  Häufiges Muster: Das API gibt HTTP 200 zurück, aber der Body enthält {"status":"error"}. Ein naiver Uptime-Monitor denkt, das System sei gesund. Nutzen Sie eine JSON-Assertion status == "ok", um das abzufangen – die Assertion schlägt fehl und der Monitor meldet DOWN, obwohl HTTP 200 anzeigt.

• Wie gehe ich mit einem API mit Rate-Limit um?

  Stellen Sie den Check-Intervall so ein, dass das API-Limit respektiert wird (z.B. 5-Minuten-Intervall, wenn das API 12 Aufrufe/Stunde erlaubt). Pro Check aus einer Region zählt der Monitor als ein API-Aufruf. Multi-Region-Checks erhöhen die Anzahl der Aufrufe – verwenden Sie Single-Region, wenn Ihr API strikte Limits hat.