Monitory webowe: HTTP(s), Keyword i JSON Query

Typy monitorów w Uptime Kuma pokrywają szeroki zakres usług — od stron WWW przez bazy danych po kontenery Docker. Wybór odpowiedniego typu monitora jest kluczowy dla skutecznego monitorowania i eliminacji fałszywych alarmów.

Monitor HTTP(s)

Podstawowy typ — wysyła żądanie HTTP GET (lub inne: POST, PUT, HEAD) do podanego URL-a i sprawdza kod odpowiedzi. Serwis jest UP jeśli kod mieści się w zakresie akceptowanych kodów (domyślnie 200–299). Używaj dla stron WWW, sklepów e-commerce, paneli CMS i endpointów API.

Monitor Keyword

Rozszerzony HTTP(s) z dodatkowym sprawdzaniem treści odpowiedzi. Uptime Kuma szuka zdefiniowanej frazy w body odpowiedzi — DOWN jeśli fraza nie zostanie znaleziona. Przykładowe zastosowanie: wpisz frazę „Dodaj do koszyka" — jeśli strona sklepu nie zawiera tej frazy, prawdopodobnie wyświetla stronę błędu. Dostępny też wariant Keyword (Inverse) — DOWN jeśli fraza JEST obecna w odpowiedzi (np. wykrywanie komunikatów o błędach).

Monitor JSON Query

Zaawansowany monitor dla API REST — pobiera odpowiedź JSON i sprawdza wartość konkretnego pola. Przykład: sprawdź, czy $.status ma wartość "ok" w odpowiedzi z endpointu health check. Idealny dla mikroserwisów z dedykowanymi endpointami healthcheck.

Monitory sieciowe: TCP, UDP, Ping, DNS

Monitor TCP Port

Sprawdza, czy konkretny port TCP jest otwarty i dostępny. Używaj do monitorowania serwerów SMTP (port 25/465/587), IMAP (993), POP3 (995), FTP (21), SSH (22), baz danych (MySQL: 3306, PostgreSQL: 5432) i innych usług nasłuchujących na określonym porcie. Konfiguracja: wpisz hostname/IP i numer portu.

Monitor UDP Port

Analogiczny do TCP, ale dla protokołu UDP. Używany rzadziej — głównie dla serwerów DNS (port 53/UDP), serwerów gier i VPN (np. WireGuard, OpenVPN UDP).

Monitor Ping

Wysyła pakiety ICMP ping do podanego hosta i mierzy czas odpowiedzi (latencję). Sprawdza dostępność serwera na poziomie sieciowym. Uwaga: wiele serwerów produkcyjnych blokuje ping ze względów bezpieczeństwa — brak odpowiedzi na ping nie zawsze oznacza niedostępność serwisu.

Monitor DNS

Sprawdza, czy serwer DNS poprawnie rozwiązuje podaną nazwę domenową. Możesz weryfikować rekordy A, AAAA, MX, CNAME, TXT i inne. Przydatny do monitorowania własnych serwerów DNS i wykrywania problemów z propagacją DNS po zmianach konfiguracji.

Monitor Heartbeat (Push) – dla zadań cron

Monitor Heartbeat działa w odwrotny sposób niż pozostałe typy — to nie Uptime Kuma odpytuje serwis, lecz serwis sam cyklicznie wysyła żądanie HTTP GET do unikalnego URL-a Uptime Kuma. Jeśli sygnał nie przyjdzie w ustalonym czasie, Uptime Kuma uznaje serwis za DOWN.

Heartbeat jest idealny do monitorowania:

• Zadań cron — kopie zapasowe bazy danych, synchronizacje, eksporty raportów
• Procesów działających w tle — queue workerów, importów danych, przetwarzania kolejki e-mail
• Skryptów automatycznych — które nie mają publicznego URL-a, ale mogą wywołać prosty GET

Monitor Docker – kontenery i procesy

Monitor Docker sprawdza stan działania kontenera Docker na wskazanym hoście. Uptime Kuma łączy się z Docker API (przez socket /var/run/docker.sock lub zdalny API) i sprawdza, czy kontener o podanej nazwie lub ID jest w stanie running.

Konfiguracja: wybierz typ Docker Container, wskaż host Docker (najczęściej local dla tej samej maszyny lub zdalny endpoint), wpisz nazwę kontenera. Uptime Kuma ostrzeże gdy kontener zatrzyma się lub wejdzie w stan exited/crashed.

Monitory baz danych

Uptime Kuma obsługuje natywne monitory dla popularnych baz danych — łączy się bezpośrednio z bazą, wykonuje proste zapytanie i weryfikuje odpowiedź:

• MySQL / MariaDB — połączenie przez standardowy port 3306, weryfikacja przez SELECT 1
• PostgreSQL — port 5432, weryfikacja przez SELECT 1
• Redis — port 6379, weryfikacja przez komendę PING
• MongoDB — weryfikacja przez ping do replica seta lub standalone
• Microsoft SQL Server — port 1433, weryfikacja przez SELECT 1

Konfiguracja: wybierz typ bazy, podaj host, port, użytkownika, hasło i nazwę bazy. Zalecane jest użycie osobnego użytkownika read-only z minimalnymi uprawnieniami — wyłącznie dla celów healthcheck.

Często zadawane pytania

Czym różni się monitor HTTP(s) od monitora Keyword w Uptime Kuma?

Monitor HTTP(s) sprawdza wyłącznie kod odpowiedzi HTTP — uznaje serwis za UP jeśli odpowiedź mieści się w zakresie akceptowanych kodów. Monitor Keyword sprawdza dodatkowo treść odpowiedzi — serwis jest UP tylko jeśli odpowiedź zawiera zdefiniowaną frazę. Keyword jest przydatny gdy strona może zwrócić kod 200 nawet przy błędach aplikacji (np. komunikat o błędzie bazy danych na stronie sklepu).

Do czego służy monitor Heartbeat w Uptime Kuma?

Monitor Heartbeat (Push) działa w odwrotny sposób — to nie Uptime Kuma sprawdza serwis, ale serwis sam wysyła sygnał „żyję" do Uptime Kuma przez dedykowany URL. Jeśli sygnał nie przyjdzie w ustalonym czasie, Uptime Kuma uznaje serwis za DOWN i wysyła alert. Heartbeat jest idealny do monitorowania zadań cron (kopie zapasowe, synchronizacje danych), które nie mają publicznego URL-a.

Jak monitorować bazę danych MySQL lub PostgreSQL w Uptime Kuma?

Uptime Kuma obsługuje natywne monitorowanie baz danych przez dedykowane typy monitorów: MySQL/MariaDB, PostgreSQL, Redis, MongoDB i Microsoft SQL Server. W konfiguracji monitora wybierz odpowiedni typ bazy, wpisz host, port, nazwę użytkownika i hasło. Zalecane jest użycie dedykowanego użytkownika read-only z minimalnymi uprawnieniami.

Zobacz też

• Jak dodać monitor w Uptime Kuma – krok po kroku
• Powiadomienia w Uptime Kuma – konfiguracja alertów
• Monitorowanie certyfikatów SSL w Uptime Kuma
• Dokumentacja Uptime Kuma (GitHub Wiki)