Monitorowanie dostępności
Metoda żądania
GET lub POST. POST pozwala sprawdzać endpoint, który przyjmuje wyłącznie zapisy (na przykład własny health check odbiornika webhooków).
Sprawdzanie portu TCP
Nie wszystko mówi po HTTP — baza danych, serwer pocztowy, serwer gier. Zamiast http(s):// wpisz jako URL tcp://host:port, a Dumza sprawdzi, czy ten port przyjmuje połączenie, zamiast wysyłać żądanie HTTP. Metoda, oczekiwany kod statusu, słowo kluczowe i próg czasu odpowiedzi nie mają zastosowania do sprawdzania TCP i są ukryte w formularzu; alerty, incydenty i cała reszta działają dokładnie tak samo.
Oczekiwany kod statusu
Każdy endpoint, który zwraca inny kod niż oczekiwany, liczy się jako niedostępny. Nie ogranicza się to do 200 — wiele API poprawnie zwraca 201, 204, a nawet 401/503 przy zdrowym sprawdzeniu (na przykład endpoint, który z założenia wymaga uwierzytelnienia). Ustaw dokładnie ten status, który Twój endpoint zwraca, gdy faktycznie działa poprawnie.
Sprawdzanie słowa kluczowego
Opcjonalnie możesz wymagać (lub zabronić) obecności konkretnego fragmentu tekstu w treści odpowiedzi — przydatne dla endpointów, które zwracają 200 nawet wtedy, gdy coś wewnątrz strony jest zepsute (na przykład CMS serwujący ogólną stronę błędu ze statusem 200). Wybierz „zawiera”, aby wymagać tekstu, albo „nie zawiera”, aby sprawdzenie kończyło się niepowodzeniem, gdy tekst się pojawi (przydatne do wykrywania banera trybu konserwacji, który Twoja aplikacja pokazuje, wciąż zwracając 200).
Próg czasu odpowiedzi
Ustaw maksymalny akceptowalny czas odpowiedzi — sprawdzenie, które odpowiada poprawnie, ale zbyt wolno, zostanie oznaczone jako „ograniczone” (degraded), a nie „niedostępne”. Jest widoczne na panelu i liczone w statystykach dostępności, ale NIE otwiera incydentu ani nie wysyła alertu. Stan ograniczony to sygnał do obserwacji, a nie powód do wzywania kogokolwiek.
Interwał sprawdzania
Jak często Dumza sprawdza endpoint. Plan Free sprawdza co 5 minut; plany płatne pozwalają zejść nawet do 1 minuty. Krótszy interwał oznacza szybsze wykrycie awarii kosztem większej liczby żądań trafiających do Twojego serwera.
Moment wysyłania alertu: notifyAfter i ponowne alerty
„Alertuj po N kolejnych awariach” określa, ile złych sprawdzeń z rzędu otwiera incydent (minimum 2, żeby uniknąć fałszywych alarmów po pojedynczym zacięciu). Niezależnie od tego opcja „ponawiaj alert co N minut” (opcjonalna, minimum 30) powtarza powiadomienie tak długo, jak monitor pozostaje niedostępny — przydatne, gdy pierwszy alert Twojego zespołu zostanie przeoczony.
Znaczenie statusów monitora
up — ostatnie sprawdzenie zakończyło się sukcesem. down — incydent jest otwarty. degraded — usługa odpowiada, ale wolniej niż ustalony próg. pending — żadne sprawdzenie jeszcze się nie odbyło (monitor dopiero utworzono albo jest wstrzymany). auth_error — token logowania monitora z uwierzytelnianiem został odrzucony; zobacz Monitorowanie z uwierzytelnianiem.
Wstrzymywanie monitora
Wstrzymany monitor całkowicie przestaje być sprawdzany, a każdy otwarty na nim incydent zamyka się automatycznie — nie będzie Cię dalej alarmować o czymś, co świadomie wyłączyłeś (planowana konserwacja, wycofanie usługi). Wznów go w dowolnym momencie, żeby znów zacząć monitorowanie.