API-Monitoring: wie JSON-Antwort prüfen, nicht nur HTTP 200

Kurz gesagt: Eine JSON-API kann HTTP 200 mit einem Body von {"status":"error","message":"DB unavailable"} zurückgeben - Monitoring, das nur den Statuscode beobachtet, meldet "UP". Echtes API-Monitoring prüft auch den Inhalt der Antwort, nicht nur den HTTP-Layer.

Das Problem: HTTP 200 != funktionierende API

REST-API-Konventionen besagen, Statuscodes korrekt zu verwenden (200 OK, 4xx Client Error, 5xx Server Error). In der Praxis:

• Manche APIs geben immer 200 zurück, der Fehler steckt im JSON-Body
• Ein API-Gateway kann 5xx in 200 mit Error-JSON umwandeln
• Frontend-BFF-Endpoints wrappen oft Backends und geben 200 zurück, wenn die Kommunikation stattfand, auch wenn das Backend fehlschlug
• GraphQL-Endpoints geben immer 200 zurück, Errors sind im errors[]-Field

Aus Sicht des klassischen Monitorings (HTTP-Statuscode) ist alles OK. Aus Sicht des echten Clients ist die API kaputt.

Content Matching: Keywords

Die einfachste Ergänzung zum HTTP-Monitoring ist Keyword Match. Sie definieren eine Zeichenkette, die in der Antwort vorkommen muss - fehlt sie, Alert.

Beispiel für einen Health-Check-Endpoint:

GET /api/health HTTP/1.1

{
  "status": "ok",
  "checks": {
    "database": "ok",
    "redis": "ok",
    "queue": "ok"
  },
  "version": "1.42.3"
}

Keyword Match auf "status":"ok" setzen. Wenn die DB fällt und der Endpoint "status":"degraded" zurückgibt, fängt das Monitoring es ab.

Negative Matching: was fehlen sollte

Manchmal ist es nützlicher zu prüfen, dass eine bestimmte Zeichenkette NICHT in der Antwort vorkommt:

• "error" - Fehler im Body
• "maintenance" - unerwarteter Maintenance-Modus
• "deprecated" - API-Endpoint wurde deprecated
• SQL-Error-Fragmente: "SyntaxError", "undefined", "null pointer" - durchsickernde Backend-Fehler

Erweiterte Assertions - Roadmap

Plain-Text-Match hat Grenzen. Für ernsthaftes API-Monitoring sind strukturierte Assertions über JSON-Struktur (JSONPath-Ausdrücke) und mehrstufige synthetische Transaktionen (Login -> geschützter Endpunkt -> Logout) angebracht.

JSONPath-Assertions und mehrstufige synthetische Transaktionen sind auf der ePulz.io-Roadmap, aber derzeit nicht implementiert. Wenn Sie diese heute benötigen, kombinieren Sie einen ePulz.io HTTP-Monitor mit Ihrem eigenen Skript, das das Ergebnis über einen Heartbeat-Monitor sendet (bei Fehler einfach den Heartbeat nicht senden).

Authentifizierung im Monitoring

Der überwachte Endpoint benötigt oft Auth. Optionen:

• Bearer Token im Authorization Header - typischerweise langlebiger Monitoring-Token ohne Expiry (sicher speichern)
• API-Key im Query-Parameter - in Logs sichtbar, nicht bevorzugt
• HMAC-Signatur - Timestamp + URL + Body-Hash mit Shared Secret signiert. Sicherste.
• mTLS - Client-Cert auf Monitoring-Seite. Geeignet für interne APIs.

Sicherheitshinweis: Für Monitoring legen Sie einen dedizierten Account / Token mit minimalen Rechten an (Read-Only Health-Endpoint, kein Admin-Token). Token regelmäßig rotieren. Wenn der Monitoring-Service leakt, läuft nicht der gesamte API-Zugriff aus.

Response Time SLO

API-Response-Time ist genauso wichtig wie der HTTP-Code. Ein Client mit 30 s Timeout sieht keinen Unterschied zwischen "API gibt 200 in 25 s zurück" und "API in Timeout gelaufen". UX-mäßig sind beide schlecht.

Einrichten:

• Hard Timeout - nach 10-15 s meldet Monitoring DOWN
• Soft Threshold - Response Time zwischen 500-2000 ms = Warning (Degraded Performance)
• Trending Alerts - Alert, wenn 95th Percentile Response Time in den letzten 24 h um 50% steigt

Per-Endpoint Monitoring

Eine große API hat Dutzende Endpoints. Überwachen Sie nicht nur /health - auch der kann lügen. Identifizieren Sie 3-5 kritische Endpoints:

• Meistgenutzte Business-Operations (POST /api/orders, GET /api/dashboard)
• Read-Endpoint für Cache Hit (schnelle Antwort)
• Write-Endpoint mit DB-Roundtrip
• External-Integration-Endpoint (ruft Drittpartei auf - erkennt Ausfälle der Abhängigkeiten)

Jeden einzeln überwachen. Beim Incident sehen Sie genau, welcher Teil der API gefallen ist.

Fazit

API-Monitoring kann nicht auf den HTTP-Statuscode reduziert werden. Qualitatives Monitoring kombiniert Status + Content Match + Response Time + Per-Endpoint-Granularität + Authentifizierung, um einem echten Client zu ähneln - nicht nur einem HTTP-Client.

API-Monitoring mit Keyword Match

Statuscode + Keyword im Content + Response Time + Auth-Header. Per-Endpoint-Granularität.

Testen für 7 Tage →