Prometheus og Grafana på Kubernetes: 12 Steg [2026]

En Kubernetes-klynge kan kjøre hundrevis av pods uten at noen merker at halvparten av dem strever med minnepress, trege disker eller en treg database-tilkobling. Uten innsyn i hva som faktisk skjer inne i klyngen, oppdager driftsteamet problemet først når en kunde klager eller en tjeneste faller helt ut. Det er nøyaktig gapet Prometheus og Grafana er bygget for å tette.

Denne guiden viser hvordan du setter opp et fullverdig overvåkingsoppsett på en norsk eller nordisk Kubernetes-klynge, fra et tomt namespace til et Grafana-dashboard med sanntidsmetrikker og Slack-varsler. Vi bruker Kubernetes 1.37.1 (utgitt 15. september 2026), Helm 4.3.0 og Helm-chartet kube-prometheus-stack 91.9.0, som i skrivende stund er de nyeste stabile versjonene. Du trenger ingen tidligere erfaring med overvåkingsstacker, bare en fungerende klynge og terminal-tilgang.

Målet er ikke bare å få noen grafer på skjermen. Målet er et oppsett du faktisk kan stole på når noe går galt klokken tre om natten: data som overlever pod-restarter, varsler som går til riktig kanal uten å drukne i falske alarmer, og et grensesnitt kollegene dine kan navigere uten å spørre deg først. Vi går gjennom dette i tolv konkrete steg, viser ferdig kode for hvert steg, og dekker sikkerhet, feilsøking og et fullstendig arbeidseksempel du kan kopiere rett inn i egen klynge.

Prometheus, Grafana og Alertmanager: hvem gjør hva

Prometheus ble opprinnelig bygget hos SoundCloud i 2012 for å løse akkurat dette problemet internt. I 2016 ble prosjektet tatt opp i Cloud Native Computing Foundation som det andre hostede prosjektet, rett etter Kubernetes selv, ifølge Prometheus sin egen prosjektoversikt. I dag er Prometheus, Grafana og Alertmanager de tre byggeklossene nesten alle Kubernetes-team i Norden lener seg på når de skal forstå hva som skjer i klyngen.

Prometheus samler inn og lagrer metrikker

Prometheus fungerer som en tidsseriedatabase. Den “scraper” (henter) metrikker fra applikasjoner og klyngekomponenter på fastsatte intervaller, lagrer dem lokalt på disk, og gjør dem søkbare med spørrespråket PromQL. Komponenten er helt frittstående og krever ikke en ekstern database for å fungere, noe som gjør den enkel å installere selv i en liten klynge.

Denne enkelheten har en bakside. Fordi alt lagres lokalt på en enkelt Prometheus-pod som standard, er en frittstående installasjon i praksis begrenset av hvor mye data én disk og én prosess kan håndtere. For de fleste klynger, inkludert de med flere hundre pods, er dette fullt tilstrekkelig, og det er nøyaktig derfor kube-prometheus-stack fortsatt bruker denne modellen som standard. Først når du trenger å beholde data i måneder, eller spørre på tvers av flere klynger samtidig, blir det aktuelt å se på de distribuerte alternativene vi dekker senere i denne guiden.

Grafana visualiserer, Alertmanager varsler

Grafana kobler seg til Prometheus som datakilde og bygger dashboards av tallene. Alertmanager tar over når Prometheus sine varslingsregler slår ut, og ruter varselet videre til Slack, e-post eller et vaktsystem. De tre verktøyene distribueres hver for seg, men i praksis installerer nesten alle dem samlet gjennom Helm-chartet kube-prometheus-stack, som også legger til node-exporter og kube-state-metrics for maskin- og klyngenivå-metrikker.

En viktig detalj mange går glipp av: Prometheus bruker en pull-basert modell, ikke push. I stedet for at applikasjonene dine sender metrikker ut til en sentral mottaker, er det Prometheus selv som med jevne mellomrom besøker hvert endepunkt og leser av tallene. Det gjør feilsøking enklere, fordi du alltid kan sjekke om et endepunkt svarer med en enkel curl mot /metrics-stien, og det betyr at nettverksfeil mellom applikasjon og overvåking viser seg umiddelbart som “target down” i Prometheus sitt eget grensesnitt i stedet for å forsvinne stille i en kø. Den fullstendige datamodellen og spørrespråket er dokumentert i detalj i Grafana sin offisielle dokumentasjon, som også er stedet å gå når du senere vil bygge egne paneltyper utover det som følger med standard-dashboardene.

Node-exporter og kube-state-metrics fyller hver sin nisje i denne arkitekturen. Node-exporter kjører som en DaemonSet på hver node og rapporterer rå maskinvaretall: CPU-bruk, minnebruk, diskplass og nettverkstrafikk på OS-nivå. Kube-state-metrics gjør noe helt annet. Den snakker med Kubernetes sitt API og rapporterer tilstanden til selve objektene, altså hvor mange replikaer en deployment faktisk har kjørende, om en pod er i Pending-tilstand, eller hvor mange ganger en container har restartet. Begge trengs for et komplett bilde: den ene viser hva maskinen gjør, den andre viser hva Kubernetes mener skal skje.

Utover disse to finnes det et stort økosystem av frittstående exportere som dekker nesten alt du kan tenke deg å overvåke. Postgres-exporter og mysqld-exporter dekker databaser, redis-exporter dekker cache-laget, og blackbox-exporter lar deg probe eksterne HTTP-, TCP- eller DNS-endepunkter fra innsiden av klyngen for å måle faktisk oppetid sett fra brukerens perspektiv, ikke bare fra applikasjonens eget synspunkt. Ingen av disse følger med kube-prometheus-stack som standard, men de installeres på samme måte, med sin egen ServiceMonitor, så snart kjernestacken fra denne guiden er på plass.

Komponent	Rolle i stacken	Nyeste versjon	Utgitt
Prometheus	Innsamling og lagring av metrikker	3.15.0	24. sept. 2026
Grafana	Dashboards og visualisering	13.2.3	29. sept. 2026
Alertmanager	Ruting og deduplisering av varsler	0.34.1	17. sept. 2026
node_exporter	Maskinvare- og OS-metrikker per node	1.12.1	14. juli 2026
kube-state-metrics	Tilstand på Kubernetes-objekter (pods, deployments)	2.20.0	16. aug. 2026
kube-prometheus-stack (Helm-chart)	Pakker alt over i én installasjon	91.9.0	2. okt. 2026

Verdt å nevne er at ingen av disse komponentene koster noe i lisens. Hele stacken er åpen kildekode under Apache 2.0 (Prometheus, Alertmanager, exporterne) eller AGPL/kommersiell dobbellisens for Grafana sin kjerne, og du betaler kun for klyngekapasiteten komponentene bruker. Det skiller den fra flere kommersielle SaaS-alternativer for observability, der kostnaden ofte skalerer med antall metrikker eller mengden data du sender inn, uavhengig av hvor mye klyngekapasitet du selv stiller til disposisjon.

Forutsetninger: verktøy og versjoner du trenger

Før du starter bør du ha disse på plass. Du finner oppgraderingsinstruksjoner for selve klyngen i vår gjennomgang av Kubernetes 1.37 og de brytende endringene dersom du fortsatt kjører en eldre versjon.

Verktøy	Versjon brukt i denne guiden	Minimumskrav
Kubernetes-klynge	1.37.1	1.33 eller nyere
Helm	4.3.0	3.x eller nyere (kommandoene er uendret fra Helm 3)
kubectl	Matchende klyngeversjon	Innen ett minor-nummer av klyngen
kube-prometheus-stack	91.9.0	Nyeste chart-release
StorageClass med dynamisk provisionering	–	Må finnes i klyngen (f.eks. gp3, managed-premium)

Sett av minst noen ekstra vCPU og noen GB minne i klyngen utover det applikasjonene dine allerede bruker. Prometheus, Grafana og de tilhørende exporterne legger seg på toppen av eksisterende arbeidsbelastning, og en klynge som allerede kjører i maksimal kapasitet bør skaleres opp før du installerer stacken.

Du bør også ha skrive- og lesetilgang til å opprette ClusterRole– og CustomResourceDefinition-objekter i klyngen, siden Prometheus-operatoren legger til flere egne CRD-er (ServiceMonitor, PodMonitor, PrometheusRule, Alertmanager, Probe og ThanosRuler). Mangler du disse rettighetene, for eksempel i en delt klynge der en plattformavdeling styrer tilgangen, må du be dem installere CRD-ene sentralt før du kjører Helm-installasjonen selv. Kubernetes sin offisielle utgivelsesside holder alltid oversikt over hvilke versjoner som er under aktiv support, noe som er nyttig å sjekke via kubernetes.io/releases før du låser deg til en bestemt chart-versjon.

Steg 1-4: klargjør klyngen, installer Helm og legg til Prometheus-repoet

Start med å bekrefte at klyngen og kommandolinjeverktøyene er riktig koblet sammen. Dette er de fire første av de tolv stegene i oppsettet, og de tar normalt under fem minutter samlet hvis klyngen allerede er satt opp korrekt fra før.

Feiler kubectl cluster-info med en tilkoblingsfeil, er det nesten alltid kubeconfig-filen som peker til feil kontekst. Kjør kubectl config get-contexts og bekreft at stjernen står ved riktig klynge før du går videre, spesielt om du jobber med flere klynger samtidig, for eksempel en for test og en for produksjon.

Steg 1: Bekreft tilkobling til klyngen med kubectl cluster-info.
Steg 2: Installer eller oppgrader Helm til 4.3.0.
Steg 3: Legg til Prometheus Community sitt Helm-repo.
Steg 4: Opprett et eget namespace for overvåking, isolert fra applikasjonene.

# Steg 1: bekreft klyngetilkobling
kubectl cluster-info
kubectl get nodes -o wide

# Steg 2: bekreft Helm-versjon
helm version --short
# Forventet: v4.3.0

# Steg 3: legg til og oppdater repoet
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# Steg 4: eget namespace holder stacken isolert fra applikasjonene
kubectl create namespace monitoring

Det er fristende å installere overvåkingsstacken i default-namespacet, men det gjør opprydding og rettighetsstyring unødvendig komplisert senere. Hold den i et eget namespace fra dag én, akkurat som du ville gjort med sikkerhetskomponenter beskrevet i vår gjennomgang av Kubernetes container-sikkerhet.

Legg også merke til at helm repo update bør kjøres som en vane hver gang du planlegger en ny installasjon, ikke bare den første gangen. Prometheus Community sitt repo publiserer nye chart-versjoner ofte, og en lokal Helm-cache som er flere uker gammel kan føre til at du installerer en versjon som allerede har kjente feilrettinger tilgjengelig. Dersom du jobber i et team, er det verdt å sjekke inn values.yaml-filen fra steg 5 i et eget Git-repo sammen med en Chart.lock eller tilsvarende versjonssperre, slik at alle i teamet installerer nøyaktig samme oppsett uavhengig av når de kjører kommandoen.

Steg 5-7: tilpass values.yaml og installer kube-prometheus-stack

Chartet kube-prometheus-stack kommer med fornuftige standardverdier, men du bør aldri installere det blindt i produksjon. Lag en egen values.yaml som styrer lagringsstørrelse, oppbevaringstid for metrikker og ressursgrenser for Prometheus-poden.

Standardchartet uten tilpasning installerer alt med minimale ressursgrenser og ingen persistent lagring, noe som er greit for en rask demo men farlig i et reelt oppsett. De tre feltene du nesten alltid må overstyre er retention (hvor lenge metrikkene lagres før de slettes automatisk), storageSpec (hvilken disk Prometheus skal skrive til, og hvor stor den er), og ressursgrensene under resources. Sett disse for lavt og Prometheus blir drept av kjernen når minnebruken eksploderer under en innsamlingsrunde med mange mål. Sett dem for høyt uten å følge opp, og du betaler for kapasitet klyngen aldri bruker, noe som fort blir en diskusjon med FinOps-ansvarlige dersom klyngen allerede kjører stramt budsjettert.

# values.yaml
prometheus:
  prometheusSpec:
    retention: 15d
    resources:
      requests:
        cpu: 500m
        memory: 2Gi
      limits:
        cpu: "1"
        memory: 4Gi
    storageSpec:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 50Gi

grafana:
  persistence:
    enabled: true
    size: 10Gi
  adminPassword: "sett-et-eget-passord-her"

alertmanager:
  alertmanagerSpec:
    storage:
      volumeClaimTemplate:
        spec:
          resources:
            requests:
              storage: 5Gi

Steg 6 og 7 er selve installasjonen. Lås alltid chart-versjonen eksplisitt med --version slik at en fremtidig helm repo update ikke drar inn en ny major-versjon uten at du har testet den først.

Merk at adminPassword satt direkte i values.yaml lagres i klartekst i chartets genererte Kubernetes Secret, noe som er akseptabelt for en test men bør unngås i produksjon. Et bedre mønster er å referere til en eksisterende Secret via admin.existingSecret, slik at selve passordet håndteres av et sekrethåndteringssystem i stedet for å ligge i en fil som sjekkes inn i Git. Dette er spesielt relevant hvis klyngen allerede følger identitetsprinsippene fra vår artikkel om OIDC og CA-rotasjon i EKS, der nettopp hemmeligheter og rotasjon av legitimasjon er tema.

# Steg 6-7: installer med låst versjon og egen values-fil
helm upgrade --install kube-prometheus-stack \
  prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --version 91.9.0 \
  -f values.yaml \
  --create-namespace

# Forventet utdrag av output:
# NAME: kube-prometheus-stack
# NAMESPACE: monitoring
# STATUS: deployed
# REVISION: 1

Steg 8-9: verifiser installasjonen og åpne Grafana

Installasjonen tar typisk ett til to minutter før alle podene er klare. Bruk kubectl get pods til å følge fremdriften, og vent til alle viser Running med riktig antall klare containere før du går videre.

# Steg 8: verifiser at alt kjører
kubectl get pods -n monitoring

# Forventet output (forenklet):
# NAME                                                     READY   STATUS    RESTARTS
# kube-prometheus-stack-grafana-7d9f6c8b5-x2kqp            3/3     Running   0
# kube-prometheus-stack-kube-state-metrics-6b7f9d-abc12    1/1     Running   0
# kube-prometheus-stack-operator-5c8d9f7b6-def34           1/1     Running   0
# kube-prometheus-stack-prometheus-node-exporter-gh56i     1/1     Running   0
# prometheus-kube-prometheus-stack-prometheus-0            2/2     Running   0
# alertmanager-kube-prometheus-stack-alertmanager-0        2/2     Running   0

# Steg 9: åpne Grafana lokalt
kubectl port-forward -n monitoring svc/kube-prometheus-stack-grafana 3000:80

Gå til http://localhost:3000 og logg inn med brukernavnet admin og passordet du satte i values.yaml. Hvis du ikke satte et eget passord, bruker chartet standardverdien prom-operator, og du bør bytte det umiddelbart under innstillinger. For produksjon anbefales en ordentlig Ingress med TLS i stedet for port-forwarding, på samme måte som beskrevet i vår gjennomgang av CI/CD mot AKS.

Chartet installerer automatisk et sett med ferdige dashboards for klyngen, deriblant oversikt over noder, namespaces, deployments og selve Prometheus-installasjonen sin egen helsetilstand. Dette er et undervurdert poeng: du får faktisk innsyn i klyngen allerede før du har koblet til en enkelt egen applikasjon. Bla gjennom mappen General i Grafana etter installasjon og se om tallene for klyngen din stemmer med det du forventer, for eksempel antall noder og totalt antall kjørende pods. Stemmer ikke tallene, er det et tegn på at node-exporter eller kube-state-metrics ikke har startet riktig, og du bør gå tilbake til steg 8 og kontrollere pod-statusen på nytt før du går videre.

Steg 10: koble egne applikasjoner til Prometheus med ServiceMonitor

Prometheus-operatoren som følger med chartet bruker en egen Kubernetes-ressurs kalt ServiceMonitor for å vite hvilke tjenester den skal hente metrikker fra. Dette er stedet de fleste nye brukere kjører seg fast, fordi operatoren kun følger ServiceMonitor-objekter som matcher en bestemt label-selector.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: min-app-monitor
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: min-app
  namespaceSelector:
    matchNames:
      - produksjon
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s

Legg merke til release: kube-prometheus-stack-labelen. Prometheus-operatoren er konfigurert til kun å plukke opp ServiceMonitor-ressurser med denne labelen (eller den du satte ved installasjon), og mangler den, blir applikasjonen din aldri scrapet selv om alt annet er riktig konfigurert. Tjenesten din må også eksponere en port kalt metrics som matcher porten i selve Service-objektet.

Har applikasjonen din ingen egen Kubernetes Service, for eksempel fordi den kjører som en frittstående pod eller en jobb, finnes et alternativ kalt PodMonitor. Den fungerer identisk med ServiceMonitor, men peker direkte på pods via label-selector i stedet for via en Service. Begge ressurstypene støtter også relabelings, som lar deg omskrive eller filtrere labels før de lagres i Prometheus. Dette er nyttig hvis applikasjonen din allerede eksponerer en label som pod_ip eller en annen høy-kardinalitet-verdi du ikke vil ha lagret, siden du da kan droppe den helt på vei inn i stedet for å rydde opp i dataene etterpå.

Steg 11-12: varslingsregler og Alertmanager til Slack

Rene dashboards er nyttige, men ingen sitter og stirrer på Grafana hele dagen. De siste to stegene setter opp automatiske varsler som trigges av PromQL-regler og rutes videre til en Slack-kanal via Alertmanager.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: min-app-regler
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  groups:
    - name: min-app.regler
      rules:
        - alert: HøyFeilrate
          expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
          for: 10m
          labels:
            severity: critical
          annotations:
            summary: "Feilraten for min-app har passert 5 % de siste 10 minuttene"
        - alert: PodCrashLooping
          expr: increase(kube_pod_container_status_restarts_total[15m]) > 3
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Pod {{ $labels.pod }} restarter stadig"

# Utdrag av Alertmanager-konfigurasjon (legges i values.yaml under alertmanager.config)
route:
  receiver: slack-varsler
  group_by: ["alertname"]
  group_wait: 30s
  repeat_interval: 4h

receivers:
  - name: slack-varsler
    slack_configs:
      - api_url: "https://hooks.slack.com/services/DIN/WEBHOOK/URL"
        channel: "#drift-varsler"
        send_resolved: true
        title: "{{ .CommonAnnotations.summary }}"

PromQL-funksjonen rate() regner ut endringshastighet over tid, mens increase() teller det absolutte antallet hendelser i vinduet du angir. Begge er sentrale i nesten alle varslingsregler, og du finner den fulle syntaksen i Prometheus sin konfigurasjonsdokumentasjon.

Legg spesielt merke til feltet for: 10m i eksempelet over. Uten det ville regelen slått ut momentant ved den minste feilrate-topp, selv en som varer i noen sekunder og løser seg selv. Ved å kreve at tilstanden holder seg over et gitt tidsvindu, filtrerer du bort kortvarige svingninger og sitter igjen med varsler som faktisk krever at et menneske gjør noe. Alertmanager sin egen group_by-innstilling gjør noe liknende på toppen: den samler flere samtidige varsler fra samme rotårsak i én enkelt Slack-melding i stedet for å spamme kanalen med tjue separate meldinger når en hel node går ned samtidig. Den fullstendige listen over konfigurasjonsmuligheter for ruting og dempe-regler finner du i Grafana sin dokumentasjon for varsling, som også dekker Grafana sitt eget innebygde varslingssystem dersom du på sikt vil flytte varslingslogikken dit i stedet for i Alertmanager.

Sikre oppsettet: RBAC, nettverkspolicyer og autentisering

Prometheus-operatoren krever ganske brede leserettigheter i klyngen for å kunne discover-e tjenester og endepunkter automatisk. Det er normalt og nødvendig, men det betyr også at monitoring-namespacet bør behandles som et sensitivt område, ikke en lekeplass alle utviklere har full skrivetilgang til. En kompromittert Grafana-instans med lesetilgang til alle metrikker i klyngen kan i praksis kartlegge hele den interne arkitekturen din, fra navn på interne tjenester til hvilke databaser som er i bruk, uten å ha rørt en eneste applikasjonspod direkte.

Tre konkrete tiltak er verdt å prioritere. Først, legg en NetworkPolicy som kun tillater innkommende scrape-trafikk fra Prometheus-podens namespace, slik at ikke hvilken som helst pod i klyngen kan lese metrikkendepunktene dine. Dernest, sett Grafana bak en ordentlig autentiseringsløsning (OAuth2-proxy, Azure AD eller et tilsvarende identitetsoppsett) før du eksponerer den utenfor klyngen, aldri bare en LoadBalancer med standard admin-passord. Til slutt, begrens hvem som kan redigere PrometheusRule- og ServiceMonitor-ressurser med RBAC, siden en feilkonfigurert regel kan skape falske alarmer i hele organisasjonen. Disse prinsippene overlapper med det vi dekket i artikkelen om migrering til Kubernetes Gateway API, der nettopp innkommende trafikkontroll er sentralt.

Verdt å nevne er også at selve metrikkene kan avsløre mer enn du tror. Et endepunkt som eksponerer HTTP-headere, databasenavn eller interne URL-er som label-verdier, lekker informasjon til alle som får lesetilgang til Prometheus-UI eller Grafana sine egne “Explore”-paneler. Gå gjennom hva applikasjonene dine faktisk eksponerer på /metrics før du kobler dem til stacken, og fjern labels som ikke tilfører operasjonell verdi. Dette er spesielt viktig i regulerte bransjer i Norden, der et overvåkingssystem med for bred lesetilgang lett blir sin egen compliance-hodepine, uavhengig av hvor godt resten av klyngen er sikret.

Vanlige fallgruver du bør unngå

De fleste problemene med denne stacken skyldes et lite utvalg gjentatte feil. Her er de du bør sjekke først.

Ingen persistent lagring satt opp. Uten storageSpec forsvinner all historisk metrikkdata hver gang Prometheus-poden restarter eller flyttes til en annen node.
For lave ressursgrenser. En klynge med mange tjenester og høy label-kardinalitet kan lett presse Prometheus over minnegrensen, og poden blir OOMKilled midt i en innsamlingsrunde.
Feil label på ServiceMonitor. Mangler release-labelen som matcher operatorens selector, blir ServiceMonitor-objektet ditt stille ignorert, uten feilmelding noe sted.
For aggressivt scrape-intervall. Å sette intervallet til 5 sekunder på alle endepunkter kan overbelaste små klynger og mette nettverket mellom noder.
Grafana eksponert uten autentisering. En offentlig IP med standard admin-passord er en åpen dør rett inn i klyngens driftsdata.
Ingen grense for oppbevaringstid. Uten retention eller retentionSize fyller Prometheus disken over tid og krasjer når volumet er fullt.
Varsler uten “for”-felt. En regel som slår ut momentant på hver forbigående verditopp skaper varsel-utmattelse, og teamet begynner raskt å ignorere Slack-kanalen helt.
Dashboards bygget i UI uten eksport. Et dashboard du bygger manuelt i Grafana sitt grensesnitt forsvinner hvis Grafana-poden mister persistent lagring. Eksporter dashboards som JSON og lagre dem i Git, eller provisioner dem direkte via values.yaml.

Ingen av disse feilene er spesielt vanskelige å fikse i etterkant, men alle sammen er mye billigere å unngå fra start enn å rydde opp i etter at en ekte driftshendelse har avslørt dem. Bruk gjerne listen som en sjekkliste rett før du går fra testklynge til produksjon.

Avansert: langtidslagring, høy tilgjengelighet og føderasjon

Standardoppsettet lagrer metrikker lokalt på en PersistentVolume, noe som fungerer fint for de første ukene, men blir en begrensning når du vil beholde data i måneder eller kjøre Prometheus på tvers av flere klynger. Da trenger du et langtidslager som snakker Prometheus sin remote-write- eller remote-read-protokoll.

I praksis legger du til et remoteWrite-felt under prometheusSpec i samme values.yaml du allerede bruker, og peker det mot endepunktet til Thanos Receiver eller Mimir sin distributor-komponent. Den lokale Prometheus-instansen fortsetter å fungere som før, men sender nå i tillegg en kopi av alle innsamlede metrikker videre til det langsiktige lageret. Dette gir deg et nyttig sikkerhetsnett: selv om det distribuerte laget skulle feile en periode, har du fortsatt full funksjonalitet lokalt i klyngen helt uavhengig av det.

Løsning	Formål	Lagringsbackend	Bakgrunn
Thanos	Langtidslagring og global spørring over flere klynger	Objektlagring (S3-kompatibel)	CNCF-prosjekt, startet av Improbable
Grafana Mimir	Horisontalt skalerbar, Prometheus-kompatibel lagring	Objektlagring (S3-kompatibel)	Utviklet av Grafana Labs
Cortex	Tidlig horisontalt skalerbar Prometheus-lagring	Objektlagring eller Cassandra	CNCF-prosjekt, forløper til Mimir

For de fleste norske team holder det lenge å starte med standard lokal lagring og bare innføre Thanos eller Mimir når du faktisk har flere klynger som skal spørres samtidig, eller et compliance-krav om å beholde metrikker lenger enn disken i klyngen tillater. Å innføre et distribuert lagringslag for tidlig gir bare mer operasjonell kompleksitet uten tilsvarende nytte.

Høy tilgjengelighet for selve Prometheus løses enklest ved å sette replicas: 2 i prometheusSpec. Operatoren kjører da to identiske Prometheus-instanser som scraper de samme målene uavhengig av hverandre, slik at et enkelt podutfall eller en nodefeil ikke skaper et hull i metrikkhistorikken.

Alertmanager kan på samme måte kjøre med flere replikaer som danner en gossip-mesh mellom seg. De synkroniserer hvilke varsler som allerede er sendt, slik at du ikke mottar dobbelt opp i Slack bare fordi du har to Alertmanager-pods i stedet for én. Dette er allerede konfigurert automatisk av Prometheus-operatoren når du setter alertmanagerSpec.replicas til mer enn 1, så det eneste du selv trenger å gjøre er å øke tallet i values.yaml.

Ressursbruk og kostnader: hva stacken faktisk koster klyngen

En fullverdig kube-prometheus-stack-installasjon er ikke gratis i form av klyngekapasitet. Prometheus-poden, Grafana, Alertmanager, node-exporter på hver node og kube-state-metrics legger samlet beslag på CPU og minne som ellers kunne gått til applikasjonene dine. I en liten klynge med få noder kan dette oppleves som en overraskende stor andel av total kapasitet, spesielt hvis ressursgrensene fra steg 5 ble satt generøst uten at noen fulgte opp i etterkant.

Det enkleste stedet å begynne er å overvåke overvåkingen selv. Chartet installerer egne dashboards for Prometheus sin egen ressursbruk, og de bør sjekkes med samme regelmessighet som resten av klyngen. Reduser scrape-frekvensen på lav-prioriterte mål, fjern metrikker du aldri spørrer på via metric_relabel_configs, og vurder å senke retention-tiden hvis 15 dager er mer enn teamet faktisk bruker i praksis. Dette er nøyaktig den typen klyngekostnad som dekkes mer generelt i vår gjennomgang av OpenCost-oppsett for kostnadsinnsyn i Kubernetes, der du kan koble kostnadsdata direkte til de samme Prometheus-metrikkene du allerede samler inn gjennom denne guiden.

Feilsøking: de vanligste problemene og løsningene

Når noe ikke fungerer som forventet, er det nesten alltid en av disse åtte årsakene.

Symptom	Sannsynlig årsak	Løsning
Pods står fast i Pending	Ingen StorageClass kan binde PersistentVolumeClaim	Sjekk `kubectl get storageclass` og sett en standard-klasse
Targets vises som Down i Prometheus-UI	NetworkPolicy eller brannmur blokkerer scrape-porten	Åpne port 9100/metrics-port fra monitoring-namespacet
Ingen data i Grafana-dashboards	Datasourcen peker på feil Prometheus-tjeneste-URL	Bekreft URL under Grafana → Connections → Data sources
ServiceMonitor plukkes ikke opp	Manglende eller feil `release`-label	Match labelen mot `serviceMonitorSelector` i operatoren
Alertmanager sender ikke til Slack	Feil webhook-URL eller manglende secret-montering	Test webhooken direkte med `curl` før du setter den i config
Prometheus-pod bruker stadig mer minne	Høy kardinalitet fra for mange unike label-kombinasjoner	Fjern høy-kardinalitet labels som bruker-ID eller request-ID
Kan ikke logge inn i Grafana etter oppgradering	Admin-secret ble regenerert av Helm	Hent nytt passord med `kubectl get secret` og decode base64
prometheus-operator i CrashLoopBackOff	CRD-ene er utdaterte etter en chart-oppgradering	Kjør `kubectl apply` på CRD-ene fra ny chart-versjon før upgrade

Et godt førstesteg i nesten alle disse situasjonene er å se på hendelsesloggen før du graver i selve konfigurasjonen. Kommandoen kubectl describe pod <pod-navn> -n monitoring viser ofte rotårsaken direkte i Events-feltet, enten det er en manglende StorageClass, en feil image-tag eller en ressursgrense som er satt for lavt til at poden i det hele tatt får lov til å starte. Kombiner det med kubectl logs på selve Prometheus- eller operator-poden, og du har løst de fleste av disse åtte problemene uten å måtte søke eksternt etter svar.

Komplett fungerende prosjekt: fra null til dashboard

Sett alt sammen med et minimalt eksempel. Her er en applikasjon som eksponerer metrikker, en Service som peker på den, og en ServiceMonitor som kobler den til stacken du allerede har installert. Et typisk repo for et slikt prosjekt inneholder fire filer: selve applikasjonsmanifestet, ServiceMonitor-en fra steg 10, PrometheusRule-en fra steg 11, og values.yaml-filen fra steg 5, alle under versjonskontroll slik at endringer i overvåkingsoppsettet går gjennom samme code review-prosess som applikasjonskoden selv.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: min-app
  namespace: produksjon
  labels:
    app: min-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: min-app
  template:
    metadata:
      labels:
        app: min-app
    spec:
      containers:
        - name: min-app
          image: minregistry.no/min-app:1.4.0
          ports:
            - name: metrics
              containerPort: 9100
---
apiVersion: v1
kind: Service
metadata:
  name: min-app
  namespace: produksjon
  labels:
    app: min-app
spec:
  selector:
    app: min-app
  ports:
    - name: metrics
      port: 9100
      targetPort: 9100

Legg ServiceMonitor-en fra steg 10 og PrometheusRule-en fra steg 11 i samme repo som disse manifestene, og rull ut alt sammen med kubectl apply -f .. Når podene er klare, kan du bekrefte at alt fungerer med noen enkle PromQL-spørringer direkte i Prometheus-UI:

# Antall kjørende replikaer akkurat nå
kube_deployment_status_replicas{deployment="min-app"}

# Gjennomsnittlig minnebruk per pod de siste 5 minuttene
avg(container_memory_working_set_bytes{pod=~"min-app-.*"})

# Feilrate på HTTP-forespørsler
sum(rate(http_requests_total{job="min-app", status=~"5.."}[5m]))

Får du tall tilbake på alle tre spørringene, er hele kjeden fra applikasjon til Prometheus til Grafana bekreftet fungerende, og du kan bygge egne dashboards og varsler videre på samme mønster. Neste naturlige steg er å koble de samme metrikkene til en Horizontal Pod Autoscaler eller KEDA, slik at klyngen selv skalerer min-app opp og ned basert på faktisk belastning i stedet for faste replika-tall. Du finner det fullstendige oversiktsbildet for hele klyngen samlet under Skytjenester-kategorien på shattered.io, inkludert relaterte guider for autoskalering og kostnadskontroll som bygger videre på samme overvåkingsdata, slik som OpenCost-oppsettet for kostnadsinnsyn og KEDA for metrikkbasert autoskalering.

Ofte stilte spørsmål

Må jeg bruke Helm, eller kan jeg installere Prometheus og Grafana manuelt?
Du kan installere alt manuelt med rene YAML-manifester, men Prometheus-operatoren og CRD-ene (ServiceMonitor, PrometheusRule) gjør oppsettet betydelig enklere å drifte over tid. De fleste team i Norden bruker kube-prometheus-stack nettopp fordi det sparer uker med konfigurasjonsarbeid som ellers går til å holde Prometheus-konfigurasjonen manuelt synkronisert med hva som faktisk kjører i klyngen. Manuell installasjon kan fortsatt gi mening hvis organisasjonen din har strenge krav til at ingen tredjeparts Helm-chart skal kjøre i klyngen, men da må du selv bygge og vedlikeholde operatorlogikken chartet ellers gir deg gratis.

Hvor mye diskplass bør jeg sette av til Prometheus?
Det avhenger av antall metrikker og oppbevaringstid, men 50 GB med 15 dagers retention er et fornuftig utgangspunkt for en mellomstor klynge. Overvåk selve diskbruken i Grafana og øk volumet før det blir kritisk.

Kan jeg kjøre dette i en liten utviklingsklynge, eller krever det en stor produksjonsklynge?
Stacken kjører fint i en liten klynge, inkludert lokale testklynger, så lenge du senker ressursgrensene i values.yaml og kutter antall replikaer til én. Full høy tilgjengelighet med to Prometheus-replikaer bør reserveres for produksjon.

Hvorfor ser jeg ikke metrikkene fra applikasjonen min i Grafana?
I ni av ti tilfeller er årsaken en ServiceMonitor som mangler riktig release-label, eller en Service hvor portnavnet ikke matcher det ServiceMonitor-en ber om. Sjekk begge først.

Er Grafana Alloy et must-have i 2026?
Nei. Grafana Alloy er en telemetri-innsamler som kan erstatte eller utvide node-exporter og enkelte scrape-jobber, særlig i oppsett som også samler logger og traces via OpenTelemetry. For et rent metrikkoppsett som dekket i denne guiden er det ikke nødvendig å legge det til.

Hvordan sikrer jeg at Alertmanager faktisk sender varsler og ikke bare demper dem?
Test receiver-konfigurasjonen isolert med en manuell curl mot webhook-URL-en før du kobler den til en reell PrometheusRule, og bruk amtool til å verifisere routingtreet. Sjekk også at group_wait og repeat_interval ikke er satt så høyt at varslene virker “stille” i testing.

Kan jeg overvåke flere klynger med én Grafana-instans?
Ja. Legg til flere Prometheus-instanser som separate datakilder i samme Grafana, eller bruk Thanos eller Mimir til å slå sammen dataene bak én enkelt forespørsels-URL. Sistnevnte er ryddigere når antall klynger passerer tre eller fire.

Trenger jeg Istio eller en service mesh for at dette skal fungere?
Nei, kube-prometheus-stack er helt uavhengig av service mesh. En mesh kan gi deg ekstra nettverksmetrikker på toppen, men den grunnleggende overvåkingen i denne guiden krever ingen slik avhengighet.

Hva er forskjellen mellom å varsle i Alertmanager og å varsle direkte fra Grafana?
Alertmanager evaluerer regler definert i PrometheusRule-objekter og er uavhengig av om noen har Grafana åpent. Grafana sitt eget varslingssystem evaluerer i stedet regler knyttet til spesifikke dashboard-paneler og kan bruke flere ulike datakilder samtidig, ikke bare Prometheus. For et rendyrket Kubernetes-oppsett som i denne guiden er Alertmanager det mest etablerte valget, men begge kan kjøre side om side uten konflikt dersom du på sikt også overvåker datakilder utenfor klyngen.