Narzędzie do monitorowania API - walidacja endpointów i analiza treści
Narzędzie do monitorowania API od HostTracker pozwala ustawić reguły dotyczące treści pobieranej z Twoich endpointów. Najpierw sprawdza, czy typ treści jest prawidłowy, a następnie przeszukuje ją pod kątem konkretnych wartości.
Więcej niż dostępność - sprawdź, czy Twoje API naprawdę działa
HostTracker sprawdza Twoje endpointy API zgodnie z harmonogramem, weryfikując kod statusu, typ treści oraz wartości zawarte w odpowiedzi - a nie tylko to, czy serwer odpowiada.
Dlaczego monitorowanie API ma znaczenie
Monitorowanie API jest naprawdę istotne. Pozwala śledzić, jak dobrze działają, jak są dostępne i czy robią to, do czego zostały stworzone. Dba też o to, by spełniały standardy wydajności, co pomaga uniknąć potencjalnych problemów
Dostępność i wydajność w jednym sprawdzeniu
Monitorowanie dostępności to w zasadzie regularne sprawdzanie endpointu API, aby upewnić się, że działa wtedy, gdy go potrzebujesz, i działa dobrze. Monitorowanie wydajności polega na mierzeniu, jak szybko i niezawodnie API odpowiada na zapytania.
Wpływ niezawodnych API na biznes
To, jak dobrze działają API, może mieć duży wpływ na wrażenia użytkowników z korzystania z aplikacji, ich ogólne działanie, a nawet na wyniki finansowe firmy.
Co monitor API sprawdza przy każdym uruchomieniu
Monitorowanie API REST powierzchownie przypomina monitorowanie dostępności, ale jest zupełnie inną pracą. Z API korzysta kod, a nie ludzie, a kod jest bezlitosny w sposób, w jaki nie jest przeglądarka. Człowiek toleruje stronę, która renderuje się nieco źle; integracja, która otrzymuje pole niewłaściwego typu, po prostu się zawiesza. Dlatego monitorowanie API musi sprawdzać więcej warstw niż samo „czy serwer odpowiedział”, a HostTracker sprawdza je po kolei, kończąc niepowodzeniem na pierwszej, która zawiedzie.
| Warstwa | Co jest weryfikowane | Jaką awarię wykrywa |
|---|---|---|
| 1 · Osiągalność | DNS się rozwiązuje, połączenie TCP się otwiera, uzgadnianie TLS się kończy | Endpoint zniknął, certyfikat wygasł, host jest nieosiągalny z części świata |
| 2 · Status | Kod statusu HTTP, w odniesieniu do kodów, które akceptujesz lub jawnie traktujesz jako błędy | 500 po wdrożeniu, 401 z powodu wygasłych danych uwierzytelniających, nieoczekiwany 429 |
| 3 · Czas | Całkowity czas odpowiedzi oraz jego podział na połączenie, TLS, nagłówki i treść | Endpoint, który nadal działa, ale po cichu wydłużył się z 200 ms do czterech sekund |
| 4 · Kształt | Typ treści i nagłówki - czy to naprawdę JSON, czy strona błędu HTML ukryta pod kodem 200 | Strona błędu albo przekierowanie do logowania podane tam, gdzie powinny być dane. Klasyczna cicha awaria API |
| 5 · Treść | Wartość wybrana z danych albo dowolne asercje na całej odpowiedzi | Brakujące pole po zmianie schematu, pusty zestaw wyników, ciąg wersji, który się cofnął, pole błędu pojawiające się wewnątrz udanej odpowiedzi |
Warstwy od pierwszej do trzeciej to to, co daje zwykły test dostępności. Czwarta i piąta to to, co czyni to monitorowaniem API - i to właśnie w tych warstwach żyje większość prawdziwych incydentów API.
Konfigurowanie żądania
Zanim cokolwiek da się zweryfikować, monitor musi wykonać żądanie, którego oczekuje Twoje API. Pełna powierzchnia żądania jest dostępna na monitorze API:
| Ustawienie | Co możesz z nim zrobić |
|---|---|
| Metoda HTTP | GET, HEAD, POST, PUT, PATCH lub DELETE |
| Niestandardowe nagłówki | Dowolne pary nazwa-wartość, jakich potrzebujesz - token bearer, klucz API, identyfikator dzierżawcy, nagłówek wersji Accept. Nagłówki są przekazywane dalej wyłącznie do tego samego hosta przy przekierowaniu, więc dane uwierzytelniające nigdy nie wyciekają do strony trzeciej, do której odsyła Twój endpoint. |
| Treść żądania | Surowa treść dla POST, PUT i PATCH albo parametry zakodowane jako formularz |
| Uwierzytelnianie HTTP | Nazwa użytkownika i hasło, ze schematem żądanym przez serwer negocjowanym na połączeniu |
| Przekierowania | Podążaj za nimi lub nie, ogranicz ich liczbę albo traktuj jakiekolwiek przekierowanie jako niepowodzenie - przydatne dla endpointu, który musi odpowiadać bezpośrednio |
| Limit czasu | Do 100 sekund, domyślnie 40 - a przekroczenie limitu czasu to niepowodzenie testu, dokładnie tego oczekujesz od endpointu objętego umową SLA |
| Limit rozmiaru odpowiedzi | Domyślnie 1 MB, można go zwiększyć, dzięki czemu nadmiernie duża odpowiedź nie może zdominować testu |
| Akceptowane i odrzucane kody statusu | Listy kodów do zignorowania oraz kodów traktowanych jako błędy - narzędzie dla endpointu, który zgodnie ze swoim kontraktem prawidłowo odpowiada 401 lub 404 |
| Kontrola DNS | Rozwiązuj nazwy przez konkretne resolwery, pomiń pamięć podręczną DNS checkpointu i sprawdzaj, na jakie adresy IP rozwiązuje się host |
| Rygor TLS | Włącz wymóg prawidłowego łańcucha certyfikatu, TLS 1.2 lub nowszego, szyfrów powyżej 128 bitów oraz sprawdzania unieważnienia - a dodatkowo obserwowanie wygasania certyfikatu na tym samym połączeniu |
Asercje: opisywanie, jak wygląda zdrowa odpowiedź
Najbardziej wyrazistym sposobem walidacji odpowiedzi jest napisanie dla niej reguł. Każda reguła to jedna linijka, reguły łączy się operatorem AND, a monitor może nieść ich do dwudziestu. Oto zweryfikowany zestaw startowy dla API JSON:
status isOk
header("Content-Type") contains "json"
body.json.path("$.count") gt 0
time lt 5sCztery linijki, a razem obejmują cztery warstwy, na których zależy: endpoint odpowiedział kodem 2xx,
odpowiedział JSON-em, a nie stroną błędu, dane zawierają prawdziwy wynik, a nie pusty, i zrobił to
wszystko w ramach budżetu czasowego. Pojedynczo przydatne reguły z tego samego katalogu obejmują
body.json.path("$.status") eq "ok" dla własnego werdyktu zdrowia API,
body.json.path("$.error") absent dla pola błędu pojawiającego się w poza tym udanej
odpowiedzi, body.json.path("$.version") eq "2.4.1", by wykryć niezamierzone cofnięcie
wersji, redirects.count eq 0 dla endpointu, który powinien odpowiadać bezpośrednio, oraz
cert.days.left gt 14 dla certyfikatu na tym samym połączeniu.
O czym może mówić reguła
Reguły odczytują z odpowiedzi konkretne podmioty i je porównują. Podmioty obejmują: kod statusu;
całkowity czas odpowiedzi oraz jego składowe - połączenie, TLS, DNS, nagłówki i treść; surową treść
wraz z jej rozmiarem i skrótem (hash); strukturalne zapytania do danych jako JSON, XML, HTML lub YAML;
poszczególne nagłówki odpowiedzi; ostateczny i pierwotny adres URL oraz ich części; łańcuch
przekierowań, krok po kroku; liczbę pozostałych dni certyfikatu, jego wystawcę i nazwy; wynegocjowany
protokół TLS i szyfr; adresy zwrócone przez DNS; oraz Set-Cookie. Porównania obejmują te
oczywiste - równe, mniejsze niż, większe niż - po contains, startsWith,
endsWith, matches dla wyrażenia regularnego, containsAny i
containsAll dla zbioru, in dla listy dopuszczalnych wartości oraz
exists, isNumber i unique.
Istnieje też oś wykrywania zmian: reguła może porównać wartość z bieżącego uruchomienia z wartością z poprzedniego, dzięki czemu możesz sprawdzić, że licznik nigdy się nie cofa albo że skrót treści się nie zmienił - to kształt reguły, która wykrywa ciche cofnięcie wersji lub nieautoryzowaną zmianę treści, a nie awarię.
Wyciąganie jednej wartości z danych
Obok języka reguł istnieje prostsza, jednowartościowa ścieżka, która od dawna jest częścią monitorowania API i często jest wszystkim, czego potrzebuje test. Mówisz monitorowi, jak sparsować treść, jak wybrać z niej jedną wartość i jaka ta wartość musi być:
- Parsuj jako JSON, a selektorem jest wyrażenie JSONPath.
- Parsuj jako XML, a selektorem jest wyrażenie XPath - to właśnie dzięki temu sprawdzanie SOAP i innych usług XML jest proste.
- Traktuj jako zwykły tekst, a selektorem jest wieloliniowe, nierozróżniające wielkości liter wyrażenie regularne.
Predykat stosowany do wybranej wartości obejmuje równe i różne od, mniejsze niż i większe niż w formach zarówno ścisłych, jak i włącznych, przynależność do listy dopuszczalnych wartości lub wykluczenie z niej, mieszczenie się w zakresie liczbowym lub poza nim, a także test na to, czy wartość jest pusta (null) lub całkowicie nieobecna.
Błędnie skonstruowany selektor jest odrzucany w chwili zapisu, a nie o trzeciej nad ranem. Selektor jest kompilowany w momencie walidacji, więc literówka w JSONPath lub XPath to błąd na formularzu, a nie monitor, który po cichu zawodzi - albo po cichu przechodzi - od chwili, gdy go utworzyłeś.
Awarie, których nie zobaczy test kodu statusu
Każda awaria w tej tabeli zwraca HTTP 200. To cały problem z monitorowaniem API wyłącznie na podstawie kodu statusu: transport się powiódł, więc transport zgłasza sukces.
| Co poszło nie tak | Jak wygląda odpowiedź | Co to wykrywa |
|---|---|---|
| Podawana jest strona błędu tam, gdzie powinny być dane | 200, z HTML | Asercja typu treści albo reguła, że treść parsuje się jako JSON |
| Indeks wyszukiwania przestał się przebudowywać | 200, z pustą tablicą wyników | Reguła, że liczba wyników wynosi co najmniej jeden |
| Pole zostało przemianowane przy zmianie schematu | 200, prawidłowy JSON, brakujące pole | Reguła, że pole istnieje |
| Wdrożenie zostało wycofane, a nikt tego nie zauważył | 200, starszy ciąg wersji | Reguła przypinająca pole wersji |
| Pole błędu pojawia się wewnątrz koperty sukcesu | 200, z ustawionym polem błędu | Reguła, że pole błędu jest nieobecne |
| Zależność dalej w łańcuchu zawodzi, a API łagodnie degraduje działanie | 200, z częściowymi lub nieaktualnymi danymi | Reguła na własnym polu zdrowia API albo na wartości świeżości w danych |
| Endpoint odpowiada teraz w cztery sekundy zamiast dwustu milisekund | 200, w końcu | Reguła czasu odpowiedzi |
| Uwierzytelnianie po cichu przestało być stosowane | 200, zwracające dane, których nie powinno zwracać | Dedykowany monitor negatywny - żądanie bez uwierzytelnienia, które musi zwrócić 401 |
Ten ostatni wiersz warto zrealizować świadomie. Drugi monitor, który nie wysyła żadnych danych uwierzytelniających i sprawdza kod 401, to najtańszy sposób, by dowiedzieć się, że warstwa autoryzacji została przypadkowo wyłączona - awaria, której nigdy nie ujawni żadna ilość testów pozytywnych.
Sprawdzanie z ponad 300 lokalizacji, bez fałszywych alarmów
Monitory API działają z publicznej floty checkpointów HostTracker - ponad 300 checkpointów w 158 miastach - a Ty wybierasz, z których lokalizacji korzysta dany monitor. Geografia ma dla API większe znaczenie niż dla witryny: endpoint obsługiwany przez CDN lub load balancer z routingiem geograficznym może być sprawny we Frankfurcie, a zawodzić w São Paulo, a test z pojedynczej lokalizacji nie ma jak tego zobaczyć. To samo dotyczy DNS - nieaktualny lub błędnie skonfigurowany rekord często propaguje się nierówno, co od wewnątrz wygląda jak przerywana awaria, a z zewnątrz - jak awaria regionalna.
Uruchamianie z wielu miejsc niesie oczywiste ryzyko: więcej checkpointów, więcej okazji, by jedna niestabilna trasa sieciowa fałszywie zaalarmowała. HostTracker radzi sobie z tym za pomocą kworum potwierdzającego. Gdy checkpoint zgłasza awarię, test jest powtarzany na dodatkowych, niezależnych checkpointach, a zmiana stanu zostaje potwierdzona dopiero, gdy się zgodzą - domyślnie werdykt większościowy wśród maksymalnie siedmiu agentów, przy minimum trzech. Możesz to zaostrzyć, wymagając zgłoszenia awarii przez określoną liczbę agentów albo pełnej zgodności między nimi, dla endpointu, gdzie fałszywe powiadomienie jest gorsze niż wolne.
Po potwierdzeniu powiadomienia są wysyłane zgodnie z opóźnieniem wybranym przez każdy kontakt - natychmiast albo po 3, 5, 15, 30 lub 60 minutach, albo po 3, 6, 12 lub 24 godzinach nieprzerwanej awarii - przez dziewięć kanałów powiadomień: e-mail, SMS, połączenie głosowe, webhook, Slack, powiadomienie push w przeglądarce oraz komunikatory Telegram, Discord i Viber. To właśnie kanał webhook pozwala alertom dotrzeć do menedżera incydentów albo narzędzia czatu zespołowego.
REST, GraphQL, SOAP i odbiorniki webhooków
Test to konfigurowalne żądanie HTTP plus analiza odpowiedzi, więc to, do czego pasuje, wynika wprost z tego.
- API REST i JSON to codzienny przypadek, a monitorowanie API REST to zwykle to, co konfiguruje się jako pierwsze: GET lub POST, nagłówki z danymi uwierzytelniającymi oraz reguły JSONPath lub asercji na danych.
- GraphQL działa jako POST z zapytaniem w treści, a następnie JSONPath do
data- i warto sprawdzić, że poleerrorsjest nieobecne, ponieważ GraphQL słynie z odpowiadania 200 z błędami w środku. - Usługi SOAP i XML to POST z kopertą jako treścią i XPath jako selektorem, który sięga do odpowiedzi dokładnie tak, jak zamierza to specyfikacja.
- Odbiorniki webhooków i endpointy zwrotne (callback) można sprawdzać pod kątem osiągalności i odpowiedzi, jaką dają na poprawnie sformułowane żądanie - to cenne, bo odbiornik, który po cichu przestał przyjmować dostawy, nie generuje żadnego błędu nigdzie w Twoim własnym systemie.
- Endpointy health i readiness to cel o najwyższej wartości ze wszystkich, jeśli je masz: Twoja aplikacja już wie, czy jej zależności są zdrowe, a asercja na tym werdykcie zamienia jej własną wiedzę w alert.
Tym, co nie pasuje, jest sekwencja - pobranie tokena, użycie go, a następnie usunięcie zasobu. Monitor API wykonuje jedno żądanie na uruchomienie. Dla prawdziwej wieloetapowej podróży narzędziem jest sterowany przeglądarką test transakcji; dla czasu wczytywania strony, a nie endpointu, zobacz pomiar dostępu i czasu wczytywania w przeglądarce.
Konfiguracja pierwszego monitora API
- Najpierw wypróbuj endpoint za pomocą bezpłatnego natychmiastowego testu HTTP - logowanie nie jest wymagane - dzięki czemu zobaczysz status, czas i odpowiedź, wobec których zaraz napiszesz reguły.
- Dodaj monitor i wybierz typ monitorowania API. Ustaw metodę i dodaj nagłówki lub treść wymagane przez endpoint; wystaw monitorowi jego własne dane uwierzytelniające zamiast ponownie wykorzystywać dane osoby.
- Napisz asercje. Zacznij od czteroliniowego zestawu opisanego wyżej - status, typ treści, jedna znacząca wartość z danych i budżet czasu odpowiedzi - który jest naprawdę dobrym domyślnym wyborem dla niemal każdego API JSON.
- Wybierz interwał od jednej minuty do 24 godzin. Trzy minuty to wartość domyślna i rozsądny punkt startowy; jedną minutę zarezerwuj dla endpointów, których awaria jest incydentem.
- Wybierz lokalizacje. Dwa lub trzy regiony, w których faktycznie znajdują się Twoi konsumenci, są lepsze niż jeden, i to właśnie one sprawiają, że awaria regionalna staje się widoczna.
- Dodaj kontakty i ustaw opóźnienie alertu dla każdego z nich. Nie każdy musi dowiedzieć się o problemie w pierwszej minucie.
- Pozwól mu działać przez dzień, a następnie przejrzyj historię czasu odpowiedzi, zanim zaostrzysz regułę czasową. Budżet ustawiony na podstawie rzeczywistych danych się sprawdza; ten ustawiony na podstawie domysłu zostaje wyciszony.
Monitorowanie API a APM i observability
To rozwiązania uzupełniające się, często ze sobą mylone. Platforma observability lub APM instrumentuje Twój kod i mówi Ci, co wydarzyło się wewnątrz żądania. Zewnętrzne monitorowanie API stoi poza Twoją infrastrukturą i mówi Ci, co faktycznie otrzymuje konsument. Warto mieć oba; żadne nie zastępuje drugiego.
| Zewnętrzne monitorowanie API | APM / observability | |
|---|---|---|
| Punkt obserwacji | Poza Twoją infrastrukturą, przez publiczny internet | Wewnątrz procesu Twojej aplikacji |
| Wymaga zmian w kodzie | Nie - nic nigdzie nie jest instalowane | Agent lub SDK w każdej usłudze |
| Widzi problemy z DNS, routingiem, TLS i CDN | Tak - leżą one na trasie, którą pokonuje | Nie - dzieją się, zanim żądanie dotrze na miejsce |
| Nadal raportuje, gdy cała platforma nie działa | Tak - nie jest hostowane przez Ciebie | Często nie - to, co raportuje, też nie działa |
| Wyjaśnia, dlaczego żądanie było wolne wewnątrz Twojego kodu | Nie - widzi podział czasu, ale nie Twój stos technologiczny | Tak - to jest cały jego cel |
| Obejmuje endpoint, którego nikt dzisiaj nie wywołał | Tak - wywołuje go zgodnie z harmonogramem | Nie - brak ruchu, brak telemetrii |
Wzorzec, na którym osiada większość zespołów, to zewnętrzne monitorowanie do wykrywania i wewnętrzna telemetria do diagnozowania: HostTracker mówi Ci, że endpoint się zepsuł, skąd to widać i wobec której reguły, a Twój własny tracing mówi Ci dlaczego. Obok tego monitor zapytań do bazy danych często wyjaśnia, dlaczego API zwolniło, a monitorowanie obciążenia serwera wyjaśnia stan hosta, na którym działa.
Ograniczenia, które warto znać
- Jedno żądanie na uruchomienie. Brak wymiany tokenów, brak łańcuchowych wywołań. Skieruj monitor na endpoint, którego uwierzytelnianie nie wygasa, a gdy musisz udowodnić sekwencję, użyj testu transakcji.
- Dwadzieścia reguł asercji na monitor. W praktyce aż nadto - czteroliniowy zestaw obejmuje większość endpointów - ale warto o tym wiedzieć, zanim zaplanujesz test kontraktu ze stoma regułami.
- Tryb asercji zastępuje starsze ustawienia słów kluczowych i statusu. Tych dwóch modeli nie da się połączyć na jednym monitorze; wybierz język reguł albo starszy tryb słów kluczowych, nie oba naraz.
- Brak walidacji OpenAPI ani schematu JSON. Sprawdzasz konkretne wartości i struktury, a nie cały dokument schematu.
- Treść żądania ma limit długości, więc bardzo duże dane POST nie są kształtem, do jakiego zbudowano ten test.
- To monitorowanie, nie testowanie. Właściwym celem jest endpoint tylko do odczytu albo idempotentny. Monitor, który zmienia dane co trzy minuty z kilku lokalizacji, w końcu stanie się przyczyną incydentu, a nie narzędziem, które go wykrywa.
Najczęściej zadawane pytania
Narzędzie do monitorowania API wysyła zgodnie z harmonogramem zapytania do Twoich endpointów i ocenia odpowiedź według zdefiniowanych przez Ciebie reguł, zamiast jedynie potwierdzać, że serwer w ogóle odpowiedział. Monitorowanie API w HostTracker najpierw sprawdza, czy endpoint jest dostępny i zwraca oczekiwany kod statusu HTTP, następnie weryfikuje, czy typ treści odpowiedzi zgadza się z oczekiwanym (JSON, XML, zwykły tekst itd.), a na koniec przeszukuje treść odpowiedzi pod kątem konkretnych wartości lub wzorców, które skonfigurowałeś. Takie warstwowe podejście wychwytuje problemy, których zwykłe sprawdzenie "czy działa" całkowicie by nie zauważyło - endpoint może zwracać prawidłowy kod statusu 200, a mimo to dostarczać uszkodzone, niekompletne lub nieaktualne dane z powodu błędu w backendzie, nieudanego zapytania do bazy danych albo zepsutej integracji dalej w łańcuchu. Ustalenie jasnych reguł walidacji z góry oznacza, że monitor wie, jak faktycznie wygląda zdrowa odpowiedź dla Twojego konkretnego API.
Monitorowanie dostępności strony internetowej zwykle sprawdza, czy strona się ładuje i zwraca prawidłowy kod statusu HTTP, co dobrze sprawdza się w przypadku stron przeznaczonych do przeglądania w przeglądarce. Monitorowanie API idzie o krok dalej, ponieważ z API korzysta kod, a nie ludzie, więc "działająca" odpowiedź musi spełniać bardziej rygorystyczne wymagania: właściwy typ treści, poprawną strukturę i prawidłowe wartości wewnątrz danych, a nie tylko pomyślny kod statusu. Endpoint może zwrócić HTTP 200, mimo że faktyczne dane są błędne, brakujące lub zniekształcone, a same tradycyjne sprawdzenia dostępności tego nie wychwycą, ponieważ patrzą jedynie na kod odpowiedzi. Monitorowanie API w HostTracker sprawdza obie warstwy - dostępność i kod statusu, tak jak robi to monitorowanie uptime, a dodatkowo waliduje typ treści i przeszukuje treść odpowiedzi pod kątem oczekiwanych wartości - dając znacznie dokładniejszy obraz tego, czy API rzeczywiście działa poprawnie.
Tak, to właśnie odróżnia monitorowanie API od podstawowego sprawdzenia dostępności. HostTracker pozwala ustawić reguły walidacji, które wykraczają poza samo potwierdzenie, że endpoint odpowiedział: możesz określić oczekiwany typ treści, dzięki czemu sprawdzenie zakończy się niepowodzeniem, jeśli endpoint niespodziewanie zacznie zwracać HTML zamiast JSON (typowy objaw serwowania strony błędu zamiast prawdziwych danych), a także przeszukiwać treść odpowiedzi pod kątem konkretnych wartości, które muszą być obecne, aby odpowiedź uznać za prawidłową. Oznacza to, że sprawdzenie może zakończyć się niepowodzeniem nawet wtedy, gdy kod statusu HTTP wygląda całkowicie normalnie, co pozwala wychwycić przypadki, w których błąd backendu lub zepsuta integracja dalej w łańcuchu generuje odpowiedź technicznie poprawną, ale funkcjonalnie błędną. Weryfikacja rzeczywistej treści, a nie tylko samej łączności, sprawia, że monitorowanie API ma sens dla endpointów, od których zależą inne systemy.
Po potwierdzeniu, że endpoint odpowiada, a typ treści zgadza się z oczekiwaniami, monitorowanie API w HostTracker przeszukuje zwróconą treść pod kątem konkretnych wartości lub wzorców tekstowych, które skonfigurowałeś w ramach reguł walidacji sprawdzenia. Dzięki temu możesz potwierdzić, że odpowiedź zawiera konkretne pole, wartość statusu lub fragment danych świadczący o tym, że endpoint działa poprawnie - na przykład sprawdzić, czy odpowiedź endpointu health-check zawiera oczekiwaną wartość statusu, a nie komunikat błędu opakowany w odpowiedź 200. Jeśli oczekiwana treść nie zostanie znaleziona, sprawdzenie zostaje oznaczone jako nieudane, mimo że samo połączenie się powiodło, a Ty otrzymujesz powiadomienie za pośrednictwem skonfigurowanych kanałów. Ten rodzaj sprawdzania świadomego treści jest szczególnie przydatny do wychwytywania częściowych awarii, gdy API jest technicznie dostępne, ale po cichu zwraca niekompletne lub nieprawidłowe dane.
Częstotliwość sprawdzeń jest konfigurowalna, a płatne plany HostTracker obsługują interwały nawet co minutę we wszystkich typach monitorowania, dzięki czemu endpointy API kluczowe dla dostępności Twojej aplikacji mogą być sprawdzane niemal nieprzerwanie. Darmowy plan działa na stałe i uruchamia sprawdzenia co 30 minut dla maksymalnie dwóch monitorów, co jest rozsądną częstotliwością dla API o niższym priorytecie lub wewnętrznych, gdzie krótkie opóźnienie w wykryciu problemu niewiele kosztuje. W przypadku API krytycznych dla biznesu - takich, które napędzają działającą aplikację, proces płatności lub integrację, na której polegają Twoi klienci - krótsze interwały oznaczają, że problemy zostaną wykryte i rozwiązane, zanim przerodzą się w większą awarię zauważalną przez użytkowników. 30-dniowy okres próbny z pełnym dostępem do funkcji, sprawdzeniami co minutę i bez podawania karty kredytowej pozwala sprawdzić, jak szybkiej wykrywalności potrzebuje Twoje konkretne API.
Tak. Monitor API może wysłać wszystko, czego endpoint wymaga do zaakceptowania żądania: dowolne niestandardowe nagłówki - w ten sposób dostarczany jest token bearer, nagłówek klucza API czy identyfikator dzierżawcy (tenant) - a także nazwę użytkownika i hasło do uwierzytelniania HTTP, treść żądania dla POST, PUT lub PATCH oraz dowolną metodę HTTP, od GET i HEAD po POST, PUT, PATCH i DELETE. Praktyczna rada jest taka sama jak dla każdego zautomatyzowanego klienta: wystaw monitorowi jego własne dane uwierzytelniające zamiast ponownie wykorzystywać dane osoby, nadaj mu możliwie najwęższy zakres, który nadal sensownie testuje endpoint, i preferuj endpoint tylko do odczytu lub dedykowaną trasę health nad czymkolwiek, co zmienia dane. Jeśli Twoje tokeny są krótkotrwałe, skieruj monitor na endpoint, którego uwierzytelnianie nie wygasa - trasę health lub status chronioną długotrwałym kluczem - zamiast próbować sprawić, by monitor wykonywał wymianę tokena, do której nie ma żadnego sposobu.
Testy API działają w interwale od jednej minuty do 24 godzin - 1, 2, 3, 5, 10, 15, 30 i 45 minut, następnie 1, 2, 4, 6, 12 i 24 godziny - a nowy monitor domyślnie ustawia trzy minuty. Działają z publicznej floty checkpointów HostTracker, obejmującej ponad 300 checkpointów w 158 miastach, a Ty wybierasz, z których lokalizacji korzysta dany monitor. Uruchamianie z kilku regionów ma dla API większe znaczenie niż dla witryny: endpoint obsługiwany przez CDN lub load balancer z routingiem geograficznym może być całkowicie sprawny w jednym regionie, a zawodzić w innym, a test z pojedynczej lokalizacji po prostu tego nie zobaczy. Napędza to również kontrolę fałszywych alarmów - gdy jeden checkpoint zgłasza awarię, test jest powtarzany z innych, niezależnych checkpointów, a zmiana stanu zostaje potwierdzona dopiero, gdy zgodzi się kworum, więc jedna niestabilna trasa sieciowa między centrum danych a Twoim hostem nikogo nie alarmuje.
Gdy test monitorowania API zakończy się niepowodzeniem - niezależnie od tego, czy endpoint nie odpowiedział, zwrócił nieoczekiwany typ treści, czy nie zawierał wartości wymaganych przez Twoje reguły walidacji - HostTracker wysyła alert przez dowolny ze skonfigurowanych przez Ciebie 9 kanałów powiadomień, w tym e-mail, SMS, połączenie głosowe, webhooki, Slack oraz komunikatory takie jak Telegram, Discord i Viber. Dzięki temu Twój zespół dowiaduje się o uszkodzonym lub działającym gorzej API w momencie wykrycia problemu, a nie z helpdeskowego zgłoszenia po godzinach cichej awarii integracji. Ponieważ test ocenia zarówno dostępność, jak i treść, alert odzwierciedla rzeczywisty problem funkcjonalny API, a nie tylko chwilowe zakłócenie połączenia, co pomaga uniknąć zarówno przeoczonych incydentów, jak i niepotrzebnego szumu.
Odkryj więcej monitoringu HostTracker
Symuluj wieloetapowe scenariusze zakupu i logowania
Modeluj rzeczywiste ścieżki użytkowników - logowanie, wyszukiwanie, finalizację zakupu - i otrzymuj alert w chwili, gdy dany krok scenariusza się zepsuje albo strona przestanie poprawnie odpowiadać.
Śledź rzeczywistą szybkość ładowania strony z ponad 300 lokalizacji
Zautomatyzuj rzeczywistą wizytę przeglądarki na swojej stronie i mierz czas ładowania względem ustawionej przez Ciebie polityki, aby spowolnienia wychodziły na jaw, zanim odwiedzający zaczną odchodzić.
Poznaj wszystkie funkcje monitorowania HostTracker
Porównaj wszystkie 8 typów monitorowania obok siebie i dobierz kontrole pasujące do Twojej strony.
Monitoruj swoje endpointy API 24/7
Rozpocznij darmowy okres próbny i otrzymuj powiadomienia w chwili, gdy endpoint zwróci błędny status, złamie kontrakt lub zacznie działać wolniej.
Część usługi monitorowania stron internetowych HostTracker.