Observability
Observability og monitoring
Vi sætter observability op med Sentry, Datadog, Grafana eller Honeycomb — ikke som et grafmuseum, men så I konkret kan svare på hvad der sker, hvorfor det sker og hvem der er ramt.
Observability uden grafmuseum
Det her gør forskel klokken to om natten
- Exceptions, releases og brugerkontekst
- Sentry
- OpenTelemetry på tværs af tjenester
- Traces
- Alerts på brugeroplevelse, ikke på tærskler
- SLO
- Hver alert har en konkret handling
- Runbook
Sådan tænker vi observability
Svar på de spørgsmål I rent faktisk har — ikke et grafmuseum.
De fleste systemer er ikke under-overvåget — de er over-instrumenteret og under-tænkt. Dashboards i ti niveauer, alerts der ringer to gange om dagen og som ingen reagerer på, og når noget faktisk går galt, sidder I alligevel i loggen og søger efter en stack trace. Vi bygger observability der svarer på spørgsmålene I rent faktisk har klokken to om natten: hvad er gået i stykker, hvor mange er ramt, og hvad skal vi gøre nu.
Vores typiske setup er Sentry til exceptions og frontend-fejl, et metrics-system (Datadog, Grafana Cloud eller Honeycomb) til drifts-data og latency, struktureret logging via OpenTelemetry til traces på tværs af tjenester, og en runbook pr. service med konkrete handlingsanvisninger pr. alert. Vi går efter SLOs i stedet for tærskler — vi alarmerer når brugeroplevelsen er truet, ikke når en tilfældig metric krydser et tilfældigt tal.
Vi sætter også det op der gør forskel for det daglige team: pr-deploy-markører på alle grafer (så I kan se hvilken deploy der knækkede noget), pr-tenant-views (når en stor kunde klager, kan I straks se deres specifikke metrics), og en on-call-rotation med klare overdragelser så ingen sidder med et brændende system uden hjælp.
Hvad I får leveret
Sentry, traces, SLO-baserede alerts og runbooks.
Bygget så hver alert kræver en konkret handling, og hver incident efterlader læring i runbooken.
Sentry til exceptions og frontend-fejl
Sentry sat op med source maps, release tracking, performance monitoring og brugerkontekst. Releases kobles til Git commits så I umiddelbart kan se hvilken kodeændring der introducerede en fejl.
Metrics, dashboards og forretnings-KPI'er
Datadog, Grafana Cloud eller Honeycomb afhængigt af jeres stack og budget. Dashboards designes pr. tjeneste og pr. forretningskritisk flow — ikke som et muséum af alle tænkelige metrics.
Distribueret tracing via OpenTelemetry
OpenTelemetry-instrumentering så I kan følge en request på tværs af frontend, API, database og tredjeparts-tjenester. Når noget er langsomt, ved I præcist hvor tiden bliver brugt — ikke kun at det er langsomt.
Struktureret logging og log-aggregation
JSON-strukturerede logs med trace-id, request-id, tenant-id og bruger-id på hver linje. Aggregeret i Datadog, Grafana Loki eller jeres egen ELK-stack — så søgning faktisk finder noget.
SLO-baserede alerts der ikke trætter
Alerts baseret på Service Level Objectives (fx '99.5% af checkout-requests under 500ms over 30 dage'), ikke på vilkårlige tærskler. Vi konfigurerer error budgets, burn-rate-alerts, og sletter alerts der ikke fører til handling.
Runbooks og on-call
Hver alert har en runbook: hvad betyder det, hvilke skridt skal man tage, hvem skal eskaleres til. On-call-rotation sat op i Opsgenie eller PagerDuty med klare overdragelser. Post-mortems efter alvorlige incidents — uden skyld, med læring.
Inden I forpligter jer
Det her bør I overveje først.
Hvor mange værktøjer har I egentlig brug for?
Det er fristende at have separate værktøjer for logs, metrics, traces, exceptions og uptime. Det giver bedst-i-klassen pr. lag, men også fem dashboards I skal jonglere mellem under en incident. Vi anbefaler ofte at samle på færre værktøjer (Datadog dækker det meste; Grafana Cloud også) — medmindre I har specifikke krav til ét lag.
Sampling og omkostning
Fuld instrumentering på alt kan blive uoverskueligt dyrt. Vi designer en sampling-strategi: 100% af exceptions, 100% af alle 5xx-responses, 5–10% af succesfulde requests — med smart sampling der altid beholder slow requests og fejlende traces. Budget-alarmer på telemetry-forbruget selv så I ikke får en overraskelse-regning.
GDPR og brugerdata i logs
Strukturerede logs må ikke indeholde PII (e-mail, navne, adresser, CPR). Vi sætter automatisk redaktion op i logging-laget og auditerer ved opsætningen. Bruger-kontekst i fejlrapporter holdes til bruger-ID og tenant-ID — alt andet kræver eksplicit beslutning.
Alert-fatigue er en reel risiko
En alert der går af tre gange om dagen og som ingen reagerer på, har mistet sin betydning. Vi gennemgår alle alerts kvartalsvis: dem ingen har handlet på fjernes eller justeres. Mål er at hver pager-alert kræver konkret handling — ellers er det støj.
FAQ
Det folk plejer at spørge om.
Hvor lang tid tager en observability-opsætning?
En grundlæggende opsætning med Sentry, struktureret logging, tre kerne-dashboards og en on-call-rotation er typisk 3–5 uger. En fuld opsætning med distribueret tracing, SLOs, runbooks pr. service og post-mortem-proces tager 6–10 uger. Vi anbefaler at starte med basis og bygge ud — fuld instrumentering på dag ét er ofte støj uden læring.
Hvilket værktøj skal vi vælge?
Sentry er næsten altid med — det dækker exceptions og frontend-fejl godt og er rimeligt til de fleste stacks. Til metrics og traces afhænger det af jeres team: Datadog er den mest omfattende men kræver disciplin på forbrug; Grafana Cloud giver god værdi for små teams; Honeycomb er suverænt til komplekse distribuerede systemer. Vi vælger sammen i discovery efter jeres stack og drifts-team.
Kan vi bruge OpenTelemetry og undgå vendor lock-in?
Ja — og det anbefaler vi som default. OpenTelemetry-instrumentering eksporteres til hvilken backend I vil. I kan starte med fx Datadog og senere skifte til Grafana Cloud uden at re-instrumentere koden. Det er en lille up-front investering der giver fleksibilitet senere.
Hvordan håndterer I on-call uden at brænde teamet ud?
Med streng disciplin på alerts — kun det der kræver handling pager. Med en rotation der ikke er tungere end teamet kan håndtere (typisk én uge pr. person, ikke nødvendigvis 24/7 hvis forretningen ikke kræver det). Med follow-the-sun hvis I har spredt team. Og med post-mortems efter hver alvorlig incident der reelt rører ved processen — ikke kun finder skyld.
Kan I tage on-call for os?
Ja, på en månedlig drifts-aftale. Vi tager typisk en hybrid model hvor jeres team er primær on-call (de kender produktet bedst), og vi er secondary for at backe op udenfor arbejdstid eller når en incident eskalerer. Vi har også taget primary on-call for kunder der ikke har et internt drifts-team.
Klar til at starte?
Lad os tage en uforpligtende snak.
Vi vender tilbage indenfor en arbejdsdag med konkret input — ikke et standardtilbud.