API monitoring: když HTTP 200 nestačí

JSON API může vrátit HTTP 200 s tělem o chybě - monitoring na stavový kód vyhlásí UP. Skutečný API monitoring kontroluje i obsah odpovědi, nejen HTTP.

Problém: HTTP 200 ≠ funkční API

Podle konvencí REST API se mají stavové kódy používat správně (200 OK, 4xx client error, 5xx server error). V praxi:

Některá API vracejí vždy 200, chyba je v JSON body
API gateway může transformovat 5xx na 200 s error JSON
Frontend BFF endpointy často obalují backendy a vracejí 200, pokud komunikace proběhla, i když backend selhal
GraphQL endpointy typicky vracejí 200; chyby (errors) jsou v poli errors[]

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

Content matching: klíčová slova

Nejjednodušším doplňkem HTTP monitoringu je shoda klíčového slova. Definujete řetězec, který musí být v odpovědi - pokud chybí, přijde upozornění.

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 nastavte na "status":"ok". Pokud DB spadne a endpoint vrátí "status":"degraded", monitoring to zachytí.

Negative matching: co by mělo chybět

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

"error" - chyba v body
"maintenance" - nečekaný režim údržby
"deprecated" - API endpoint byl označen jako zastaralý (deprecated)
fragmenty SQL chyb: "SyntaxError", "undefined", "null pointer" - prosakující backend chyby

Pokročilé asercie

Prostá shoda textu má své 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).

ePulz.io tyto možnosti podporuje přímo. Multi-step / API monitoring umožňuje řetězit až 10 kroků (GET/POST/PUT/PATCH/DELETE/HEAD), u každého kroku ověřit stavový kód, obsah i JSONPath hodnotu a ukládat proměnné z odpovědi pro další kroky. Funkce je dostupná na plánech Profi a Business a běží na primárním regionu. Pro jednodušší případy na nižších plánech můžete HTTP monitor zkombinovat se samostatným pomocným skriptem, který posílá výsledek přes heartbeat monitor.

Autentizace v monitoringu

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

Bearer token v Authorization hlavičce - typicky long-lived monitorovací token bez expirace (je třeba ho bezpečně uložit)
API klíč v query parametru - viditelný v logech, nepreferované
HMAC signature - timestamp + URL + hash body podepsaný sdíleným tajemstvím. Nejbezpečnější.
mTLS - klientský certifikát na straně monitoringu. Vhodné pro interní API.

Bezpečnostní upozornění: Pro monitoring vytvořte dedikovaný účet / token s minimálními právy (read-only health endpoint, ne admin token). Token pravidelně rotujte. Pokud monitorovací služba unikne, neunikne celý přístup do API.

SLO času odezvy

Čas odezvy API 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 skončilo timeoutem". Z hlediska UX jsou oba špatné.

Nastavte:

Hard timeout - po 10-15 s monitoring oznámí DOWN
Soft threshold - čas odezvy mezi 500-2000 ms = warning (degraded performance)
Trendová upozornění - upozornění, pokud 95. percentil času odezvy stoupne o 50 % za posledních 24 h

Per-endpoint monitoring

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

Nejpoužívanější business operace (POST /api/orders, GET /api/dashboard)
Čtecí endpoint testující 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 tak přesně vidíte, která část API spadla.

Závěr

API monitoring nelze zredukovat na HTTP stavový kód. Kvalitní monitoring kombinuje status + content match + čas odezvy + per-endpoint granularitu + autentizaci, aby věrně napodoboval reálného klienta - nejen HTTP klienta.

API monitoring se shodou klíčového slova

Stavový kód + keyword v obsahu + čas odezvy + auth hlavičky. Per-endpoint granularita.

Spustit monitoring →