API monitoring: keď HTTP 200 nestačí

V skratke: JSON API môže vrátiť HTTP 200 s telom {"status":"error","message":"DB unavailable"} - monitoring, ktorý sleduje len status kód, vyhlási "UP". Pravdivý API monitoring kontroluje aj obsah odpovede, ne len HTTP layer.

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

REST API conventions hovoria použiť status kódy správne (200 OK, 4xx client error, 5xx server error). V praxi:

• Niektoré API vracajú vždy 200, chyba je v JSON body
• API gateway môže transformovať 5xx na 200 s error JSON
• Frontend BFF endpointy často wrappujú backendy a vracajú 200 ak komunikácia prebehla, aj keď backend zlyhal
• GraphQL endpointy vždy vracajú 200, errors sú v errors[] field

Z perspektívy klasického monitoringu (HTTP status kód) je všetko OK. Z perspektívy reálneho klienta sa API rozbilo.

Content matching: kľúčové slová

Najjednoduchší doplnok HTTP monitoringu je keyword match. Definujete reťazec, ktorý musí byť v odpovedi - ak chýba, alert.

Príklad pre health check endpoint:

GET /api/health HTTP/1.1

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

Keyword match nastaviť na "status":"ok". Ak DB padne a endpoint vráti "status":"degraded", monitoring zachytí.

Negative matching: čo by malo chýbať

Niekedy je užitočnejšie kontrolovať, že určitý reťazec NEnie v odpovedi:

• "error" - chyba v body
• "maintenance" - nečakaný maintenance mód
• "deprecated" - API endpoint sa stal deprecated
• SQL error fragmenty: "SyntaxError", "undefined", "null pointer" - prosakujúce backend chyby

JSONPath alebo JQ pre štruktúrované matching

Plain text match má limity. Pre seriózny API monitoring potrebujete navigovať v JSON štruktúre:

# Body
{
  "status": "ok",
  "data": {
    "users_online": 1247,
    "queue_depth": 0
  }
}

# Pravidlá:
$.status == "ok"
$.data.queue_depth < 100
$.data.users_online > 0

Niektoré monitoring tools (vrátane ePulzio Pro plánov) podporujú JSONPath výrazy ako asercie - alert sa spustí pri prvom nesplnenom pravidle.

Multi-step API checks

Niektoré API operácie sú stateful - login + use token + logout. Single endpoint check nezistí, či celý flow funguje. Multi-step check robí:

1. POST /api/login s test credentials → extrahuje token z odpovede
2. GET /api/protected s tokenom → kontroluje content
3. POST /api/logout → kontroluje 200

Ak ktorýkoľvek krok zlyhá, alert. Toto je synthetic transaction monitoring - simulácia reálneho používateľského flow.

Authentication v monitoringu

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

• Bearer token v Authorization headeri - typicky long-lived monitoring token bez expirácie (treba bezpečne uložiť)
• API key v query parametri - viditeľný v logoch, nepreferované
• HMAC signature - timestamp + URL + body hash signed s shared secret. Najbezpečnejšie.
• mTLS - klient cert na strane monitoringu. Vhodné pre interné API.

Response time SLO

API response time je rovnako dôležitý ako HTTP kód. Klient s timeoutom 30 s nevidí rozdiel medzi "API vráti 200 za 25 s" a "API timeoutol". Z hľadiska UX oba sú zlé.

Nastavte:

• Hard timeout - po 10-15 s monitoring oznámi DOWN
• Soft threshold - response time medzi 500-2000 ms = warning (degraded performance)
• Trending alerts - alert ak 95th percentile response time stúpne o 50% v posledných 24 h

Per-endpoint monitoring

Veľké API má desiatky endpointov. Nemonitorujte len /health - aj ten môže klamať. Identifikujte 3-5 kritických endpointov:

• Najpoužívanejšie business operations (POST /api/orders, GET /api/dashboard)
• Read endpoint pre cache hit (rýchla odpoveď)
• Write endpoint s DB roundtripom
• External integration endpoint (volá tretiu stranu - detekuje výpadky závislostí)

Každý monitorujte samostatne. Pri incidente vidíte presne, ktorá časť API padla.

Záver

API monitoring nemôže byť zredukovaný na HTTP status kód. Kvalitný monitoring kombinuje status + content match + response time + per-endpoint granularitu + authentication, aby simulárne pripomínal reálneho klienta - nie len HTTP klient.