API-figyelés: amikor a HTTP 200 nem elég

Egy JSON API visszaadhat HTTP 200-at hibáról szóló törzzsel - az állapotkódra figyelő monitorozás UP-ot jelez. A valódi API-figyelés a válasz tartalmát is ellenőrzi, nem csak a HTTP-t.

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

A REST API konvenciók szerint az állapotkódokat helyesen kell használni (200 OK, 4xx kliensoldali hiba, 5xx szerveroldali hiba). A gyakorlatban:

Egyes API-k mindig 200-at adnak vissza, a hiba a JSON törzsben van
Egy API gateway átalakíthatja az 5xx-et 200-zá hiba-JSON-nal
A frontend BFF végpontok gyakran becsomagolják a backendeket, és 200-at adnak vissza, ha a kommunikáció megtörtént, még akkor is, ha a backend elbukott
A GraphQL végpontok jellemzően 200-at adnak vissza; a hibák (errors) az errors[] mezőben vannak

A klasszikus monitorozás (HTTP állapotkód) szemszögéből minden rendben van. A valódi kliens szemszögéből az API tönkrement.

Tartalmi egyezés: kulcsszavak

A HTTP-figyelés legegyszerűbb kiegészítése a kulcsszó-egyezés. Megad egy szöveget, amelynek szerepelnie kell a válaszban - ha hiányzik, értesítés érkezik.

Példa egy health check végpontra:

GET /api/health HTTP/1.1

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

A kulcsszó-egyezést állítsa be "status":"ok" értékre. Ha az adatbázis kiesik, és a végpont "status":"degraded" választ ad, a monitorozás elkapja.

Negatív egyezés: aminek hiányoznia kell

Néha hasznosabb azt ellenőrizni, hogy egy bizonyos szöveg NINCS a válaszban:

"error" - hiba a törzsben
"maintenance" - váratlan karbantartási mód
"deprecated" - az API-végpontot elavultként (deprecated) jelölték meg
SQL-hibatöredékek: "SyntaxError", "undefined", "null pointer" - kiszivárgó backend-hibák

Haladó ellenőrzések

A sima szöveges egyezésnek megvannak a korlátai. A komoly API-figyeléshez a JSON-struktúra fölötti strukturált ellenőrzések (JSONPath-kifejezések) és a többlépéses szintetikus tranzakciók (bejelentkezés -> védett végpont -> kijelentkezés) alkalmasak.

Az ePulz.io ezeket a lehetőségeket közvetlenül támogatja. A többlépéses / API-figyelés akár 10 lépés (GET/POST/PUT/PATCH/DELETE/HEAD) láncolását teszi lehetővé, minden lépésnél ellenőrizheti az állapotkódot, a tartalmat és a JSONPath értéket, valamint változókat menthet a válaszból a további lépésekhez. A funkció a Profi és Business csomagokban érhető el, és az elsődleges régióban fut. Egyszerűbb esetekben az alacsonyabb csomagokon a HTTP monitort kombinálhatja egy különálló segédszkripttel, amely az eredményt egy heartbeat monitoron keresztül küldi.

Hitelesítés a monitorozásban

A figyelt végpont gyakran hitelesítést igényel. A lehetőségek:

Bearer token az Authorization fejlécben - jellemzően hosszú élettartamú, lejárat nélküli monitorozási token (biztonságosan kell tárolni)
API-kulcs a query paraméterben - látható a naplókban, nem ajánlott
HMAC-aláírás - időbélyeg + URL + törzs hash megosztott titokkal aláírva. A legbiztonságosabb.
mTLS - kliensoldali tanúsítvány a monitorozás oldalán. Belső API-khoz alkalmas.

Biztonsági figyelmeztetés: A monitorozáshoz hozzon létre egy dedikált fiókot / tokent minimális jogosultságokkal (csak olvasható health végpont, nem admin token). A tokent rendszeresen forgassa. Ha a monitorozó szolgáltatás kiszivárog, nem szivárog ki a teljes API-hozzáférés.

Válaszidő SLO

Az API válaszideje ugyanolyan fontos, mint a HTTP-kód. A 30 másodperces időkorláttal rendelkező kliens nem lát különbséget az "API 25 másodperc alatt ad 200-at" és az "API időtúllépéssel végződött" között. UX szempontból mindkettő rossz.

Állítsa be:

Kemény időkorlát - 10-15 másodperc után a monitorozás DOWN-t jelez
Lágy küszöb - 500-2000 ms közötti válaszidő = figyelmeztetés (csökkent teljesítmény)
Trendértesítések - értesítés, ha a válaszidő 95. percentilise 50%-kal nő az elmúlt 24 órában

Végpontonkénti figyelés

Egy nagy API-nak több tucat végpontja van. Ne csak a /health végpontot figyelje - az is hazudhat. Azonosítson 3-5 kritikus végpontot:

A leggyakrabban használt üzleti műveletek (POST /api/orders, GET /api/dashboard)
Cache hitet tesztelő olvasási végpont (gyors válasz)
Adatbázis-körfordulóval rendelkező írási végpont
Külső integrációs végpont (harmadik felet hív - észleli a függőségek kieséseit)

Mindegyiket külön figyelje. Egy incidens során így pontosan látja, az API melyik része esett ki.

Összegzés

Az API-figyelést nem lehet a HTTP-állapotkódra leszűkíteni. A minőségi monitorozás kombinálja az állapotot + tartalmi egyezést + válaszidőt + végpontonkénti részletességet + hitelesítést, hogy hűen utánozza a valódi klienst - ne csak a HTTP-klienst.

API-figyelés kulcsszó-egyezéssel

Állapotkód + kulcsszó a tartalomban + válaszidő + hitelesítési fejlécek. Végpontonkénti részletesség.

Monitorozás indítása →