API monitoring: jak kontrolovat JSON odpověď, ne jen HTTP 200

Ve zkratce: JSON API může vrátit HTTP 200 s tělem {"status":"error","message":"DB unavailable"} - monitoring, který sleduje jen status kód, vyhlásí "UP". Pravdivý API monitoring kontroluje i obsah odpovědi, ne jen HTTP layer.

Problém: HTTP 200 != funkční API

REST API conventions říkají používat status kódy správně (200 OK, 4xx client error, 5xx server error). V praxi:

• Některé API vrací vždy 200, chyba je v JSON body
• API gateway může transformovat 5xx na 200 s error JSON
• Frontend BFF endpointy často wrappují backendy a vrací 200 pokud komunikace proběhla, i když backend selhal
• GraphQL endpointy vždy vrací 200, errors jsou v errors[] field

Z perspektivy klasického monitoringu (HTTP status kód) je všechno OK. Z perspektivy reálního klienta se API rozbilo.

Content matching: klíčová slova

Nejjednodušší doplněk HTTP monitoringu je keyword match. Definujete řetězec, který musí být v odpovědi - pokud chybí, alert.

Příklad pro health check endpoint:

GET /api/health HTTP/1.1

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

Keyword match nastavit na "status":"ok". Pokud DB padne a endpoint vrátí "status":"degraded", monitoring zachytí.

Negative matching: co by mělo chybět

Někdy je užitečnější kontrolovat, že určitý řetězec NEnie v odpovědi:

• "error" - chyba v body
• "maintenance" - nečekaný maintenance mód
• "deprecated" - API endpoint se stal deprecated
• SQL error fragmenty: "SyntaxError", "undefined", "null pointer" - prosakující backend chyby

Pokročilé asercie - roadmap

Plain text match má limity. Pro seriózní API monitoring jsou vhodné strukturované asercie nad JSON strukturou (JSONPath výrazy) a vícekrokové synthetic transakce (login -> chráněný endpoint -> logout).

JSONPath asercie a multi-step synthetic transakce jsou v roadmapě ePulz.io, ale aktuálně nejsou implementovány. Pokud je potřebujete dnes, kombinujte ePulz.io HTTP monitor s vlastním side-skriptem, který posílá výsledek přes heartbeat monitor (při selhání jednoduše neposílejte heartbeat).

Authentication v monitoringu

Monitorovaný endpoint často vyžaduje auth. Možnosti:

• Bearer token v Authorization headeru - typicky long-lived monitoring token bez expirace (treba bezpečně uložit)
• API key v query parametru - viditelný v logách, nepreferované
• HMAC signature - timestamp + URL + body hash signed s shared secret. Nejbezpečnější.
• mTLS - klient cert na straně monitoringu. Vhodné pro interní API.

Bezpečnostní upozornění: Pro monitoring vytvořte dedicated account / token s minimálními právy (read-only health endpoint, ne admin token). Token rotujte pravidelně. Pokud monitoring service má leak, neunikne celý přístup do API.

Response time SLO

API response time je stejně důležitý jako HTTP kód. Klient s timeoutem 30 s nevidí rozdíl mezi "API vrátí 200 za 25 s" a "API timeoutoval". Z hlediska UX oba jsou špatné.

Nastavte:

• Hard timeout - po 10-15 s monitoring oznámí DOWN
• Soft threshold - response time mezi 500-2000 ms = warning (degraded performance)
• Trending alerts - alert pokud 95th percentile response time stoupne o 50% v posledních 24 h

Per-endpoint monitoring

Velké API má desítky endpointů. Nemonitorujte jen /health - i ten může klamat. Identifikujte 3-5 kritických endpointů:

• Nejpoužívanější business operations (POST /api/orders, GET /api/dashboard)
• Read endpoint pro cache hit (rychlá odpověď)
• Write endpoint s DB roundtripem
• External integration endpoint (volá třetí stranu - detekuje výpadky závislostí)

Každý monitorujte samostatně. Při incidentu vidíte přesně, která část API padla.

Závěr

API monitoring nemůže být zredukován na HTTP status kód. Kvalitní monitoring kombinuje status + content match + response time + per-endpoint granularitu + authentication, aby podobně připomínal reálního klienta - ne jen HTTP klient.

API monitoring s keyword match

Status kód + keyword v obsahu + response time + auth headers. Per-endpoint granularita.

Vyzkoušet na 7 dní →