Uptime Kuman itsehostaus vuonna 2026: hälytykset, TLS ja pysyvä data

Useimmat Uptime Kuman asennusohjeet päättyvät ensimmäisen sivulatauksen jälkeen. Se on liian aikaista: data volume voi olla vain luku -tilassa tai container DNS ei ehkä pysty selvittämään valvottavien hostien osoitteita. Hyödyllinen production-testi on vaativampi — luo HTTP- ja TCP-monitorit, aiheuta yksi hallittu häiriö ja vastaanota valitun providerin kautta sekä hälytys että palautumisilmoitus.

Uptime Kuman rooli on suoraviivainen: olemassa olevien palveluiden monitorointi ja hälytykset yli 90 kohteeseen. Sen operatiivinen rajapinta kattaa muutakin kuin web-prosessin, joten riippuvuudet, tallennettu tila ja public route on nimettävä eksplisiittisesti ennen kuin oikea data alkaa saapua.

Määritä Uptime Kuman onnistumiskriteerit ensin

Hyödyllinen Uptime Kuma -kaavio näyttää public routen, private portin 3001, tilarajan ja kaikki tukevat vaatimukset. Merkitse, mitkä nuolet kuljettavat tunnistetietoja ja mitkä ovat tavallista käyttäjäliikennettä. Uptime Kuman ulkoinen vaatimus on outbound access jokaiseen valvottavaan endpointiin ja alert providerille. Testaa outbound DNS, TLS ja providerin toiminta julkaisematta uutta inbound-palvelua.

Todista kaavio yhdellä oikealla toimella: luo HTTP- ja TCP-monitorit, aiheuta yksi hallittu häiriö ja vastaanota valitun providerin kautta sekä hälytys että palautumisilmoitus. Todennäköinen kuormitus syntyy monitorien aikavälistä, retry countista, status page -liikenteestä ja samalla sekunnilla tehtävien outbound probejen määrästä; monitoroi tätä polkua sen sijaan, että käsittelisit kaikkia HTTP-pyyntöjä samanarvoisina.

Käytä Uptime Kumaa sen todellisen pullonkaulan ympärillä

Uptime Kuman ensimmäinen hyödyllinen operatiivinen metriikka kertoo, pystyykö se luomaan HTTP- ja TCP-monitorit, aiheuttamaan yhden hallitun häiriön ja toimittamaan valitun providerin kautta sekä hälytyksen että palautumisilmoituksen. Yhdistä tähän saturaatiosignaalit, jotka kuvaavat monitorien aikaväliä, retry countia, status page -liikennettä ja samalla sekunnilla tehtävien outbound probejen määrää. Pelkkään prosessiin perustuvan proben ei pitäisi kutsua raskaita riippuvuuksia tai käynnistää containeria uudelleen, koska upstream on hetkellisesti saavuttamattomissa.

Käsittele päivityksiä datamuutoksina, koska SQLite-migraatiot ja notification provider -muutokset voivat muuttaa nopean image pullin tilalliseksi sovelluspäivitykseksi. Kiinnitä versiot, harjoittele palautetulla tilalla ja pidä edellinen image saatavilla, kunnes rollback on edelleen mahdollinen. Kun data volume on vain luku -tilassa tai container DNS ei pysty selvittämään valvottavien hostien osoitteita, säilytä ennen uudelleenkäynnistystä kerätyt lokit; ne sisältävät yleensä syyn paljastavan viestin.

Tallenna tunnetusti toimiva Uptime Kuma -deployment

Määritä Uptime Kumalle ennen käynnistystä tunnetusti toimiva transaktio: luo HTTP- ja TCP-monitorit, aiheuta yksi hallittu häiriö ja vastaanota valitun providerin kautta sekä hälytys että palautumisilmoitus. Tallenna sen edellytykset, odotettu vastaus ja cleanup-vaiheet versionhallintaan ilman salaisia arvoja. Kiinnitä tämän referenssin luomiseen käytetty image-versio.

Käytä transaktiota replacementin ja erillisen restoren validointiin. Palautettu palvelu on hyväksyttävä vasta, kun monitorihistoria, notification credentials ja maintenance windowt ovat palautuneet ja testihälytys toimitetaan edelleen. Seuraa samalla monitorien aikaväliä, retry countia, status page -liikennettä ja samalla sekunnilla tehtävien outbound probejen määrää ja muuta hitain tai rajoittavin osa service-level-hälytykseksi.

Testiin tarvitaan myös negatiivinen tapaus: estä tilapäisesti outbound accessin testipolku, jota käytetään jokaiseen valvottavaan endpointiin ja alert providerille. Varmista, että Uptime Kuma tuottaa toimintaan johtavan virheen säilyttäen datan, palauta toimiva tila ja toista tunnetusti toimiva transaktio. Molempien tulosten säilyttäminen estää pinnallista health endpointia muodostumasta ainoaksi production-ympäristön todisteeksi.

Tarkistettavat container-asetukset

Käytä containeria korvattavana runtime-ympäristönä, älä totuuden lähteenä.

docker run -d \
  --name uptime-kuma \
  --restart unless-stopped \
  -p 127.0.0.1:3001:3001 \
  -v uptime-kuma-data:/app/data \
  -e UPTIME_KUMA_PORT=3001 \
  louislam/uptime-kuma:1

Salli ja varmista outbound- tai client-side-polku, jota tarvitaan jokaiseen valvottavaan endpointiin ja alert providerille pääsemiseen. Tarkista containerin käyttäjä, kirjoitettavat polut ja bindattu listener ennen kuin julkaiset sen. Suorita koko toiminto — luo HTTP- ja TCP-monitorit, aiheuta yksi hallittu häiriö ja vastaanota valitun providerin kautta sekä hälytys että palautumisilmoitus — ja tallenna tuloksen tuottanut tarkka image reference.

Palauta Uptime Kuma tyhjälle hostille

Suojaa Uptime Kuman tila ennen containerin optimointia. Tarvittava kokonaisuus on SQLite-tietokanta ja /app/data-polkuun ladatut assetit. Mounttaa /app/data ennen bootstrapia, kirjoita harmitonta testidataa ja korvaa container varmistaaksesi, että polku on todella persistentti. Jos useiden storejen on pysyttävä yhdenmukaisina, dokumentoi järjestys, jossa kirjoitukset keskeytetään ja varmuuskopiot otetaan.

Säilytä kopiot deployment-palvelimen ulkopuolella ja salaa tunnistetietoja tai yksityistä sisältöä sisältävä materiaali. Recovery onnistuu, kun monitorihistoria, notification credentials ja maintenance windowt palaavat ja testihälytys toimitetaan edelleen. Persistentin mountin ja erillisen kopion ero käsitellään oppaassa persistent storage and snapshots.

Anna Uptime Kumalle yksi kanoninen osoite

Julkaise yksi vakaa HTTPS-origin reverse proxyn kautta. Ohjaa valittu hostname containerin porttiin 3001, välitä alkuperäinen host ja HTTPS-scheme ja vältä toisen suoran originin julkaisemista.

Testaa Uptime Kumaa puhtaalta ulkoiselta clientilta. Erottele ingress-virhe tunnetusta sovellusrajasta — data volume on vain luku -tilassa tai container DNS ei pysty selvittämään valvottavien hostien osoitteita. Certificate-, DNS- tai 502-virhe kuuluu routingiin; pyyntö, joka saavuttaa Uptime Kuman ja epäonnistuu myöhemmin, liittyy sovelluksen tilaan, kapasiteettiin tai sen tukivaatimukseen. Custom-domain TLS -opas käsittelee ensimmäistä ryhmää.

Uptime Kumaa koskevat tietoturvapäätökset

Sovelluskohtainen tietoturvariski on first-user setupin suorittaminen julkisesti näkyvässä instanssissa. Operatiivinen ratkaisu on viimeistellä first-user setup yksityisesti ja suojata dashboardit sekä status page -hallinta sen jälkeen erikseen. Suorita bootstrap rajoitetun routen kautta ja poista väliaikainen setup-pääsy heti tämän jälkeen.

UPTIME_KUMA_PORT ohjaa toimintaa, ei luottamuksellisuutta; validoi sen tyyppi ja arvo ja säilytä aidot Uptime Kuma -tunnistetiedot erillään. Anna Uptime Kuma -prosessille vain dokumentoidut mountit ja riippuvuusreitit; vältä host root- ja Docker socket -pääsyä. Lokita epäonnistuneet autentikoinnit ja konfiguraatiovirheet, mutta redaktoi tokenit, connection stringit ja käyttäjien sisältö.

Dockup-deployment tarvitsee edelleen Uptime Kuma -hyväksyntätestin

Routing, certificatejen käsittely, palvelun korvaaminen ja liitetty tallennustila ovat järkeviä automaation kohteita. Dockup hoitaa nämä Uptime Kumaa varten ja voi provisioida siihen liittyvän managed databasen tai muodostaa yhteyden asiakkaan omalla palvelimella oleviin palveluihin.

Sen ei kuitenkaan pidä keksiä Uptime Kuman trust policyä. Deploymentin jälkeen julkaise yksi vakaa HTTPS-origin reverse proxyn kautta, pakota tämä raja — viimeistele first-user setup yksityisesti ja suojaa dashboardit sekä status page -hallinta sen jälkeen erikseen — ja varmista seuraavan skenaarion tulos: luo HTTP- ja TCP-monitorit, aiheuta yksi hallittu häiriö ja vastaanota valitun providerin kautta sekä hälytys että palautumisilmoitus. Lopputuloksena on yhden klikkauksen infrastruktuuri, jolla on sovelluskohtainen hyväksyntätesti.

Usein kysytyt kysymykset

Mitä Uptime Kuma tarvitsee tuotantodeploymentiin?

Reititä Uptime Kuma -container portissa 3001 yhden HTTPS-originin kautta. Ulkoinen toimitusvaatimus on outbound access jokaiseen valvottavaan endpointiin ja alert providerille. Älä pidä Uptime Kumaa valmiina, ennen kuin pystyt luomaan HTTP- ja TCP-monitorit, aiheuttamaan yhden hallitun häiriön ja vastaanottamaan valitun providerin kautta sekä hälytyksen että palautumisilmoituksen.

Mitkä Uptime Kuman tiedot kuuluvat varmuuskopioon?

Persistoi /app/data ja sisällytä samaan recovery manifestiin SQLite-tietokanta ja /app/data-polkuun ladatut assetit. Puhdas Uptime Kuma -restore on onnistunut vain, kun monitorihistoria, notification credentials ja maintenance windowt palaavat ja testihälytys toimitetaan edelleen.

Tarvitseeko Uptime Kuma HTTPS:n reverse proxyn takana?

Käytä julkisessa Uptime Kuma -originissa HTTPS:ää ja pidä portti 3001 sisäisellä reitillä. Sovella Uptime Kuman asetusta oikein: julkaise yksi vakaa HTTPS-origin reverse proxyn kautta. Uptime Kuman tapauksessa HTTPS suojaa tunnistetietoja tai käyttäjien sisältöä siirron aikana ja pitää originista riippuvan client-käyttäytymisen yhdenmukaisena.

Miten Uptime Kuman päivitys pitäisi testata?

Palauta nykyinen Uptime Kuma -tila eristettyyn deploymentiin, ota ehdokasversio käyttöön ja toista sen hyväksyntätransaktio. Kiinnitä erityistä huomiota siihen, että SQLite-migraatiot ja notification provider -muutokset voivat muuttaa nopean image pullin tilalliseksi sovelluspäivitykseksi. Säilytä edellinen Uptime Kuma -image, kunnes sen data-migraation ja rollbackin rajat ovat selvillä.