JournalindeksDockup / feltnote
Note / self-host-grafana

Sådan selvhoster du Grafana i 2026: Dashboards, alerts og persistent state

Deploy Grafana med den rigtige port, durable storage, TLS, authentication og backups. Fejlsøg, når dashboards forsvinder sammen med SQLite-filen i produktion.

Der findes to versioner af at “køre Grafana”: Enten eksisterer der en container, eller også udfører servicen sit egentlige arbejde. Kun den anden version er relevant. Her er beviset, at du tilføjer en read-only data source, gemmer et panel, evaluerer en alert rule og leverer en testnotifikation via et contact point.

Grafana bruges til dashboards og alerts over metrics, logs og traces. Deploymentet skal bevare de dele, der ligger bag denne funktionalitet; en port, et volume og et certifikat er input — ikke resultatet.

Grafanas produktionsopsætning

Grafanas HTTP-proces lytter på 3000; behold den port på applikationsnetværket, og publicér kun platformens route. Netværkskontrakten for Grafana er tilgængelige data sources og SMTP, hvis alert-levering er påkrævet. Behold private endpoints på intern DNS, tillad kun nødvendige udgående kald, og giv Grafana en afgrænset service credential.

Skriv grænsen ned som en kort kontrakt: Hvem ejer kravet, hvilken credential bruges, hvilken timeout er acceptabel, og hvordan viser en fejl sig? Kør derefter denne transaktion: Tilføj en read-only data source, gem et panel, evaluer en alert rule, og lever en testnotifikation via et contact point. Observer query fan-out, dashboard refresh-intervaller, alert-evaluering og plugin-memory i stedet for Grafanas egne gemte metrics under kørslen, fordi denne belastning giver et mere nyttigt udgangspunkt for dimensionering end en inaktiv container.

Start Grafana uden at skjule de bevægelige dele

Start Grafana på en måde, der holder routen privat, indtil bootstrap er færdig.

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

Hvis processen går i loop, skal du sammenligne imagets forventede bruger med ejeren af hver mounted path. Hvis den forbliver kørende, skal du teste port 3000 lokalt og derefter gå direkte videre til workflowet: Tilføj en read-only data source, gem et panel, evaluer en alert rule, og lever en testnotifikation via et contact point. Pin imagets version, men først efter at dette end-to-end-tjek er bestået, og registrer den præcise konfiguration sammen med servicen.

Giv Grafana én canonical address

TLS-udstedelse er kun halvdelen af Grafana-routen. Sæt GF_SERVER_ROOT_URL til den offentlige HTTPS-URL. Send trafik internt til 3000, og videresend det eksterne scheme, så genererede URLs og secure cookies forbliver konsistente.

Brug det komplette Grafana-scenarie fra et rent netværk — ikke kun root-siden. En 502- eller certifikatfejl kan isoleres med automatisk domain- og TLS-opsætning. Hvis trafikken når processen, og dashboards forsvinder sammen med SQLite-filen, eller OAuth-callbacks bruger localhost, skal du diagnosticere tilstanden dér, hvor den opstår, i stedet for at stable redirects oven på hinanden.

Design Grafanas restore før lancering

Det durable recovery-sæt består af Grafana-databasen, plugins og provisioned configuration. Mount /var/lib/grafana før bootstrap, skriv harmløse eksempeldata, og erstat containeren for at bevise, at stien faktisk er persistent. Et volume beskytter data mod udskiftning af containeren, men ikke mod tab af hosten, utilsigtet sletning eller korruption på applikationsniveau.

Tag backups, der forstår data sourcen: Brug logical dumps til live-databaser, når det er nødvendigt, og kopiér kun filer fra en konsistent tilstand. Opbevar én krypteret kopi væk fra Grafana-hosten. Acceptkriteriet for en restore er specifikt — brugere, folders, dashboards, alert rules og data-source metadata skal vende tilbage, og test-alerten skal evalueres. Guiden til restore-testede backups forklarer, hvorfor det ikke er nok, at jobbet lykkes.

Luk midlertidig setup-adgang

Et sikkert Grafana-deployment begynder med at fjerne autoritet. Undgå at beholde admin/admin eller utilsigtet eksponere anonymous access; udskift i stedet bootstrap-adminens password, begræns redigering af data sources, og sørg for, at service-account tokens er afgrænsede.

Udskift GF_SECURITY_ADMIN_PASSWORD med det samme, opbevar den uden for imaget, og rotér den som en administrator-credential, hvis den bliver eksponeret. Begræns administrative routes, brug privat DNS til dependencies, og gennemgå alle bind mounts. Når logs sendes centralt, skal secrets og privat indhold filtreres, før de forlader serveren.

Øv den risikable Grafana-ændring

En grøn container er nødvendig, men ikke tilstrækkelig. Service-level-indikatoren er en vellykket gennemførelse af “tilføj en read-only data source, gem et panel, evaluer en alert rule, og lever en testnotifikation via et contact point”, mens de sandsynlige belastningssignaler er query fan-out, dashboard refresh-intervaller, alert-evaluering og plugin-memory i stedet for Grafanas egne gemte metrics.

Change control er vigtigt, fordi Grafana-databasemigrationer og plugin-kompatibilitet kræver en staged upgrade med de samme provisioning-filer. Bevar det gamle image, test migrationer på en kopi af state, og dokumentér, om rollback understøttes, efter at schemaet er flyttet. Hvis dashboards forsvinder sammen med SQLite-filen, eller OAuth-callbacks bruger localhost, skal du diagnosticere den første grænse, der adskiller sig fra det fungerende miljø.

Registrer et kendt velfungerende Grafana-deployment

For Grafana skal du definere en kendt velfungerende transaktion før lancering: Tilføj en read-only data source, gem et panel, evaluer en alert rule, og lever en testnotifikation via et contact point. Læg forudsætninger, forventet svar og oprydningstrin i version control uden secret-værdier. Pin det image, der bruges til at etablere denne reference.

Brug transaktionen til at validere en udskiftning og en uafhængig restore. Den restored service er kun acceptabel, når brugere, folders, dashboards, alert rules og data-source metadata vender tilbage, og test-alerten evalueres. Observer samtidig query fan-out, dashboard refresh-intervaller, alert-evaluering og plugin-memory i stedet for Grafanas egne gemte metrics, og gør den langsomste eller mest begrænsede del til en service-level alert.

Gaten skal også have et negativt scenarie: Afvis midlertidigt testidentitetens adgang til tilgængelige data sources og SMTP, hvis alert-levering er påkrævet. Bekræft, at Grafana giver en handlingsanvisende fejl, samtidig med at data bevares, gendan den gyldige tilstand, og gentag den kendt velfungerende transaktion. Ved at gemme begge resultater undgår du, at et overfladisk health endpoint bliver det eneste produktionsbevis.

Hvor Dockup fjerner arbejde for Grafana

Routing, certifikater, udskiftning af services og tilknyttet storage er fornuftige mål for automation. Dockup håndterer dette for Grafana og kan provisionere den relaterede managed database eller oprette forbindelse til services på kundens egen server.

Det, Dockup ikke bør opfinde, er Grafanas trust policy. Efter deployment skal du sætte GF_SERVER_ROOT_URL til den offentlige HTTPS-URL, håndhæve denne grænse — udskift bootstrap-adminens password, begræns redigering af data sources, og sørg for, at service-account tokens er afgrænsede — og verificere resultatet af dette scenarie: Tilføj en read-only data source, gem et panel, evaluer en alert rule, og lever en testnotifikation via et contact point. Resultatet er infrastruktur med ét klik og en applikationsspecifik accepttest.

Ofte stillede spørgsmål

Hvad skal Grafana bruge til et produktionsdeployment?

Route Grafana-containeren på port 3000 gennem én HTTPS-origin. Det understøttende netværkskrav er tilgængelige data sources og SMTP, hvis alert-levering er påkrævet. Erklær ikke Grafana klar, før du kan tilføje en read-only data source, gemme et panel, evaluere en alert rule og levere en testnotifikation via et contact point.

Hvilke Grafana-data hører hjemme i en backup?

Gør /var/lib/grafana persistent, og medtag Grafana-databasen, plugins og provisioned configuration i det samme recovery-manifest. En ren Grafana-restore er kun vellykket, når brugere, folders, dashboards, alert rules og data-source metadata vender tilbage, og test-alerten evalueres.

Kræver Grafana HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Grafana-origin, og behold port 3000 på den interne route. Anvend Grafana-indstillingen korrekt: Sæt GF_SERVER_ROOT_URL til den offentlige HTTPS-URL. For Grafana beskytter HTTPS credentials eller brugerindhold under transport og sørger for, at origin-følsom klientadfærd forbliver konsistent.

Hvordan bør en Grafana-opgradering testes?

Restore den aktuelle Grafana-state til et isoleret deployment, anvend kandidatversionen, og gentag dens accepttransaktion. Vær særligt opmærksom, fordi Grafana-databasemigrationer og plugin-kompatibilitet kræver en staged upgrade med de samme provisioning-filer. Behold det tidligere Grafana-image, indtil grænsen for datamigration og rollback er forstået.