Dealownia
Menu
sprawdzono – jak sprawdzamy oferty

Uptime Kuma na VPS: monitoring stron i powiadomienia

Uptime Kuma 2 w Dockerze za nginx: instalacja, co monitorować, powiadomienia na Discord lub e-mail, kopia danych i zewnętrzny monitor na wypadek awarii VPS.

Aplikacje na własnym serwerzezaktualizowano 5 min czytania

Redakcja serwisu Dealownia · ceny i fakty ze stron dostawców, jak sprawdzamy

Kiedy strona przestaje działać, chcesz dowiedzieć się o tym pierwszy. Uptime Kuma 2 pod adresem https://status.example.pl co minutę sprawdza Twoje strony, pilnuje ważności certyfikatów, odbiera sygnały od zadań cron i wysyła powiadomienia o awarii. Dołożysz też darmowy monitor zewnętrzny, bo Kuma na tym samym serwerze nie powie Ci, że cały serwer leży. Oprogramowanie jest darmowe; płacisz tylko za VPS, a Kuma zużywa go niewiele.

Czego potrzebujesz

  • VPS z Ubuntu 24.04 LTS, nginx i Dockerem – przygotowany jak w poradniku od zera.
  • Minimum: 1 vCPU, 1 GB RAM, kilka GB wolnego dysku. Dokumentacja Uptime Kuma nie podaje wymagań sprzętowych; orientacyjnie kontener zajmuje ok. 120 MiB RAM po starcie (baza SQLite) – sprawdź u siebie docker stats.
  • Dysk lokalny serwera, nie udział sieciowy: dokumentacja ostrzega, że SQLite na NFS może uszkodzić bazę.
  • Subdomenę, np. status.example.pl, i kanał powiadomień (Discord, Telegram, e-mail SMTP albo inny z listy w Kumie).

Krok 1. Plik compose.yaml

bash
sudo mkdir -p /opt/apps/uptime-kuma && sudo chown deploy:deploy /opt/apps/uptime-kuma
cd /opt/apps/uptime-kuma
yaml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    environment:
      UPTIME_KUMA_DB_TYPE: sqlite
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"

To oficjalny plik z repozytorium Kumy z dwiema zmianami. Port jest opublikowany tylko na 127.0.0.1, bo Docker omija reguły ufw i "3001:3001" otworzyłoby panel na świat bez HTTPS. Zmienna UPTIME_KUMA_DB_TYPE (dostępna od wersji 2.0) wybiera SQLite – wersja 2 umie też pracować z MariaDB, ale przy kilkudziesięciu monitorach SQLite wystarcza i nie wymaga osobnej bazy.

bash
docker compose up -d
docker compose logs -f uptime-kuma

Zakończ podgląd logów Ctrl+C, gdy zobaczysz, że serwer nasłuchuje. Sprawdzenie: curl -sI http://127.0.0.1:3001 | head -1 powinno zwrócić przekierowanie (302) na stronę konfiguracji lub logowania.

Krok 2. nginx z obsługą WebSocket

Interfejs Kumy działa na WebSocket – bez nagłówków Upgrade i Connection panel się nie załaduje. Mapę WebSocket tworzysz raz na serwer (wyjaśnienie w poradniku o reverse proxy); polecenie niżej nic nie zmieni, jeśli plik już istnieje:

bash
[ -f /etc/nginx/conf.d/websocket-map.conf ] || sudo tee /etc/nginx/conf.d/websocket-map.conf >/dev/null <<'EOF'
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}
EOF

Plik /etc/nginx/sites-available/status.example.pl:

nginx
server {
    listen 80;
    listen [::]:80;
    server_name status.example.pl;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

Blok map jest wzorem z dokumentacji nginx i trzymamy go wyłącznie w conf.d/websocket-map.conf – nie wklejaj go do plików w sites-available.

bash
sudo ln -s /etc/nginx/sites-available/status.example.pl /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d status.example.pl

Wejdź na https://status.example.pl i od razu załóż konto administratora – do tego momentu ekran zakładania konta jest dostępny dla każdego, kto trafi na adres.

Krok 3. Powiadomienia

W Settings → Notifications dodaj kanał. Dla Discorda wystarczy adres webhooka kanału (w Discordzie: ustawienia kanału → Integracje → Webhooki). Zaznacz „Default enabled”, żeby każdy nowy monitor dostał to powiadomienie automatycznie, i kliknij „Test”. Nie wpisuj adresu webhooka nigdzie poza Kumą – kto go zna, może pisać na Twój kanał.

Krok 4. Co monitorować

  • Każda strona (HTTP(s)): adres strony głównej, interwał 60 s. W opcjach monitora włącz powiadomienie o wygasającym certyfikacie – dostaniesz ostrzeżenie, zanim odnowienie certbota zawiedzie po cichu.
  • Treść strony (HTTP(s) – Keyword): fraza, która musi być w HTML, np. nazwa serwisu. Wyłapuje sytuację, w której serwer zwraca 200, ale z pustą lub błędną stroną.
  • Narzędzia: Umami ma endpoint /api/heartbeat, GlitchTip /_health/.
  • Zadania cron (Push): Kuma daje adres, który zadanie wywołuje po udanym przebiegu. Brak sygnału w ustalonym czasie oznacza awarię kopii zapasowej albo builda:
bash
/opt/apps/umami/backup.sh && curl -fsS -m 10 "https://status.example.pl/api/push/TWÓJ_TOKEN?status=up&msg=OK" >/dev/null
  • Domena i DNS (DNS): przydaje się, gdy zmieniasz rekordy albo domena zbliża się do odnowienia.

W Kumie 2 nowe monitory mają domyślnie 0 ponowień (w wersji 1 było 1). Przy jednym zgubionym pakiecie dostaniesz alarm, więc ustaw 1–2 ponowienia dla stron po drugiej stronie internetu.

Krok 5. Zewnętrzny monitor jako zabezpieczenie

Kuma stoi na tym samym serwerze co strony. Gdy padnie VPS, sieć u dostawcy albo sam Docker, Kuma też nie działa i nikt Cię nie powiadomi. Dlatego dołóż dwie warstwy z zewnątrz: darmowy plan UptimeRobot sprawdza strony i sam panel Kumy co 5 minut i wysyła e-mail, a Healthchecks.io w darmowym planie czeka na ping po nocnej kopii zapasowej i alarmuje, gdy ten nie przyjdzie – także wtedy, gdy serwer w ogóle nie odpowiada. Wystarczy w nich kilka monitorów: strona główna, https://status.example.pl i najważniejsze zadanie cron.

Krok 6. Kopia danych

Wersja 2 usunęła eksport i import kopii w formacie JSON z panelu, więc kopią jest katalog data. Baza SQLite zapisywana w trakcie kopiowania może być niespójna, dlatego zatrzymaj kontener na kilka sekund:

bash
cd /opt/apps/uptime-kuma
sudo install -d -m 700 backup
docker compose stop uptime-kuma
sudo sh -c 'umask 077; tar -czf "backup/uptime-kuma-$(date +%F).tar.gz" data'
docker compose start uptime-kuma

Kopie trafiają do /opt/apps/uptime-kuma/backup (prawa 700, czyta je tylko root) – tak jak w pozostałych poradnikach o aplikacjach. Wysyłaj je też poza serwer, np. jak w poradniku o kopiach. Ten sam katalog data zabezpiecz przed każdą większą aktualizacją.

Najczęstsze problemy

  • Panel ładuje się bez końca albo pokazuje błąd połączenia z serwerem. Brak nagłówków WebSocket w nginx albo zbyt krótki proxy_read_timeout na pośredniku przed nginx. Sprawdź konfigurację z kroku 2.
  • Fałszywe alarmy co kilka dni. Domyślne 0 ponowień w Kumie 2. Ustaw 1–2 ponowienia i interwał ponowienia 20–60 s.
  • Aktualizacja z wersji 1 trwa bardzo długo. Migracja do wersji 2 przelicza tabelę uderzeń serca; według przewodnika migracji może to trwać od minut do godzin. Nie przerywaj jej. Przed migracją zatrzymaj Kumę i skopiuj data, a postęp śledź w docker compose logs -f.
  • „database is locked” albo uszkodzona baza. Katalog data leży na udziale sieciowym (NFS, SMB). Przenieś go na lokalny dysk.
  • Chcesz monitorować kontenery (typ „Docker Container”). Wymaga to zamontowania gniazda /var/run/docker.sock w kontenerze Kumy, co daje jej pełną kontrolę nad Dockerem. Na małym serwerze zwykle wystarczy monitor HTTP na endpoint zdrowia usługi.

Co dalej

Monitoring dostępności nie pokaże błędów JavaScript, które widzą użytkownicy – do tego służy GlitchTip. Jeśli wolisz mieć Kumę, analitykę i stronę w jednym pliku, zobacz stack Docker Compose. Serwer pod monitoring porównasz w rankingu VPS.

Powiązane poradniki