Kubernetes-övervakning kräver en annan approach än traditionell övervakning. Denna guide täcker Prometheus, Grafana, metrics-server, kube-state-metrics, logging med Loki/EFK, alerting med Alertmanager och övervakning av kostnader i K8s-kluster.
Kubernetes-övervakning (K8s-monitoring) är fundamentalt annorlunda än traditionell serverövervakning. I stället för att övervaka enskilda servrar övervakar du ett dynamiskt system där pods skapas och förstörs kontinuerligt, noder läggs till och tas bort, och arbetsbelastningar flyttas automatiskt. Du behöver en övervakningsstack som förstår K8s unika egenskaper.
Den här guiden ger dig en komplett genomgång av hur du bygger en robust övervakningsstack för Kubernetes i produktion. Jag har satt upp och driftsatt övervakning för allt från enklare K3s-kluster till stora EKS-kluster med hundratals noder – här är vad jag lärt mig om vad som fungerar och vad som inte gör det.
Kubernetes monitoring stack – översikt
En komplett K8s-övervakningsstack består av flera lager: metrics-insamling (Prometheus, metrics-server), visualisering (Grafana), logging (Loki, EFK-stacken), alerting (Alertmanager), och kostnadsövervakning (Kubecost, OpenCost). Stacken kan installeras manuellt, via Helm-charts, eller via hanterade tjänster från molnleverantörer.
Prometheus är standarden för K8s-metrics – det är ett open source-system för insamling och lagring av tidsseriedata med en kraftfull frågesyntax (PromQL). Prometheus scrapar (hämtar) metrics från instrumenterade tjänster över HTTP. Kube-prometheus-stack (ett Helm-chart) installerar Prometheus, Grafana, Alertmanager och en samling förkonfigurerade dashboards och alert-regler.
För hanterade alternativ: Amazon Managed Service for Prometheus + Grafana, Azure Monitor Managed Service for Prometheus, eller GCP Cloud Monitoring. Dessa hanterade tjänster minskar driftkomplexiteten men ger mindre flexibilitet. För de flesta team rekommenderar jag att börja med Kube-prometheus-stack och övergå till hanterade tjänster när driftskomplexiteten blir ett problem.
Metrics-server och kube-state-metrics
Metrics-server är en cluster-wide aggregator för resursanvändningsdata. Den samlar in CPU och minne per pod och nod från Kubelet och exponerar dem via Metrics API. Metrics-server krävs för Horizontal Pod Autoscaler (HPA) och `kubectl top`. Den är lättviktig och installeras som standard i de flesta K8s-distributioner.
Kube-state-metrics (KSM) är en add-on som genererar metrics från Kubernetes API-objekt – inte från faktisk resursanvändning utan från objektens tillstånd. KSM exporterar metrics som: antal pods per deployment, antal tillgängliga repliker, resursförfrågningar och begränsningar per container, antal noder i varje status, och PVC-status.
Båda är avgörande. Metrics-server ger dig realtidsdata för auto-scaling och felsökning ("varför är podden långsam?"). KSM ger dig långsiktiga trender och kapacitetsplaneringsdata ("ökar antalet pods i detta namespace över tid?"). Installera båda från dag ett.
Prometheus – hjärtat i K8s-övervakning
Prometheus samlar in metrics via pull-modellen – den scrapar metrics-endpoints med en konfigurerbar intervall (standard 30 sekunder). I Kubernetes använder Prometheus service discovery för att automatiskt hitta nya pods, tjänster, noder och endpoints. Du konfigurerar scrape-regler i Prometheus-konfigurationen för att specificera vilka tjänster som ska övervakas.
ServiceMonitor är ett CRD (Custom Resource Definition) i Prometheus Operator som låter dig definiera scrape-konfiguration i Kubernetes-format. Du skapar en ServiceMonitor för varje tjänst du vill övervaka, med label-selector som matchar tjänstens labels. Detta är mycket enklare än att manuellt konfigurera Prometheus scrape-regler.
För icke-Kubernetes-tjänster: använd Prometheus remote write för att skicka metrics från externa system (databaser, lastbalanserare, molntjänster) till din Prometheus-instans. Använd också Prometheus exporters – specialiserade agenter som samlar in metrics från system som inte exponerar Prometheus-format direkt (PostgreSQL exporter, Redis exporter, Nginx exporter).
Grafana – visualisering och dashboards
Grafana är standardvisualiseringsplattformen för Prometheus-data. Med Grafana skapar du dashboards som visualiserar metrics i realtid – linjediagram, stapeldiagram, värmekartor, och stat-tavlor. Kube-prometheus-stack installerar med ett antal förkonfigurerade dashboards: Kubernetes Cluster Overview, Namespace by Pod, Pod Details, och Node Exporter.
Skapa anpassade dashboards för dina specifika behov: applikationsspecifika dashboards (request latency, error rate, throughput), teamspecifika dashboards (resursanvändning per team/namespace), och kostnadsdashboards (Kubecost). Använd variabler i Grafana för att göra dashboards interaktiva – välj namespace, deployment eller pod från en dropdown-meny.
Grafana stöder också alerting direkt från paneler. Du kan skapa alert-regler baserade på dina dashboards och få notifikationer via Slack, Teams, PagerDuty eller e-post. Grafana Alerting har ersatt det tidigare separata Grafana-alertingssystemet och är nu enhetligt och kraftfullt.
Logging med Loki och EFK-stacken
Loki är Grafanas loggaggregeringssystem som är designat för Kubernetes. Till skillnad från Elasticsearch (som indexerar hela loggmeddelanden) lagrar Loki loggar komprimerade och indexerar endast metadata (labels som namespace, pod, container). Detta gör Loki billigare och enklare att driva, särskilt i stora kluster.
EFK-stacken (Elasticsearch, Fluentd/Fluent Bit, Kibana) är det mer traditionella alternativet. Elasticsearch indexerar fulltext, vilket ger kraftfullare sökning men kräver mer resurser. Fluent Bit är en lättviktig loggprocessor som körs som DaemonSet på varje nod och samlar in containerloggar från Docker/containerd.
Välj Loki för kostnadseffektiv logghantering i stora K8s-kluster (särskilt om du redan använder Grafana). Välj EFK om du behöver avancerad fulltextsökning, maskininlärning på loggar (Elastic ML), eller långsiktig logglagring med indexering. Många organisationer använder båda – Loki för daglig felsökning och EFK för compliance och forensik.
Alerting med Alertmanager
Prometheus Alertmanager hanterar alerting – den tar emot alerts från Prometheus, grupperar dem, undertrycker dubbletter, och skickar notifikationer via konfigurerbara kanaler. Alertmanager har inbyggda funktioner för: group by (gruppera alerts per namespace, severity, cluster), inhibit (undertryck lågprioritets-alerts om högprioritets-alert är aktiv), och silence (tysta kända problem under underhåll).
Definiera alert-regler i Prometheus (eller som PrometheusRule CRD) med PromQL-uttryck. Exempel: `node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.1` (mindre än 10% ledigt minne på en nod). Använd labels för att kategorisera alerts: severity=critical, severity=warning, team=platform, namespace=production.
Konfigurera route i Alertmanager för att dirigera alerts till rätt kanal: kritiska alerts till PagerDuty/Opsgenie, varningar till Slack/Teams, info till e-post. Använd group_by och group_wait för att minska alert-trötthet – gruppera liknande alerts från samma namespace och skicka en sammanfattning var 5:e minut i stället för en alert per händelse.
Anpassade metrics och applikationsövervakning
Utöver infrastrukturmetrics behöver du applikationsspecifika metrics – request latency, error rate, antal aktiva användare, köstorlek, och affärs-KPI:er. Dina applikationer exponerar dessa metrics via en HTTP-endpoint (oftast /metrics) i Prometheus-format. Använd client-bibliotek som Prometheus client (Go, Java, Python, Node.js, .NET, Ruby).
För att mäta HTTP-request latency: instrumentera din HTTP-server med Prometheus Histogram-metrics med bucket-storlekar som speglar dina SLA:er (0.1s, 0.5s, 1s, 2s, 5s). Kombinera med labels för metod, path, status code. Skapa en dashboard som visar P50, P95 och P99 latency över tid.
Applikationsspecifik alerting: sätt alerts på anpassade metrics som "antal pågående order i status ERROR > 10" eller "antal aktiva användare i kritiska flöden = 0". Använd Service Level Objectives (SLOs) baserade på dina anpassade metrics – "99.9% av requests ska ha < 500ms latency under en 30-dagarsperiod" – och alerta när SLO-budgeten närmar sig att överskridas.
Kostnadsövervakning i Kubernetes
Kubernetes kostnadsallokering är en av de största utmaningarna med K8s i produktion. Pod-resurser delar noder, vilket gör det svårt att veta vilket team eller vilken applikation som driver kostnaderna. Kubecost (CNCF-projekt) och OpenCost (CNCF-incubating) löser detta genom att analysera resursanvändning och allokera kostnader per namespace, deployment, pod och label.
Kubecost installeras som ett Helm-chart och integreras med din molnleverantörs prislista (AWS, Azure, GCP, on-prem). Det ger: kostnad per namespace/deployment, resursallokering med overhead, rekommendationer för resursoptimering, och budgetvarningar. OpenCost är det CNCF-community-drivna alternativet som nu är standard för K8s-kostnadsallokering.
Använd kostnadsövervakning för att: identifiera over-provisionerade resurser (HPA-inställningar som är för generösa), upptäcka övergivna resurser (gamla pods som inte används), allokera kostnader till rätt team/affärsenhet, och fatta beslut om node-storlek och instance-typer (spot instances vs on-demand).
Cluster-events och felsökning
Kubernetes events är en undervärderad källa till insyn. Varje gång något händer i klustret (pod startas, nod blir NotReady, resource quota uppnås) skapas en event-resurs. Events är temporära (rensa efter 1 timme) men ovärderliga för felsökning. Använd `kubectl get events --sort-by='.lastTimestamp'` för att se de senaste händelserna.
För att fånga events för övervakning: använd event-exporter eller Kubernetes event-manager för att skicka events till Prometheus, Loki eller en extern loggplattform. Kube-prometheus-stack inkluderar kube-events-exporter som exponerar K8s-events som Prometheus metrics – du kan skapa alerts på kritiska events (ImagePullBackOff, CrashLoopBackOff, NodeNotReady).
Integrera cluster-events med din incident-hanteringsplattform (PagerDuty, Opsgenie) för att snabbt upptäcka och åtgärda problem. Konfigurera automation: när en pod fastnar i CrashLoopBackOff, starta om deployment eller eskalera till teamet. K8s-event-driven automation (via Keptn eller Flux) blir allt vanligare 2026.
Sammanfattning: K8s monitoring best practices
- Installera Kube-prometheus-stack (Prometheus + Grafana + Alertmanager) som bas för all övervakning.
- Använd ServiceMonitor CRD för att definiera vilka tjänster som ska övervakas – det är K8s-nativt.
- Använd kube-state-metrics för objektstatus och metrics-server för resursanvändning.
- Lägg till anpassade applikationsmetrics (latens, fel, throughput) med Prometheus client-bibliotek.
- Använd Loki för loggaggregering (eller EFK för avancerad fulltextsökning).
- Konfigurera Alertmanager med gruppering, inhibition och routing till rätt kanaler.
- Använd Kubecost/OpenCost för kostnadsallokering och optimering.
- Övervaka K8s-events för snabb upptäckt av problem (CrashLoopBackOff, ImagePullBackOff).
- Använd SLO-baserad alerting – alerta när SLO-budgeten hotas, inte vid varje enskild avvikelse.
- Dokumentera dina dashboards och alert-regler så att hela teamet förstår övervakningsstacken.
Vill du ha hjälp med Kubernetes-övervakning?
Jag hjälper team att bygga och optimera övervakningsstackar för Kubernetes. Läs mer om moln- och infratjänster eller boka ett samtal.
“Kubernetes-övervakning kräver en helt annan approach än traditionell serverövervakning – pods kommer och går, men din övervakning måste följa med.”
- Simon Axelsson
Vanliga frågor
- Vad är skillnaden mellan Prometheus och metrics-server?
- Metrics-server samlar in grundläggande CPU/minne-data per pod och nod från Kubelet och exponerar dem via Metrics API (används av HPA och kubectl top). Prometheus scrapar valfri metrics-endpoint och lagrar data som tidsserier med rikare metadata och längre lagring – används för visualisering, alerting och trendanalys.
- Ska jag använda Loki eller Elasticsearch för K8s-loggar?
- Loki är bättre för kostnadseffektiv logghantering i stora kluster – det indexerar bara labels, inte logginnehåll, vilket ger lägre lagringskostnad och enklare drift. Elasticsearch/EFK är bättre om du behöver avancerad fulltextsökning, maskininlärning på loggar, eller har specifika compliance-krav som kräver indexering.
- Hur övervakar jag kostnader i Kubernetes?
- Installera Kubecost (Helm-chart) eller OpenCost (CNCF). De analyserar resursanvändning per pod och allokerar molnkostnader baserat på molnleverantörens prislista (AWS, Azure, GCP). Du får kostnad per namespace, deployment, pod och label – och rekommendationer för resursoptimering och spot instances.
- Vad är ServiceMonitor i Prometheus Operator?
- ServiceMonitor är en Custom Resource Definition (CRD) som definierar hur Prometheus ska scrapa metrics från en Kubernetes-tjänst. Du specificerar label-selector (matchLabels), port, intervall, och path. Prometheus Operator läser ServiceMonitor-resurser och konfigurerar Prometheus automatiskt.
- Hur sätter jag upp alerting i Prometheus?
- Definiera alert-regler i Prometheus-konfigurationen (eller som PrometheusRule CRD) med PromQL. Exempel: `up == 0` alertar när en tjänst är nere. Alertmanager tar emot alerts, grupperar dem (per namespace, severity), och skickar via konfigurerbara kanaler (Slack, PagerDuty, e-post). Använd group_by och group_wait för att minska alert-trötthet.
Om författaren
Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.
Fler artiklar av Simon