IT-övervakning som fungerar – vad ska ni mäta och när ska någon agera?

Publicerad 9 november 2026

Sammanfattning: IT-övervakning skapar inget värde bara genom att samla in fler mätvärden. Det viktiga är att upptäcka sådant som faktiskt påverkar verksamheten och se till att rätt person agerar i rätt tid. En fungerande övervakningsmodell behöver därför knyta ihop teknik, tröskelvärden, larm, incidenthantering och verksamhetens krav på tillgänglighet.

Det är relativt enkelt att övervaka mycket: CPU, minne, disk, ping, nätverkstrafik, svarstid, loggar, tjänster, certifikat och backupjobb.

Problemet är att mer data inte automatiskt ger bättre kontroll. En övervakningsplattform som skickar 500 larm varje vecka kan i praktiken ge sämre överblick än en miljö som skickar tio relevanta larm. För när allt är viktigt blir till slut inget viktigt.

Övervakning ska svara på en verksamhetsfråga

Det tekniska mätvärdet är sällan slutmålet. CPU på 95 procent är inte automatiskt ett problem. Det kan vara helt normalt för systemet. CPU på 70 procent kan däremot vara kritiskt om det normalt ligger på 10 procent och svarstiderna plötsligt har tredubblats.

Därför behöver organisationen förstå vad ett tekniskt mätvärde betyder för den tjänst som verksamheten använder. Det är först då övervakningen blir användbar.

Tre perspektiv på övervakning

Vi tycker det är praktiskt att skilja på åtminstone tre nivåer.

Infrastruktur

Fungerar de tekniska komponenterna? Det handlar om CPU, minne, disk, nätverksportar, switchar, brandväggar, virtuella maskiner och databaser.

Tjänst och användarupplevelse

Fungerar det användaren faktiskt behöver? Går webbplatsen att öppna? Svarar API:et? Fungerar inloggningen? Kan databasen göra en transaktion? Fungerar en kritisk integration?

En server kan tekniskt vara uppe. Men tjänsten kan ändå vara oanvändbar.

Säkerhet

Finns händelser som behöver analyseras ur ett säkerhetsperspektiv? Nationellt cybersäkerhetscenter (NCSC) har ”Säkerställ förmågan att upptäcka säkerhetshändelser” som åtgärd 1 bland sina tio rekommenderade säkerhetsåtgärder, där loggning och övervakning är centrala delar. Säkerhetsloggarna behöver dessutom skyddas mot obehörig åtkomst och ändring, eftersom de annars kan manipuleras av den som orsakat händelsen.

Samma tekniska miljö kan alltså behöva övervakas ur flera perspektiv.

Börja med de kritiska tjänsterna

Det är frestande att börja med tekniken. Vi har 30 servrar, låt oss lägga in alla 30 i övervakningen. Det är inte fel. Men en bättre fråga är först: vilka tjänster är verksamheten mest beroende av? Och därefter: vilka komponenter bygger tjänsten på?

En kritisk tjänst kanske kräver:

• internetanslutning
• brandvägg
• DNS
• identitetstjänst
• applikationsserver
• databas
• lagring
• extern API-leverantör

Om endast applikationsservern övervakas saknas en stor del av bilden.

Ett larm måste ha en mottagare

Ett vanligt problem i övervakningslösningar är att systemet meddelar att något är fel, men att ingen riktigt vet vem som ska agera, när eller hur.

En fungerande modell behöver därför definiera:

• Vad ska larma?
• Vilken allvarlighetsgrad har händelsen?
• Vem får larmet?
• När förväntas någon reagera?
• Vad händer om personen inte reagerar?

Ett övervakningsverktyg skiljer normalt på datainsamling, villkor som löser ut vid problemtillstånd och åtgärder som styr vad som ska hända, bland annat notifieringar. Notifieringar kan skickas via flera kanaler, exempelvis e-post, script eller webhook.

Tekniken kan alltså skicka larmet. Men organisationen behöver fortfarande bestämma vad larmet ska leda till.

Övervakning dygnet runt är inte samma sak som bemannad incidenthantering dygnet runt

Det här är en viktig distinktion. Ett system kan samla in data och generera larm dygnet runt. Det betyder inte automatiskt att en människa sitter och hanterar alla larm dygnet runt.

Organisationen behöver därför vara tydlig med:

• när övervakningen sker
• när larm genereras
• vem som tar emot dem
• vilka tider incidentrespons finns
• vilka larm som eventuellt ska eskaleras utanför ordinarie tid

Det är särskilt viktigt för kritiska tjänster. Annars kan både kund och leverantör tro att den andra parten har ett ansvar som aldrig faktiskt avtalats.

Larmtrötthet är ett riktigt problem

Om ett system skickar 150 diskvarningar, 40 CPU-larm, 30 meddelanden om otillgänglig tjänst som återställs efter 20 sekunder och ytterligare 80 informationsmeddelanden, börjar människor filtrera mentalt. Till slut missas det viktiga larmet.

Därför behöver tröskelvärden kalibreras. En CPU-topp på tre sekunder ska kanske inte larma. Hög CPU under 20 minuter kombinerat med ökad svarstid ska kanske göra det. Det handlar om att hitta relevanta avvikelser, inte maximal mängd notiser.

Korrelation kan minska bruset

Tänk att en switch slutar fungera. Det kan skapa larm för 20 accesspunkter, fyra servrar, 15 nätverksenheter och en mängd tjänster. Men den bakomliggande incidenten är egentligen att switchen är nere.

Moderna övervakningsverktyg har stöd för händelser, taggar och korrelation som kan användas för att strukturera problem och notifieringar. Bra övervakning försöker därför hjälpa människan att förstå vad grundproblemet är, inte bara hur många saker som är röda.

Övervaka även det som snart blir ett problem

Övervakning behöver inte bara handla om att något är trasigt. Den kan också upptäcka trender:

• diskutrymmet minskar med 10 GB per vecka
• certifikatet går ut om 21 dagar
• backupvolymen växer snabbare än lagringen
• CPU-användningen har ökat varje månad
• WAN-länken närmar sig kapacitetstaket

Det ger organisationen möjlighet att agera innan incidenten inträffar. Där finns ofta den största nyttan med proaktiv övervakning.

Övervaka backupen

Backup är ett bra exempel. Frågorna kan vara:

• Kördes jobbet?
• Hur lång tid tog det?
• Hur mycket data kopierades?
• Har volymen förändrats oväntat?
• Finns tillräcklig lagringskapacitet?
• Har ett jobb misslyckats flera dagar i rad?

Men som vi skrivit om i vår insikt om Microsoft 365-backup och återställning räcker det inte att jobbet är grönt. Återställningen behöver också testas.

Vad ska ledningen få se?

Ledningen behöver normalt inte en teknisk instrumentpanel med 300 mätvärden. Mer relevanta frågor är:

• Hur tillgängliga är våra kritiska tjänster?
• Vilka återkommande problem har vi?
• Var finns kapacitetsrisker?
• Hur snabbt upptäcks incidenter?
• Hur snabbt återställs tjänster?
• Vilka större avvikelser behöver beslut eller investering?

Det är den översättningen som gör övervakning till styrinformation.

Sju frågor för en bättre övervakningsmodell

1. Vilka tjänster är mest kritiska?
2. Vilka tekniska beroenden bygger de på?
3. Vilka mätvärden visar verklig påverkan?
4. När ska ett mätvärde bli ett larm?
5. Vem ansvarar för varje typ av larm?
6. När ska larm eskaleras till incident?
7. Hur används historiken för förbättring och kapacitetsplanering?

När de frågorna är besvarade blir verktygsvalet betydligt enklare.

Så kan Kristensson i Skåne stödja arbetet

Kristensson i Skåne hjälper organisationer att etablera och förvalta övervakning av servrar, nätverk, molnmiljöer, applikationer, databaser, webbplatser, API:er, backup samt tillgänglighet och prestanda. Vi arbetar bland annat med Zabbix och kan även integrera andra datakällor och molnplattformars övervakning.

Stödet kan omfatta:

• nulägesanalys
• implementation
• triggers och tröskelvärden
• instrumentpaneler
• larmflöden
• eskaleringsmodell
• rapportering
• kapacitetsuppföljning
• löpande förvaltning

Målet är inte att skapa flest grafer. Målet är att organisationen ska upptäcka rätt problem innan användarna behöver tala om att något är trasigt.

Vanliga frågor

Vill ni veta vad som faktiskt behöver övervakas hos er? Läs mer om våra övervakningstjänster för företag eller kontakta oss för ett förutsättningslöst samtal.

Källor: Nationellt cybersäkerhetscenter (NCSC), 10 rekommenderade säkerhetsåtgärder, åtgärd 1 – Säkerställ förmågan att upptäcka säkerhetshändelser; Zabbix dokumentation om items, triggers, actions och notifieringar. Verifierat 2026-09-09.

Den här texten är allmän information. Vilken övervakningsmodell som passar beror alltid på den enskilda miljön och verksamhetens krav.