Slik hoster du Grafana selv i 2026: Dashboards, varsler og persistent tilstand
Distribuer Grafana med riktig port, persistent lagring, TLS, autentisering og sikkerhetskopier. Feilsøk når dashboards forsvinner sammen med SQLite-filen i produksjon.
Det finnes to versjoner av «å kjøre Grafana»: En container eksisterer, eller tjenesten fullfører den faktiske jobben sin. Det er bare den siste som teller. Her består beviset i å legge til en skrivebeskyttet datakilde, lagre et panel, evaluere en varslingsregel og levere et testvarsel via et kontaktpunkt.
Grafana brukes til dashboards og varsler basert på metrics, logger og traces. Distribusjonen må bevare delene som ligger bak denne funksjonaliteten; en port, et volum og et sertifikat er forutsetninger, ikke resultatet.
Grafanas produksjonsoppsett
Grafanas HTTP-prosess lytter på port 3000. Behold denne porten på applikasjonsnettverket, og eksponer bare plattformruten. Nettverkskravene for Grafana er tilgjengelige datakilder og SMTP dersom levering av varsler er nødvendig. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Grafana en avgrenset tjenestekredential.
Skriv ned grensesnittet som en kort kontrakt: hvem som eier kravet, hvilken credential som brukes, hvilken timeout som er akseptabel og hvordan feil vises. Kjør deretter denne transaksjonen: legg til en skrivebeskyttet datakilde, lagre et panel, evaluer en varslingsregel og lever et testvarsel via et kontaktpunkt. Følg med på query-fan-out, intervaller for dashboard-oppdatering, evaluering av varsler og plugin-minne i stedet for Grafanas egne lagrede metrics under kjøringen, fordi denne arbeidsbelastningen gir et mer nyttig utgangspunkt for dimensjonering enn en inaktiv container.
Start Grafana uten å skjule de bevegelige delene
Start Grafana slik at ruten forblir privat til bootstrap er fullført.
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 prosessen starter på nytt i en løkke, sammenligner du brukeren image forventer, med eieren av hver monterte sti. Hvis den holder seg oppe, tester du port 3000 lokalt og går deretter direkte til arbeidsflyten: legg til en skrivebeskyttet datakilde, lagre et panel, evaluer en varslingsregel og lever et testvarsel via et kontaktpunkt. Lås image-versjonen først etter at denne ende-til-ende-kontrollen har bestått, og dokumenter den nøyaktige konfigurasjonen ved siden av tjenesten.
Gi Grafana én kanonisk adresse
TLS-utstedelse er bare halve Grafana-ruten. Angi GF_SERVER_ROOT_URL til den offentlige HTTPS-URL-en. Send trafikken internt til port 3000, og videresend den eksterne protokollen slik at genererte URL-er og sikre cookies forblir konsistente.
Kjør hele Grafana-scenarioet fra et rent nettverk, ikke bare en kontroll av rotsiden. En 502-feil eller sertifikatfeil kan isoleres med automatisk oppsett av domene og TLS. Hvis trafikken når prosessen og dashboards forsvinner sammen med SQLite-filen, eller OAuth-callbacks bruker localhost, må du diagnostisere tilstanden der den oppstår i stedet for å legge flere redirects oppå hverandre.
Planlegg Grafanas gjenoppretting før lansering
Det permanente gjenopprettingssettet består av Grafana-databasen, plugins og provisionert konfigurasjon. Monter /var/lib/grafana før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at denne stien faktisk er persistent. Et volum beskytter data mot at containeren erstattes, men ikke mot tap av verten, utilsiktet sletting eller korrupsjon på applikasjonsnivå.
Ta sikkerhetskopier som forstår datakilden: bruk logiske dumps for aktive databaser når det er nødvendig, og kopier filer bare fra en konsistent tilstand. Oppbevar én kryptert kopi utenfor Grafana-verten. Akseptansekriteriet for en gjenoppretting er konkret — brukere, mapper, dashboards, varslingsregler og metadata for datakilder kommer tilbake, og testvarslet evalueres. Veiledningen for sikkerhetskopiering som er testet gjennom gjenoppretting forklarer hvorfor vellykket jobb alene ikke er tilstrekkelig.
Fjern midlertidig tilgang til oppsettet
En sikker Grafana-distribusjon starter med å fjerne privilegier. Unngå å beholde admin/admin eller utilsiktet eksponere anonym tilgang. Bytt i stedet bootstrap-passordet for administratoren, begrens redigering av datakilder og sørg for at tokens for servicekontoer har et avgrenset scope.
Bytt ut eksempelverdien i GF_SECURITY_ADMIN_PASSWORD umiddelbart, lagre den utenfor imaget og roter den som en administratorkredential hvis den blir eksponert. Begrens administrative ruter, bruk privat DNS for avhengigheter og gå gjennom hver bind mount. Når logger sendes til et sentralt system, må du filtrere bort secrets og privat innhold før de forlater serveren.
Øv på den risikable Grafana-endringen
En grønn container er nødvendig, men ikke tilstrekkelig. Tjenestens service-level indicator er vellykket gjennomføring av «legg til en skrivebeskyttet datakilde, lagre et panel, evaluer en varslingsregel og lever et testvarsel via et kontaktpunkt», mens de mest sannsynlige belastningssignalene er query-fan-out, intervaller for dashboard-oppdatering, evaluering av varsler og plugin-minne i stedet for Grafanas egne lagrede metrics.
Endringskontroll er viktig fordi Grafana-databasemigreringer og plugin-kompatibilitet krever en trinnvis oppgradering med de samme provisioneringsfilene. Bevar det gamle imaget, test migreringer på en kopi av tilstanden og dokumenter om rollback støttes etter at schemaet er flyttet. Hvis dashboards forsvinner sammen med SQLite-filen, eller OAuth-callbacks bruker localhost, må du diagnostisere det første grensesnittet som skiller seg fra det fungerende miljøet.
Dokumenter en Grafana-distribusjon som fungerer
For Grafana må du definere en fungerende transaksjon før lansering: legg til en skrivebeskyttet datakilde, lagre et panel, evaluer en varslingsregel og lever et testvarsel via et kontaktpunkt. Legg forutsetninger, forventet respons og oppryddingstrinn i versjonskontroll uten hemmelige verdier. Lås image-versjonen som ble brukt til å etablere referansen.
Bruk transaksjonen til å validere en erstatning og en uavhengig gjenoppretting. Den gjenopprettede tjenesten er bare godkjent når brukere, mapper, dashboards, varslingsregler og metadata for datakilder kommer tilbake, og testvarslet evalueres. Følg samtidig med på query-fan-out, intervaller for dashboard-oppdatering, evaluering av varsler og plugin-minne i stedet for Grafanas egne lagrede metrics, og gjør den tregeste eller mest begrensede delen om til et tjenestevarsel.
Kontrollen trenger også et negativt scenario: nekt testidentiteten midlertidig tilgang til tilgjengelige datakilder og SMTP dersom levering av varsler er nødvendig. Bekreft at Grafana produserer en feilmelding som kan brukes til handling, samtidig som dataene bevares. Gjenopprett den gyldige tilstanden og gjenta den fungerende transaksjonen. Når begge resultatene beholdes, hindrer det at et overfladisk health-endepunkt blir det eneste produksjonsbeviset.
Slik fjerner Dockup arbeid for Grafana
Ruting, sertifikater, erstatning av tjenester og tilknyttet lagring er fornuftige mål for automatisering. Dockup håndterer dette for Grafana og kan provisionere den tilknyttede managed-databasen eller koble til tjenester på kundens egen server.
Det Dockup ikke bør finne på, er Grafanas trust policy. Etter distribusjonen angir du GF_SERVER_ROOT_URL til den offentlige HTTPS-URL-en, håndhever denne grensen — bytt bootstrap-passordet for administratoren, begrens redigering av datakilder og sørg for at tokens for servicekontoer har et avgrenset scope — og verifiserer resultatet av dette scenarioet: legg til en skrivebeskyttet datakilde, lagre et panel, evaluer en varslingsregel og lever et testvarsel via et kontaktpunkt. Resultatet er infrastruktur med ett klikk og en applikasjonsspesifikk akseptansetest.
Vanlige spørsmål
Hva trenger Grafana for en produksjonsdistribusjon?
Rout Grafana-containeren på port 3000 gjennom én HTTPS-origin. Det tilhørende nettverkskravet er tilgjengelige datakilder og SMTP dersom levering av varsler er nødvendig. Ikke erklær Grafana som klar før du kan legge til en skrivebeskyttet datakilde, lagre et panel, evaluere en varslingsregel og levere et testvarsel via et kontaktpunkt.
Hvilke Grafana-data bør inngå i en sikkerhetskopi?
Gjør /var/lib/grafana persistent, og inkluder Grafana-databasen, plugins og provisionert konfigurasjon i det samme gjenopprettingsmanifestet. En ren Grafana-gjenoppretting er bare vellykket når brukere, mapper, dashboards, varslingsregler og metadata for datakilder kommer tilbake, og testvarslet evalueres.
Krever Grafana HTTPS bak en reverse proxy?
Bruk HTTPS for den offentlige Grafana-originen, og behold port 3000 på den interne ruten. Bruk Grafana-innstillingen riktig: angi GF_SERVER_ROOT_URL til den offentlige HTTPS-URL-en. For Grafana beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for at klientadferd som avhenger av origin, forblir konsistent.
Hvordan bør en Grafana-oppgradering testes?
Gjenopprett gjeldende Grafana-tilstand i en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom fordi Grafana-databasemigreringer og plugin-kompatibilitet krever en trinnvis oppgradering med de samme provisioneringsfilene. Behold det forrige Grafana-imaget til grensen for datamigrering og rollback er forstått.