API-valvonta tarkoittaa, että API:llesi lähetetään oikeita pyyntöjä säännöllisin väliajoin ja tarkistetaan, että vastaukset ovat oikein, eikä vain sitä, että palvelin vastasi. API, joka palauttaa 200 OK -vastauksen tyhjällä listalla, virheilmoituksella rungossa tai kymmenen sekunnin viiveellä, on rikki siitä riippuville sovelluksille, vaikka yksinkertainen tarkistus menisi läpi. Tämä tarkistuslista käy läpi, mitä kannattaa määrittää, jotta API-valvontasi huomaa todelliset ongelmat.
1. Valitse päätepisteet
Älä valvo kaikkea. Valvo sitä, mistä käyttäjät ja integraatiot ovat riippuvaisia:
Health- tai status-päätepiste, jos se tarkistaa riippuvuudet, kuten tietokannan. Health-päätepiste, joka vain palauttaa ”ok” tarkistamatta mitään, kertoo vähän.
Tunnistautuminen: päätepiste, joka myöntää tokeneita tai vahvistaa istuntoja. Jos se pettää, kaikki pettää.
Keskeiset lukupäätepisteet: ne, joita sovelluksesi kutsuu joka näkymässä, kuten tilausten listaus tai profiilin haku.
Kriittiset kirjoituspolut: kassa, rekisteröityminen tai webhook-vastaanottimet, valvottuina testidatalla. Polkuvalvonta ajaa tällaisen API-kutsujen sarjan vaihe vaiheelta, kuljettaa arvoja, kuten tokenin tai tilausnumeron, vaiheesta seuraavaan ja pitää salaisuudet suojattuina.
Kolmansien osapuolten API:t, joista olet riippuvainen, kuten maksu- tai toimituspalvelut, jotta tiedät, milloin ongelma ei ole sinun. Uptimecheckin kolmansien osapuolten valvonta seuraa 31 palvelun, kuten Klarnan, Shopifyn ja Cloudflaren, tilasivuja tai mitä tahansa Statuspagessa ylläpidettyä sivua.
2. Määritä pyyntö: metodi, otsakkeet ja runko
Tarkistuksen pitäisi näyttää oikean asiakkaan pyynnöltä:
Metodi: GET lukuihin, POST, PUT tai PATCH päätepisteisiin, jotka niitä vaativat.
Otsakkeet: Accept: application/json, Content-Type pyynnöille, joissa on runko, sekä API:si vaatimat omat otsakkeet, kuten versio-otsake.
Runko: pieni, kelvollinen hyötykuorma POST-pyynnöille, esimerkiksi hakukysely.
Valitse pyyntöjä, jotka on turvallista toistaa joka minuutti. Vältä päätepisteitä, jotka luovat oikeita tilauksia, lähettävät sähköposteja tai veloittavat kortteja, ellet käytä erillistä testitiliä.
3. Hoida tunnistautuminen
Useimmat API:t vaativat tunnistetiedot. Vaihtoehdot:
Basic auth yksinkertaisille suojatuille päätepisteille.
API-avain tai bearer-token otsakkeessa, esimerkiksi Authorization: Bearer <token>.
Luo valvontaa varten erillinen tili tai token, jolla on vain lukuoikeudet. Se rajaa vahinkoja, jos token vuotaa, ja pitää valvontaliikenteen lokeissa erillään. Muista, että tokenit vanhenevat. Pitkäikäinen, vain lukuoikeuksin varustettu valvontatoken estää väärät hälytykset, kun lyhytikäinen token vanhenee.
4. Tarkista tilakoodi
Päätä, mitkä tilakoodit tarkoittavat onnistumista. Yleensä se on 200, 201 tai 204 päätepisteestä riippuen. Suhtaudu uudelleenohjauksiin varoen: API, joka yhtäkkiä ohjaa kirjautumissivulle, palauttaa 3xx-koodin ja sen jälkeen 200-vastauksen HTML:nä. Se on katko jokaiselle sovellukselle, joka odottaa JSONia.
5. Tarkista vastauksen sisältö
Tässä useimmat API-tarkistukset jäävät vajaiksi. Tarkista, että vastauksessa on jotain, minkä vain toimiva API palauttaisi:
Kenttä, jonka pitäisi aina olla mukana, kuten ”status”:”ok” tai ”id”.
Tunnettu arvo testidatasta.
Virhetekstin, kuten ”error”, puuttuminen.
Uptimecheckissä määrität jokaiselle API-valvonnalle odotetut tilakoodit, avainsanan ja JSON-tarkistukset, esimerkiksi että $.status on ok tai että otsake on olemassa, sekä metodin, otsakkeet (myös basic auth tai bearer-token) ja rungon.
6. Aseta vasteajan raja-arvot
API:lle hidas on uusi alhaalla. Mobiilisovellukset aikakatkaisevat ja integraatiot yrittävät uudelleen, mikä lisää kuormaa entisestään. Tallenna vasteaika jokaisessa tarkistuksessa ja aseta raja sen mukaan, mikä on normaalia:
Katso viikon vasteajat löytääksesi perustason.
Aseta hälytysraja selvästi normaalin vaihtelun yläpuolelle, esimerkiksi kaksi tai kolme kertaa tavallinen vasteaika.
Hälytä jatkuvasta hitaudesta, ei yksittäisistä piikeistä. Yksi hidas pyyntö on kohinaa, sarja hitaita on ongelma.
Uptimecheckissä asetat jokaiselle valvonnalle hitaan vasteen rajan, ja saat hälytyksen, kun kolme peräkkäistä tarkistusta on sitä hitaampia, sekä toisen, kun vaste nopeutuu taas.
Tarkistaminen useammalta kuin yhdeltä alueelta näyttää, onko hitaus maailmanlaajuista vai rajoittuuko se yhteen verkkoreittiin. Uptimecheck tarkistaa Tukholmasta, Lontoosta ja New Yorkista ja jakaa jokaisen vasteajan DNS:ään, yhteyden muodostukseen, TLS:ään, palvelimeen ja lataukseen, joten näet, milloin hitaus alkaa ja mihin aika kuluu.
7. Valvo koko ketjua
API pettää harvoin yksin. Lisää valvonnat sille, mistä se on riippuvainen:
API:n isäntänimen SSL-varmenteet. Vanhentunut varmenne rikkoo kaikki asiakkaat kerralla.
API-verkkotunnuksen DNS-tietueet.
API-palvelinten palvelinresurssit, kuten suoritin, muisti ja levy.
Ajastetut työt, jotka pitävät datan ajan tasalla, heartbeat-valvonnalla.
8. Ohjaa hälytykset oikeille ihmisille
API-hälytykset kuuluvat yleensä palvelusta vastaaville kehittäjille. Lähetä ne tiimin chat-kanavalle ja tuotannon yöllisiä katkoja varten kanavalle, joka tavoittaa puhelimen. Syötä hälytykset webhookeilla omiin häiriönhallintatyökaluihisi. Katso ilmoitukset.
9. Automatisoi valvontojen luonti
Jos julkaiset uusia palveluja usein, luo valvonnat osana julkaisua. Uptimecheckin REST API (Professional ja Business) kattaa valvonnat, huoltoikkunat ja tilapäivitykset, ja se on dokumentoitu osoitteessa app.uptimecheck.com/docs/api, joten valvonta voi olla osa julkaisuputkeasi eikä erillinen käsin tehtävä vaihe jälkikäteen. MCP-palvelimen avulla tekoälyavustajat voivat tehdä saman API-avaimella.
10. Kerro API:n käyttäjille, mitä tapahtuu
Jos muut tiimit tai asiakkaat rakentavat API:si päälle, anna heille tilasivu, jossa API on omana komponenttinaan. Silloin he eivät joudu katkosi aikana debuggaamaan omaa koodiaan.
Yleiset virheet API-valvonnassa
Vain health-päätepisteen tarkistaminen. Health-päätepisteet menevät usein läpi, vaikka varsinaiset päätepisteet pettävät, koska jokin riippuvuus on alhaalla.
Oikean käyttäjän tuotantotunnusten käyttäminen. Kun käyttäjä vaihtaa salasanansa tai lähtee, valvonta rikkoutuu. Käytä erillistä tiliä.
Rungon ohittaminen. HTML-virhesivu tilakoodilla 200 menee läpi pelkkää tilaa tarkistavasta valvonnasta.
Hälyttäminen jokaisesta hitaasta vasteesta. Yksittäiset piikit luovat kohinaa ja opettavat ihmiset sivuuttamaan hälytykset.
Riippuvuuksien unohtaminen. API on kunnossa, mutta varmenne vanheni tai DNS-tietue muuttui.
Tarkistuslista
Valitse päätepisteet: health, tunnistautuminen, keskeiset luvut, kriittiset kirjoitukset, tärkeimmät kolmansien osapuolten API:t.
Määritä jokaiselle tarkistukselle metodi, otsakkeet ja runko.
Käytä erillistä, vain lukuoikeuksin varustettua tokenia tai basic auth -tunnuksia.
Määritä odotetut tilakoodit.
Tarkista sisältö: kenttä tai arvo, jonka vain toimiva API palauttaa.
Tallenna vasteaika ja hälytä jatkuvasta hitaudesta.
Tarkista useammalta kuin yhdeltä alueelta.
Valvo API:n takana olevia SSL-varmenteita, DNS:ää, palvelimia ja ajastettuja töitä.
Ohjaa hälytykset vastuutiimille, ja tuotannolle kanava, joka tavoittaa puhelimen.
Luo valvonnat API:n kautta osana julkaisuja.
Yhteenveto
200 OK on API-tarkistuksen alku, ei loppu. Lähetä realistisia pyyntöjä, tarkista sisältö, seuraa vasteaikaa ja kata API:n takana oleva ketju.
API-valvonta omilla metodeilla, otsakkeilla, rungoilla, JSON-tarkistuksilla ja hitaan vasteen hälytyksillä sisältyy jokaiseen Uptimecheckin pakettiin. Kokeile ilmaiseksi 14 päivää, luottokorttia ei tarvita.