Monitoring API: kogda HTTP 200 nedostatochno

JSON API mozhet vernut HTTP 200 s oshibkoy v tele otveta - monitoring po kodu statusa obyavit UP. Nastoyashchiy monitoring API proveryaet i soderzhimoe otveta, a ne tolko HTTP.

Problema: HTTP 200 != rabotayushchee API

Soglasno konventsiyam REST API, kody statusa nuzhno ispolzovat pravilno (200 OK, 4xx client error, 5xx server error). Na praktike:

Nekotorye API vsegda vozvrashchayut 200, oshibka nakhoditsya v JSON body
API gateway mozhet preobrazovat 5xx v 200 s error JSON
Frontend BFF endpointy chasto oborachivayut bekendy i vozvrashchayut 200, esli kommunikatsiya proshla uspeshno, dazhe esli bekend upal
GraphQL endpointy obychno vozvrashchayut 200; oshibki (errors) nakhodyatsya v massive errors[]

S tochki zreniya klassicheskogo monitoringa (HTTP kod statusa) vse v poryadke. S tochki zreniya realnogo klienta API slomalos.

Content matching: klyuchevye slova

Prosteyshee dopolnenie k HTTP monitoringu - eto sovpadenie po klyuchevomu slovu. Vy zadaete stroku, kotoraya dolzhna prisutstvovat v otvete - esli ee net, prikhodit opoveshchenie.

Primer dlya health check endpointa:

GET /api/health HTTP/1.1

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

Ustanovite keyword match na "status":"ok". Esli BD upadet i endpoint vernet "status":"degraded", monitoring eto perekhvatit.

Negative matching: chego ne dolzhno byt

Inogda poleznee proveryat, chto opredelennoy stroki NET v otvete:

"error" - oshibka v tele otveta
"maintenance" - neozhidannyy rezhim obsluzhivaniya
"deprecated" - API endpoint pomechen kak ustarevshiy (deprecated)
fragmenty SQL oshibok: "SyntaxError", "undefined", "null pointer" - protekayushchie oshibki bekenda

Prodvinutye asserty

Sovpadenie po prostomu tekstu imeet svoi predely. Dlya seryeznogo monitoringa API podkhodyat strukturirovannye asserty nad strukturoy JSON (vyrazheniya JSONPath) i mnogoshagovye sinteticheskie tranzaktsii (login -> zashchishchennyy endpoint -> logout).

ePulz.io podderzhivaet eti vozmozhnosti napryamuyu. Multi-step / API monitoring pozvolyaet svyazyvat do 10 shagov (GET/POST/PUT/PATCH/DELETE/HEAD), na kazhdom shage proveryat kod statusa, soderzhimoe i znachenie JSONPath, a takzhe sokhranyat peremennye iz otveta dlya sleduyushchikh shagov. Funktsiya dostupna na tarifakh Profi i Business i rabotaet v pervichnom regione. Dlya bolee prostykh sluchaev na bolee nizkikh tarifakh vy mozhete skombinirovat HTTP monitor s otdelnym vspomogatelnym skriptom, kotoryy otpravlyaet rezultat cherez heartbeat monitor.

Authentication v monitoringe

Monitorimyy endpoint chasto trebuet auth. Varianty:

Bearer token v zagolovke Authorization - obychno dolgozhivushchiy monitoring token bez sroka deystviya (khranite ego bezopasno)
API key v query parametre - viden v logakh, nepredpochtitelno
HMAC podpis - timestamp + URL + khesh tela, podpisannye obshchim sekretom. Samyy bezopasnyy.
mTLS - klientskiy sertifikat na storone monitoringa. Podkhodit dlya vnutrennikh API.

Preduprezhdenie o bezopasnosti: Dlya monitoringa sozdayte vydelennyy akkaunt / token s minimalnymi pravami (read-only health endpoint, ne admin token). Regulyarno rotiruyte token. Esli servis monitoringa skomprometirovan, polnyy dostup k API ne utechet.

SLO vremeni otklika

Vremya otklika API stol zhe vazhno, kak HTTP kod. Klient s timeoutom 30 s ne vidit raznitsy mezhdu "API vozvrashchaet 200 za 25 s" i "API zavershilos timeoutom". S tochki zreniya UX oba varianta plokhi.

Nastroyte:

Hard timeout - cherez 10-15 s monitoring soobshchaet DOWN
Soft threshold - vremya otklika mezhdu 500-2000 ms = warning (degraded performance)
Trendovye opoveshcheniya - opoveshchenie, esli 95-y pertsentil vremeni otklika vyros na 50 % za poslednie 24 ch

Per-endpoint monitoring

U bolshogo API desyatki endpointov. Ne monitorte tolko /health - on tozhe mozhet vrat. Opredelite 3-5 kriticheskikh endpointov:

Naibolee ispolzuemye biznes-operatsii (POST /api/orders, GET /api/dashboard)
Chitayushchiy endpoint, proveryayushchiy cache hit (bystryy otvet)
Pishushchiy endpoint s roundtrip k BD
Endpoint vneshney integratsii (vyzyvaet tretyu storonu - obnaruzhivaet sboi zavisimostey)

Monitorte kazhdyy otdelno. Pri intsidente vy tak tochno vidite, kakaya chast API upala.

Zaklyuchenie

Monitoring API nelzya svesti k HTTP kodu statusa. Kachestvennyy monitoring sochetaet status + content match + vremya otklika + per-endpoint granulyarnost + authentication, chtoby verno imitirovat realnogo klienta - a ne tolko HTTP klienta.

Monitoring API s sovpadeniem po klyuchevomu slovu

Kod statusa + klyuchevoe slovo v soderzhimom + vremya otklika + auth headers. Per-endpoint granulyarnost.

Zapustit monitoring →