Uptime Kuma en Beszel zelf hosten op een VPS met Docker Compose

15 min leestijd·Matthieu·uptime-kumabeszelmonitoringself-hostingdocker-composedocker|

Implementeer Uptime Kuma voor externe beschikbaarheidsmonitoring en Beszel voor servermetrieken op één VPS. Docker Compose-setup met notificaties, waarschuwingen, statuspagina's en beveiligingshardening.

Je app is gedeployed. Gebruikers melden zich aan. Maar je hebt geen idee of het om 3 uur 's nachts uitvalt, of de schijf volloopt terwijl je slaapt.

Deze handleiding implementeert twee monitoringtools op één VPS met Docker Compose:

  • Uptime Kuma (84k+ GitHub-sterren) bewaakt externe beschikbaarheid: HTTP-endpoints, TCP-poorten, DNS-records, SSL-certificaten.
  • Beszel (~20k sterren) bewaakt de interne servergezondheid: CPU, RAM, schijf, netwerk en Docker-statistieken per container.

Samen verbruiken ze ongeveer 150-180 MB RAM. Een Prometheus + Grafana + node_exporter-stack voor dezelfde taak heeft 800+ MB nodig.

Vereisten: Een VPS met Debian 12 of Ubuntu 24.04 waarop Docker en Docker Compose geïnstalleerd zijn. Een reverse proxy (Caddy of Nginx) die TLS afhandelt. Een domeinnaam met DNS die naar je server wijst. Deze handleiding gebruikt Caddy voor reverse proxy-voorbeelden. Docker in productie op een VPS: wat er misgaat en hoe je het oplost

Wat is het verschil tussen Uptime Kuma en Beszel?

Uptime Kuma bewaakt externe beschikbaarheid. Het vertelt je of je websites, API's en diensten bereikbaar zijn van buiten je server. Beszel bewaakt de interne servergezondheid: CPU-gebruik, RAM, schijfruimte, netwerkbandbreedte en Docker-statistieken per container. Een webserver kan lage CPU en genoeg vrij geheugen rapporteren terwijl hij volledig onbereikbaar is door een verkeerd geconfigureerde firewall of een verlopen TLS-certificaat. Je hebt beide tools nodig.

Functie Uptime Kuma Beszel
Wat het bewaakt HTTP, TCP, DNS, ping, SSL-verloop, push/heartbeat CPU, RAM, schijf, netwerk, temperatuur, Docker-containers
Architectuur Enkele container, webinterface Hub + agent (één agent per bewaakte server)
Database SQLite (standaard) of MariaDB PocketBase (ingebouwde SQLite)
Notificatiekanalen 90+ (e-mail, Telegram, Discord, Slack, webhooks, enz.) E-mail (SMTP via PocketBase)
Statuspagina's Ja, openbaar met aangepast domein Nee
RAM-gebruik ~80-120 MB Hub: ~10-50 MB, Agent: ~25 MB
GitHub-sterren 84k+ ~20k

Geen van beide tools vervangt de ander. Uptime Kuma vangt externe storingen op. Beszel vangt uitputting van resources op voordat het externe storingen veroorzaakt.

Hoeveel RAM gebruikt de monitoringstack?

Uptime Kuma v2.x gebruikt ongeveer 80-120 MB RAM afhankelijk van het aantal monitors. De Beszel-hub voegt 10-50 MB toe en elke agent gebruikt circa 25 MB. De gecombineerde stack draait comfortabel op een 1 GB VPS, met ongeveer 150-180 MB totaal. Ter vergelijking: Prometheus + Grafana + node_exporter samen hebben 800+ MB nodig alleen al in rust.

Stack RAM in rust Opzettijd Geschikt voor
Uptime Kuma + Beszel ~150-180 MB 30 minuten Kleine tot middelgrote self-hosted setups
Prometheus + Grafana + node_exporter ~800 MB+ 2-4 uur Grootschalige infrastructuur met aangepaste queries
Netdata ~300-400 MB 15 minuten Realtime metrieken, enkele server

Hoe installeer ik Uptime Kuma met Docker Compose?

Uptime Kuma draait als enkele container en bedient zijn webinterface op poort 3001. Het onderstaande Compose-bestand pint op de major versietag 2, bindt alleen aan localhost, stelt resourcelimieten in en voegt een health check toe.

Maak de projectmap aan:

mkdir -p /opt/uptime-kuma && cd /opt/uptime-kuma

Maak het Compose-bestand aan:

# /opt/uptime-kuma/compose.yaml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - ./data:/app/data
    environment:
      - TZ=Europe/Berlin
    deploy:
      resources:
        limits:
          memory: 256m
          cpus: "0.5"
    healthcheck:
      test: ["CMD", "node", "/app/extra/healthcheck.js"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 15s

De binding 127.0.0.1:3001:3001 zorgt ervoor dat de container alleen op localhost luistert. Zonder het prefix 127.0.0.1 publiceert Docker de poort op alle interfaces, waardoor je firewall wordt omzeild. Docker omzeilt UFW: 4 geteste oplossingen voor je VPS

Start de container:

docker compose up -d

[+] Running 1/1
 ✔ Container uptime-kuma  Started

docker compose ps

NAME           IMAGE                      COMMAND                  SERVICE        CREATED          STATUS                    PORTS
uptime-kuma    louislam/uptime-kuma:2     "/usr/bin/dumb-init …"   uptime-kuma    10 seconds ago   Up 9 seconds (healthy)    127.0.0.1:3001->3001/tcp

De status (healthy) betekent dat de ingebouwde health check geslaagd is. Als je (starting) ziet, wacht 15 seconden tot de start_period voltooid is.

Reverse proxy met Caddy

Voeg een vermelding toe aan je Caddyfile:

# /etc/caddy/Caddyfile (append)
status.example.com {
    reverse_proxy localhost:3001
}

Herlaad Caddy:

systemctl reload caddy

Caddy verkrijgt automatisch een TLS-certificaat van Let's Encrypt. Open https://status.example.com in je browser. Uptime Kuma vraagt je om een beheerdersaccount aan te maken bij de eerste toegang.

Schakel 2FA onmiddellijk in

Na het aanmaken van je beheerdersaccount, ga naar Settings > Security > Two-Factor Authentication en schakel het in. Het Uptime Kuma-dashboard geeft leestoegang tot de volledige topologie van je infrastructuur. Iedereen die de login compromitteert, ziet elk bewaakt endpoint. Stel 2FA in voordat je monitors toevoegt.

Hoe stel ik Beszel in om mijn VPS te bewaken?

Beszel gebruikt een hub-agent-architectuur. De hub is het webdashboard dat gegevens opslaat en metrieken toont. De agent draait op elke server die je wilt bewaken en streamt metrieken terug naar de hub. Wanneer beide op dezelfde VPS draaien, communiceren ze via een Unix-socket in plaats van het netwerk.

Maak de projectmap aan:

mkdir -p /opt/beszel && cd /opt/beszel

Maak het Compose-bestand aan:

# /opt/beszel/compose.yaml
services:
  beszel-hub:
    image: henrygd/beszel:0.18
    container_name: beszel-hub
    restart: unless-stopped
    ports:
      - "127.0.0.1:8090:8090"
    environment:
      - APP_URL=https://beszel.example.com
    volumes:
      - ./beszel_data:/beszel_data
      - ./beszel_socket:/beszel_socket
    deploy:
      resources:
        limits:
          memory: 128m
          cpus: "0.25"

  beszel-agent:
    image: henrygd/beszel-agent:0.18
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./beszel_agent_data:/var/lib/beszel-agent
      - ./beszel_socket:/beszel_socket
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - LISTEN=/beszel_socket/beszel.sock
      - KEY=${BESZEL_KEY}
    deploy:
      resources:
        limits:
          memory: 64m
          cpus: "0.15"

Over deze configuratie:

  • De hub-image is gepind op 0.18, die de fix voor CVE-2026-27734 (v0.18.4) bevat. Pinnen op een minor versie voorkomt onverwachte breaking changes terwijl je nog steeds patchupdates ontvangt.
  • De agent gebruikt network_mode: host zodat hij de netwerkinterfacestatistieken van de host kan lezen. Dit is vereist voor nauwkeurige bandbreedtemonitoring.
  • De agent en hub delen een beszel_socket-volume voor Unix-socketcommunicatie. Dit voorkomt het blootstellen van poort 45876 op het netwerk wanneer beide op dezelfde server draaien.
  • De Docker-socket wordt alleen-lezen (:ro) gemount. Meer hierover in het beveiligingsgedeelte hieronder.

Docker-socketbeveiliging

Het mounten van /var/run/docker.sock geeft de agent toegang tot de Docker-API. Zelfs met :ro is dit effectief root-equivalente toegang omdat de Docker-API geprivilegieerde containers kan aanmaken, omgevingsvariabelen uit elke container kan lezen en toegang heeft tot volumes. Docker Security Hardening: Rootless Mode, Seccomp, AppArmor op een VPS

Beszel heeft de socket nodig om CPU-, geheugen- en netwerkstatistieken per container te verzamelen. Als je geen containermonitoring nodig hebt, verwijder dan de Docker-socketmount volledig.

CVE-2026-27734 (opgelost in v0.18.4) demonstreerde dit risico: een geauthenticeerde Beszel-gebruiker kon de Docker-API traverseren via ongezuiverde container-ID's, waardoor willekeurige endpoints zoals /version of /containers/json bereikt werden. De fix zuivert alle gebruikersinvoer voordat Docker-API-URL's worden samengesteld. Zorg ervoor dat je v0.18.4 of nieuwer draait. De 0.18-tag in het bovenstaande Compose-bestand resolveert naar v0.18.4 (laatste patch per maart 2026).

Agentsleutel genereren

Start eerst de hub:

cd /opt/beszel
docker compose up -d beszel-hub

Open de hub op https://beszel.example.com (na het configureren van je reverse proxy, volgende sectie). Maak een beheerdersaccount aan. Ga naar Add System in het dashboard. De hub toont een publieke sleutel. Kopieer deze.

Maak een .env-bestand voor de agent:

# /opt/beszel/.env
BESZEL_KEY="ssh-ed25519 AAAA... (paste the key from the hub UI)"

chmod 600 /opt/beszel/.env

Start nu de agent:

docker compose up -d beszel-agent

Terug in de hub-UI, voeg het systeem toe met het socketpad /beszel_socket/beszel.sock. Binnen enkele seconden verschijnen CPU-, RAM-, schijf- en Docker-containermetrieken.

Reverse proxy voor Beszel

Voeg toe aan je Caddyfile:

# /etc/caddy/Caddyfile (append)
beszel.example.com {
    reverse_proxy localhost:8090
}

systemctl reload caddy

Hoe configureer ik notificaties in Uptime Kuma?

Uptime Kuma ondersteunt meer dan 90 notificatiekanalen. De drie meest voorkomende voor self-hosters zijn e-mail (SMTP), Telegram en Discord.

SMTP e-mailnotificaties

Ga naar Settings > Notifications > Setup Notification. Selecteer Email (SMTP) als type.

Veld Waarde
Hostname Je SMTP-server (bijv. smtp.example.com)
Port 587 (STARTTLS) of 465 (impliciet TLS)
Security STARTTLS of TLS
Username Je SMTP-gebruikersnaam
Password Je SMTP-wachtwoord
From Email monitoring@example.com
To Email jij@example.com

Klik op Test om een testnotificatie te sturen voordat je opslaat. Uptime Kuma verstuurt de test onmiddellijk. Als het mislukt, controleer je SMTP-inloggegevens en firewallregels (poort 587 uitgaand moet open zijn).

Telegram-botnotificaties

  1. Stuur een bericht naar @BotFather op Telegram en maak een nieuwe bot met /newbot.
  2. Kopieer het bottoken (formaat: 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11).
  3. Start een chat met je bot en stuur een willekeurig bericht.
  4. Verkrijg je chat-ID: open https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates in je browser. Het veld chat.id in het antwoord is je chat-ID.
  5. Voeg in Uptime Kuma een Telegram-notificatie toe. Plak het bottoken en de chat-ID. Klik op Test.

Discord-webhooknotificaties

  1. Ga in je Discord-server naar Server Settings > Integrations > Webhooks > New Webhook.
  2. Geef het een naam (bijv. "Uptime Kuma"), kies een kanaal en kopieer de webhook-URL.
  3. Voeg in Uptime Kuma een Discord-notificatie toe en plak de webhook-URL. Klik op Test.

Stel de standaardnotificatie in om op alle nieuwe monitors van toepassing te zijn door Default Enabled aan te vinken. Zo erft elke monitor die je aanmaakt het notificatiekanaal zonder handmatige configuratie.

Welke Uptime Kuma-monitortypen moet ik instellen?

Uptime Kuma ondersteunt veel monitortypen. Hier zijn de vier meest nuttige voor een self-hosted stack:

  1. HTTP(s) - Controleert een URL, zoekt optioneel naar een trefwoord in de responsbody. Gebruik het voor webapps, API's en dashboards. Stel het trefwoord in op een string die alleen verschijnt wanneer de app gezond is (bijv. je app-naam in de HTML-titel).
  2. TCP - Maakt verbinding met een host:poort. Gebruik het voor databases (PostgreSQL op 5432), mailservers (SMTP op 587) of elke dienst zonder HTTP-endpoint.
  3. DNS - Resolveert een hostname en controleert of het resultaat overeenkomt met een verwacht IP. Detecteert DNS-kaping of verkeerd geconfigureerde records.
  4. Push / Heartbeat - Uptime Kuma genereert een URL. Je cronjob of backupscript roept deze aan bij succes. Als de URL niet binnen het interval wordt aangeroepen, activeert Uptime Kuma een waarschuwing. Dit is de enige manier om scripts te bewaken die geen luisterpoort hebben.

Push-monitorvoorbeeld voor cronjobs

Maak een Push-monitor in Uptime Kuma. Stel het heartbeat-interval in op je cronfrequentie plus een gratieperiode. Kopieer de push-URL.

Voeg de curl-aanroep toe aan het einde van je backupscript:

#!/bin/bash
# /opt/scripts/backup.sh
pg_dump mydb | gzip > /backups/mydb-$(date +%F).sql.gz

# Signal success to Uptime Kuma
curl -fsS -o /dev/null "https://status.example.com/api/push/abc123?status=up&msg=backup-ok"

Als het script faalt voordat het de curl-regel bereikt, of als cron niet draait, markeert Uptime Kuma de monitor als down na het verlopen van het interval.

Hoe stel ik Beszel-waarschuwingen in voor CPU en schijf?

Beszel-waarschuwingen informeren je wanneer servermetrieken een drempelwaarde overschrijden. Klik op het belpictogram naast een systeem in het dashboard om waarschuwingen te configureren.

Aanbevolen drempelwaarden voor een kleine VPS (2-4 vCPU, 4-8 GB RAM):

Metriek Waarschuwing Kritiek Waarom
CPU > 70% gedurende 5 min > 90% gedurende 2 min Aanhoudend hoge CPU betekent op hol geslagen processen of een te kleine instantie
RAM > 80% gedurende 5 min > 90% gedurende 2 min Linux begint boven 85% zwaar te swappen, wat de prestaties vernietigt
Schijf > 80% > 90% Docker-images, logs en databases groeien ongemerkt. Bij 100% crashen diensten
Bandbreedte > 80% van de planlimiet > 95% Voorkomt extra kosten of throttling

Deze drempelwaarden zijn opzettelijk lager dan enterprise-standaarden. Op een kleine VPS heb je minder marge. Een piek van 70% naar 100% CPU duurt seconden, geen minuten.

SMTP configureren voor Beszel-waarschuwingen

Beszel gebruikt PocketBase als backend. SMTP wordt geconfigureerd via het PocketBase-beheerpaneel:

  1. Ga naar https://beszel.example.com/_/ (de PocketBase-beheer-URL, let op de underscore).
  2. Log in met de beheerdersgegevens die je tijdens de installatie hebt aangemaakt.
  3. Ga naar Settings > Mail settings.
  4. Schakel Use SMTP mail server in.
  5. Voer je SMTP-host, poort, gebruikersnaam en wachtwoord in.
  6. Stel het afzenderadres in.
  7. Klik op Save en Send test email.

Hoe maak ik een openbare statuspagina met Uptime Kuma?

Uptime Kuma kan openbare statuspagina's serveren die de beschikbaarheid van je diensten tonen. Deze zijn handig om uptime te communiceren naar je gebruikers zonder je monitoringdashboard bloot te stellen.

  1. Ga naar Status Pages in de linkerzijbalk.
  2. Klik op New Status Page. Kies een naam en slug (bijv. status).
  3. Voeg groepen toe (bijv. "Webdiensten", "API's", "Infrastructuur").
  4. Sleep monitors naar elke groep.
  5. Publiceer de pagina. Deze is bereikbaar op https://status.example.com/status/<slug>.

Aangepast domein voor de statuspagina

Als je wilt dat https://status.example.com de statuspagina direct toont, stel dan de statuspagina in als standaard in de Uptime Kuma-instellingen. Het rootpad toont dan de openbare pagina terwijl het dashboard op /dashboard blijft.

Statuspagina's vereisen geen authenticatie. Plaats geen monitors in een statuspaginagroep als het onthullen van het bestaan van het endpoint een beveiligingsprobleem is.

Incidentbeheer

Wanneer een dienst uitvalt, toont Uptime Kuma deze automatisch als degraded op de statuspagina. Je kunt ook handmatige incidenten aanmaken:

  1. Ga naar Status Pages, selecteer je pagina, klik op Create Incident.
  2. Schrijf een titel en beschrijving (bijv. "Databaseonderhoud, geschatte duur 15 minuten").
  3. Stel de stijl in op info, warning, danger of primary.
  4. Publiceer. De incidentbanner verschijnt bovenaan de openbare statuspagina.

Los het incident op wanneer het klaar is. Uptime Kuma bewaart een geschiedenis van eerdere incidenten zodat je gebruikers je operationele track record kunnen zien.

Hoe bewaak ik mijn monitoringstack van buitenaf?

Als je VPS uitvalt, vallen Uptime Kuma en Beszel mee uit. Je hoort over de storing op hetzelfde moment als je gebruikers. De oplossing: een externe watchdog die je Uptime Kuma-instantie bewaakt vanaf een andere locatie.

Optie 1: UptimeRobot (gratis tier)

  1. Maak een gratis account aan bij UptimeRobot.
  2. Voeg een nieuwe monitor toe: type HTTP(s), URL https://status.example.com/api/status-page/heartbeat/<slug>.
  3. Stel het controle-interval in op 5 minuten.
  4. Configureer e-mail- of Telegram-notificaties.

Het endpoint /api/status-page/heartbeat/<slug> retourneert een JSON-payload met de status. UptimeRobot controleert het en waarschuwt je als je Uptime Kuma-instantie onbereikbaar wordt.

Optie 2: Healthchecks.io (gratis tier)

Healthchecks.io werkt met het push-model. Maak een check aan, kopieer de ping-URL en voeg een cronjob toe op je VPS:

# /etc/cron.d/monitoring-heartbeat
*/5 * * * * root curl -fsS --retry 3 -o /dev/null https://hc-ping.com/your-uuid-here

Als de cronping stopt met aankomen (omdat je server down is), stuurt Healthchecks.io je een waarschuwing. Dit dekt het scenario waarin je hele VPS onbereikbaar wordt.

Optie 3: bewaken vanaf een tweede VPS

Als je meerdere servers draait, installeer Uptime Kuma op een andere VPS en laat elke instantie de andere bewaken. Dit is de meest betrouwbare aanpak omdat je beide endpoints beheert en er geen afhankelijkheid is van een gratis dienst van derden.

Beveiligingshardening

Firewallregels

Als je de Beszel-agent in standalone-modus draait op een remote server (zonder de Unix-socketmethode), luistert deze op poort 45876. Alleen de hub moet deze poort bereiken:

ufw allow from <hub-ip-address> to any port 45876 proto tcp comment "Beszel agent"
ufw status numbered

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere
[ 4] 45876/tcp                  ALLOW IN    <hub-ip-address>

Open poort 45876 niet voor de hele wereld. De agent stelt systeemmetrieken bloot zonder authenticatie op die poort. Hij vertrouwt op de SSH-sleutel van de hub voor verificatie, maar netwerkrestrictie voegt verdediging in de diepte toe.

Voor de single-VPS-setup in deze handleiding is poort 45876 helemaal niet nodig omdat hub en agent communiceren via een Unix-socket.

Uptime Kuma: wachtwoordauthenticatie voor API uitschakelen

Als je Uptime Kuma alleen via de webinterface benadert, schakel dan API-toegang uit via Settings > Security > API Key. Minder blootgestelde endpoints, minder om te patchen.

Versie-informatie verbergen

Uptime Kuma en Beszel tonen beide standaard versie-informatie in hun webinterface. Je reverse proxy moet dit niet verergeren. In je Caddyfile laat Caddy standaard al Server-headers weg. Als je Nginx gebruikt:

server_tokens off;

Het onthullen van versie-informatie helpt aanvallers om bekende kwetsbaarheden te targeten. Houd het minimaal.

Hoe maak ik een backup van Uptime Kuma- en Beszel-gegevens?

Beide tools gebruiken op SQLite gebaseerde databases. SQLite-bestanden kunnen niet veilig gekopieerd worden terwijl de applicatie ernaar schrijft. Gebruik de juiste backupmethoden.

Uptime Kuma-backup

Uptime Kuma slaat alles op in /app/data (gemapped naar ./data in het Compose-bestand). De ingebouwde backup exporteert een JSON-bestand:

  1. Ga naar Settings > Backup.
  2. Klik op Export. Sla het JSON-bestand op buiten de server.

Voor geautomatiseerde backups, stop de container kort of gebruik SQLite's online backup:

sqlite3 /opt/uptime-kuma/data/kuma.db ".backup '/opt/backups/kuma-$(date +%F).db'"

Beszel-backup

Beszel gebruikt PocketBase. Maak een backup van de datamap:

sqlite3 /opt/beszel/beszel_data/data.db ".backup '/opt/backups/beszel-$(date +%F).db'"

Bewaar backups buiten de server. Een monitoringstack die zijn geschiedenis verliest wanneer de schijf sterft, bewaakt niets. Docker-volumes back-uppen en herstellen op een VPS

Hoe update ik Uptime Kuma en Beszel veilig?

Pin op de minor versie, niet op latest. Dit voorkomt dat breaking changes binnenkomen zonder je medeweten.

# Update Uptime Kuma
cd /opt/uptime-kuma
docker compose pull
docker compose up -d

[+] Pulling 1/1
 ✔ uptime-kuma Pulled
[+] Running 1/1
 ✔ Container uptime-kuma  Started

docker compose ps

Controleer of de kolom STATUS de waarde (healthy) toont. Als de nieuwe versie problemen veroorzaakt, pin de vorige versie in compose.yaml en maak opnieuw aan:

# In compose.yaml, change the image tag to the previous version:
# image: louislam/uptime-kuma:2.2.1
docker compose up -d

Hetzelfde proces geldt voor Beszel. Maak altijd een backup voordat je bijwerkt.

Image-pinningstrategie

De tag louislam/uptime-kuma:2 volgt de nieuwste 2.x-release. Dat is handig maar betekent dat docker compose pull zonder waarschuwing van 2.2.1 naar 2.3.0 kan springen. Voor productie, pin op een specifieke minor versie:

image: louislam/uptime-kuma:2.2

Bekijk de release-opmerkingen voordat je pullt. Uptime Kuma publiceert releases op GitHub. Beszel doet hetzelfde op hun releasepagina.

Abonneer je op releasenotificaties van beide repositories (Watch > Custom > Releases op GitHub) zodat je weet wanneer beveiligingspatches verschijnen.

Docker Compose resourcelimieten, healthchecks en herstartbeleid

Probleemoplossing

Uptime Kuma toont (unhealthy) in docker compose ps:

docker compose logs uptime-kuma --tail 50

Veelvoorkomende oorzaken: beschadigde SQLite-database (herstel vanuit backup), poortconflict (een andere dienst op 3001), of onvoldoende geheugen (verhoog de resourcelimiet).

Beszel-agent maakt geen verbinding met de hub:

docker compose logs beszel-agent --tail 50

Controleer of de KEY in .env overeenkomt met de sleutel die in het Add System-dialoogvenster van de hub wordt getoond. Als je Unix-sockets gebruikt, controleer dan of het pad van de gedeelde volumemount overeenkomt op beide diensten.

Beszel toont geen Docker-containerstatistieken:

De Docker-socketmount ontbreekt of het Docker-socketpad is onjuist. Controleer:

ls -la /var/run/docker.sock

srw-rw---- 1 root docker 0 Mar 20 10:00 /var/run/docker.sock

De socket moet bestaan en de container moet leestoegang hebben. De :ro-mount in het Compose-bestand regelt dit.

Notificaties komen niet aan:

Voor SMTP: controleer of poort 587 (of 465) uitgaand niet geblokkeerd wordt door je hostingprovider. Sommige providers blokkeren uitgaande SMTP standaard. Test met:

nc -zv smtp.example.com 587

Connection to smtp.example.com 587 port [tcp/submission] succeeded!

Voor Telegram: controleer het bottoken en de chat-ID. De chat-ID moet een nummer zijn, niet de bot-gebruikersnaam.

Hoog geheugengebruik:

Het aantal monitors telt. Uptime Kuma v2.x gebruikt ongeveer 100 MB in rust. Elke HTTP-monitor voegt verbindingsstatus toe. Als je meer dan 100 monitors hebt met een geheugenlimiet van 256 MB, verhoog dan de limiet of verdeel over meerdere instanties.

Controleer het werkelijke gebruik:

docker stats --no-stream uptime-kuma beszel-hub beszel-agent

CONTAINER ID   NAME           CPU %     MEM USAGE / LIMIT   MEM %     NET I/O       BLOCK I/O   PIDS
abc123         uptime-kuma    0.15%     99MiB / 256MiB      38.67%    1.2kB / 2kB   0B / 0B     8
def456         beszel-hub     0.08%     10MiB / 128MiB      7.81%     1kB / 1.5kB   0B / 745kB  8
ghi789         beszel-agent   0.05%     22MiB / 64MiB       34.38%    0B / 0B       0B / 0B     5

Docker-logrotatie: voorkom dat logs uw VPS-schijf vullen

Klaar om het zelf te proberen?

Implementeer je monitoringstack op een Virtua Cloud VPS. →

Gerelateerde artikelen