Nástroj pro monitorování API: validace endpointů a analýza textu
Nástroj pro monitorování API od HostTracker vám umožní nastavit pravidla pro obsah, který se z vašich endpointů stahuje. Při první kontrole ověří, že je typ obsahu platný. Poté vyhledá zadané hodnoty v obsahu odpovědi.
Ověřte více než dostupnost - zkontrolujte, že vaše API skutečně fungují
HostTracker kontroluje vaše API endpointy podle plánu a validuje stavový kód, typ obsahu i hodnoty uvnitř odpovědi - ne jen to, zda server odpovídá.
Proč je monitorování API důležité
Monitorování vašich API je opravdu důležité. Pomáhá vám sledovat, jak dobře fungují, jak jsou dostupná a zda dělají to, co mají. Zároveň zajišťuje, že splňují výkonnostní standardy, což pomáhá předcházet případným problémům
Dostupnost a výkon v jedné kontrole
Monitorování dostupnosti v podstatě znamená pravidelné kontrolování API endpointu, aby bylo jisté, že je k dispozici, když ho potřebujete, a že funguje dobře. Monitorování výkonu měří, jak rychle a spolehlivě API reaguje na požadavky.
Dopad spolehlivých API na byznys
To, jak dobře API fungují, může mít velký dopad na to, jak uživatelé vnímají aplikace, jak dobře fungují celkově, a dokonce i na hospodářský výsledek firmy.
Co monitor API kontroluje při každém běhu
Monitorování REST API vypadá povrchně jako monitorování dostupnosti, ale je to jiná práce. API nekonzumují lidé, ale kód, a kód je nemilosrdný způsobem, jakým prohlížeč není. Lidský návštěvník toleruje stránku, která se vykreslí trochu špatně; integrace, která dostane pole se špatným typem, se prostě rozbije. Monitorování API proto musí kontrolovat víc vrstev než jen „odpověděl server“, a HostTracker je kontroluje v pořadí, přičemž selže na první, která nedrží.
| Vrstva | Co se ověřuje | Jaké selhání odhalí |
|---|---|---|
| 1 · Dostupnost | DNS se rozpojí, TCP spojení se otevře, TLS handshake proběhne | Endpoint je pryč, certifikát vypršel, host je z části světa nedosažitelný |
| 2 · Stav | HTTP stavový kód, oproti kódům, které přijímáte, nebo které výslovně považujete za chyby | 500 po nasazení, 401 z vypršelého přihlašovacího údaje, neočekávaný 429 |
| 3 · Čas | Celková doba odezvy a její rozpad na připojení, TLS, hlavičky a tělo | Endpoint, který stále funguje, ale potichu se z 200 ms dostal na čtyři sekundy |
| 4 · Tvar | Typ obsahu a hlavičky - je to skutečně JSON, nebo chybová stránka HTML v přestrojení za 200 | Chybová stránka nebo přesměrování na přihlášení tam, kde by měl být obsah. Klasické tiché selhání API |
| 5 · Obsah | Hodnota vybraná z těla odpovědi, nebo volná validační pravidla nad celou odpovědí | Chybějící pole po změně schématu, prázdná sada výsledků, verze, která se vrátila zpátky, chybová položka objevující se v jinak úspěšné odpovědi |
Vrstvy jedna až tři jsou to, co vám dá běžná kontrola dostupnosti. Čtvrtá a pátá jsou to, co z ní dělá monitorování API - a jsou to právě vrstvy, kde se odehrává většina skutečných incidentů s API.
Nastavení požadavku
Než lze cokoli validovat, musí monitor odeslat požadavek, jaký vaše API očekává. Na monitoru API je k dispozici kompletní povrch požadavku:
| Nastavení | Co s ním můžete dělat |
|---|---|
| HTTP metoda | GET, HEAD, POST, PUT, PATCH nebo DELETE |
| Vlastní hlavičky | Libovolné dvojice jméno a hodnota, které potřebujete - bearer token, API klíč, identifikátor tenantu, hlavička verze Accept. Hlavičky se při přesměrování posílají jen na stejný host, takže přihlašovací údaj nikdy neunikne třetí straně, na kterou vás endpoint odkáže. |
| Tělo požadavku | Syrové tělo pro POST, PUT a PATCH, nebo parametry kódované jako formulář |
| HTTP autentizace | Uživatelské jméno a heslo, se schématem, které server na spojení vyžádá |
| Přesměrování | Sledovat je nebo ne, omezit, kolik se jich sleduje, nebo považovat jakékoli přesměrování rovnou za selhání - užitečné pro endpoint, který musí odpovídat přímo |
| Časový limit | Až 100 sekund, výchozí hodnota 40 - a vypršení časového limitu je selhání kontroly, což je přesně to, co chcete u endpointu se SLA |
| Limit velikosti odpovědi | Výchozí hodnota 1 MB, lze zvýšit, takže rozbíhavá odpověď nemůže spotřebovat celou kontrolu |
| Přijaté a odmítnuté stavové kódy | Seznamy kódů, které se ignorují, a kódů, které se berou jako chyby - nástroj pro endpoint, který legitimně odpovídá 401 nebo 404 jako součást svého kontraktu |
| Řízení DNS | Přeložit přes konkrétní resolvery, obejít DNS mezipaměť kontrolního bodu a ověřovat, na jaké IP adresy se host překládá |
| Přísnost TLS | Volitelně vyžadovat platný řetěz certifikátu, TLS 1.2 nebo lepší, šifry nad 128 bitů a kontrolu odvolání - plus sledování vypršení certifikátu na stejném spojení |
Validační pravidla: popis toho, jak vypadá zdravá odpověď
Nejvýraznějším způsobem, jak odpověď validovat, je napsat pro ni pravidla. Každé pravidlo je jeden řádek, pravidla se kombinují spojkou AND a jeden monitor jich může nést až dvacet. Toto je ověřený startovní balíček pro JSON API:
status isOk
header("Content-Type") contains "json"
body.json.path("$.count") gt 0
time lt 5sČtyři řádky, a dohromady pokrývají čtyři vrstvy, na kterých záleží: endpoint odpověděl kódem 2xx,
odpověděl JSON, ne chybovou stránkou, tělo obsahuje skutečný výsledek, ne prázdný, a stihlo se to celé v
rámci rozpočtu. Mezi jednotlivě užitečná pravidla ze stejného katalogu patří
body.json.path("$.status") eq "ok" pro vlastní verdikt zdraví API,
body.json.path("$.error") absent pro chybovou položku objevující se v jinak úspěšné
odpovědi, body.json.path("$.version") eq "2.4.1" pro odhalení nechtěného návratu na starší
verzi, redirects.count eq 0 pro endpoint, který by měl odpovídat přímo, a
cert.days.left gt 14 pro certifikát na stejném spojení.
O čem pravidlo umí mluvit
Pravidla čtou subjekty z odpovědi a porovnávají je. Subjekty pokrývají stavový kód; celkovou dobu
odezvy a její složky pro spojení, TLS, DNS, hlavičky a tělo; syrové tělo spolu s jeho velikostí a
hashem; strukturované dotazy do těla jako JSON, XML, HTML nebo YAML; jednotlivé hlavičky odpovědi;
konečnou i původní URL a jejich části; řetěz přesměrování, hop po hopu; zbývající dny platnosti
certifikátu, vydavatele a jména; vyjednaný protokol TLS a šifru; adresy, které vrátil DNS; a
Set-Cookie. Porovnání jdou od zjevných - rovná se, menší než, větší než - přes
contains, startsWith, endsWith, matches pro
regulární výraz, containsAny a containsAll pro množinu, in pro
seznam přijatelných hodnot a exists, isNumber a unique.
Existuje i osa detekce změn: pravidlo dokáže porovnat hodnotu z tohoto běhu s hodnotou z předchozího, takže můžete ověřit, že se čítač nikdy nevrací zpět nebo že se hash těla nezměnil - tvar pravidla, který odhalí tichý návrat na starší verzi nebo neautorizovanou změnu obsahu spíš než výpadek.
Vytažení jedné hodnoty z těla odpovědi
Vedle jazyka pravidel existuje jednodušší cesta s jedinou hodnotou, která je součástí monitorování API tady už dlouho a často je to vše, co kontrola potřebuje. Řeknete monitoru, jak má tělo parsovat, jak z něj vybrat jednu hodnotu a jaká tato hodnota musí být:
- Parsovat jako JSON, a selektorem je výraz JSONPath.
- Parsovat jako XML, a selektorem je výraz XPath - díky čemuž je jednoduché kontrolovat SOAP a další XML služby.
- Brát to jako prostý text, a selektorem je víceřádkový, na velikosti písmen nezávislý regulární výraz.
Predikát aplikovaný na vybranou hodnotu pokrývá rovná se a nerovná se, menší-než a větší-než v ostré i inkluzivní podobě, členství v seznamu přijatelných hodnot nebo vyloučení z něj, uvnitř číselného rozsahu nebo mimo něj, a test na to, zda je hodnota null nebo úplně chybí.
Poškozený selektor se odmítne při uložení, ne ve tři ráno. Selektor se kompiluje ve chvíli validace, takže překlep v JSONPath nebo XPath je chyba na formuláři, ne monitor, který od chvíle, kdy jste ho vytvořili, potichu selhává - nebo potichu prochází.
Selhání, která kontrola jen stavového kódu nevidí
Každé selhání v této tabulce vrací HTTP 200. To je celý problém s monitorováním API jen podle stavového kódu: přenos proběhl úspěšně, takže přenos hlásí úspěch.
| Co se pokazilo | Jak vypadá odpověď | Co to odhalí |
|---|---|---|
| Tam, kde má být obsah, se servíruje chybová stránka | 200, s HTML | Validace typu obsahu, nebo pravidlo, že se tělo parsuje jako JSON |
| Vyhledávací index se přestal přebudovávat | 200, s prázdným polem výsledků | Pravidlo, že počet výsledků je alespoň jeden |
| Pole bylo přejmenováno při změně schématu | 200, platný JSON, chybějící člen | Pravidlo, že pole existuje |
| Nasazení bylo vráceno zpět, aniž by si toho kdokoli všiml | 200, starší řetězec verze | Pravidlo, které fixuje pole verze |
| Chybová položka se objeví uvnitř obálky úspěchu | 200, s nastavenou chybovou položkou | Pravidlo, že chybová položka chybí |
| Navazující závislost selhává a API elegantně degraduje | 200, s částečnými nebo zastaralými daty | Pravidlo na vlastním poli zdraví API, nebo na hodnotě čerstvosti v odpovědi |
| Endpoint teď odpovídá za čtyři sekundy místo dvou set milisekund | 200, nakonec | Pravidlo na dobu odezvy |
| Autentizace se potichu přestala uplatňovat | 200, vrací data, která by neměl | Vyhrazený negativní monitor - neautentizovaný požadavek, který musí vrátit 401 |
Ten poslední řádek stojí za to udělat úmyslně. Druhý monitor, který neposílá žádné přihlašovací údaje a ověřuje 401, je nejlevnější způsob, jak zjistit, že se autorizační vrstva náhodou vypnula - selhání, které žádné množství pozitivního testování nikdy neodhalí.
Kontrola z více než 300 lokalit, bez falešných poplachů
Monitory API běží z veřejné flotily kontrolních bodů HostTracker - více než 300 kontrolních bodů ve 158 městech - a vy si vybíráte, které lokality daný monitor používá. Geografie je u API důležitější než u webu: endpoint za CDN nebo geo-směrovaným load balancerem může být zdravý ve Frankfurtu a nefunkční v São Paulu, a kontrola z jediné lokality to nemá jak vidět. Totéž platí pro DNS - zastaralý nebo špatně nastavený záznam se často šíří nerovnoměrně, což zevnitř vypadá jako přerušovaný výpadek a zvenčí jako regionální.
Spouštění z mnoha míst přináší zjevné riziko: víc kontrolních bodů, víc příležitostí, aby jedna nespolehlivá síťová trasa vyvolala planý poplach. HostTracker to řeší potvrzovacím kvórem. Když kontrolní bod nahlásí selhání, kontrola se zopakuje na dalších nezávislých kontrolních bodech a změna stavu se potvrdí, teprve když se na ní shodnou - ve výchozím stavu verdikt většiny z až sedmi agentů, s minimem tří. Můžete to zpřísnit a vyžadovat, aby selhání nahlásil konkrétní počet agentů, nebo aby se shodli úplně všichni, pro endpoint, kde je falešné hlášení horší než pomalá odpověď.
Po potvrzení se upozorňování řídí zpožděním, které si zvolil každý kontakt - okamžitě, nebo po 3, 5, 15, 30 či 60 minutách, nebo po 3, 6, 12 či 24 hodinách nepřetržitého selhávání - napříč devíti notifikačními kanály: e-mail, SMS, hlasový hovor, webhook, Slack, web push a messengery Telegram, Discord a Viber. Webhook je způsob, jakým se upozornění dostane do nástroje pro řešení incidentů nebo týmového chatu.
REST, GraphQL, SOAP a příjemci webhooků
Kontrola je konfigurovatelný HTTP požadavek plus analýza odpovědi, takže z toho přímo plyne, na co se hodí.
- REST a JSON API jsou běžný případ a REST monitorování API je to, co si většina účtů nastaví jako první: GET nebo POST, hlavičky pro přihlašovací údaj a pravidla JSONPath nebo validační pravidla nad tělem.
- GraphQL funguje jako POST s dotazem v těle a poté JSONPath do
data- a stojí za to ověřit, že chybí položkaerrors, protože GraphQL je proslulý tím, že odpovídá 200 i s chybami uvnitř. - SOAP a XML služby jsou POST s obálkou jako tělem a XPath jako selektorem, který se do odpovědi dostane přesně tak, jak zamýšlí specifikace.
- Příjemci webhooků a callback endpointy lze kontrolovat na dostupnost a na odpověď, kterou dají na dobře formovaný požadavek - cenné proto, že příjemce, který potichu přestal přijímat doručení, nevytvoří chybu nikde ve vašem vlastním systému.
- Health a readiness endpointy jsou ze všech nejcennějším cílem, pokud je máte: vaše aplikace už sama ví, zda jsou její závislosti zdravé, a pravidlo na tomto verdiktu promění vlastní znalost aplikace v upozornění.
Co se nehodí, je posloupnost - získat token, použít ho a poté smazat prostředek. Monitor API odešle jeden požadavek na běh. Pro skutečnou vícekrokovou cestu je nástrojem prohlížečem řízená kontrola transakce; pro časování stránky místo endpointu viz časování přístupu z prohlížeče a načítání stránek.
Nastavení prvního monitoru API
- Nejprve endpoint vyzkoušejte pomocí bezplatné okamžité HTTP kontroly - bez přihlášení - abyste viděli stav, časování i odpověď, proti kterým chystáte psát pravidla.
- Přidejte monitor a vyberte typ monitorování API. Nastavte metodu a přidejte hlavičky nebo tělo, které endpoint potřebuje; vydejte monitoru vlastní přihlašovací údaj místo opakovaného použití osobního.
- Napište validační pravidla. Začněte čtyřřádkovým balíčkem výše - stav, typ obsahu, jedna smysluplná hodnota z těla a rozpočet na dobu odezvy - což je opravdu dobrý výchozí bod pro téměř jakékoli JSON API.
- Vyberte interval mezi jednou minutou a 24 hodinami. Tři minuty jsou výchozí a rozumný výchozí bod; jednu minutu si nechte na endpointy, u kterých je výpadek incidentem.
- Vyberte lokality. Dva nebo tři regiony, kde skutečně žijí vaši spotřebitelé, jsou lepší než jeden jediný, a právě to dělá regionální selhání viditelným.
- Přidejte kontakty a nastavte každému zpoždění upozornění. Ne každý potřebuje vědět o problému hned první minutu.
- Nechte to běžet den a teprve pak se podívejte na historii doby odezvy, než zpřísníte pravidlo na čas. Rozpočet nastavený podle skutečných dat vydrží; ten nastavený odhadem se nakonec umlčí.
Monitorování API vs APM a observabilita
Tyto dvě věci se doplňují a často se zaměňují. Platforma pro observabilitu nebo APM instrumentuje váš kód a řekne vám, co se stalo uvnitř požadavku. Externí monitorování API stojí mimo vaši infrastrukturu a řekne vám, co skutečně dostane spotřebitel. Obojí se vyplatí mít; ani jedno druhé nenahradí.
| Externí monitorování API | APM / observabilita | |
|---|---|---|
| Odkud se dívá | Mimo vaši infrastrukturu, přes veřejný internet | Zevnitř procesu vaší aplikace |
| Vyžaduje změny kódu | Ne - nikam se nic neinstaluje | Agent nebo SDK v každé službě |
| Vidí problémy s DNS, směrováním, TLS a CDN | Ano - jsou na cestě, kterou prochází | Ne - odehrávají se dřív, než požadavek dorazí |
| Hlásí i tehdy, když je celá platforma nedostupná | Ano - nehostujete ho vy | Často ne - to, co hlásí, je taky nedostupné |
| Vysvětlí, proč byl požadavek pomalý uvnitř vašeho kódu | Ne - vidí rozpad časování, ne váš stack | Ano - to je celý jeho smysl |
| Pokrývá endpoint, který dnes nikdo nevolal | Ano - volá ho podle harmonogramu | Ne - žádný provoz, žádná telemetrie |
Vzorec, ke kterému dospěje většina týmů, je externí monitorování pro detekci a interní telemetrie pro diagnostiku: HostTracker vám řekne, že se endpoint rozbil, odkud a proti kterému pravidlu, a vaše vlastní trasování vám řekne proč. Vedle toho často vysvětlí, proč se API zpomalilo, monitor databázových dotazů, a monitoring zátěže serveru vysvětlí stav hostu, na kterém běží.
Limity, které stojí za to znát
- Jeden požadavek na běh. Žádná výměna tokenu, žádné řetězené volání. Namiřte monitor na endpoint, jehož autentizace nevyprší, a pro situace, kdy je potřeba dokázat posloupnost, použijte kontrolu transakce.
- Dvacet validačních pravidel na monitor. V praxi bohatě dost - čtyřřádkový balíček pokryje většinu endpointů - ale stojí za to to vědět, než naplánujete stovkou pravidel psaný kontraktní test.
- Režim validačních pravidel nahrazuje starší nastavení klíčových slov a stavu. Oba modely nelze na jednom monitoru kombinovat; vyberte si jazyk pravidel, nebo starší režim klíčových slov, ne obojí.
- Žádná validace podle OpenAPI ani JSON schématu. Ověřujete konkrétní hodnoty a struktury, ne celý dokument schématu.
- Tělo požadavku má limit délky, takže velmi rozsáhlý payload POST není tvar, pro který je tato kontrola navržená.
- Je to monitorování, ne testování. Správným cílem je endpoint jen pro čtení nebo idempotentní. Monitor, který každé tři minuty z několika lokalit mění data, se nakonec sám stane příčinou incidentu, místo aby ho detekoval.
Často kladené otázky
Nástroj pro monitorování API odesílá požadavky na vaše API endpointy podle nastaveného plánu a vyhodnocuje odpověď podle pravidel, která si sami definujete - nejde jen o potvrzení, že server vůbec odpověděl. Monitorování API od HostTracker nejprve ověří, že je endpoint dostupný a vrací očekávaný HTTP stavový kód, poté zkontroluje, že typ obsahu odpovědi odpovídá očekávání (JSON, XML, prostý text a podobně), a nakonec v těle odpovědi vyhledá konkrétní hodnoty nebo vzory, které jste nakonfigurovali. Tento vrstvený přístup odhalí problémy, které by jednoduchá kontrola "je to dostupné" úplně přehlédla - endpoint může vracet běžný stavový kód 200, a přitom vracet poškozená, neúplná nebo zastaralá data kvůli chybě na backendu, selhanému databázovému dotazu nebo přerušené integraci dále v řetězci. Nastavení jasných validačních pravidel předem znamená, že monitor přesně ví, jak má zdravá odpověď pro vaše konkrétní API vypadat.
Monitorování dostupnosti webu obvykle kontroluje, zda se stránka načte a vrátí běžný HTTP stavový kód, což dobře funguje u stránek určených k prohlížení v prohlížeči. Monitorování API jde dál, protože API konzumuje kód, ne lidé, takže "funkční" odpověď musí splňovat přísnější požadavky: správný typ obsahu, platnou strukturu a správné hodnoty uvnitř dat - nejen úspěšný stavový kód. Endpoint může vrátit HTTP 200, přestože jsou skutečná data chybná, chybějící nebo poškozená, a tradiční kontroly dostupnosti to samy o sobě nezachytí, protože sledují jen stavový kód odpovědi. Monitorování API od HostTracker kontroluje obě vrstvy - dostupnost a stavový kód, stejně jako monitorování dostupnosti - a navíc validaci typu obsahu a vyhledávání očekávaných hodnot v těle odpovědi, což dává mnohem přesnější obrázek o tom, zda API skutečně funguje správně.
Ano, právě to odlišuje monitorování API od základní kontroly dostupnosti. HostTracker umožňuje nastavit validační pravidla, která jdou dál než jen potvrzení, že endpoint odpověděl: můžete určit očekávaný typ obsahu, takže kontrola selže, pokud endpoint neočekávaně začne místo JSON vracet HTML (což bývá typický příznak toho, že se místo skutečných dat servíruje chybová stránka), a můžete v obsahu odpovědi vyhledávat konkrétní hodnoty, které musí být přítomny, aby se odpověď považovala za zdravou. To znamená, že kontrola může selhat, i když HTTP stavový kód vypadá naprosto normálně - odhalí tak případy, kdy chyba na backendu nebo přerušená navazující integrace vytvoří technicky úspěšnou, ale funkčně chybnou odpověď. Právě validace skutečného obsahu, nejen konektivity, dělá monitorování API smysluplným pro endpointy, na kterých závisí další systémy.
Poté, co HostTracker potvrdí, že endpoint odpovídá a typ obsahu odpovídá očekávání, monitorování API vyhledá ve vráceném obsahu konkrétní hodnoty nebo textové vzory, které jste nastavili jako součást validačního pravidla kontroly. Díky tomu si můžete ověřit, že odpověď obsahuje konkrétní pole, stavovou hodnotu nebo údaj, který potvrzuje, že endpoint funguje správně - například že odpověď health-check endpointu obsahuje očekávanou stavovou hodnotu, a ne chybovou zprávu zabalenou do odpovědi 200. Pokud očekávaný obsah nenajde, kontrola se označí jako neúspěšná, přestože samotné spojení proběhlo v pořádku, a vy dostanete upozornění přes nastavené notifikační kanály. Tento typ kontroly citlivé na obsah je obzvlášť užitečný pro odhalování dílčích výpadků, kdy je API technicky dostupné, ale potichu vrací neúplná nebo nesprávná data.
Frekvence kontrol je nastavitelná a placené plány HostTracker podporují u všech typů monitorování intervaly až jednou za minutu, takže API endpointy klíčové pro dostupnost vaší aplikace lze kontrolovat téměř nepřetržitě. Trvale bezplatný plán spouští kontroly každých 30 minut až na dvou monitorech, což je rozumná frekvence pro méně kritická nebo interní API, kde krátké zpoždění při odhalení problému nic nestojí. U byznysově kritických API - těch, která pohánějí ostrou aplikaci, platební proces nebo integraci, na niž spoléhají vaši zákazníci - kratší intervaly znamenají, že se problémy odhalí a vyřeší dřív, než přerostou ve větší výpadek, kterého si všimnou i uživatelé. 30denní zkušební verze se všemi funkcemi, kontrolami každou minutu a bez nutnosti zadávat platební kartu vám umožní ověřit, jak rychlé odhalení vaše konkrétní API potřebuje.
Ano. Monitor API dokáže poslat cokoli, co endpoint pro přijetí požadavku vyžaduje: libovolné vlastní hlavičky - tak se dodává bearer token, hlavička s API klíčem nebo identifikátor tenantu - plus uživatelské jméno a heslo pro HTTP autentizaci, tělo požadavku pro POST, PUT nebo PATCH a jakoukoli HTTP metodu od GET a HEAD přes POST, PUT, PATCH až po DELETE. Praktická rada je stejná jako u jakéhokoli automatizovaného klienta: vydejte monitoru vlastní přihlašovací údaj místo opakovaného použití osobního, dejte mu nejužší rozsah oprávnění, který ještě smysluplně otestuje endpoint, a upřednostněte endpoint jen pro čtení nebo vyhrazenou health-route před čímkoli, co mění data. Pokud jsou vaše tokeny krátce platné, namiřte monitor na endpoint, jehož autentizace nevyprší - health nebo status route chráněnou dlouhodobě platným klíčem - místo snahy přimět monitor k výměně tokenu, kterou nemá jak provést.
Kontroly API běží v intervalu od jedné minuty do 24 hodin - 1, 2, 3, 5, 10, 15, 30 a 45 minut, poté 1, 2, 4, 6, 12 a 24 hodin - a nový monitor má ve výchozím stavu tři minuty. Běží z veřejné flotily kontrolních bodů HostTracker, která pokrývá více než 300 kontrolních bodů ve 158 městech, a vy si vybíráte, které lokality daný monitor používá. Spouštění z více regionů je u API důležitější než u webu: endpoint za CDN nebo geo-směrovaným load balancerem může být v jednom regionu naprosto zdravý a v jiném nefunkční, a kontrola z jediné lokality to prostě nemůže vidět. Řídí se tím i kontrola falešných poplachů - když jeden kontrolní bod nahlásí selhání, kontrola se zopakuje z dalších nezávislých kontrolních bodů a změna stavu se potvrdí, teprve když se na ní shodne kvórum, takže jedna nespolehlivá síťová trasa mezi datovým centrem a vaším hostitelem nikoho nezaláme.
Když kontrola API selže - ať už proto, že endpoint neodpověděl, vrátil neočekávaný typ obsahu, nebo neobsahoval hodnoty vyžadované vaším validačním pravidlem - HostTracker odešle upozornění přes kterýkoli z 9 nastavených notifikačních kanálů, včetně e-mailu, SMS, hlasového hovoru, webhooků, Slacku a messengerových aplikací jako Telegram, Discord a Viber. Váš tým se tak o rozbitém nebo degradovaném API dozví ve chvíli, kdy je problém odhalen, místo aby se o něm dozvěděl přes ticket podpory poté, co integrace potichu selhávala už celé hodiny. Protože kontrola vyhodnocuje dostupnost i obsah zároveň, upozornění odráží skutečný funkční problém API, a ne jen krátký výpadek spojení, což pomáhá předejít jak přehlédnutým incidentům, tak zbytečnému šumu.
Objevte další možnosti monitorování HostTracker
Simulujte vícekrokové scénáře objednávky a přihlášení
Modelujte skutečné cesty uživatelů – přihlášení, vyhledávání, dokončení objednávky – a nechte se upozornit ve chvíli, kdy se některý krok scénáře přeruší nebo stránka přestane správně reagovat.
Sledujte reálnou rychlost načítání stránek z více než 300 lokalit
Automatizujte skutečnou návštěvu vaší stránky v prohlížeči a měřte dobu načítání podle vámi nastavené politiky, takže se zpomalení projeví dřív, než návštěvníci začnou odcházet.
Projděte si všechny funkce sledování HostTracker
Porovnejte všech 8 typů sledování vedle sebe a zkombinujte kontroly, které se hodí právě pro váš web.
Monitorujte své API endpointy 24/7
Vyzkoušejte zdarma a nechte se upozornit ve chvíli, kdy endpoint vrátí špatný status, poruší svůj kontrakt nebo zpomalí.
Součást služby pro monitorování webů HostTracker.