Grafana zelf hosten in 2026: dashboards, alerts en persistente status

Er zijn twee versies van “Grafana draaien”: er bestaat een container, of de service voert zijn echte taak uit. Alleen de tweede is relevant. Het bewijs bestaat hieruit dat je een read-only data source toevoegt, een panel opslaat, een alert rule evalueert en via een contact point een testnotificatie aflevert.

Grafana dient dit doel: dashboards en alerts voor metrics, logs en traces. De deployment moet de onderdelen achter dat gedrag behouden; een poort, een volume en een certificaat zijn invoer, niet het resultaat.

De productievorm van Grafana

Het Grafana HTTP-proces luistert op 3000; houd die poort op het applicatienetwerk en publiceer alleen de platformroute. Het netwerkcontract voor Grafana bestaat uit bereikbare data sources en SMTP als alert delivery nodig is. Houd private endpoints op interne DNS, sta alleen vereiste uitgaande verbindingen toe en geef Grafana een servicecredential met beperkte scope.

Leg de grens vast in een kort contract: wie eigenaar is van de requirement, welke credential wordt gebruikt, welke timeout acceptabel is en hoe een fout zichtbaar wordt. Voer vervolgens deze transactie uit: voeg een read-only data source toe, sla een panel op, evalueer een alert rule en lever via een contact point een testnotificatie af. Observeer tijdens de run query fan-out, dashboard-refreshintervallen, alert-evaluatie en plugingeheugen in plaats van de eigen opgeslagen metrics van Grafana, omdat die workload een bruikbaarder uitgangspunt voor de sizing biedt dan een inactieve container.

Start Grafana zonder de bewegende delen te verbergen

Start Grafana op een manier die de route privé houdt totdat de bootstrap is voltooid.

docker run -d \
  --name grafana \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v grafana-data:/var/lib/grafana \
  -e GF_SECURITY_ADMIN_PASSWORD=replace-with-a-long-random-value \
  grafana/grafana:latest

Als het proces blijft herstarten, vergelijk je de verwachte gebruiker van de image met de eigenaar van elk gemount pad. Blijft het proces actief, test dan lokaal poort 3000 en ga vervolgens direct naar de workflow: voeg een read-only data source toe, sla een panel op, evalueer een alert rule en lever via een contact point een testnotificatie af. Pin de imageversie pas nadat deze end-to-endcontrole slaagt en leg de exacte configuratie naast de service vast.

Geef Grafana één canoniek adres

TLS-uitgifte is slechts de helft van de Grafana-route. Stel GF_SERVER_ROOT_URL in op de publieke HTTPS-URL. Stuur verkeer intern naar 3000 en geef het externe scheme door, zodat gegenereerde URL's en secure cookies consistent blijven.

Gebruik het volledige Grafana-scenario vanaf een schoon netwerk, niet alleen de rootpagina. Een 502- of certificaatfout kun je isoleren met automatische domein- en TLS-configuratie. Als verkeer het proces bereikt en dashboards verdwijnen wanneer het SQLite-bestand verdwijnt, of OAuth-callbacks localhost gebruiken, diagnoseer die toestand dan op de plek waar die optreedt in plaats van redirects op elkaar te stapelen.

Ontwerp het Grafana-herstel vóór de launch

De duurzame recoveryset bestaat uit de Grafana-database, plugins en de provisioned configuratie. Mount /var/lib/grafana vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Een volume beschermt data tegen het vervangen van een container, maar niet tegen verlies van de host, per ongeluk verwijderen of corruptie op applicatieniveau.

Maak back-ups die de data source begrijpen: gebruik waar nodig logical dumps voor live databases en kopieer bestanden alleen vanuit een consistente toestand. Bewaar één versleutelde kopie buiten de Grafana-host. Het acceptatiecriterium voor een restore is specifiek — users, folders, dashboards, alert rules en data-sourcemetadata worden teruggezet en de testalert wordt geëvalueerd. De handleiding voor geteste restores legt uit waarom alleen een succesvolle job onvoldoende is.

Sluit tijdelijke setup-toegang

Een veilige Grafana-deployment begint met het verwijderen van autoriteit. Laat admin/admin niet staan en stel anonieme toegang niet onbedoeld bloot; vervang in plaats daarvan het bootstrap-adminwachtwoord, beperk het bewerken van data sources en houd service-accounttokens beperkt in scope.

Vervang GF_SECURITY_ADMIN_PASSWORD onmiddellijk, bewaar het buiten de image en roteer het zoals een administratorcredential als het is blootgesteld. Beperk administratieve routes, gebruik private DNS voor dependencies en controleer elke bind mount. Wanneer logs centraal worden verzonden, filter je secrets en private content voordat ze de server verlaten.

Oefen de risicovolle Grafana-wijziging

Een groene container is noodzakelijk maar niet voldoende. De service-level indicator is het succesvol voltooien van “een read-only data source toevoegen, een panel opslaan, een alert rule evalueren en via een contact point een testnotificatie afleveren”, terwijl de waarschijnlijke druksignalen query fan-out, dashboard-refreshintervallen, alert-evaluatie en plugingeheugen zijn in plaats van de eigen opgeslagen metrics van Grafana.

Change control is belangrijk omdat Grafana-databasemigraties en plugincompatibiliteit een gefaseerde upgrade met dezelfde provisioningbestanden vereisen. Bewaar de oude image, test migraties op een kopie van de state en documenteer of rollback wordt ondersteund nadat het schema is gewijzigd. Als dashboards verdwijnen wanneer het SQLite-bestand verdwijnt, of OAuth-callbacks localhost gebruiken, diagnoseer dan de eerste grens die afwijkt van de werkende omgeving.

Leg een bekende goede Grafana-deployment vast

Definieer voor Grafana vóór de launch een bekende goede transactie: voeg een read-only data source toe, sla een panel op, evalueer een alert rule en lever via een contact point een testnotificatie af. Zet de vereisten, verwachte response en cleanupstappen zonder secretwaarden in version control. Pin de image die is gebruikt om die referentie vast te leggen.

Gebruik de transactie om een vervanging en een onafhankelijke restore te valideren. De herstelde service is alleen acceptabel wanneer users, folders, dashboards, alert rules en data-sourcemetadata worden teruggezet en de testalert wordt geëvalueerd. Observeer tegelijkertijd query fan-out, dashboard-refreshintervallen, alert-evaluatie en plugingeheugen in plaats van de eigen opgeslagen metrics van Grafana, en maak van het traagste of meest beperkte onderdeel een service-level alert.

De gate heeft ook een negatieve case nodig: ontzeg de testidentiteit tijdelijk toegang tot bereikbare data sources en SMTP als alert delivery nodig is. Bevestig dat Grafana een bruikbare fout produceert terwijl de data behouden blijft, herstel de geldige toestand en herhaal de bekende goede transactie. Door beide resultaten te bewaren voorkom je dat een oppervlakkig health endpoint het enige productiebewijs wordt.

Waar Dockup werk voor Grafana uit handen neemt

Routing, certificaten, het vervangen van services en gekoppelde storage zijn redelijke automatiseringsdoelen. Dockup regelt die voor Grafana en kan de bijbehorende managed database provisionen of verbinding maken met services op de eigen server van een klant.

Wat het niet zelf moet verzinnen, is het Grafana-trustbeleid. Stel na de deployment GF_SERVER_ROOT_URL in op de publieke HTTPS-URL, handhaaf deze grens — vervang het bootstrap-adminwachtwoord, beperk het bewerken van data sources en houd service-accounttokens beperkt in scope — en verifieer het resultaat van dit scenario: voeg een read-only data source toe, sla een panel op, evalueer een alert rule en lever via een contact point een testnotificatie af. Het resultaat is infrastructuur met één klik en een applicatiespecifieke acceptatietest.

Veelgestelde vragen

Wat heeft Grafana nodig voor een productiedeployment?

Routeer de Grafana-container op poort 3000 via één HTTPS-origin. De vereiste voor het ondersteunende netwerk bestaat uit bereikbare data sources en SMTP als alert delivery nodig is. Markeer Grafana pas als gereed wanneer je een read-only data source kunt toevoegen, een panel kunt opslaan, een alert rule kunt evalueren en via een contact point een testnotificatie kunt afleveren.

Welke Grafana-data hoort in een back-up?

Maak /var/lib/grafana persistent en neem de Grafana-database, plugins en provisioned configuratie op in hetzelfde recoverymanifest. Een schone Grafana-restore is alleen geslaagd wanneer users, folders, dashboards, alert rules en data-sourcemetadata worden teruggezet en de testalert wordt geëvalueerd.

Heeft Grafana HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Grafana-origin en houd poort 3000 op de interne route. Pas de Grafana-instelling correct toe: stel GF_SERVER_ROOT_URL in op de publieke HTTPS-URL. Voor Grafana beschermt HTTPS credentials of gebruikerscontent tijdens transport en houdt het origingevoelige gedrag van clients consistent.

Hoe moet een Grafana-upgrade worden getest?

Zet de huidige Grafana-state terug in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat Grafana-databasemigraties en plugincompatibiliteit een gefaseerde upgrade met dezelfde provisioningbestanden vereisen. Houd de vorige Grafana-image beschikbaar totdat de grenzen van datamigratie en rollback duidelijk zijn.