Monitoring, Logging, Tracing: Hvordan observability-prosjekter feiler og hvordan man redder dem med klare SLOs

Et Observability-prosjekt starter i mange virksomheter med en god impuls: oppdage feil raskere, avgrense årsaker presist, avlaste support, gjøre releaser tryggere. I praksis tipper initiativet imidlertid ofte i motsatt retning: for mange dashboards uten innhold, for mange alarmer uten prioritering, økende lagrings- og lisenskostnader, og til slutt gjenstår spørsmålet om driften faktisk blir bedre.

Kjernefeilen er sjelden et manglende verktøy. Som regel mangler en faglig klar måldefinisjon: Hva skal fungere pålitelig for hvilken tjeneste- eller prosesskjede – og hvordan måler vi det? Nettopp her hjelper SLOs (Service Level Objectives, målbare måltall for en tjeneste) som styringsrammer. SLOs knytter teknisk telemetri (monitoring, logging, tracing) til driftsrealitet, ansvar og beslutningsveier.

Denne artikkelen plasserer typiske feilmønstre og viser hvordan du kan få Observability tilbake på sporet – med klare SLOs og med fokus på drift, administrasjon, data, grensesnitt, vedlikehold, sikkerhet og utrulling.

Monitoring, logging, tracing: Hva er hva — og hvorfor er «mer data» ikke nok?

Observability blir ofte brukt som samlebetegnelse. For drift er det viktig å skille tydelig mellom de tre signaltypene:

• Monitoring/metrikk: aggregerte tidsserier (f.eks. responstider, feilrater, kølengder). Fordel: raskt, rimelig, godt egnet for alarmering. Risiko: uten kontekst vanskelig å forklare.
• Logging: hendelser med kontekst (f.eks. oppdrag opprettet, validering mislyktes, ekstern API svarer 503). Fordel: detaljert og revisjonssporbart. Risiko: datamengder, personvern, «loggsuppe» uten struktur.
• Tracing: distribuerte spor over flere komponenter (Distributed Tracing). Fordel: viser hvor tid tapes og hvilken avhengighet som svikter. Risiko: instrumentering, sampling-strategi, korrelasjon på tvers av systemer.

En vanlig misoppfatning: Hvis vi bare samler nok logger og traces, løser hendelsene seg nærmest av seg selv. I realiteten øker kompleksiteten først. Uten et målbildet og kriterier for relevans blir Observability en datainnsamlingsplass – ikke et styringsinstrument.

Hvorfor Observability-prosjekter mislykkes: De vanligste mønstrene fra driftsvirkeligheten

Følgende mønstre forekommer særlig ofte i modne bedriftslandskaper – altså der hvor forretningsprogramvare, grensesnitt og infrastruktur har vokst over år, og flere team er involvert.

1) Tool-first i stedet for Service-first: Dashboards uten driftsbeslutning

Et nytt APM- eller loggverktøy blir innført, og så bygges det «for alle tilfeller» dashboards. Det som mangler, er spørsmålet: Hvilken driftsbeslutning skal bli raskere eller bedre av dette? Et dashboard som ikke hjelper under en hendelse, er i hverdagen ofte bare dekorasjon. Typisk symptom: Ved en feil hopper team mellom ti visninger uten å vite hvilken av dem som er pålitelig.

2) Alarmflom og Alert Fatigue: Alt er kritisk, altså er ingenting kritisk

Når hver CPU-topp, hver enkelt HTTP-feil og hver advarsel fra en agent ender som et alarmtilfelle, er resultatet ikke økt sikkerhet, men avflatning. Alert Fatigue betyr: On-Call reagerer senere, eskalasjoner blir uklare, og reelle driftsavbrudd drukner. For IT-ledelsen er det også en risiko med hensyn til compliance og etterprøvbarhet: «Vi hadde alarmer» er ikke bevis for at man reagerte målrettet.

3) Ingen korrelasjon: Tickets uten Trace-IDer, logger uten kontekst

Spesielt for prosesstilnærmede programvareløsninger (ERP-nære arbeidsflyter, integrasjonsflyter, portaler) oppstår hendelser ofte i grensesnittene: REST-APIs, message broker, filimporter, EDI, identitetsleverandører. Uten Korrelasjons-ID (en entydig identifikator som følger med gjennom kjeden) lar ikke en enkelt transaksjon seg spore ende-til-ende. Resultat: mye tid brukes på «Er dette hos oss eller hos partneren?» i stedet for rotårsaksanalyse.

4) Kostnadseksplosjon på grunn av logg- og Trace-Volumen

Logging og tracing er dataintensive. Uten retention-strategi (lagringstid), sampling (målrettet utvalg for traces) og filterregler blir storage og ingest fort kostbart – on-prem så vel som i skyen. Ofte kuttes det da i panikk, noe som forringer datakvaliteten. Det skaper en ond sirkel: mindre tillit → mer «for sikkerhets skyld» logging → høyere kostnader.

5) Sikkerhets- og personvernspørsmål blir adressert for sent

Logger inneholder raskt personopplysninger (navn, e-post, IP, kundenummer) eller sensitive data (tokens, session-IDs, interne URLer). Hvis juridisk- og sikkerhetsperspektivet først kommer etter utrulling, truer to dårlige valg: skru av eller «fortsette som før» med risiko. Observability må fra starten ta hensyn til dataklassifisering (beskyttelsesbehov), maskering/redaction og tilgangskonsepter.

6) Uklar eierskap: Hvem er for hvilken tjeneste «on the hook»?

I mange virksomheter drifter Team A infrastrukturen, Team B applikasjonen, Team C integrasjonen, Team D databasen/stacken. Observability viser problemer – men uten et klart tjenestesnitt og driftsforpliktelser forblir ansvaret diffust. Da ender det i chat-diskusjoner i stedet for en ryddig incident-prosess med tydelig overlevering.

SLOs som redningsanker: Hva et godt SLO leverer

SLOs er målbare målverdier for tjenestekvalitet. De avledes fra SLIs (Service Level Indicators, den målte indikatorverdien). Viktig: SLOs er ikke først og fremst markedsførings‑«tilgjengelighetstall», men et styringsverktøy for drift og prioritering.

Et godt SLO besvarer for en konkret tjeneste (f.eks. «ordreregistrering i portalen», «dokumentopplasting», «fakturakjøring om natten», «API for lagerbokføringer») tre spørsmål:

• Hva er «godt» fra brukerens perspektiv? (f.eks. «Respons < 1,5 s» eller «suksess uten feil»)
• Hvordan måler vi det objektivt? (SLI, datakilde, målevindu)
• Hva skjer hvis det ikke overholdes? (prioriteringer, Change-Stop, kapasitets‑tiltak)

Slik blir observabilitet fra en datainnsjø til et system som støtter beslutninger: Hva er virkelig kritisk akkurat nå? Hvor investerer vi neste gang? Hvilke risikoer aksepterer vi bevisst?

Fra SLAs til SLOs og Error Budgets: Praktisk vurdering for beslutningstakere

I virksomheter finnes det ofte SLAs (Service Level Agreements, kontraktsfestede eller interne forpliktelser). SLOs er tettere forankret i teknikk og drift og kan fungere som en intern styringsparameter, selv om et SLA er veldig grovt.

En sentral mekanisme er det Error Budget: Hvis et SLO for eksempel krever 99,9 % suksess over 30 dager, er et lite «budsjett» for feil/ikke-tilgjengelighet akseptert. Det høres ved første øyekast kontraintuitivt ut, men er operativt verdifullt: Det gjør det mulig å etablere en saklig balanse mellom stabilitet og endring (releases, migrasjoner, ytelsesoptimalisering).

Viktig for praksis: Error Budgets fungerer bare hvis målingen er rettferdig og organisasjonen er villig til å trekke konsekvenser. Ellers blir det bare enda et nøkkeltall.

Definere SLOs som virkelig styrer overvåking, logging og tracing

Den vanligste feilen med SLOs er at de er for generiske («99,9 % tilgjengelighet for appen»). Mer fornuftig er en SLO-struktur langs brukerhandlinger og integrasjonspunkter. En pragmatisk fremgangsmåte:

Trinn 1: Avgrens tjenester langs prosesskjeden

Definer «tjenester» ikke etter organisasjonskartet, men etter effekt: for eksempel «Opprette ordre», «Behandle betaling», «Registrere plukking», «Grensesnitt mot fraktselskap». Spesielt i individuelle landskap for bedriftsprogramvare er disse grensene avgjørende, fordi support og fagavdeling tenker i slike enheter.

Trinn 2: Per tjeneste 1–3 SLIs som avbilder brukeropplevelsen

Gode SLIs er for eksempel:

• Suksessrate for en transaksjon (f.eks. HTTP 2xx/3xx, eller «Business Success» fra applikasjonslogikk)
• Latens på kritisk sti (p95/p99 i stedet for gjennomsnitt)
• Ferskhet i datarørledninger («Hvor gamle er dataene i DWH/rapportering?»)

Poenget: Ikke hver systemmetrik er et SLI. Høy CPU er et symptom, men ikke et brukerresultat. Bruk systemmetrikker som diagnose, ikke som mål.

Trinn 3: Fastsett målevindu, unntak og avhengigheter tydelig

Et SLO uten målevindu er verdiløst. Fastslå: 28 dager rullerende? Månedlig? Kun i forretningstid? Og avklar hvilke avhengigheter som inkluderes: Hvis en ekstern partner-API feiler, teller det i ditt SLO? For drift og eskalering er denne klarheten gull verdt.

Trinn 4: Koble varsling til SLO-burn-rate

I stedet for «Alarm ved feil > X i løpet av 5 minutter» fungerer ofte en burn-rate-tilnærming bedre i praksis: Hvor raskt forbrukes Error Budget? På den måten prioriterer du varsler etter risiko for måloppnåelse – ikke etter volumet av enkeltmetrikker. Resultat: færre varsler, men mer relevante.

Arkitekturkonsekvenser: Hva du må planlegge teknisk for robust observabilitet

SLOs er styring, men de trenger et teknisk grunnlag. I etablerte landskap er det sjelden «bare konfigurere». Typiske arkitekturbyggesteiner:

Telemetri-pipeline: Innsamling, transformasjon, lagring, tilgjengeliggjøring

Enten on-prem eller sky: Dere trenger en klar kjede for hvordan telemetri kommer inn i systemet. Dette inkluderer agenter/Collector, transport (Queue/Buffer), behandling (Parsing, Enrichment, Redaction), lagring og tilgang. Spesielt for logging og tracing er en buffer viktig for å avdempe belastningstopper og for å unngå å belaste produksjonssystemene ved forstyrrelser.

Identiteter og tilgang: Hvem har rett til å se hvilke data?

Observability-data er ofte sensitive. Planlegg roller og leietakerkonsepter: Drift ser infrastrukturmetrikker, support ser korrelerte hendelser, forretningsområdet får kun aggregerte tjenestesyn. Suppler med audit-logger for tilgang til logs/traces dersom regulatoriske krav er relevante.

Datahygiene i logging: Struktur, maskering, retensjon

«Vi logger alt» er ikke en plan. Fornuftig er strukturerte logger (maskinlesbare), definerte felt (f.eks. service, miljø, korrelasjons-ID, feilkategori) og konsekvent maskering. Fastsett retensjon etter formål: Kort for debugging (f.eks. 7–14 dager), lengre for sikkerhetshendelser eller revisjonskrav – men atskilt, slik at kostnader og tilgangsrettigheter forblir styrbare.

Tracing målrettet, ikke flate-dekkende: Sampling og kritiske stier

Distributed Tracing er spesielt verdifullt ved integrasjonsstrømmer og ytelsesproblemer. Heldekkende 100 % tracing er sjelden økonomisk mulig og ofte ikke nødvendig. Sett opp sampling-regler (f.eks. flere traces ved feil eller ved unormal latenstid) og fokuser på den kritiske stien: Login/SSO, upload, lagre ordre, grensesnittkall, købehandling.

Konkrete eksempler: SLOs for typiske bedriftsprogramvare-scenarier

For at SLOs ikke skal forbli teoretiske, her er tre eksempler som ofte forekommer i prosessnære programvareløsninger. Tallene er bevisst ment som plassholdere – målverdier må tilpasses bruk, belastningsprofil og prosessrisiko.

Eksempel A: Kundenportal «Opprette ordre»

• SLI suksessrate: Andel vellykkede ordreopprettelser (forretningssuksess) per 30 dager.
• SLI latenstid: p95 for end-to-end-tid for ordreopprettelse (inkl. DB-commit og bekreftelsesrespons).
• Diagnosesignaler: DB-deadlocks/timeouts, kølengder for etterfølgende behandling, feilklasser i applikasjonsloggen (validering vs. infrastruktur).

Viktig: SLO bør måle brukerflyten, ikke bare „HTTP 200“. Ellers overser du tilfeller der en forespørsel var teknisk vellykket, men ble faglig avbrutt.

Eksempel B: Grensesnitt mot en fraktleverandør (REST/EDI)

• SLI: Andel av forsendelsesregistreringer som innen X minutter er bekreftet som vellykkede (inkl. omforsøk).
• Avhengigheter: Eksternt endepunkt, nettverksti, sertifikater, ratebegrensninger.
• Diagnose: Feilkoder etter kategori, omforsøksrate, Dead-Letter-Queue (arkiv for meldinger som etter flere forsøk ikke kunne behandles).

Her viser fordelene med SLO-er for drift: De lar deg tydelig skille om en hendelse gjelder egen behandling (f.eks. utløpt sertifikat) eller primært partneren (f.eks. 5xx-feil). Det reduserer War-Room-tid og forbedrer kommunikasjonen med fagavdelingen og partnere.

Eksempel C: Nattkjøring „Faktura/Batch-behandling“

• SLI: Andel av batch-jobber som fullføres vellykket innen definert cutoff-tid.
• SLI: Antall manuelle inngrep per kjøring (operasjoner som utløser Runbooks).
• Diagnose: Lås-/deadlock-mønstre i databasen, ressursflaskehalser, IO-ventetider, avvik i deljobber.

Spesielt batch-prosesser er klassiske „blind spots“: brukerne oppdager problemer først om morgenen. Et SLO med cutoff-tid setter klare forventninger og muliggjør målrettet alerting som ikke eskalerer ved hver lille forsinkelse, men som tidlig signaliserer reelle risikoer.

Utrulling og drift: Slik holder SLO-modellen seg levende i hverdagen

Den vanskeligste delen er ikke den første definisjonen, men forankringen. Observability feiler ofte på grunn av driftsprosesser, ikke teknikken.

Roller og ansvar (uten overhead)

Du trenger ikke en stor SRE-organisasjon, men klare ansvarsområder:

• Service Owner: faglig/teknisk ansvarlig for målverdier og prioritering.
• Ops/Plattform: drifter telemetri-pipeline, tilgang, retensjon, kostnadskontroll.
• On-Call/Support: bruker alerts, Runbooks, eskaleringsveier; gir tilbakemelding om alarmkvalitet.

Viktig er en fast rytme (månedlig eller annenhver uke): SLO-review, topp-alerts, kostnader/volum, åpne „unknowns“.

Knytt Runbooks og incident-prosessen til observability

En alarm uten handlingsvei er støy. Knytt hver kritisk alert-regel til et Runbook (kort handlingsinstruks): Hva skal sjekkes? Hvilke dashboards/views er relevante? Hvordan eskaleres det? Hvilke umiddelbare tiltak er tillatt (f.eks. deaktivere funksjon, begrense køen, skrivebeskyttet modus)?

For IT-ledelsen er dette også en skaleringshendel: Gode Runbooks reduserer avhengigheten av enkeltpersoner og senker gjennomsnittlig løsningstid (MTTR) uten „heltedyrking“.

Release- og Change-Management: SLO-er som stoppskilt, ikke som dekor

Når error budget er knapp, bør risikable endringer utsettes eller rulles ut med ekstra sikkerhetstiltak (f.eks. canary, feature flags, kort og tett overvåkingsvindu). Dette er ikke et mål i seg selv: det forhindrer at stabilitet først blir viktig etter en driftsstans.

Innholdsmessig kan man her bygge videre på eksisterende release-management-standarder og knytte interne lenker til innlegg om utrulling, godkjenning og tilbakeringings-/tilbakerullingsplanlegging.

Sjekkliste: Varselsignaler på at Observability-prosjektet ditt sporer av

• Alarmer blir regelmessig dempet eller ignorert.
• Dashboards finnes i stort antall, men ingen vet hvilket som er avgjørende i en incident.
• Loggvolumet vokser raskere enn nytten; lagringstiden kortes ned «etter magefølelsen».
• Sikkerhet/personvern diskuteres først etter utrulling når det gjelder innhold i logger.
• Incidents ender ofte med «kunne ikke reproduseres» eller «uklart hvem som er ansvarlig».
• Tracing finnes, men uten en gjennomgående korrelasjons-ID på tvers av grensesnitt.

Hvis flere punkter gjelder, lønner det seg nesten alltid med en reset ved hjelp av SLOs: prioritere få tjenester, definere klare SLIs, målrette telemetri og forenkle alarmeringen radikalt.

Konklusjon: SLOs gjør Observability styrbart igjen – og driftsmessig ærlig

Monitoring, Logging og Tracing er uunnværlige, men de løser ikke et driftsproblem alene. Et Observability-prosjekt mislykkes typisk ikke på grunn av manglende data, men på grunn av manglende målklarhet, dårlig alarmkvalitet, ukontrollerte datamengder og uklart eierskap. SLOs flytter initiativet tilbake til det som teller i virksomhetens hverdag: pålitelige tjenester langs prosesskjeden, klare prioriteringer i en incident, og etterprøvbare beslutninger mellom stabilitet, kostnader og endring.

Hvis du vil justere Observability i ditt landskap eller pragmatisk stabilisere et fastlåst oppsett, lønner det seg med et strukturert blikk på tjenestegrenser, SLIs, telemetri-pipeline og driftsprosesser. For en første avgrensning og en ryddig Prosjektstart — Arkitektur & samarbeid når du oss via .

Drøfte prosjekt eller moderniseringsprosjekt med Net-Base.