Monitoryng API: koly HTTP 200 nedostatno

JSON API mozhe povernuty HTTP 200 z pomylkoyu v tili vidpovidi - monitoryng za kodom statusu ogolosyt UP. Spravzhniy monitoryng API pereviryaye y vmist vidpovidi, a ne lyshe HTTP.

Problema: HTTP 200 != pratsyuyuche API

Zgidno z konventsiyamy REST API, kody statusu treba vykorystovuvaty pravylno (200 OK, 4xx client error, 5xx server error). Na praktytsi:

Deyaki API zavzhdy povertayut 200, pomylka v JSON body
API gateway mozhe peretvoryty 5xx na 200 z error JSON
Frontend BFF endpointy chasto obgortayut bekendy i povertayut 200, yakshcho komunikatsiya proyshla uspishno, navit koly bekend vpav
GraphQL endpointy zazvychay povertayut 200; pomylky (errors) v masyvi errors[]

Z tochky zoru klasychnogo monitoryngu (HTTP kod statusu) vse garazd. Z tochky zoru realnogo kliyenta API zlamalosya.

Content matching: klyuchovi slova

Nayprostishe dopovnennya do HTTP monitoryngu - tse zbig za klyuchovym slovom. Vy zadayete ryadok, yakyy maye buty u vidpovidi - yakshcho yogo nemaye, prykhodyt spovishchennya.

Pryklad dlya health check endpointu:

GET /api/health HTTP/1.1

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

Vstanovit keyword match na "status":"ok". Yakshcho BD vpade i endpoint poverne "status":"degraded", monitoryng tse pereykhopyt.

Negative matching: chogo ne maye buty

Inodi korysnishe pereviryaty, shcho pevnogo ryadka NEMAYE u vidpovidi:

"error" - pomylka v tili vidpovidi
"maintenance" - neochikuvanyy rezhym obslugovuvannya
"deprecated" - API endpoint poznachenyy yak zastarilyy (deprecated)
fragmenty SQL pomylok: "SyntaxError", "undefined", "null pointer" - pomylky bekenda, shcho protikayut

Prosunuti aserty

Zbig za prostym tekstom maye svoyi mezhi. Dlya seryoznogo monitoryngu API pidkhodyat strukturovani aserty nad strukturoyu JSON (vyrazy JSONPath) ta bagatokrokovi syntetychni tranzaktsiyi (login -> zakhyshchenyy endpoint -> logout).

ePulz.io pidtrymuye tsi mozhlyvosti napryamu. Multi-step / API monitoryng dozvolyaye lantsyuzhyty do 10 krokiv (GET/POST/PUT/PATCH/DELETE/HEAD), na kozhnomu krotsi pereviryaty kod statusu, vmist i znachennya JSONPath, a takozh zberihaty zminni z vidpovidi dlya nastupnykh krokiv. Funktsiya dostupna na taryfakh Profi i Business ta pratsyuye v pervynnomu regioni. Dlya prostishykh vypadkiv na nyzhchykh taryfakh vy mozhete poyednaty HTTP monitor z okremym dopomizhnym skryptom, yakyy nadsylaye rezultat cherez heartbeat monitor.

Authentication u monitoryngu

Monitorovanyy endpoint chasto vymagaye auth. Varianty:

Bearer token u zagolovku Authorization - zazvychay dovgozhyvuchyy monitoryng token bez termina diyi (zberihayte yogo bezpechno)
API key u query parametri - vydno v logakh, neperevazhno
HMAC pidpys - timestamp + URL + khesh tila, pidpysani spilnym sekretom. Naybilsh bezpechnyy.
mTLS - kliyentskyy sertyfikat na botsi monitoryngu. Pidkhodyt dlya vnutrishnikh API.

Poperedzhennya pro bezpeku: Dlya monitoryngu stvorit vydilenyy akaunt / token z minimalnymy pravamy (read-only health endpoint, ne admin token). Regulyarno rotuyte token. Yakshcho servis monitoryngu skomprometovano, povnyy dostup do API ne vytreche.

SLO chasu vidpovidi

Chas vidpovidi API takyy samyy vazhlyvyy, yak HTTP kod. Kliyent z timeoutom 30 s ne bachyt riznytsi mizh "API povertaye 200 za 25 s" i "API zavershylosya timeoutom". Z tochky zoru UX obydva varianty pogani.

Nalashtuyte:

Hard timeout - cherez 10-15 s monitoryng povidomlyaye DOWN
Soft threshold - chas vidpovidi mizh 500-2000 ms = warning (degraded performance)
Trendovi spovishchennya - spovishchennya, yakshcho 95-y pertsentyl chasu vidpovidi zris na 50 % za ostanni 24 god

Per-endpoint monitoryng

U velykogo API desyatky endpointiv. Ne monitorte lyshe /health - vin tezh mozhe brekhaty. Vyznachte 3-5 krytychnykh endpointiv:

Naybilsh vykorystovuvani biznes-operatsiyi (POST /api/orders, GET /api/dashboard)
Chytalnyy endpoint, shcho testuye cache hit (shvydka vidpovid)
Zapysuyuchyy endpoint z roundtrip do BD
Endpoint zovnishnoyi integratsiyi (vyklykaye tretyu storonu - vyyavlyaye zboyi zalezhnostey)

Monitorte kozhen okremo. Pid chas intsydentu vy tak tochno bachyte, yaka chastyna API vpala.

Vysnovok

Monitoryng API ne mozhna zvesty do HTTP kodu statusu. Yakisnyy monitoryng poyednuye status + content match + chas vidpovidi + per-endpoint granulyarnist + authentication, shchob virno imituvaty realnogo kliyenta - a ne lyshe HTTP kliyenta.

Monitoryng API zi zbigom za klyuchovym slovom

Kod statusu + klyuchove slovo u vmisti + chas vidpovidi + auth headers. Per-endpoint granulyarnist.

Zapustyty monitoryng →