Monitorowanie endpointów

Co jest "endpointem"?

Endpoint to wszystko co jest adresowalne w internecie i można odpytać żeby zweryfikować dostępność. Klasyczny przypadek to URL strony WWW — ale w nowoczesnej infrastrukturze rzeczy o które dbasz są dużo bardziej zróżnicowane: REST API, endpointy GraphQL, serwery pocztowe, listenery baz danych, kolejki wiadomości, porty health-check kontenerów, wewnętrzne panele admin, odbiorcy webhooków. DiagnoSEO Uptime Monitoring traktuje je jednolicie: definiujesz co znaczy "zdrowy" dla tego endpointa, ustawiasz harmonogram checków, dostajesz alert przy awarii.

Ta strona opisuje każdy typ endpointa który tool obsługuje, do czego się każdy nadaje i jaki sygnał daje monitorowanie.

Endpointy HTTP / HTTPS (strony WWW)

Domyślny przypadek. Wpisujesz https://example.com i monitor wykonuje request GET co określony interwał (1 minuta, 5, 10, 30, lub 60 minut w zależności od planu). Udany check oznacza: nawiązano połączenie TCP, handshake TLS zakończony (dla HTTPS), odebrano odpowiedź HTTP z oczekiwanym kodem statusu (domyślnie: 2xx lub 3xx), oraz opcjonalnie keyword obecny (lub nieobecny) w body odpowiedzi. Check rejestruje Time To First Byte, całkowity czas odpowiedzi, rozmiar treści, łańcuch przekierowań i pełny zestaw nagłówków odpowiedzi.

Endpointy HTTP są właściwym wyborem dla: stron marketingowych, blogów, sklepów e-commerce, dashboardów SaaS, portali dokumentacji — wszędzie tam gdzie ludzie odwiedzają przeglądarką.

Endpointy API (REST / GraphQL / JSON-RPC)

API potrzebują czegoś więcej niż "czy odpowiedziało" — potrzebują "czy odpowiedziało poprawnie". Konfigurujesz monitor z customową metodą HTTP (GET, POST, PUT, DELETE, PATCH), customowymi nagłówkami (tokeny auth, content-type), body requestu (payload JSON dla POST/PUT) oraz asercjami JSON na odpowiedzi (data.status musi równać się "ok", result.count musi być większe od 0, errors[] musi być puste). API zwracające HTTP 200 z popsutym payload to najgorszy rodzaj awarii — wygląda zdrowo dla naiwnego monitora ale zawodzi każdego klienta. Asercje JSON to wyłapują.

Zobacz dedykowany poradnik monitorowania API dla szczegółów konfiguracji i składni asercji.

Endpointy portów TCP

Dla usług nie-HTTP: SMTP (port 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), listenery baz danych (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), customowe porty aplikacji. Monitor otwiera połączenie TCP do podanego host:port i raportuje sukces jeśli połączenie zostało zaakceptowane w oknie timeout. Bez handshake'a na poziomie protokołu — po prostu "czy demon słucha".

To właściwy monitor dla każdej usługi opartej na TCP gdzie zależy ci na dostępności i nie potrzebujesz checków świadomych protokołu. Dla weryfikacji banneru SMTP lub checków na poziomie zapytania do bazy danych użyj monitora heartbeat (Twoja usługa pinguje nas gdy jest zdrowa, zobacz cron-job / heartbeat monitoring).

Endpointy ping (ICMP)

Check dostępności na warstwie 3. Monitor wysyła żądanie ICMP echo do docelowego hostname lub IP i czeka na odpowiedź. Przydatne dla routerów, switchy, urządzeń IoT, wszystkiego co odpowiada na ping ale nie uruchamia HTTP. Pamiętaj że wielu dostawców chmury (AWS, GCP, Azure) domyślnie blokuje ICMP na poziomie security-group nawet gdy host jest poza tym zdrowy — dla workloadów chmurowych preferuj checki HTTP lub porty TCP.

Endpointy hostname / DNS

Monitoring rozwiązywania DNS. Tool periodycznie rozwiązuje rekordy A, AAAA, MX, NS, TXT i CNAME Twojej domeny, robi snapshot wyników i alertuje gdy któryś się zmieni. Wyłapuje: nieautoryzowane przejęcia DNS, przypadkowe błędy konfiguracji podczas migracji providera DNS, zewnętrzne usługi aktualizujące swoje endpointy bez powiadomienia (Twój CDN przełącza bloki IP, na przykład), rekordy MX wymazane przez literówkę.

Monitoring DNS nie chodzi o dostępność — Twój provider DNS jest niemal na pewno bardziej niezawodny niż origin. Chodzi o wykrywanie zmiany. Zobacz monitoring zmian DNS dla pełnego opisu.

Endpointy certyfikatów SSL

Każdy endpoint HTTPS dostaje automatyczny monitoring SSL na wierzchu swojego checka uptime. Tool odczytuje certyfikat, parsuje okres ważności i wystawcę, i ostrzega na 30, 14, 7, 3 i 1 dzień przed wygaśnięciem. Zobacz monitoring certyfikatów SSL dla szczegółów.

Endpointy wygaśnięcia domeny

Dla każdego monitorowanego URL tool również odpytuje WHOIS raz dziennie i śledzi datę wygaśnięcia rejestracji domeny. Ostrzeżenia odpalają się na tych samych progach co SSL (30/14/7/3/1 dni). Niedopłaty odnowień są katastrofalne — domena staje się bez właściciela i ktoś może ją zarejestrować w momencie zakończenia okresu grace. Zobacz monitoring wygaśnięcia domeny.

Wybór właściwego typu endpointa

Jeśli nie wiesz którego typu monitora użyć, zacznij od HTTP/HTTPS dla wszystkiego z interfejsem webowym, portu TCP dla reszty, i dodaj checki heartbeat dla zadań batch które nie wystawiają żadnej powierzchni sieciowej. Możesz monitorować ten sam cel wieloma typami — na przykład check portu TCP na 443 wyłapie "serwer jest up, ale handshake TLS popsuty" które check HTTP na tym samym URL też by zaflagował, podczas gdy heartbeat z Twojego własnego wewnętrznego agenta monitorującego potwierdzi że logika Twojej aplikacji faktycznie działa.

Najczęściej zadawane pytania

• Co jest endpointem?

  Wszystko adresowalne w internecie: URL-e HTTP/HTTPS, REST API, porty TCP (SMTP, MySQL, customowe), hostnamy do ping'owania, rekordy DNS, certyfikaty SSL i wpisy rejestracji domen. Skonfiguruj jeden monitor per typ endpointa.

• Czy używać checka HTTP czy portu TCP?

  HTTP to dobry domyślny wybór dla każdej usługi web. Port TCP jest lepszy dla usług nie-HTTP (bazy danych, serwery pocztowe, custom protokoły) gdzie zależy ci tylko na "czy demon przyjmuje połączenia". Użyj TCP dla low-level dostępności, HTTP dla "czy aplikacja faktycznie odpowiada poprawnie".

• Czym różnią się monitory heartbeat (cron-job)?

  Heartbeat jest odwrócony — zamiast my odpytujemy Twoją usługę, Twoja usługa pinguje nas pod znanym URL. Jeśli nie dostaniemy pinga w oczekiwanym oknie, alertujemy. Używane dla cron jobów, procesów batch i wszystkiego co działa na harmonogramie bez powierzchni sieciowej do sprawdzania.

• Czy jeden URL może mieć wiele monitorów?

  Tak. Możesz monitorować ten sam cel różnymi typami checków — np. check HTTP dla pełnej dostępności plus check TCP port 443 który łapie problemy z TLS-handshake'iem. Każdy monitor działa niezależnie i alertuje niezależnie.

• Czy muszę monitorować SSL i domenę osobno?

  Nie — każdy endpoint HTTPS automatycznie dostaje monitoring SSL na wierzchu swojego checka uptime, a każdy monitorowany URL dostaje codzienne śledzenie wygaśnięcia domeny. Oba w zestawie, bez dodatkowej konfiguracji. Monitoring domeny jest per-domain — wiele monitorów na tej samej domenie współdzieli dane WHOIS.