Monitoreringsdata som bevis: overvågning, APM og opbevaring

Forside · Gennemgået oktober 2026 · Af John Nielsen

Data fra overvågningssystemer og APM (application performance monitoring) er ofte den mest detaljerede kilde til, hvad der skete før, under og efter et nedbrud. Men de er bygget til drift, ikke til bevis: rådata aggregeres efter kort tid, alarmer kan være slået fra, og grafer i et dashboard er en fortolkning af data, ikke data selv. Skal de bruges i en tvist, skal de sikres hurtigt, i rå form og med dokumentation af, hvordan systemet var sat op.

Haster det? Rådata aggregeres ofte efter få dage, og detaljerede traces og logs kan være væk efter 15 til 30 dage, så et kort udfald ikke længere kan ses. Se akut forensisk sikring; hastesager koster ekstra.

Artiklen handler om datakilden. Hvordan oppetid og SLA-tal beregnes ud fra den, er beskrevet i SLA-målinger: metode og fejlkilder, og den juridiske side af SaaS-tvister findes på digital-bevissikring.dk.

Hvad overvågning og APM registrerer

Monitoreringssystemer samler forskellige typer data, som har forskellig bevisværdi:

Metrikker · Talværdier over tid: CPU, hukommelse, svartider, fejlrater, kølængder
Tjek og prober · Om en tjeneste svarede på en forespørgsel udefra eller indefra
Alarmer og hændelser · Hvornår en tærskel blev overskredet, hvem der fik besked, og hvornår den blev kvitteret
Traces · Enkelte forespørgslers vej gennem systemets komponenter med tid pr. trin
Logs · Tekstposter fra applikationer og infrastruktur, ofte samlet i samme platform
Konfiguration · Tærskler, målepunkter, intervaller og hvilke systemer der overvåges

Metrikker og tjek siger noget om tilstanden, traces om årsagen, og alarmer om, hvad driftsorganisationen vidste og hvornår. I en tvist om ansvar for et nedbrud kan netop det sidste være afgørende: Blev leverandøren varslet, og hvor lang tid gik der, før nogen reagerede?

Aggregering og opbevaring

Den største faldgrube er, at de fleste systemer gemmer rådata i kort tid og derefter kun aggregerede værdier. En metrik kan være registreret hvert tiende sekund de første dage, derefter som gennemsnit pr. minut og senere pr. time. Et udfald på tre minutter kan forsvinde helt i et timegennemsnit, og et maksimum kan blive udjævnet til noget, der ser normalt ud.

Opbevaringstiden afhænger af produkt, abonnement og konfiguration og er ofte meget forskellig for de enkelte datatyper. Hos Datadog var standarden på tidspunktet for gennemgangen (oktober 2026) 15 eller 30 dage for indekserede traces afhængigt af abonnement, mens metrikker gemmes i 15 måneder. Detaljerede traces og logs forsvinder altså typisk længe før metrikkerne. Traces samples desuden ofte, så kun en brøkdel af forespørgslerne gemmes. Mangler en bestemt forespørgsel, betyder det ikke, at den ikke fandt sted.

Konsekvensen er, at sikringen skal ske, mens rådata stadig findes. Hvordan logrotation og opbevaring generelt påvirker sikringen, er beskrevet i logfiler og logrotation.

Hvem har data

Overvågningen kan ligge hos kunden, hos driftsleverandøren, hos en underleverandør eller i en SaaS-platform, som en af parterne abonnerer på. I en tvist mellem kunde og leverandør er det ofte den ene part, der har adgangen. Det giver to praktiske problemer: Den anden part kan ikke selv sikre data, og den part, der har adgangen, kan ændre konfigurationen eller lade data udløbe.

Kortlæg derfor tidligt, hvilke overvågningssystemer der findes, hvem der administrerer dem, og hvem der har eksportrettigheder. Er det leverandørens system, kan en skriftlig anmodning om bevarelse være første skridt.

Sikring

Eksportér rådata, ikke kun skærmbilleder af dashboards. De fleste platforme har API’er eller eksportfunktioner til metrikker, hændelser og logs.
Notér opløsningen på de eksporterede data: rådata, minutværdier eller timeværdier.
Sikr alarmhistorikken med tidspunkter for udløsning, notifikation, kvittering og lukning.
Sikr konfigurationen: tærskler, målepunkter, intervaller, vedligeholdelsesvinduer og ændringshistorik for selve overvågningen.
Tag skærmbilleder af dashboards som supplement, med tidsinterval og tidszone synligt, så de kan holdes op mod rådata.
Hash eksporterne, og registrér, hvem der har lavet dem, med hvilket værktøj og hvornår.

Konfigurationens ændringshistorik overses ofte. Hvis en tærskel er hævet, eller et tjek er slået fra i perioden, ændrer det fortolkningen af, at der ikke kom nogen alarm.

Tid og ure

Overvågningsdata stammer fra mange kilder med hvert sit ur: agenter på servere, prober fra eksterne lokationer og platformens egen modtagelse. Platformen gemmer typisk tidspunkter i UTC, mens dashboards viser browserens lokale tid. Ved eksport kan tidszonen være angivet eller ej.

Sammenlign tidspunkter i overvågningen med uafhængige kilder, fx firewall-logs eller applikationslogs, og dokumentér eventuelle afvigelser. Se urafvigelse og korrektion.

Fejlkilder i fortolkningen

Måleren var selv nede. Et hul i dataene kan betyde, at systemet var nede, eller at agenten, proben eller netværket til overvågningen var nede.
Målepunktet måler noget andet. En probe, der kun tjekker forsiden, viser ikke, om login eller betaling virkede.
Gennemsnit skjuler udfald. Brug maksimum, percentiler og rådata, hvor de findes.
Sampling. Manglende traces er ikke bevis for, at forespørgsler ikke fandt sted.
Ændret konfiguration. Tærskler og målepunkter kan være ændret i perioden.
Planlagt vedligeholdelse. Alarmer kan være undertrykt i vedligeholdelsesvinduer, som ikke fremgår af grafen.

Integritet

Monitoreringsdata ligger hos en part, der kan have interesse i sagen, og administratorer kan ofte slette eller ændre data. Platformens egen auditlog over brugerhandlinger, fx sletning af dashboards, ændring af alarmer og eksport, kan vise, om der er grebet ind. Den bør sikres sammen med selve dataene. De generelle principper er beskrevet i logintegritet.

Uafhængige kilder styrker billedet. En ekstern prober, som ingen af parterne kontrollerer, eller kundens egne fejlrapporter med tidspunkter kan bekræfte eller afkræfte overvågningens billede.

Traces som årsagsspor

Traces er den del af APM, der kommer tættest på en årsag. En trace viser, hvilke tjenester en forespørgsel passerede, hvor lang tid hvert trin tog, og hvor en fejl opstod, fx en database, der svarede langsomt, eller et eksternt API, der returnerede fejl. Det kan flytte en diskussion fra “systemet var langsomt” til “kald til en bestemt komponent tog flere sekunder”.

Tre forhold skal med i vurderingen. For det første instrumenteringen: Kun de dele af koden, der er instrumenteret, optræder i en trace, og en komponent uden instrumentering kan fremstå som et tomt hul. For det andet samplingen: Hvis der kun gemmes traces for en del af forespørgslerne, eller kun for dem med fejl, er udvalget ikke repræsentativt. For det tredje versioner: Agenter og biblioteker opdateres, og målingen kan ændre sig mellem to perioder. Notér derfor agentversioner og samplingregler for den periode, sagen handler om.

Hvad data kan og ikke kan bevise

Monitoreringsdata kan vise, at en målt værdi lå på et bestemt niveau på et bestemt tidspunkt, at en alarm blev sendt, og hvornår den blev håndteret. De kan sjældent alene vise årsagen til et nedbrud, og de viser ikke, hvad brugerne faktisk oplevede, hvis målepunkterne ikke svarer til brugernes vej gennem systemet.

Konklusioner bør derfor formuleres præcist: “Proben fra den eksterne lokation fik ikke svar fra forsiden mellem 10.04 og 10.31 UTC” er en observation. “Systemet var nede i 27 minutter” er en slutning, der kræver flere kilder.

Dokumentation i sagen

Rapporten bør beskrive, hvilke systemer der var overvåget og hvordan, hvilke data der er eksporteret og i hvilken opløsning, perioder uden data og mulige forklaringer, konfigurationsændringer i perioden og de uafhængige kilder, der er brugt til kontrol. Leverandørens synspunkt på sagen, når kunden giver leverandøren skylden, er beskrevet på bevissikring-digitalt.dk.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Massesletning efter en tvist er opstået: tekniske tegn

Læs også: SLA-målinger: hvordan tallene beregnes, og hvor de kan være forkerte · Leverancens tilstand på overdragelsestidspunktet: sikring af miljøer og builds

→ Uvildig IT-sagkyndig med forensic-baggrund · For MSP’er · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik