Beszel zelf hosten in 2026: agents, private networking en back-ups

De kortste Beszel-demo bewijst dat een proces op poort 8090 luistert. Voor productie is sterker bewijs nodig. De omgeving moet dit scenario ook doorstaan nadat de container is vervangen: een agent registreren, CPU-, geheugen- en schijfgrafieken bekijken, een threshold alert activeren en de agent opnieuw verbinden nadat een hub is herstart.

Beszel wordt met een duidelijk doel ingezet: lichtgewicht servermonitoring in een kleine container. De meest voorkomende deploymentvalkuil is dat de hub poort 45876 op een agent niet kan bereiken of dat de SSH-sleutel is gewijzigd. Daarom verdienen het afhandelen van de publieke URL en duurzame state net zoveel aandacht als het starten van de image.

De runtimegrens van Beszel in kaart brengen

Procesgezondheid en productgezondheid zijn bij Beszel twee verschillende zaken. Poort 8090 kan antwoorden terwijl de transactie aan de gebruikerskant nog steeds mislukt. Het netwerkcontract voor Beszel bestaat uit een Beszel-agent op elke gemonitorde machine. Houd private endpoints op interne DNS, sta alleen de vereiste uitgaande verbindingen toe en geef Beszel een servicecredential met beperkte rechten.

Gebruik deze readiness-oefening na belangrijke configuratiewijzigingen: registreer een agent, bekijk CPU-, geheugen- en schijfgrafieken, activeer een threshold alert en verbind de agent opnieuw nadat een hub is herstart. Houd dure externe checks buiten liveness-probes, zodat een storing bij een provider geen restart-loop veroorzaakt. Bij capaciteitsplanning moet je het aantal agents, metrics-retentie, hubopslag en netwerkbereikbaarheid naar elke agent op de eigen poort volgen. Dat geeft een realistischer beeld van de belasting van Beszel dan paginaverzoeken.

Zorg voor een eenduidige public origin

De browser, API-client en Beszel moeten het eens zijn over één origin. Routeer de hub daarom via HTTPS en houd agentpoorten private. Behoud de oorspronkelijke host en het oorspronkelijke protocol, terwijl je voorkomt dat poort 8090 als concurrerend publiek adres beschikbaar is.

De handleiding voor het oplossen van een onbereikbare website helpt onderscheid te maken tussen een onbereikbare route en een applicatie die wel antwoordt. Dat onderscheid is hier belangrijk: de hub kan poort 45876 op een agent niet bereiken of de SSH-sleutel is gewijzigd. Alleen het eerste probleem los je op met wijzigingen aan ingress; voor het tweede zijn Beszel-logs, state of inspectie van de workload nodig.

De eerste productiegerichte instance draaien

De eerste container moet eenvoudig te verwijderen en opnieuw aan te maken zijn. Houd data buiten de writable layer, bind poort 8090 alleen waar de proxy erbij kan en geef configuratie tijdens runtime door.

docker run -d \
  --name beszel \
  --restart unless-stopped \
  -p 127.0.0.1:8090:8090 \
  -v beszel-data:/beszel_data \
  henrygd/beszel:latest

Pin de image na de eerste test. Lees de eerste startupfout in plaats van het laatste restartbericht, controleer elke mount met docker inspect en volg de logs terwijl je een agent registreert, CPU-, geheugen- en schijfgrafieken bekijkt, een threshold alert activeert en de agent opnieuw verbindt nadat een hub is herstart. Met die volgorde kun je een verkeerd image-commando onderscheiden van een probleem met dependencies of permissies.

Logs die de volgende vraag beantwoorden

Een groene container is noodzakelijk, maar niet voldoende. De service-level indicator is het succesvol uitvoeren van “een agent registreren, CPU-, geheugen- en schijfgrafieken bekijken, een threshold alert activeren en de agent opnieuw verbinden nadat een hub is herstart”. De waarschijnlijke signalen van druk zijn het aantal agents, metrics-retentie, hubopslag en netwerkbereikbaarheid naar elke agent op de eigen poort.

Change control is belangrijk, omdat hub- en agentversies samen moeten worden getest: protocolwijzigingen kunnen eruitzien als stille gaten in de monitoring. Bewaar de oude image, test migraties op een kopie van de state en documenteer of rollback na een schemawijziging wordt ondersteund. Als de hub poort 45876 op een agent niet kan bereiken of de SSH-sleutel is gewijzigd, onderzoek dan de eerste grens die afwijkt van de werkende omgeving.

Een productieacceptatietest voor Beszel

Maak vóór de eerste echte gebruikers een releasewerkblad voor Beszel. Daarin moeten de gepinde image, poort 8090, canonical origin, persistente paden en de eigenaar van een Beszel-agent op elke gemonitorde machine staan. Voeg het verwachte resultaat van deze transactie toe: een agent registreren, CPU-, geheugen- en schijfgrafieken bekijken, een threshold alert activeren en de agent opnieuw verbinden nadat een hub is herstart.

Gebruik het werkblad na een normale vervanging en na een schone restore. Recovery is pas geslaagd als systemen, historie en alerts terug zijn en elke herstelde agent weer actuele metrics verstuurt. Verzamel ook een korte resource-trace met het aantal agents, metrics-retentie, hubopslag en netwerkbereikbaarheid naar elke agent op de eigen poort. Bewaar die naast de release, zodat toekomstige capaciteitswijzigingen met dezelfde workload kunnen worden vergeleken.

Voeg één gecontroleerde storing toe: blokkeer tijdelijk de toegang van de testidentiteit tot een Beszel-agent op elke gemonitorde machine. Controleer of Beszel het probleem bij de juiste grens rapporteert, herstel de geldige toestand en voer de transactie opnieuw uit. Zo test je de zichtbaarheid van fouten, niet alleen succes, en voorkom je dat een interface die er gezond uitziet een defecte worker, callback of databaseverbinding verbergt.

De Beszel-restore vóór de lancering ontwerpen

Breng elk duurzaam artefact in kaart: hubdata, gebruikers, systemen en alertconfiguratie. Mount /beszel_data vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dat pad daadwerkelijk persistent is. Neem ook configuratie op die bepaalt hoe opgeslagen data wordt geïnterpreteerd, niet alleen de grootste directory.

Stel retentie in, kopieer back-ups naar een andere host en voer een clean-room restore uit. De Beszel-drill is voltooid wanneer systemen, historie en alerts terug zijn en elke herstelde agent weer actuele metrics verstuurt. Als snapshots onderdeel zijn van het plan, gebruik dan richtlijnen voor PITR versus snapshots om vast te leggen wat elk mechanisme kan herstellen.

Tijdelijke toegang voor de setup afsluiten

Maak een threat model van de handeling die Beszel uitvoert, niet alleen van het loginformulier. De grootste fout hier is het publiceren van agent-listeners naar het internet zonder netwerkcontroles. Implementeer deze grens: houd agent-listeners op private netwerken en bescherm het hubaccount en de enrollment keys.

Beszel heeft in deze baseline geen verplichte bootstrap secret; bescherm in plaats daarvan het daadwerkelijke administratoraccount of de upstream-authenticatie. Los een permissiefout niet op door de container als root te draaien of de host breed te mounten. Resource limits horen ook bij het securityontwerp wanneer gebruikers het aantal agents, metrics-retentie, hubopslag en netwerkbereikbaarheid naar elke agent op de eigen poort kunnen beïnvloeden.

Het herhaalbare infrastructuurwerk naar Dockup verplaatsen

Voor Beszel is Dockup vooral nuttig op de grens tussen een image en een duurzame service. Het houdt de route naar 8090, TLS, secretwaarden en storage gekoppeld tijdens het vervangen van containers, ongeacht of de compute van Dockup of van je gekoppelde server komt.

Rond af met applicatiekennis: routeer de hub via HTTPS en houd agentpoorten private; verbind een Beszel-agent op elke gemonitorde machine en test die; voer vervolgens deze verificatie uit: een agent registreren, CPU-, geheugen- en schijfgrafieken bekijken, een threshold alert activeren en de agent opnieuw verbinden nadat een hub is herstart. Bewaar het resultaat als deploymentcheck, zodat de volgende image-update op gedrag wordt beoordeeld en niet alleen op de status van de container.

Veelgestelde vragen

Wat heeft Beszel nodig voor een productie-deployment?

Routeer de Beszel-container op poort 8090 via één HTTPS-origin. De bijbehorende netwerkvereiste is een Beszel-agent op elke gemonitorde machine. Markeer Beszel pas als klaar wanneer je een agent kunt registreren, CPU-, geheugen- en schijfgrafieken kunt bekijken, een threshold alert kunt activeren en de agent opnieuw kunt verbinden nadat een hub is herstart.

Welke Beszel-data hoort in een back-up?

Maak /beszel_data persistent en neem hubdata, gebruikers, systemen en alertconfiguratie op in hetzelfde recoverymanifest. Een schone Beszel-restore is pas geslaagd wanneer systemen, historie en alerts terug zijn en elke herstelde agent weer actuele metrics verstuurt.

Heeft Beszel HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Beszel-origin en houd poort 8090 op de interne route. Pas de Beszel-instelling correct toe: routeer de hub via HTTPS en houd agentpoorten private. Bij Beszel beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het ervoor dat origingevoelig gedrag van clients consistent blijft.

Hoe moet je een Beszel-upgrade testen?

Herstel de actuele Beszel-state in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat hub- en agentversies samen moeten worden getest: protocolwijzigingen kunnen eruitzien als stille gaten in de monitoring. Bewaar de vorige Beszel-image totdat de grenzen voor datamigratie en rollback duidelijk zijn.