Hur datainsamlingen fungerar i praktiken

Det finns två huvudsakliga metoder, och de flesta mogna miljöer använder båda parallellt.

Agentbaserad övervakning

En lättviktsagent installeras på varje nod — server, VM eller container-host. Agenten rapporterar CPU, minne, disk, nätverksinterface och processlistor till en central plattform. Fördelen är djup och tillförlitlighet: agenten fortsätter buffra data lokalt även om nätverket tillfälligt går ner, och den kan samla mätvärden som inte exponeras via fjärrprotokoll.

Nackdelen är underhåll. Varje agent behöver uppdateras, konfigureras och licensieras. I en Kubernetes-miljö med hundratals pods löser man det med DaemonSets, men i en heterogen on-prem-miljö med Windows Server 2016 och RHEL 8 sida vid sida kräver det en genomtänkt utrullningsstrategi — helst via IaC-verktyg som Ansible eller Puppet.

Agentlös övervakning

Här frågar övervakningsplattformen systemen utifrån via protokoll som SNMP (nätverksutrustning), WMI/WinRM (Windows), SSH (Linux) eller molnleverantörernas API:er (CloudWatch, Azure Monitor, Google Cloud Monitoring). Fördelen är att du slipper installera något på målsystemen — perfekt för nätverksswitchar, brandväggar och miljöer med strikta ändrings­hanteringsprocesser.

Nackdelen är att du är beroende av nätverks­anslutning och att insiktsdjupet ofta är begränsat till det leverantörens API exponerar.

Vår rekommendation

I de flesta kundmiljöer vi driftar hos Opsio kör vi agentbaserad övervakning på beräkningsnoder och agentlös polling mot nätverksinfrastruktur och molnleverantörs-API:er. Managerade molntjänster

Vad ska övervakas — och vad kan du hoppa över?

Många organisationer börjar med att övervaka allt, vilket snabbt resulterar i tiotusentals mätvärden som ingen tittar på. En bättre approach är att utgå från Googles fyra gyllene signaler — ett ramverk från SRE-boken som fungerar lika bra på infrastrukturnivå:

1. Latens — svarstiden för förfrågningar. På infrastrukturnivå: disklatens, nätverkslatens mellan zoner, DNS-resolution.

2. Trafik — belastningen på systemet. Nätverksgenomströmning, antal aktiva anslutningar, requests per sekund mot lastbalanseraren.

3. Felfrekvens — andelen misslyckade förfrågningar. TCP-retransmissions, diskfel, OOM-kills.

4. Mättnad — hur nära resursen är att nå sitt tak. CPU-steal-time i virtualiserade miljöer, minnesutnyttjande, disk-IOPS mot provisionerad kapacitet.

Specifika komponenter att prioritera

Servrar och beräkning: CPU-användning (men framför allt steal time i molnet), minnesanvändning inklusive swap, disk-I/O och filesystem-fyllnad. En disk som når 100 % utan förvarning är en av de vanligaste orsakerna till oplanerade driftstopp vi hanterar i vårt NOC.

Nätverk: Paketförlust, jitter, bandbredds­utnyttjande per interface, BGP-sessioner (om du kör egen peering) och VPN-tunnelstatus. I multi-cloud-miljöer är nätverket ofta den svagaste länken.

Databaser: Anslutningspooler, query-latens, replikeringsfördröjning, table locks. Databasövervakning sitter i gränslandet mellan infrastruktur och applikation, men replikerings-lag är definitivt ett infrastrukturproblem.

Containrar och Kubernetes: Nod-resurser, pod-restarts, pending pods (indikerar resursbrist), etcd-hälsa. Kubernetes egen metrics-server ger grundläggande data, men för produktion behöver du Prometheus eller en managerad lösning som Datadog eller Grafana Cloud.

Molnresurser: CloudWatch-mätvärden för AWS (övervaka särskilt BurstBalance på EBS-volymer i eu-north-1), Azure Monitor för Sweden Central, samt kostnadsanomalier — en plötslig kostnadsökning kan indikera en runaway-process eller säkerhetsincident. Cloud FinOps

Larmhantering utan brus: tre nivåer som fungerar

Alarmeringströtthet — alert fatigue — är det snabbaste sättet att underminera en övervakningsinvestering. När operatörer får hundratals larm per dygn slutar de läsa dem, och den kritiska varningen drunknar i bruset.

Hos Opsio använder vi en trestegsmodell:

Nivå 1 — Info: Loggas, syns i dashboarden, men genererar ingen notifiering. Exempel: CPU-användning över 70 % under 5 minuter. Användbart för trendanalys men kräver ingen akut åtgärd.

Nivå 2 — Varning: Notifiering till Slack/Teams-kanal. Kräver uppmärksamhet inom definierad tidsram (typiskt 30–60 minuter). Exempel: disk-fyllnad över 85 %, replikeringsfördröjning över 10 sekunder.

Nivå 3 — Kritiskt: Omedelbar notifiering via PagerDuty/OpsGenie, telefon till jourhavande. Kräver respons inom SLA (typiskt 15 minuter). Exempel: nod oåtkomlig, databas ej svarar, säkerhetsrelaterad anomali.

Nyckeln: granska larmkonfigurationen kvartalsvis. Ta bort larm som aldrig ledde till åtgärd, och sänk tröskeln på larm som slog till för sent. Det här arbetet kräver disciplin men har direkt effekt på MTTR.

Observability: bortom traditionell monitoring

Infrastrukturövervakning har de senaste åren vuxit in i det bredare konceptet observability — förmågan att förstå ett systems interna tillstånd utifrån dess externa output. Där traditionell monitoring ställer frågor du definierat i förväg ("Är CPU-användningen under 90 %?") låter observability dig ställa frågor du inte förutsåg ("Varför är latensen hög bara för kunder i region X under kontorstid?").

De tre pelarna:

• Mätvärden (metrics): Numeriska tidsserie-datapunkter. Prometheus-formatet har blivit de facto-standard.
• Loggar: Eventdata med kontext. Strukturerade loggar (JSON) gör analys dramatiskt enklare än fritext.
• Traces: Distribuerade spår som visar en förfrågans resa genom mikrotjänster. OpenTelemetry är bransch­standarden 2026.

Enligt CNCF:s årliga undersökning har adoption av OpenTelemetry ökat stadigt, och verktyg som Grafana, Jaeger och Tempo har blivit standard i molnbaserade driftsmiljöer. Datadog State of Cloud visar konsekvent att organisationer med sammankopplade mätvärden, loggar och traces löser incidenter snabbare.

Managerad DevOps

Verktyg i praktiken: vad vi ser hos kunder

Det finns inget universalverktyg. Valet beror på miljöns storlek, teamets kompetens och budget. Här är en ärlig jämförelse baserad på vad vi driftar åt kunder:

I Opsios managerade miljöer utgår vi ofta från Prometheus + Grafana för Kubernetes-arbetsbelastningar och kompletterar med molnleverantörens nativa verktyg för resurser som inte exponerar Prometheus-mätvärden (t.ex. RDS, Azure SQL).

Säkerhet och regelefterlevnad i övervakningsdata

Övervakningsdata innehåller ofta känslig information — servernamn, IP-adresser, ibland till och med snippets från loggmeddelanden med persondata. Enligt GDPR (artikel 5 och 6) måste du ha rättslig grund för att behandla denna data, och enligt NIS2-direktivet — som nu gäller för en bredare krets av organisationer — behöver du dessutom kunna visa att din övervakning är tillräcklig för att upptäcka och rapportera säkerhetsincidenter.

Några praktiska åtgärder:

• Dataklassificering: Definiera vilka mätvärden och loggar som innehåller personuppgifter, och applicera retention policies därefter.
• Kryptering: TLS i transit (självklart), men också kryptering at rest för logglagring — särskilt om du använder molnbaserade verktyg.
• Åtkomstkontroll: RBAC i övervakningsplattformen. Alla ska inte se alla dashboards.
• Datalokalitet: Om du använder en SaaS-baserad övervaknings­plattform, verifiera att data lagras inom EU. Opsio kör övervakningsdata i eu-north-1 (Stockholm) respektive Sweden Central.

Molnsäkerhet

Så kommer du igång — en pragmatisk startsträcka

Att bygga en komplett övervakningslösning tar månader. Att få värde från övervakning kan ta dagar — om du prioriterar rätt.

1. Vecka 1: Installera agenter eller konfigurera agentlös polling mot dina tio mest affärskritiska system. Definiera basvärden (baselines) genom att samla data utan larm i 5–7 dagar.

2. Vecka 2–3: Sätt tröskelvärden baserade på faktiska baselines, inte gissningar. Konfigurera larm i tre nivåer. Integrera larm med teamets kommunikationsplattform.

3. Vecka 4: Bygg dashboards för tre målgrupper: driftteamet (tekniskt djup), teamledare (service-hälsa) och ledning (tillgänglighets-SLA:er).

4. Månad 2–3: Utöka till alla produktionssystem. Koppla ihop mätvärden med loggar. Inför runbooks — dokumenterade steg-för-steg-procedurer kopplat till specifika larm.

5. Kvartalsvis: Granska larmkonfiguration, ta bort brus, justera tröskelvärden.

Om du inte har kapacitet internt — och det har väldigt få organisationer under 500 anställda — är det här ett område där en managerad tjänsteleverantör (MSP) med 24/7-bemanning ger omedelbart värde. Opsios SOC/NOC hanterar monitoring-setup, larmoptimering och första-linjens incidentrespons som en integrerad tjänst. Molnmigrering

Vanliga frågor

Vad är skillnaden mellan infrastrukturövervakning och applikationsövervakning?

Infrastrukturövervakning fokuserar på underliggande resurser — servrar, nätverk, lagring och virtualisering. Applikationsövervakning mäter prestanda och felfrekvens i själva mjukvaran. I praktiken behöver du båda: utan frisk infrastruktur spelar det ingen roll hur välskriven applikationen är.

Vilka mätvärden bör jag prioritera i min övervakning?

Börja med de fyra gyllene signalerna: latens, trafik, felfrekvens och mättnad. Lägg sedan till diskens I/O-prestanda, minnesanvändning och nätverkspaketförlust. Definiera basvärden för din specifika miljö innan du sätter tröskelvärden — annars får du antingen för många eller för få larm.

Behöver jag agentbaserad eller agentlös övervakning?

Det beror på miljön. Agentbaserad övervakning ger djupare insikt och fungerar även vid nätverksavbrott, men kräver installation och underhåll på varje nod. Agentlös övervakning via SNMP eller API:er passar bättre för stora, homogena miljöer. De flesta produktionsmiljöer tjänar på en hybrid-approach.

Hur undviker jag alarmeringströtthet (alert fatigue)?

Inför en tydlig larmhierarki: info, varning och kritiskt. Koppla eskalering till allvarlighetsgrad. Stäng av larm som aldrig leder till åtgärd, och granska larmkonfigurationen minst kvartalsvis. I Opsios NOC filtrerar vi bort brus med korrelationsregler så att operatörerna fokuserar på verkliga incidenter.

Vad kostar det att outsourca infrastrukturövervakning till en MSP?

Kostnaden varierar beroende på antal noder, komplexitet och SLA-krav. Typiskt ligger en managerad övervakningstjänst betydligt lägre än att bemanna en intern 24/7-jour med minst fem heltidsekvivalenter. Kontakta Opsio för en dimensionering baserad på din miljö.