Uptime Kuma VPS-telepítés: Docker Compose, Caddy, értesítések

Az Uptime Kuma egy nyílt forráskódú, saját üzemeltetésű monitor HTTP(S)-, TCP-, ping-, DNS-, WebSocket- és egyéb ellenőrzésekhez. Külön VPS-en futva akkor is tovább ellenőriz, amikor a éles szervered leáll, ahelyett hogy vele együtt eltűnne.

Ez az Uptime Kuma VPS-telepítés a v2-t telepíti Docker Compose-zal, a 3001-es portot loopbacken tartja, HTTPS-t ad hozzá Caddy-vel, az értesítéseket a Telegramra, Discordra és Slackre irányítja, és közzétesz egy állapotoldalt.

Előfeltételek és amire szükséged lesz

Egy VPS legalább 1 vCPU-val, 1 GB RAM-mal és 10 GB helyi SSD-tárhellyel
Ubuntu 24.04 LTS vagy más aktuális, Docker által támogatott Ubuntu kiadás
A VPS-re telepített Docker Engine és Docker Compose
Egy domain vagy aldomain, amely A rekorddal a VPS-re mutat (például status.example.com)
SSH-hozzáférés és alapszintű jártasság a parancssorban

Ha a Docker még nincs telepítve, kövesd a Docker Ubuntu telepítési útmutatóját. Ez telepíti a Docker Engine-t és az alább használt Compose bővítményt.

Miért kell a monitorozó VPS-nek elkülönülnie attól, amit figyel

Production in Region A has failed and its website, API and database are down, while Uptime Kuma on a separate VPS in Region B stays online, keeps probing those services and routes alerts to Telegram, Discord and Slack. An external watchdog checks Uptime Kuma itself.

Az azonos szerveren futó éles rendszer és monitorozás ugyanabba a hibatartományba esik. Ha az a szerver leáll, egyszerre tűnik el az alkalmazás és az a rendszer, amelynek riasztania kellene.

Két gyakorlati elrendezés javít ezen:

Azonos szolgáltató, másik helyszín. Tedd az éles rendszert és a monitorozást külön hostokra, eltérő helyszínekre. Ez csökkenti az egyetlen szerver vagy egyetlen adatközpont kiesésének kockázatát, de nem véd meg minden szolgáltatói szintű hálózati vagy vezérlősík-incidenstől.
Teljesen más szolgáltató. Ha a monitort máshol üzemelteted, az a szolgáltató egészét érintő incidensek ellen is véd. Cserébe eggyel több fiókot, számlát és üzemeltetési felületet kell kezelned.

Egyetlen Uptime Kuma példány mögött továbbra sincs külső őrszem. Vegyél fel egy külső HTTP(S) ellenőrzést a nyilvános állapotoldalára. Az UptimeRobot ingyenes csomagja jelenleg 50 monitort tartalmaz ötperces időközzel. Ettől az Uptime Kuma nem lesz magas rendelkezésre állású, de szólni fog, ha maga a monitor tűnik el.

Ugyanez a szabály vonatkozik a nyilvános állapotoldalakra is: ami szól a hibáról, nem lehet ugyanabban a hibatartományban, mint ami elromlik.

Építkezz Linux VPS-en root hozzáféréssel, NVMe-vel és AMD EPYC teljesítménnyel.

Linux csomagok megtekintése

A VPS méretezése

Az Uptime Kuma esetében nincs megbízható képlet a monitorok száma és a RAM között, mert a terhelés a monitor típusától, az időköztől, az újrapróbálkozási beállításoktól és az előzmények megőrzési idejétől függ. Az egyszerű HTTP(S)-, TCP-, ping- és DNS-ellenőrzések könnyebbek, mint a Chromiumot futtató Browser Engine ellenőrzések.

Néhány alapvető ellenőrzéshez indulj 1 vCPU-val, 1 GB RAM-mal és helyi SSD-tárhellyel. A tényleges használatot ezzel figyeld: docker stats uptime-kuma az adatbázis növekedését pedig ezzel: du -sh /opt/uptime-kuma/data. Akkor adj hozzá memóriát, ha a használat tartósan magas marad, ha a konténer OOM kill-t jelez, vagy ha Browser Engine ellenőrzéseket veszel be.

A teljes v2 image tartalmazza a Chromiumot és a beágyazott MariaDB-t; Docker tag dokumentáció elmagyarázza a full és a slim image közötti különbséget.

Uptime Kuma telepítése Docker Compose-zal

Mentsd ezt a fájlt docker-compose.yml néven a /opt/uptime-kuma/ könyvtárba:

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

Három sort érdemes kiemelni:

Az image: louislam/uptime-kuma:2 rögzíti a fő verziót. A :2 tag a stabil 2.x kiadási ágat követi. Ne használd a :latest taget.
A 127.0.0.1:3001:3001 csak a localhosthoz köti a konténert. A nyílt internet soha ne érje el közvetlenül a 3001-es portot. A TLS-tanúsítványt és a nyilvános hosztnevet a fordított proxy tartja.
Az adatkötet tárolja az adatbázist, a monitorok beállításait és az előzményeket. Tartsd helyi tárolón, mert az Uptime Kuma telepítési dokumentációja figyelmeztet, hogy a megbízható POSIX zárolás nélküli fájlrendszerek, köztük sok NFS-beállítás, megsérthetik az SQLite-ot. Állítsd le a stacket, mielőtt fájlrendszerszintű másolatot készítesz.

Indítsd el és ellenőrizd:

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

A docker compose ps várt kimenete:

NAME          IMAGE                       STATUS                   PORTS
uptime-kuma   louislam/uptime-kuma:2      Up (healthy)             127.0.0.1:3001->3001/tcp

Az irányítópult első eléréséhez ne nyisd meg a 3001-es portot az internet felé, még rövid időre sem. Használj SSH-alagutat:

ssh -L 3001:127.0.0.1:3001 [email protected]

Nyisd meg a böngészőben a http://localhost:3001 címet, hozd létre az adminfiókot, adj meg erős jelszót, majd zárd az alagutat. Ettől kezdve az irányítópult HTTPS-en, a fordított proxyn keresztül érhető el.

Ha nincs szükséged kézi Compose-ra, kínálunk Uptime Kuma egykattintásos alkalmazást is. Az alkalmazás oldalán jelenleg v1 szerepel, így nem egyezik az útmutatóban leírt v2-es Compose telepítéssel. Ha kifejezetten v2 kell, válaszd a kézi Compose utat.

Fordított proxy és TLS

Public traffic reaches Caddy on the host or an Nginx Proxy Manager container over HTTPS on port 443. Caddy forwards to Uptime Kuma on 127.0.0.1:3001 while the NPM container uses a shared Docker network instead. Public access to port 3001 is blocked, and first-time setup runs through an SSH tunnel to localhost:3001.

Az Uptime Kuma ne legyen közvetlenül elérhető kívülről. Tegyél elé fordított proxyt a TLS, a rendes URL-kezelés és az egyetlen nyilvános belépési pont miatt. Két út van.

Caddy. Ha a Caddy még nincs telepítve, kövesd a hivatalos Ubuntu csomagtelepítési lépéseket. Ha a Caddy hosztszolgáltatásként fut, az alábbi Caddyfile a loopbackon futó Uptime Kuma felé proxyzik, és automatikusan intézi a tanúsítvány kiállítását és megújítását.

Tipp: ha a monitorozó VPS-en csak az Uptime Kuma fut, válaszd a Caddy-t. A Caddyfile három sor, a tanúsítvány kiállítását és megújítását pedig a Caddy magától elintézi. Nincs Certbot és nincs külön megújítási időzítő, amit hajnali 4-kor kellene bébiszitterkedni.

Mentsd ezt /etc/caddy/Caddyfile néven:

status.example.com {
    reverse_proxy 127.0.0.1:3001
}

Töltsd újra a Caddy-t:

sudo systemctl reload caddy

Ellenőrizd:

curl -I https://status.example.com

Sikeres 2xx vagy 3xx választ kell kapnod érvényes tanúsítvánnyal. Ha a kapcsolat nem jön létre, ellenőrizd, hogy a domain A vagy AAAA rekordja erre a VPS-re mutat, hogy a 80-as és 443-as port elérhető, és hogy a Caddy mindkettőre rá tud kötni. Ezek mind részei a Caddy automatikus HTTPS követelményeinek.

Nginx Proxy Manager. Ha az NPM közvetlenül a hoston fut, vegyél fel egy Proxy Hostot a status.example.com címhez, irányítsd a 127.0.0.1 3001-es portjára, kérj Let's Encrypt tanúsítványt, és kapcsold be a Websockets Support opciót. Ha az NPM Dockerben fut, a 127.0.0.1 magára az NPM konténerre mutat vissza. Ilyenkor kösd az NPM-et és az Uptime Kuma konténerét ugyanarra a Docker hálózatra, majd irányítsd a proxy hostot az uptime-kuma 3001-es portjára.

Értesítések irányítása: Telegram, Discord, Slack

Az Uptime Kuma ugyanazt a monitoreseményt több értesítési csatornára is el tudja küldeni. Állítsd be egyszer az egyes szolgáltatókat, majd aszerint csatolj egy vagy több csatornát egy monitorhoz, hogy kinek kell a riasztás.

Az értesítéseket globálisan itt állítod be: Beállítások > Értesítések, majd az egyes monitorokhoz rendeled őket. Egy monitor egy vagy több csatornát is meg tud szólaltatni. Ugyanaz a riasztás mehet Telegramon az ügyeletes mérnöknek, Slacken a csapatnak és e-mailben az auditnaplóba, mindez egyetlen eseményből.

A Telegramban írj a @BotFather és futtasd a /newbot parancsot. Válassz nevet és felhasználónevet. A BotFather válaszul küld egy bot tokent. Tedd el.
Küldj bármilyen üzenetet az új botodnak. Utána nyisd meg böngészőben a https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates címet. Keresd meg a chat.id mezőt, az a te chat azonosítód.
Az Uptime Kuma felületén: Beállítások > Értesítések > Értesítés beállítása > Telegram. Illeszd be a bot tokent és a chat azonosítót. Kattints erre: Teszt. Ellenőrizd, hogy a bot elküldi a tesztriasztást.
Ha a tesztüzenet nem érkezik meg, ellenőrizd a bot token és a chat azonosító helyességét, és győződj meg róla, hogy a VPS tűzfala engedi a kimenő HTTPS-t az api.telegram.org felé.

Discord

Nyisd meg azt a Discord szervert, ahová a riasztásokat kéred. Kattints jobb gombbal a célcsatornára, majd Csatorna szerkesztése > Integrációk > Webhookok > Új webhook. Adj neki nevet (például „Uptime Kuma”), válaszd ki a csatornát, és másold ki a webhook URL-t.
Az Uptime Kuma felületén: Beállítások > Értesítések > Értesítés beállítása > Discord. Illeszd be a webhook URL-t. Opcionálisan beállíthatod a felhasználónevet és az avatart is.
Kattintson Teszt. Ellenőrizd, hogy a webhook kiposztolja a tesztriasztást a csatornára.

Slack

A Slackben hozz létre egy Incoming Webhook ahhoz a csatornához, ahová a riasztásokat kéred. A Slack egy https://hooks.slack.com/services/T.../B.../.... alakú webhook URL-t ad vissza.
Az Uptime Kuma felületén: Beállítások > Értesítések > Értesítés beállítása > Slack. Illeszd be a webhook URL-t. Opcionálisan beállíthatod az ikont és a csatorna felülírását is.
Kattintson Teszt.

Ha minden teszt lefut, szerkeszd az egyes monitorokat, és válaszd ki, mely értesítési csatornákat használják. Állítsd be a Max Retries (maximális újrapróbálkozás) és Retry Interval (újrapróbálkozások közti idő) úgy, hogy egyetlen rövid hiba ne váltson ki azonnal riasztást.

A beépített állapotoldal (és mikor növöd ki)

Az Uptime Kuma nyilvános állapotoldalakat kínál egyedi sluggal, csoportosított monitorokkal, saját domainekkel, incidensbejegyzésekkel és tervezett karbantartási üzenetekkel. Egyetlen példányból több állapotoldalt is közzétehetsz, különböző szolgáltatásokhoz vagy közönségekhez.

A nagyobb korlát az ügyfélkommunikáció. A látogatók jelenleg nem tudnak e-mailben feliratkozni a frissítésekre közvetlenül az állapotoldalról, és ez a nyilvános oldal továbbra is ugyanannak az Uptime Kuma alkalmazásnak a része, mint az üzemeltetői irányítópult. A látogatói önfeliratkozás még mindig nyitott funkciókérésként szerepel.

Ha ügyfélfeliratkozásokra vagy a monitorozó irányítópulttól különálló állapotrendszerre van szükséged, a Kener az egyik alternatíva. A saját üzemeltetésű monitorozó rendszerről szóló cikkünk elmagyarázza, hogyan lehet a két eszközt párosítani.

Gyakori problémák

Az értesítések némán elbuknak, ha a VPS tűzfala blokkolja a kimenő HTTPS-t. Tünet: a Test gomb egyes csatornáknál működik, másoknál nem. Megoldás: ellenőrizd, hogy a kimenő HTTPS-kapcsolatok engedélyezettek, és hogy a curl -I https://api.telegram.org sikerrel fut a VPS-ről.

A böngésző „ERR_TOO_MANY_REDIRECTS” hibát mutat a proxy bekapcsolása után. Nézd meg, nincs-e kettőzött HTTP-ről HTTPS-re irányítás a Caddy-ben, a Nginx Proxy Managerben vagy egy előtte lévő CDN-ben. Az Uptime Kuma továbbra is HTTP-t szolgáljon ki a 3001-es porton, a TLS-t pedig a nyilvános fordított proxy zárja le. Ha bekapcsolod a megbízható proxy fejléceket, az aktuális útvonal a Beállítások > Reverse Proxy > HTTP fejlécek > Trust Proxy.

A konténer néhány percenként újraindul. Nézd meg, hogy a konténer memóriahiány miatt állt-e le, majd figyeld az aktuális használatot a docker stats uptime-kuma paranccsal. Ha a konténert OOM ölte meg, vagy a memória a VPS határa közelében marad, adj hozzá RAM-ot, csökkentsd a nehéz ellenőrzéseket, vagy növeld az időközüket.

Az állapotoldal localhoston működik, a nyilvános hosztnéven viszont nem. Ellenőrizd, hogy a fordított proxy változatlanul továbbítja a gyökérútvonalat, megőrzi a Host fejlécet, és támogatja a WebSocketst. Az Uptime Kuma nem támogatja az alkönyvtárba telepítést, ezért használj külön domaint vagy aldomaint az example.com/uptime-kuma-féle útvonal helyett.

Összegzés

Az Uptime Kuma külön VPS-en kézben tartja az ellenőrzéseket, a riasztások útvonalát és a nyilvános állapotoldalt, de a frissítések, a mentések, az operációs rendszer foltozása és a monitor külső őrszeme is a tiéd lesz. Válassz az éles rendszertől eltérő helyszínen lévő VPS-t, telepítsd a v2-t Docker Compose-zal, vagy használd az egykattintásos alkalmazást, miután megnézted a feltüntetett verziót, tegyél elé Caddy-t, és kösd be azokat a csatornákat, amelyeket a csapatod tényleg néz.

Gyakran ismételt kérdések

Mennyi RAM kell az Uptime Kuma futtatásához?

Az Uptime Kuma esetében nincs megbízható képlet a monitorok száma és a RAM között, mert a fogyasztás a monitor típusától, az ellenőrzési időköztől, az újrapróbálkozási beállításoktól, az előzmények megőrzésétől és a Browser Engine használatától függ. Néhány alapvető ellenőrzéshez indulj 1 GB RAM-mal, és nézd a tényleges használatot a docker stats uptime-kuma paranccsal. Adj hozzá memóriát, ha a használat a határ közelében marad, vagy ha a konténert megöli az OOM.

Futtatható az Uptime Kuma ugyanazon a szerveren, mint az alkalmazásom?

Nem. Ha a monitorozó eszköz és az alkalmazás közös szerveren van, egy kiesés egyszerre viszi le mindkettőt, és pont akkor veszíted el a riasztást, amikor a legnagyobb szükség lenne rá. Az Uptime Kuma fusson külön VPS-en, lehetőleg másik adatközpontban.

Tud az Uptime Kuma riasztásokat küldeni Telegramra, Discordra és Slackre?

Igen. A Telegram, a Discord és a Slack beépített értesítési szolgáltatások, az e-mail, az általános webhookok, a PagerDuty, az ntfy, a Mattermost és sok más mellett. A Telegram bot tokent és chat azonosítót használ, a Discord és a Slack pedig webhook URL-eket. Ugyanahhoz a monitorhoz több értesítési csatornát is csatolhatsz.

Mi a különbség az Uptime Kuma és az UptimeRobot között?

Az Uptime Kuma saját üzemeltetésű, tehát a szerver, a frissítések, a mentések és a riasztások útvonala a te dolgod. Akár 20 másodperces ellenőrzési időközt is támogat. Az UptimeRobot üzemeltetett SaaS, és a jelenlegi ingyenes csomagja 50 monitort tartalmaz ötperces ellenőrzésekkel. Válaszd az Uptime Kumát, ha kontrollt akarsz, vagy az UptimeRobotot, ha nem szeretnél monitorozó szervert üzemeltetni.

Kínál az Uptime Kuma nyilvános állapotoldalt?

Igen. Kiválaszthatod, mely monitorok látszanak, csoportosíthatod őket, több állapotoldalt tehetsz közzé, saját domainhez kötheted őket, és karbantartási üzeneteket is ütemezhetsz. A látogatói e-mailes önfeliratkozás nincs beépítve, ezért ha az ügyfeleknek fel kell iratkozniuk a frissítésekre, használj külön, ügyfeleknek szánt állapotoldal-eszközt.

Az Uptime Kuma beállítása egy VPS-en