Uptime Kuma to otwartoźródłowy monitor hostowany na własnym serwerze, obsługujący testy HTTP(S), TCP, ping, DNS, WebSocket i inne. Na osobnym VPS sprawdza dalej, gdy Twój serwer produkcyjny padnie, zamiast zniknąć razem z nim.
Ta konfiguracja Uptime Kuma na VPS wdraża wersję v2 przy użyciu Docker Compose, zostawia port 3001 na loopbacku, dodaje HTTPS przez Caddy, kieruje powiadomienia na Telegram, Discord i Slack oraz publikuje stronę statusu.
Wymagania wstępne i co będzie potrzebne
- VPS z co najmniej 1 vCPU, 1 GB RAM i 10 GB lokalnej przestrzeni SSD
- Ubuntu 24.04 LTS albo inne aktualne wydanie Ubuntu wspierane przez Dockera
- Docker Engine i Docker Compose zainstalowane na VPS
- Domena lub subdomena wskazująca na VPS rekordem A (na przykład status.example.com)
- Dostęp SSH i podstawowa swoboda w wierszu poleceń
Jeśli Docker nie jest jeszcze zainstalowany, skorzystaj z przewodnika instalacji Dockera na Ubuntu. Instaluje on Docker Engine oraz wtyczkę Compose używaną poniżej.
Dlaczego VPS monitorujący musi być oddzielony od tego, co nadzoruje
Produkcja i monitoring na tym samym serwerze dzielą tę samą domenę awarii. Gdy ten serwer padnie, znikają jednocześnie aplikacja i system, który ma wysłać powiadomienie.
Poprawiają to dwa praktyczne układy:
- Ten sam dostawca, inna lokalizacja. Umieść produkcję i monitoring na osobnych hostach w różnych lokalizacjach. Zmniejsza to ryzyko awarii pojedynczego serwera lub jednego centrum danych, ale nie chroni przed każdą awarią sieci czy warstwy sterowania obejmującą całego dostawcę.
- Zupełnie inny dostawca. Hostowanie monitoringu gdzie indziej chroni też przed awariami obejmującymi całego dostawcę. Kosztem jest kolejne konto, kolejna faktura i kolejny obszar do utrzymania.
Pojedyncza instancja Uptime Kuma wciąż nie ma zewnętrznego strażnika. Dodaj jedno zewnętrzne sprawdzenie HTTP(S) jej publicznej strony statusu. Darmowy plan UptimeRobota obejmuje obecnie 50 monitorów w pięciominutowych odstępach. Nie zapewni to Uptime Kuma wysokiej dostępności, ale powie Ci, kiedy zniknie sam monitoring.
Ta sama zasada dotyczy publicznych stron statusu: to, co informuje Cię o awarii, nie może dzielić domeny awarii z tym, co ulega awarii.
Twórz na VPS Linux z dostępem root, NVMe i mocą AMD EPYC.
Zobacz plany LinuxDobór wielkości VPS
Uptime Kuma nie ma wiarygodnego przelicznika liczby monitorów na RAM, bo obciążenie zależy od typu monitora, interwału, ustawień ponowień i czasu przechowywania historii. Proste testy HTTP(S), TCP, ping i DNS są lżejsze niż testy Browser Engine, które uruchamiają Chromium.
Przy niewielkim zestawie podstawowych testów zacznij od 1 vCPU, 1 GB RAM i lokalnego dysku SSD. Rzeczywiste zużycie obserwuj przez docker stats uptime-kuma a przyrost bazy danych przez du -sh /opt/uptime-kuma/data. Dołóż pamięci, gdy zużycie utrzymuje się wysoko, gdy kontener zgłosi OOM kill albo gdy wprowadzisz testy Browser Engine.
Pełny obraz v2 zawiera Chromium i wbudowaną MariaDB; dokumentacja tagów Dockera wyjaśnia różnicę między obrazem full a slim.
Wdrożenie Uptime Kuma za pomocą Docker Compose
Zapisz ten plik jako docker-compose.yml w /opt/uptime-kuma/:
services:
uptime-kuma:
image: louislam/uptime-kuma:2
container_name: uptime-kuma
restart: unless-stopped
ports:
# Bind to localhost only. The reverse proxy will expose it on 443.
- "127.0.0.1:3001:3001"
volumes:
- ./data:/app/data
Trzy linijki warto omówić:
- image: louislam/uptime-kuma:2 przypina wersję główną. Tag :2 śledzi stabilną linię 2.x. Nie używaj :latest.
- 127.0.0.1:3001:3001 wiąże kontener wyłącznie z localhostem. Publiczny internet nigdy nie może sięgać portu 3001 bezpośrednio. Certyfikat TLS i publiczną nazwę hosta trzyma reverse proxy.
- Wolumen danych przechowuje bazę danych, konfigurację monitorów i historię. Trzymaj go na lokalnym dysku, ponieważ dokumentacja instalacji Uptime Kuma ostrzega, że systemy plików bez niezawodnego blokowania POSIX, w tym wiele konfiguracji NFS, mogą uszkodzić SQLite. Zatrzymaj stack, zanim wykonasz kopię na poziomie systemu plików.
Uruchom i sprawdź:
sudo install -d -o "$USER" -g "$USER" /opt/uptime-kuma
cd /opt/uptime-kuma
# Paste the docker-compose.yml file above.
sudo docker compose up -d
sudo docker compose ps
Oczekiwany wynik docker compose ps:
NAME IMAGE STATUS PORTS
uptime-kuma louislam/uptime-kuma:2 Up (healthy) 127.0.0.1:3001->3001/tcp
Aby wejść do panelu po raz pierwszy, nie otwieraj portu 3001 do internetu, nawet na chwilę. Użyj tunelu SSH:
ssh -L 3001:127.0.0.1:3001 [email protected]
Otwórz http://localhost:3001 w przeglądarce, utwórz konto administratora, ustaw mocne hasło i zamknij tunel. Od tej pory panel dociera do Ciebie po HTTPS przez reverse proxy.
Jeśli nie potrzebujesz ręcznego Compose, oferujemy też Uptime Kuma jako aplikację instalowaną jednym kliknięciem. Obecna strona aplikacji podaje v1, więc nie odpowiada konfiguracji v2 z tego poradnika. Jeśli potrzebujesz konkretnie v2, wybierz ręczną drogę przez Compose.
Reverse proxy i TLS
Nie wystawiaj Uptime Kuma bezpośrednio. Postaw przed nim reverse proxy dla TLS, poprawnej obsługi adresów URL i jednego publicznego punktu wejścia. Są dwie drogi.
Caddy. Jeśli Caddy nie jest jeszcze zainstalowany, wykonaj oficjalne kroki instalacji pakietu na Ubuntu. Gdy Caddy działa jako usługa hosta, poniższy Caddyfile przekierowuje do Uptime Kuma na loopbacku i automatycznie zajmuje się wydaniem oraz odnawianiem certyfikatu.
Wskazówka: jeśli na VPS monitorującym stoi tylko Uptime Kuma, wybierz Caddy. Caddyfile ma trzy linijki, a wydanie i odnowienie certyfikatu Caddy załatwia sam. Bez Certbota i bez osobnego timera odnawiania, którego trzeba pilnować o 4 nad ranem.
Zapisz to jako /etc/caddy/Caddyfile:
status.example.com {
reverse_proxy 127.0.0.1:3001
}
Przeładuj Caddy:
sudo systemctl reload caddy
Sprawdź:
curl -I https://status.example.com
Powinieneś dostać poprawną odpowiedź 2xx lub 3xx z ważnym certyfikatem. Jeśli połączenie się nie uda, sprawdź, czy rekord A lub AAAA domeny wskazuje na ten VPS, czy porty 80 i 443 są osiągalne i czy Caddy może się do obu przypiąć. To wszystko należy do wymagań automatycznego HTTPS w Caddy.
Nginx Proxy Manager. Jeśli NPM działa bezpośrednio na hoście, dodaj Proxy Host dla status.example.com, przekieruj go na 127.0.0.1 na port 3001, poproś o certyfikat Let's Encrypt i włącz Websockets Support. Jeśli NPM działa w Dockerze, 127.0.0.1 wskazuje z powrotem na sam kontener NPM. Podłącz wtedy NPM i Uptime Kuma do tej samej sieci Dockera, a proxy host skieruj na uptime-kuma na port 3001.
Kierowanie powiadomień: Telegram, Discord, Slack
Uptime Kuma potrafi wysłać to samo zdarzenie monitora do wielu kanałów powiadomień. Skonfiguruj każdego dostawcę raz, a potem przypnij do monitora jeden lub kilka kanałów zależnie od tego, kto ma dostać alert.
Powiadomienia konfiguruje się globalnie w Ustawienia > Powiadomienia, a potem przypisuje do poszczególnych monitorów. Każdy monitor może odpalić jeden lub wiele kanałów. Ten sam alert może trafić na Telegram do dyżurnego inżyniera, na Slack do zespołu i na e-mail do dziennika audytu, wszystko z jednego zdarzenia.
Telegram
- W Telegramie napisz do @BotFather i uruchom /newbot. Wybierz nazwę i nazwę użytkownika. BotFather odpowie tokenem bota. Zachowaj go.
- Wyślij nowemu botowi dowolną wiadomość. Następnie otwórz w przeglądarce https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates. Znajdź pole chat.id, to jest Twoje ID czatu.
- W Uptime Kuma: Ustawienia > Powiadomienia > Skonfiguruj powiadomienie > Telegram. Wklej token bota i ID czatu. Kliknij Test. Sprawdź, czy bot wysyła testowy alert.
- Jeśli wiadomość testowa nie dotrze, sprawdź poprawność tokenu bota i ID czatu oraz upewnij się, że firewall na VPS przepuszcza wychodzące HTTPS do api.telegram.org.
Discord
- Otwórz serwer Discord, na którym chcesz otrzymywać alerty. Kliknij prawym przyciskiem docelowy kanał, a następnie Edytuj kanał > Integracje > Webhooki > Nowy webhook. Nadaj mu nazwę (na przykład „Uptime Kuma”), wybierz kanał i skopiuj URL webhooka.
- W Uptime Kuma: Ustawienia > Powiadomienia > Skonfiguruj powiadomienie > Discord. Wklej URL webhooka. Opcjonalnie ustaw nazwę użytkownika i awatar.
- Kliknij Test. Sprawdź, czy webhook publikuje testowy alert na kanale.
Slack
- W Slacku utwórz Incoming Webhook dla kanału, na którym chcesz otrzymywać alerty. Slack zwróci URL webhooka w postaci https://hooks.slack.com/services/T.../B.../....
- W Uptime Kuma: Ustawienia > Powiadomienia > Skonfiguruj powiadomienie > Slack. Wklej URL webhooka. Opcjonalnie skonfiguruj ikonę i nadpisanie kanału.
- Kliknij Test.
Gdy wszystkie testy przejdą, edytuj każdy monitor i wybierz kanały powiadomień, których ma używać. Ustaw Max Retries (maksymalna liczba prób) oraz Retry Interval (odstęp między próbami) tak, aby jedna krótka awaria nie wywoływała alertu od razu.
Wbudowana strona statusu (i kiedy przestanie wystarczać)
Uptime Kuma ma publiczne strony statusu z własnymi slugami, grupowaniem monitorów, własnymi domenami, wpisami o incydentach i komunikatami o zaplanowanych pracach. Z jednej instancji możesz też opublikować kilka stron statusu, dla różnych usług lub odbiorców.
Większym ograniczeniem jest komunikacja z klientami. Odwiedzający nie mogą obecnie zapisać się mailowo na aktualizacje bezpośrednio ze strony statusu, a ta publiczna strona pozostaje częścią tej samej aplikacji Uptime Kuma co panel operatora. Samodzielny zapis odwiedzających wciąż figuruje jako otwarte zgłoszenie funkcji.
Jeśli potrzebujesz subskrypcji dla klientów albo systemu statusu oddzielonego od panelu monitoringu, jedną z alternatyw jest Kener. Nasz tekst o samodzielnie hostowanym stosie monitoringu wyjaśnia, jak połączyć oba narzędzia.
Najczęstsze problemy
Powiadomienia po cichu zawodzą, gdy firewall na VPS blokuje wychodzące HTTPS. Objaw: przycisk Test działa dla części kanałów, dla innych nie. Rozwiązanie: sprawdź, czy wychodzące połączenia HTTPS są dozwolone i czy curl -I https://api.telegram.org działa z poziomu VPS.
Przeglądarka pokazuje „ERR_TOO_MANY_REDIRECTS” po włączeniu proxy. Poszukaj zdublowanych przekierowań z HTTP na HTTPS w Caddy, Nginx Proxy Managerze lub w CDN-ie przed nimi. Uptime Kuma powinien nadal serwować HTTP na porcie 3001, a TLS kończy publiczne reverse proxy. Jeśli włączasz zaufane nagłówki proxy, aktualna ścieżka to Ustawienia > Reverse Proxy > Nagłówki HTTP > Trust Proxy.
Kontener restartuje się co kilka minut. Sprawdź, czy kontener nie został ubity z powodu braku pamięci, a potem obserwuj bieżące zużycie przez docker stats uptime-kuma. Jeśli kontener padł od OOM albo pamięć trzyma się blisko limitu VPS, dołóż RAM-u, ogranicz ciężkie testy albo wydłuż ich interwały.
Strona statusu działa na localhoście, ale nie przez publiczną nazwę hosta. Sprawdź, czy reverse proxy przekazuje ścieżkę główną bez zmian, zachowuje nagłówek Host i obsługuje WebSockets. Uptime Kuma nie wspiera instalacji w podkatalogu, więc użyj osobnej domeny lub subdomeny zamiast ścieżki w rodzaju example.com/uptime-kuma.
Podsumowanie
Uptime Kuma na osobnym VPS daje Ci kontrolę nad testami, kierowaniem alertów i publiczną stroną statusu, ale bierzesz też na siebie aktualizacje, kopie zapasowe, łatanie systemu i zewnętrznego strażnika samego monitoringu. Wybierz VPS w innej lokalizacji niż produkcja, wdróż v2 przez Docker Compose albo użyj aplikacji jednym kliknięciem po sprawdzeniu podanej wersji, postaw przed tym Caddy i podłącz kanały, które Twój zespół faktycznie obserwuje.
Często zadawane pytania
Ile RAM-u potrzebuje Uptime Kuma?
Uptime Kuma nie ma wiarygodnego przelicznika liczby monitorów na RAM, bo zużycie zmienia się wraz z typem monitora, interwałem sprawdzania, ustawieniami ponowień, czasem przechowywania historii i użyciem Browser Engine. Przy niewielkim zestawie podstawowych testów zacznij od 1 GB RAM i obserwuj rzeczywiste zużycie przez docker stats uptime-kuma. Dołóż pamięci, jeśli zużycie trzyma się blisko limitu albo kontener pada od OOM.
Czy uruchamiać Uptime Kuma na tym samym serwerze co moja aplikacja?
Nie. Jeśli narzędzie monitorujące i aplikacja dzielą serwer, awaria wyłącza oba naraz i tracisz alerty dokładnie wtedy, gdy są najbardziej potrzebne. Uruchom Uptime Kuma na osobnym VPS, najlepiej w innym centrum danych.
Czy Uptime Kuma może wysyłać alerty na Telegram, Discord i Slack?
Tak. Telegram, Discord i Slack należą do wbudowanych usług powiadomień, obok e-maila, ogólnych webhooków, PagerDuty, ntfy, Mattermosta i wielu innych. Telegram korzysta z tokenu bota i ID czatu, a Discord i Slack z adresów URL webhooków. Do jednego monitora możesz przypiąć kilka kanałów powiadomień.
Czym różni się Uptime Kuma od UptimeRobota?
Uptime Kuma hostujesz sam, więc serwer, aktualizacje, kopie zapasowe i kierowanie alertów są na Tobie. Obsługuje interwały sprawdzania nawet co 20 sekund. UptimeRobot to hostowany SaaS, a jego obecny darmowy plan obejmuje 50 monitorów z testami co pięć minut. Wybierz Uptime Kuma, jeśli chcesz kontroli, albo UptimeRobota, jeśli nie chcesz prowadzić serwera monitoringu.
Czy Uptime Kuma ma publiczną stronę statusu?
Tak. Możesz wybrać, które monitory są widoczne, pogrupować je, opublikować kilka stron statusu, przypisać im własne domeny i zaplanować komunikaty o pracach serwisowych. Samodzielny zapis odwiedzających na e-mail nie jest wbudowany, więc gdy klienci mają subskrybować aktualizacje, użyj osobnego, klienckiego narzędzia do stron statusu.
