API jälgimine

Miks API vajab eraldi monitooringut

API ei ole lihtsalt leht asukohaga /api/. See on leping. HTTP meetodil on tähtsus – GET vs POST muudab tähendust. Päised kannavad autentimist, sisu läbirääkimist, idempotentsuse võtmeid. Päringu body on sisend. Vastuse koodil on tähendus (401 vs 403 vs 422 – igaüks räägib erineva loo). Vastuse bodyl on struktuur – JSON-radadel, millest integratsioonid sõltuvad. Tavaline uptime-kontroll, mis lihtsalt teeb GET-päringu URL-ile, jätab suurema osa viisidest, kuidas API võib mitte töötada, kahe silma vahele: vigane JSON, mis ikka tagastab 200, autentimis-endpoint, mis võtab vastu valed andmed, webhook katki läinud payload-skeemiga, endpoint, mis tagastab 200, aga sees on "status": "error".

API monitooring lahendab selle, andes sulle kontrolli iga päringu osa ja iga vastuse kontrolli üle. Konfigureerid täpselt sellise päringu, nagu teevad su integreerijad – sama meetod, samad päised, sama body, sama autentimine – ja täpselt selle, mis tähendab edu – täpsed koodid, väärtused JSON-radadel, vastuse aja künnised, suurusepiirid.

Päringu seadistamine

Iga DiagnoSEO Uptime Monitoring API monitori jaoks saad seadistada:

• HTTP-meetod: GET, POST, PUT, PATCH, DELETE, HEAD. Vali see, mida kasutavad sinu integratsioonid.
• Kohandatud päised: JSON-objektina, nt {"Authorization": "Bearer eyJ...", "X-API-Version": "2024-01-15"}. Standard OAuth-i, JWT, API-võtmete, sisu läbirääkimise testimiseks.
• Päringu keha: suvaline string – JSON, XML, vormindatud, lihttekst. Saadetakse POST/PUT/PATCH/DELETE korral.
• Basic auth: kasutajanimi ja parool, kui endpoint on sedasi kaitstud.
• Oodatavad staatusekoodid: loend või vahemik. Vaikimisi 200-399, aga saad täpsustada ühe koodi (nt täpselt 201 loomise-endpointi jaoks) või lubada kindlad koodid (nt 200,202,204).

Kontroll järgib maksimaalselt 5 ümbersuunamist, dekodeerib gzipi, parsib Content-Type'i, et tuvastada JSON. Iga kontroll salvestab tegeliku staatusekoodi, vastuse aja, suuruse ja võimaliku vea. Mitu järjestikust tõrget (seadistatav, vaikimisi 2) käivitab intsidenti.

JSON path assertsioonid

Paljude API-de jaoks pole ainult staatusekoodidest küllalt. Health-endpoint võib tagastada 200 bodyga {"status": "degraded", "db": "down"} – ikka 200, aga kindlasti tahad seda teada. Hinnainfo API võib tuua 200 bodyga, kus data.price on langenud väärtusele null. Otsingu API võib tagastada 200, kuid results: [], sest indeks on maas.

Selliste juhtumite jaoks seadista JSON path assertsioon. Sea rada (nt data.status või health.checks.db) ja oodatav väärtus (nt healthy, true või konkreetne number). Iga kontrolli ajal dekodeeritakse vastus JSON-ist, ning radalt leitud väärtust võrreldakse oodatavaga. Eriarvamus lõpetab kontrolli veaolekus, sõltumata HTTP-staatusekoodist.

Rada kasutab punktnootatsiooni koos sulgudega: data.items[0].id töötab, sama suhtes users.john.email. Asserteeritav väärtus võrreldakse stringina, seega "true" sobib bool-tüüpi true-ga ja numbrid sobivad nii stringina kui numbritena.

Autentimise mustrid

Kaks levinumat autentimise stiili töötavad kohe. Bearer-tokenite puhul (OAuth, JWT, API-võtmed) kasuta päiste välja: {"Authorization": "Bearer eyJhbGciOi..."}. Token salvestatakse monitori seadistusse ning saadetakse igal kontrollil kaasa. Basic auth'i jaoks kasuta spetsiaalseid kasutajanimi/parool välju – need salvestatakse ja kombineeritakse automaatselt standardpäisesse.

Kui autentimine nõuab iga päringu allkirjastamist või tokeni uuendamist, on asi keerulisem. Kaks mõistlikku mustrit: (1) seadista pikaaegne teenusekonto token spetsiaalselt monitooringuks või (2) loo autentimata health-endpoint, mis peegeldab päris kaitstud endpointi seisu ning jälgi seda. Enamik tänapäevaseid API-sid toetab seda juba.

Soovitatavad mustrid

• Üks monitor iga kriitilise endpointi jaoks. Ära testi kõiki – vali 5-10, mille töö katkestus tooks kaasa tõsiseid tagajärgi.
• Kasuta täpseid koode. Vaikeväärtus 200-399 on API jaoks liiga leebe. Loomise-endpoint peaks tagastama ainult 201; idempotentne ainult 200; login ainult 200 (edu) või 401 (korralik tõrge – mitte 500).
• Kombineeri staatuse- ja JSON-asserte. Koos püüavad nad kinni probleemid nii transpordis kui sisus. Ainult staatus ei leia sisuvigu; ainult JSON-assertsioon on habras redirectide puhul.
• Sea vastuseajale künnis. API degradeerumine on esimene märk sõltuvusprobleemidest. Monitor, millel rt_threshold_ms = 800, ütleb, et API aeglustub, enne kui päriselt kukub.
• Hoia body väiksena. Kontroll toimub iga minut – suured body-d raiskavad mõlema poole jaoks andmemahtu. Esinduslikud, kuid minimaalsed payloadid on piisavad.

Ühenda teiste monitori tüüpidega

Iga API endpointi jaoks kontrollib API monitor, et päring töötab. Eraldi ping- või pordimonitor kontrollib, et host on elus. SSL/domeeni kontroll sama hostinimega püüab kinni sertifikaadi ja registriga seotud probleemid. DNS-alammonitor jälgib kirje muutmist, mis võib viidata võltsimisele. Koos annavad neli monitori API-le täieliku ülevaate minimaalse kattuvusega.

Seadistus

Ava tööriist, vajuta "Lisa monitor", vali tüübiks "API". Kleebi URL. Ava Täpsemad seaded. Vali meetod, sisesta päised JSONina, lisa body kui vaja, sea basic auth kui kasutad, trüki oodatavad koodid (nt 200 või 200,201). Lisa JSON path assertsioon, kui vaja. Sea intervall ja kinnituslävi. Salvesta. Järgmisest tsüklist teeb monitor sinu API-le täpselt sellise päringu, nagu sinu integratsioon seda teeks, valideerib vastuse ning annab häire hetkega probleemide ilmnemisel.

Korduma kippuvad küsimused

• Milliseid HTTP-meetodeid saan kasutada API monitooringuks?

  GET, POST, PUT, DELETE, PATCH ja HEAD. Sea meetod monitori kohta — kirjutamise endpointide (POST/PUT/PATCH) puhul on päringu body samuti seadistatav kui JSON-string või vorm-andmed.

• Kuidas toimivad JSON-assertsioonid?

  Sa sisestad JSON-rada (nt data.status või results[0].id) ja oodatava väärtuse. Monitor võtab vastuse, parsib selle JSON-iks, eraldab raja ning võrdleb seda oodatavaga. Kui need ei klapi, kukub check läbi "assertion failed" veaga, kus näidatakse tegelikku väärtust.

• Kas saan saata autentimispäiseid?

  Jah. Kohandatud HTTP päised on seadistatavad monitori kohta — Authorization tokenid, API-võtmed, content-type, mis iganes. Päiste väärtused on andmebaasis puhkeolekus krüpteeritud. Basic Auth jaoks on spetsiaalne kasutajanimi/parool väli, mis signeerib päringu automaatselt.

• Mis siis, kui mu API tagastab 200 koos vea-payloadiga?

  Levinud muster: API tagastab HTTP 200, kuid body ütleb {"status":"error"}. Naiivne uptime-monitor arvab, et kõik on korras. Kasuta JSON-asserstiooni status == "ok", et see leitaks — assertsioon kukub läbi ja monitor annab märku DOWN-ist isegi kui HTTP-kood on 200.

• Kuidas käsitleda rate limitiga API-d?

  Sea kontrolli intervall nii, et see arvestaks API limiidiga (nt 5-minutiline intervall, kui API lubab 12 päringut/tunnis). Monitor arvestab ühe päringuna API kohta iga kontrolli kohta ühe regiooni piires. Multi-region kontrollid korrutavad päringute arvu — kasuta ainult single-regioni, kui su API on piirangutega.