De IceWhale-communitythread uit 2023 over Uptime Kuma is meer een introductie dan een installatiehandleiding. In het bericht staat dat de tutorial de installatie op CasaOS behandelt, terwijl de reacties vooral ingaan op waarom mensen Uptime Kuma waarderen: storingsmeldingen, monitoring van niet-kritieke services in productie en push-monitoren. De forumtekst bevat zelf geen stapsgewijze configuratie van het installatieprogramma.
Een actuele pagina moet daarom de CasaOS-context en de gebruiksscenario's uit de community behouden, maar voor de daadwerkelijke implementatie gebruikmaken van de onderhouden Docker-vereisten van Uptime Kuma.
Wat Uptime Kuma toevoegt aan een homeserver
Uptime Kuma is een zelfgehost dashboard voor monitoring. Het kan controleren of een website, TCP-service, DNS-eindpunt, pingdoel, Docker-gerelateerde service of taak met push-meldingen actief is en kan meldingen versturen wanneer de status verandert.
In de oorspronkelijke reacties werden meldingen herhaaldelijk genoemd als de praktische meerwaarde. Een dashboard is nuttig, maar het belangrijkste voordeel is dat je merkt dat een service niet beschikbaar is voordat iemand in het huishouden dat meldt.
Gebruik de huidige Uptime Kuma-container
De huidige implementatie-instructies voor Uptime Kuma gebruiken de onderhouden image louislam/uptime-kuma:2. De webapplicatie luistert op poort 3001 en slaat de permanente database en configuratie op onder /app/data.
Voor een huidige aangepaste CasaOS-app vertaal je de onderhouden Docker-installatie-instellingen van Uptime Kuma naar het CasaOS-appformulier, in plaats van een oude image-tag uit een video uit 2023 te gebruiken.
Stel het dashboard beschikbaar op poort 3001
De webservice in de container gebruikt TCP-poort 3001. Als die hostpoort al bezet is, koppel je een andere hostpoort aan containerpoort 3001 en open je de CasaOS-app via de gekozen hostpoort.
Als je de hostpoort wijzigt, hoef je de interne poort van Uptime Kuma niet te wijzigen, tenzij de upstreamapplicatie die wijziging expliciet ondersteunt en nodig heeft.
Behoud /app/data
Koppel een CasaOS-hostmap of Docker-volume aan /app/data. Dit is het belangrijkste doel voor back-ups, omdat deze map de monitoringconfiguratie, gebruikersgegevens en SQLite-database bevat.
Als je de container opnieuw aanmaakt zonder dat permanente volume, gedraagt deze zich als een nieuwe Uptime Kuma-installatie.
Bewaar de database op een bestandssysteem met betrouwbare vergrendeling
De huidige richtlijnen van Uptime Kuma waarschuwen dat de SQLite-database betrouwbare POSIX-bestandsvergrendeling nodig heeft en raden specifiek bestandssystemen zoals veel NFS-configuraties voor de datamap af.
Voor een homeserver is het bewaren van /app/data op lokale opslag de eenvoudigste keuze. Je kunt die lokale map vervolgens back-uppen naar een andere schijf of externe bestemming.
Kies monitors die aansluiten bij de gebruikerservaring
Een ping-monitor bewijst alleen dat een machine op ICMP reageert. Als de werkelijke vereiste is dat “Jellyfin moet laden”, is een HTTP-monitor voor het Jellyfin-eindpunt betekenisvoller.
Een praktische set kan bestaan uit:
- HTTP-controles voor webapplicaties;
- TCP-controles voor services zonder bruikbaar web-eindpunt;
- DNS-controles voor Pi-hole of AdGuard Home;
- ping-controles voor elementaire bereikbaarheid van hosts;
- push-monitors voor geplande taken die hun voltooiing moeten melden.
Waarom de in de thread genoemde push-monitor belangrijk is
Een deelnemer uit de community zei specifiek dat die push-monitors vaak gebruikte. In plaats van dat Uptime Kuma een service opvraagt, roept een back-upscript of geplande taak bij succes een unieke URL aan. Als die heartbeat niet binnen het verwachte tijdvenster arriveert, markeert Uptime Kuma de monitor als ongezond.
Dit is nuttig voor taken waarbij “de server is online” niet bewijst dat de taak daadwerkelijk is uitgevoerd.
Test meldingen vóór de eerste storing
Configureer ten minste één meldingskanaal en activeer bewust een testmelding. Een monitoringsysteem dat stilletjes geen meldingen verstuurt, is slechts een historisch dashboard.
Overweeg bij services voor het huishouden ook alertmoeheid. Als je elk klein eindpunt met directe meldingen monitort, kan het echte storingen juist gemakkelijker maken om te negeren.
Houd het monitoringdashboard privé, tenzij externe toegang bewust is ingesteld
Uptime Kuma kan interne hostnamen, servicenamen, netwerkadressen en storingsgeschiedenis onthullen. Stel het niet rechtstreeks bloot aan het openbare internet alleen omdat monitoring op afstand nuttig is. Gebruik een VPN, privé-overlaynetwerk of geauthenticeerde reverse proxy als externe toegang nodig is.
Beschouw de CasaOS-thread uit 2023 niet als een actuele versiepin
De brondiscussie prijst een goed onderhouden applicatie, maar bevat geen imageversie. Dat is gunstig: gebruik de huidige upstream-release in plaats van exact de container te proberen reconstrueren die in september 2023 bestond.
Veelgestelde vragen over Uptime Kuma op CasaOS
Welke poort gebruikt de huidige versie van Uptime Kuma?
Poort 3001 voor de webinterface.
Welke map moet permanent worden opgeslagen?
/app/data.
Waarom moet de datamap op lokale opslag blijven?
De SQLite-database vereist betrouwbare bestandsvergrendeling en de huidige upstream-richtlijnen waarschuwen tegen ongeschikte netwerkbestandssystemen.
Wat waardeerde de oorspronkelijke community het meest?
Meldingen en de functionaliteit voor push-monitors werden in de reacties herhaaldelijk benadrukt.
