API monitorozás: hogyan ellenőrizzük a JSON választ, nem csak HTTP 200-at

Röviden: Egy JSON API visszaadhatja a HTTP 200-at {"status":"error","message":"DB unavailable"} törzzsel - a csak státuszkódot figyelő monitorozás "UP"-ot jelent. Az igazi API monitorozás a válasz tartalmát is ellenőrzi, nem csak a HTTP réteget.

A probléma: HTTP 200 != működő API

A REST API konvenciók szerint a státuszkódokat helyesen kell használni (200 OK, 4xx client error, 5xx server error). A gyakorlatban:

• Néhány API mindig 200-at ad vissza, a hiba a JSON törzsben van
• Egy API gateway átalakíthatja az 5xx-et 200-ra error JSON-nal
• A frontend BFF végpontok gyakran wrappolnak backendeket és 200-at adnak vissza, ha a kommunikáció megtörtént, akkor is ha a backend hibázott
• A GraphQL végpontok mindig 200-at adnak vissza, a hibák az errors[] mezőben vannak

A klasszikus monitorozás (HTTP státuszkód) szemszögéből minden OK. Az igazi kliens szemszögéből az API elromlott.

Content matching: kulcsszavak

A HTTP monitorozás legegyszerűbb kiegészítése a keyword match. Definiálsz egy karakterláncot, ami kötelezően a válaszban kell legyen - ha hiányzik, riasztás.

Példa health check végpontra:

GET /api/health HTTP/1.1

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

Keyword match-et állítsd "status":"ok"-ra. Ha leesik a DB és a végpont "status":"degraded"-et ad vissza, a monitorozás elkapja.

Negative matching: minek kell hiányoznia

Néha hasznosabb ellenőrizni, hogy egy bizonyos karakterlánc NINCS a válaszban:

• "error" - hiba a törzsben
• "maintenance" - váratlan maintenance mód
• "deprecated" - az API végpont deprecated lett
• SQL hiba töredékek: "SyntaxError", "undefined", "null pointer" - kiszivárgó backend hibák

Haladó assertion-ök - roadmap

A sima szöveges egyezésnek vannak korlátai. Komoly API monitoringhoz strukturált assertion-ök JSON-struktúra felett (JSONPath kifejezések) és többlépcsős szintetikus tranzakciók (login -> védett endpoint -> logout) megfelelőek.

A JSONPath assertion-ök és többlépcsős szintetikus tranzakciók az ePulz.io roadmapen vannak, de jelenleg nincsenek implementálva. Ha ma szükségesek, kombinálja az ePulz.io HTTP monitort saját mellékszkripttel, amely az eredményt egy heartbeat monitoron keresztül küldi (hiba esetén egyszerűen ne küldje a heartbeat-et).

Authentication a monitorozásban

A monitorozott végpont gyakran auth-ot igényel. Opciók:

• Bearer token az Authorization headerben - jellemzően long-lived monitoring token expiry nélkül (biztonságosan tárolni)
• API kulcs query paraméterben - látható logokban, nem előnyben részesített
• HMAC aláírás - timestamp + URL + body hash aláírva shared secrettel. Legbiztonságosabb.
• mTLS - kliens cert a monitoring oldalán. Belső API-khoz megfelelő.

Biztonsági figyelmeztetés: A monitorozáshoz hozz létre dedikált account / tokent minimális jogokkal (read-only health végpont, nem admin token). A tokent rotáld rendszeresen. Ha a monitoring service kiszivárog, nem szivárog ki a teljes API hozzáférés.

Response time SLO

Az API response time ugyanolyan fontos, mint a HTTP kód. Egy 30 s timeout-os kliens nem lát különbséget "az API 200-at ad vissza 25 s alatt" és "az API timeout-olt" között. UX szempontból mindkettő rossz.

Állítsd be:

• Hard timeout - 10-15 s után a monitoring DOWN-t jelent
• Soft threshold - response time 500-2000 ms között = warning (degraded performance)
• Trending alerts - riasztás, ha a 95-ös percentilis response time 50%-kal nő az utóbbi 24 órában

Per-endpoint monitorozás

Egy nagy API-nak tucatnyi végpontja van. Ne csak a /health-et monitorozd - még az is hazudhat. Azonosíts 3-5 kritikus végpontot:

• Leghasználtabb business műveletek (POST /api/orders, GET /api/dashboard)
• Read végpont cache hit-hez (gyors válasz)
• Write végpont DB roundtrippel
• External integration végpont (harmadik felet hív - észleli a függőségek kiesését)

Mindegyiket külön monitorozd. Incidens során pontosan látod, az API mely része esett le.

Következtetés

Az API monitorozás nem redukálható HTTP státuszkódra. A minőségi monitorozás kombinálja a státuszt + content matchet + response time-ot + per-endpoint granularitást + authentication-t, hogy egy valódi klienst utánozzon - nem csak egy HTTP klienst.

API monitoring keyword matchcsel

Státuszkód + keyword a tartalomban + response time + auth headerek. Per-endpoint granularitás.

Kipróbálás 7 napra →