Monitoring, Logging, Tracing: Hvordan Observability-projekter fejler, og hvordan man redder dem med klare SLO'er

Et Observability-projekt starter i mange virksomheder med et godt incitament: fejl opdages hurtigere, årsager afgrænses præcist, support aflastes, releases gøres mere sikre. I praksis glider initiativet dog ofte i den modsatte retning: for mange dashboards uden indhold, for mange alarmer uden prioritet, stigende lagrings- og licensomkostninger, og til sidst står spørgsmålet tilbage, om driften reelt bliver bedre.

Kernefejlen er sjældent et manglende værktøj. Ofte mangler en fagligt klar måldefinition: Hvad skal fungere pålideligt for hvilken service- eller proceskæde – og hvordan måler vi det? Netop her hjælper SLOs (Service Level Objectives, målbare målværdier for en service) som styrepunkter. SLOs forbinder teknisk telemetri (monitoring, logging, tracing) med driftsrealitet, ansvarsfordeling og beslutningsveje.

Denne artikel kategoriserer typiske failure-mønstre og viser, hvordan I kan få Observability tilbage på ret kurs med klare SLOs – med fokus på drift, administration, data, grænseflader, vedligehold, sikkerhed og rollout.

Monitoring, Logging, Tracing: Hvad er hvad – og hvorfor er “mere data” ikke nok?

Observability bruges ofte som en samlebetegnelse. For driften er det vigtigt at adskille de tre signaltyper klart:

• Monitoring/Metrikker: kondenserede tidsserier (f.eks. responstider, fejlprocenter, kølængder). Fordel: hurtigt, omkostningseffektivt, velegnet til alarmering. Risiko: uden kontekst svært at forklare.
• Logging: hændelser med kontekst (f.eks. ordre oprettet, validering mislykkedes, ekstern API svarer 503). Fordel: detaljeret og revisionssporbart. Risiko: datamængder, databeskyttelse, “log-suppe” uden struktur.
• Tracing: fordelte udførelsesspor over flere komponenter (Distributed Tracing). Fordel: viser, hvor tid tabes, og hvilken afhængighed der driller. Risiko: instrumentering, sampling-strategi, korrelation på tværs af systemer.

En hyppig fejlopfattelse: Hvis vi blot samler nok logs og traces, løser incidents sig nærmest af sig selv. I realiteten øges kompleksiteten først. Uden et mål- og relevanskriterium bliver Observability et datalager – ikke et styringsinstrument.

Hvorfor Observability-projekter fejler: De hyppigste mønstre fra driftsdagligdagen

Følgende mønstre optræder især i modne virksomhedslandskaber – altså dér hvor forretningssoftware, grænseflader og infrastruktur er vokset over år, og hvor flere teams er involveret.

1) Tool-first frem for service-first: Dashboards uden driftsbeslutning

Et nyt APM- eller logværktøj indføres, og der bygges dashboards „for en sikkerheds skyld“. Det, der mangler, er spørgsmålet: Hvilken driftsbeslutning skal dermed blive hurtigere eller bedre? Et dashboard, der ikke hjælper under et incident, er i hverdagen ofte kun dekoration. Typisk symptom: I en fejltilstand hopper teams mellem ti visninger uden at vide, hvilken af dem der er pålidelig.

2) Alarmflod og alarmtræthed: Alt er kritisk, så intet er kritisk

Når hver CPU-top, hver enkelt HTTP-fejl og hver advarsel fra en agent udløser en alarm, fører det ikke til øget sikkerhed, men til afstumpning. Alarmtræthed betyder: on-call reagerer senere, eskalationer bliver uklare, og reelle nedbrud drukner. For IT-ledelsen er det også en risiko i forhold til compliance og dokumenterbarhed: „Vi havde alarmer“ er ikke bevis for, at der blev reageret målrettet.

3) Keine Korrelation: Tickets ohne Trace-IDs, Logs ohne Kontext

Især for processnære softwareløsninger (ERP-nære workflows, integrationsstrømme, portaler) opstår incidents ofte ved grænseflader: REST-APIs, Message Broker, filimports, EDI, Identity-Provider. Uden en Korrelations-ID (en entydig identifikator, der løber gennem kæden) kan en enkelt transaktion ikke følges ende-til-ende. Resultat: meget tid bruges på „er det hos os eller hos partneren?“ i stedet for årsagsanalyse.

4) Kostenexplosion durch Log- und Trace-Volumen

Logging og tracing er dataintensive. Uden en Retention-Strategie (opbevaringsperiode), Sampling (målrettet stikprøve ved traces) og filterregler bliver Storage og Ingest hurtigt dyrt – on-prem som i skyen. Ofte skæres der så i panik, hvilket forringer datakvaliteten. Det skaber en ond cirkel: mindre tillid → mere „for en sikkerheds skyld“ logging → højere omkostninger.

5) Sicherheits- und Datenschutzthemen werden zu spät adressiert

Logs indeholder hurtigt personoplysninger (navne, e-mail, IP, kundenumre) eller følsomt indhold (Tokens, Session-IDs, interne URLs). Hvis juridisk- og security-perspektivet først kommer efter rollout, truer to dårlige muligheder: slukke det eller „fortsætte som før“ med risiko. Observability skal fra starten tage højde for Dataklassificering (beskyttelsesbehov), maskering/redaction og adgangskoncepter.

6) Unklare Ownership: Wer ist für welchen Service „on the hook“?

I mange virksomheder driver Team A infrastrukturen, Team B applikationen, Team C integrationen, Team D database-stacken. Observability viser problemer – men uden en klar servicesnitflade og driftsforpligtelser forbliver ansvaret diffust. Så ender det i chatdiskussioner i stedet for en ordentlig incident-proces med tydelig overlevering.

SLOs als Rettungsanker: Was ein gutes SLO leistet

SLOs er målbare mål for servicekvalitet. De udledes af SLIs (Service Level Indicators, den målte indikator). Vigtigt: SLOs er ikke primært marketing-„tilgængelighedstal“, men et styringsinstrument for drift og prioritering.

Et godt SLO besvarer for en konkret service (f.eks. „ordreindtastning i portalen“, „dokumentupload“, „natkørsel af faktura“, „API til lagerbogføringer“) tre spørgsmål:

• Hvad er „godt“ fra brugerens synspunkt? (f.eks. „svar < 1,5 s“ eller „succes uden fejl“)
• Hvordan måler vi det objektivt? (SLI, datakilde, måleperiode)
• Hvad sker der, hvis det ikke overholdes? (prioriteringer, ændringsstop, kapacitetsforanstaltninger)

Dermed bliver Observability fra en datapool til et system, der understøtter beslutninger: Hvad er virkelig kritisk lige nu? Hvor investerer vi som det næste? Hvilke risici accepterer vi bevidst?

Fra SLAs til SLOs og Error Budgets: Praktisk kontekst for beslutningstagere

I virksomheder findes der ofte SLAs (Service Level Agreements, kontraktmæssige eller interne forpligtelser). SLOs er tættere forankret i teknikken og driften og kan fungere som en intern styringsparameter, selv når et SLA er meget groft.

En central mekanisme er Error Budget: Hvis et SLO f.eks. kræver 99,9% succes over 30 dage, accepteres et lille ”budget” for fejl/ikke-tilgængelighed. Det lyder umiddelbart kontraintuitivt, men er operationelt værdifuldt: Det muliggør en saglig balance mellem stabilitet og forandring (releases, migrationer, performance-optimering).

Vigtigt i praksis: Error Budgets fungerer kun, hvis målingen er retfærdig, og organisationen er parat til at trække konsekvenser. Ellers bliver det bare endnu en måleparameter.

SLOs definieren, die Monitoring, Logging und Tracing wirklich steuern

Den hyppigste fejl ved SLOs er, at de er for generiske („99,9% tilgængelighed for appen“). Mere meningsfuldt er en SLO-struktur langs brugerhandlinger og integrationspunkter. En pragmatisk fremgangsmåde:

Trin 1: Skær servicegrænser langs processkæden

Definer „Services“ ikke efter organisationsdiagram, men efter effekt: fx „oprette ordre“, „behandle betaling“, „bogføre kommissionering“, „interface til fragtleverandør“. Især i skræddersyede virksomhedssystemlandskaber er disse grænser afgørende, fordi support og forretningsenheder tænker i disse enheder.

Trin 2: Per Service 1–3 SLIs, der afspejler brugerpåvirkning

Anbefalede SLIs omfatter:

• Succesrate for en transaktion (fx HTTP 2xx/3xx, eller „Business Success“ fra applikationslogik)
• Latens på den kritiske sti (p95/p99 i stedet for gennemsnit)
• Freshness i datapipelines („Hvor gamle er dataene i DWH/rapportering?“)

Pointen: Ikke alle systemmetrikker er et SLI. Høj CPU er et symptom, ikke et brugerresultat. Brug systemmetrikker til diagnosticering, ikke som mål.

Trin 3: Fastlæg målevinduer, undtagelser og afhængigheder tydeligt

Et SLO uden målevindue er værdiløst. Fastlæg: 28 dage rullende? Månedligt? Kun i business-tid? Og afklar, hvilke afhængigheder der medregnes: Hvis en ekstern partner-API går ned, tæller det i dit SLO? For drift og eskalation er denne klarhed guld værd.

Trin 4: Kobl Alerting til SLO-Burn-Rate

I stedet for „Alarm bei Fehler > X in 5 Minuten“ fungerer en burn-rate-tilgang i praksis ofte bedre: Hvor hurtigt forbruges Error Budget? Dermed prioriterer I alarmer efter risiko for at nå målet – ikke efter enkeltmetrikers lydstyrke. Resultat: færre alarmer, men mere relevante.

Arkitekturkonsekvenser: Hvad I teknisk skal planlægge for en robust Observability

SLOs er governance, men de har brug for et teknisk fundament. I etablerede landskaber er det sjældent ”bare at konfigurere”. Typiske arkitekturkomponenter:

Telemetry-Pipeline: Indsamling, transformering, lagring, tilgængeliggørelse

Uanset on-prem eller Cloud: I skal have en klar kæde for, hvordan telemetri kommer ind i systemet. Det omfatter agenter/Collector, transport (Queue/Buffer), behandling (Parsing, Enrichment, Redaction), lagring og adgang. Især ved Logging og Tracing er en Buffer vigtig for at absorbere belastningstoppe og ved fejl ikke at belaste produktionssystemerne.

Identitäten und Zugriffe: Wer darf welche Daten sehen?

Observability-data er ofte følsomme. Planlæg roller og tenant-koncepter: Drift ser infrastrukturmetrikker, Support ser korrelerede hændelser, fagområdet får kun aggregerede serviceviews. Suppler med audit-logs for adgang til logs/traces, hvis regulatoriske krav er relevante.

Datenhygiene im Logging: Struktur, Redaction, Retention

„Vi logger alt“ er ikke en plan. Fornuftigt er strukturerede logs (maskinlæsbare), definerede felter (fx Service, miljø, korrelations-ID, fejlklasse) og konsekvent maskering. Fastlæg retention efter formål: Kort til debugging (fx 7–14 dage), længere til security-events eller audit-krav – men adskilt, så omkostninger og adgangsrettigheder kan styres.

Tracing gezielt, nicht flächig: Sampling und kritische Pfade

Distributed Tracing er særligt værdifuldt ved integrationsstrækninger og performance-problemer. Et fladedækkende 100%-tracing er sjældent økonomisk muligt og ofte unødvendigt. Indfør sampling-regler (fx flere traces ved fejl eller ved usædvanlig latenstid) og fokusér den kritiske sti: Login/SSO, Upload, ordregemning, Schnittstellen-Call, Queue-Verarbeitung.

Konkrete Beispiele: SLOs für typische Unternehmenssoftware-Szenarien

For at SLOs ikke skal forblive teoretiske, tre eksempler, som ofte optræder i procesnære softwareløsninger. Tallene er bevidst pladsholdere – målværdier skal passe til brug, belastningsprofil og procesrisiko.

Beispiel A: Kundenportal „Auftrag anlegen“

• SLI Erfolgsrate: Andel af succesfuldt gennemførte ordreoprettelser (Business Success) i en 30-dages periode.
• SLI Latenz: p95 for end-to-end-tiden for ordreoprettelse (inkl. DB-Commit og bekræftelsesrespons).
• Diagnose-Signale: DB-Deadlocks/Timeouts, Queue-længder for efterfølgende behandling, fejlklasser i applikationsloggen (validering vs. infrastruktur).

Vigtigt: SLO’et bør måle brugerflowet, ikke kun „HTTP 200“. Ellers overser I tilfælde, hvor en forespørgsel var teknisk succesfuld, men forretningsmæssigt blevet afbrudt.

Eksempel B: Grænseflade til en transportør (REST/EDI)

• SLI: Andel af forsendelsesregistreringer, der er bekræftet som succesfulde inden for X minutter (inkl. genforsøg).
• Afhængigheder: Eksternt endpoint, netværkssti, certifikater, ratebegrænsninger.
• Diagnose: Fejlkoder efter kategori, andel genforsøg, Dead-Letter-Queue (arkiv for beskeder, som efter flere forsøg ikke kunne behandles).

Her viser SLO’ernes værdi for driften sig: I kan klart skelne, om et incident vedrører jeres egen behandling (f.eks. certifikat udløbet) eller primært partneren (f.eks. 5xx-fejl). Det reducerer war-room-tid og forbedrer kommunikationen med fagafdelingen og partnerne.

Eksempel C: Natkørsel „Faktura/Batch-behandling“

• SLI: Andel af batch-jobs, der er gennemført succesfuldt inden for den definerede cutoff-tid.
• SLI: Antal manuelle indgreb per kørsel (operationer, der udløser runbooks).
• Diagnose: Lock-/deadlock-mønstre i databasen, ressourceflaskehalse, IO-ventetider, afvigere i deljobs.

Specielt batch-processer er klassiske „blind spots“: brugerne opdager problemer først om morgenen. Et SLO med cutoff-tid skaber klare forventninger og muliggør målrettet alerting, som ikke eskalerer ved hver lille forsinkelse, men tidligt signalerer reelle risici.

Rollout og drift: Sådan forbliver SLO-modellen levende i hverdagen

Den sværeste del er ikke den første definition, men stabiliseringen. Observability fejler ofte på driftsprocesser, ikke på teknikken.

Roller og ansvarsområder (uden Overhead)

I behøver ikke en stor SRE-organisation, men klare ansvarsområder:

• Service Owner: fagligt/teknisk ansvarlig for målværdier og prioritering.
• Drift/Platform: driver telemetri-pipeline, adgang, opbevaring, omkostningskontrol.
• On-Call/Support: bruger alerts, runbooks og eskalationsveje; leverer feedback om alarmkvalitet.

Det er vigtigt med en fast rytme (månedligt eller hver anden uge): SLO-review, top-alerts, omkostninger/volumen, åbne ukendte.

Sammenkæd runbooks og incident-processen med Observability

Et alarm uden handlingsvej er støj. Kobl hver kritisk alert-regel til et runbook (kort handlingsvejledning): Hvad skal tjekkes? Hvilke dashboards/views er relevante? Hvordan eskaleres? Hvilke øjeblikkelige foranstaltninger er tilladt (f.eks. slå en funktion fra, begrænse køen, read-only-tilstand)?

For IT-ledelsen er det også et skaleringselement: Gode runbooks reducerer afhængigheden af enkeltpersoner og sænker den gennemsnitlige løsningstid (MTTR) uden ‚helteindsats‘.

Release- og Change-Management: SLO’er som stopskilt, ikke som pynt

Hvis error budget er knapt, bør risikable ændringer udsættes eller rulles ud med ekstra beskyttelsesforanstaltninger (f.eks. canary, feature flags, snævert overvågningsvindue). Det er ikke et mål i sig selv: Det forhindrer, at stabilitet først bliver vigtig efter en hændelse.

Indholdsmæssigt kan man her bygge videre på eksisterende release-management-standarder og knytte interne links til indlæg om rollout, accept og fallback-planlægning.

Tjekliste: Advarselssignaler på, at jeres Observability-projekt er ude af kurs

• Alarmer bliver regelmæssigt slået fra eller ignoreret.
• Der findes mange Dashboards, men ingen ved, hvilket der er afgørende ved et Incident.
• Log-Volumen vokser hurtigere end nytten; Retention forkortes „efter fornemmelse“.
• Security/Datenschutz diskuteres først efter rollout om indholdet i logs.
• Incidents ender ofte med „kunne ikke reproduceres“ eller „uklart, hvem der er ansvarlig“.
• Tracing findes, men uden en gennemgående Korrelations-ID på tværs af Schnittstellen.

Hvis flere punkter gør sig gældende, er et reset via SLOs næsten altid relevant: prioritere få services, definere klare SLIs, målrette telemetri og radikalt forenkle alarmhåndteringen.

Konklusion: SLOs gør Observability igen styrbar – og driftsmæssigt ærlig

Monitoring, Logging og Tracing er uundværlige, men de løser ikke alene et driftsproblem. Et Observability-projekt fejler typisk ikke på grund af manglende data, men på grund af manglende målklarhed, dårlig alarmkvalitet, uhåndterede datamængder og uklar ansvarsfordeling. SLOs bringer initiativet tilbage til det, der tæller i virksomhedens hverdag: pålidelige services langs proceskæden, klare prioriteter i et incident og gennemsigtige beslutninger mellem stabilitet, omkostninger og forandring.

Hvis du vil genrette Observability i dit IT-landskab eller pragmatisk stabilisere et fastlåst setup, er et struktureret blik på servicegrænser, SLIs, telemetri-pipeline og driftsprocesser en god investering. For en første indplacering og en ordentlig Projektstart — Arkitektur & samarbejde kan du kontakte os via .

Drøft projekt eller moderniseringsforløb med Net-Base.