Monitoring portów sieciowych
Więcej niż sama strona. Pilnuj dostępności swoich baz danych, serwerów pocztowych i własnych usług TCP z natychmiastową reakcją na ich awarię.
Kompleksowy nadzór nad usługami
Wiele krytycznych aplikacji nie działa na standardowym HTTP. Bazy danych takie jak PostgreSQL czy MySQL, serwery poczty (SMTP/IMAP) lub usługi VPN wymagają innego podejścia do monitoringu. Monitoring portów w Pulsitorze weryfikuje niskopoziomową łączność TCP z wybranym portem Twojego serwera. Ten rodzaj kontroli jest nieoceniony przy sprawdzaniu, czy usługa jest gotowa przyjmować połączenia, i pomaga wykryć problemy z zaporą lub padnięte procesy w tle, które monitoring WWW mógłby przeoczyć. Protokół wybierasz sam dla każdego monitora, więc kontrola nigdy nie zgaduje go z numeru portu.
Kontrole portów świadome protokołu
To, w czym Pulsitor jest mocny od pierwszego dnia.
Protokół wskazujesz Ty
Protokół wybierasz sam dla każdego monitora — TCP, TCP z TLS, HTTP, HTTPS lub sondę UDP.
Limit czasu pod Twoją kontrolą
Możesz precyzyjnie określić limity czasu połączenia, co pomaga wskazać przeciążone serwery.
Prywatne węzły w drodze
Przygotowujemy obsługę węzłów prywatnych, dzięki której zmonitorujesz usługi także wewnątrz swojej sieci lokalnej.
Jeden port, osiem rodzajów kontroli
Ten sam host i port mogą znaczyć osiem różnych rzeczy. Powiedz, którą z nich masz na myśli, a kontrola powie Ci prawdę — także na UDP, gdzie połączenia po prostu nie ma.
TCP
Zwykłe nawiązanie połączenia. Odpowiada na jedyne pytanie, które liczy się przy bazie danych, kolejce czy serwerze gry: czy ten port w ogóle przyjmuje połączenia?
TCP + TLS
Połączenie plus zakończony handshake TLS. Dla IMAPS, SMTPS i wszystkiego za TLS na niestandardowym porcie — certyfikat, którego serwer nie potrafi przedstawić, kładzie kontrolę.
HTTP
Prawdziwe żądanie GET na dowolnym porcie, na którym nasłuchuje Twoja aplikacja. Aplikacja na :3000 czy :9000 jest sprawdzana jak strona, a nie jak goły socket.
HTTPS
To samo żądanie przez TLS. Port 8443 nie jest już przypadkiem szczególnym — liczy się protokół, który wybrałeś, a nie ten, który sugerował numer portu.
UDP (bez sondy)
Dla własnych usług UDP. Pusty datagram dowodzi, że port jest zamknięty, gdy host go odrzuci; port, który milczy, może być jednak równie dobrze zdrową usługą odpowiadającą tylko swoim klientom, więc liczy się jako dostępny. Mówimy to wprost, zamiast wymyślać pewność, której UDP dać nie może.
DNS (UDP)
Prawdziwe zapytanie DNS, na które odpowiada Twój resolver. UDP nie ma handshake, na którym można się oprzeć, więc sama odpowiedź jest dowodem, że port jest otwarty, a usługa żyje — a jej czas obiegu to prawdziwy czas odpowiedzi.
NTP (UDP)
Zapytanie o czas do Twojego serwera NTP, powiązane z wracającą odpowiedzią. Kontrola, od której zależy każda maszyna w Twojej sieci i której nikt nie pilnuje.
STUN (UDP)
Binding request do serwera STUN lub TURN — strona UDP każdego wdrożenia WebRTC. A zarazem najelegantszy sposób, by własna usługa UDP dała się sprawdzić: postaw obok niej mały responder STUN.
Szeroki zakres monitoringu
Cokolwiek, co mówi przez gniazdo
Pilnuj wszystkiego, co komunikuje się przez sieć — od serwerów baz danych po urządzenia IoT.
Problemy sieciowe, zanim ruszy lawina
Wychwyć problemy warstwy sieciowej, zanim wywołają kaskadowe awarie Twoich aplikacji.
Po Twojej stronie nic się nie instaluje
Konfiguracja jest prosta i nie wymaga instalowania żadnego oprogramowania po stronie monitorowanej.
Monitoring portów w skrócie
Osiem protokołów, jeden port, żadnego zgadywania.
| Właściwość | Wartość |
|---|---|
| Protokoły | TCP, TCP + TLS, HTTP, HTTPS, UDP, DNS przez UDP, NTP przez UDP, STUN przez UDP |
| Zakres portów | Od 0 do 65535 |
| Limit czasu | Od 1 do 60 sekund |
| Częstotliwość sprawdzeń | Od 15 do 180 sekund, zależnie od planu |
| Zanim powstanie incydent | Potwierdzenie z więcej niż jednego z 5 regionów |
| Kanały powiadomień | 14 |
| Dostępne w | Wszystkie plany, także Free |
Pytania o monitoring portów
Co sprawdzenie portu powie, a czego nie.
Jakie protokoły zna sprawdzenie portu?
Osiem: czyste TCP, TCP z TLS, HTTP, HTTPS, gołą sondę UDP oraz prawdziwe zapytania DNS, NTP i STUN przez UDP. Jeden wybierasz na monitorze — nigdy nie jest zgadywany z numeru portu.
Jak działa sprawdzenie UDP bez połączenia?
Przy DNS, NTP i STUN sonda wysyła prawdziwe zapytanie i czeka na prawdziwą odpowiedź, a ta odpowiedź jest dowodem, że usługa żyje. Goła sonda UDP czyta zamiast tego odrzucenie ICMP, które odsyła zamknięty port.
Czy mogę monitorować bazę danych albo serwer pocztowy?
Tak. PostgreSQL, MySQL, SMTP, IMAP, Redis, serwer gry — cokolwiek, co przyjmuje połączenie na porcie osiągalnym z internetu.
Jakie numery portów i limity czasu są dozwolone?
Dowolny port od 0 do 65535, z limitem czasu połączenia ustawianym między 1 a 60 sekund.
Czy monitoring portów jest dostępny w planie darmowym?
Tak. Sprawdzenia portów działają w każdym planie, także we Free.
Szybki start monitoringu portów
Podaj adres IP lub domenę oraz numer portu, który chcesz mieć pod nadzorem, i wybierz protokół, którym mówi usługa.
Ustaw częstotliwość kontroli odpowiednio do znaczenia danej infrastruktury.
Zapisz monitor i miej spokój — Twoje usługi backendowe są pod stałą opieką.