Logging og feilsøking i Norscode

Mange løsninger havner i drift med godt resultat, men blir vanskelige å drifte. Denne guiden hjelper deg å gjøre loggingen forståelig, nyttig og trygg.

God logging er ikke bare ekstra tekst rundt applikasjonen. Den er en del av hvordan systemet forklarer seg selv når noe går galt. Når logger er utydelige, for detaljerte på feil sted eller mangler kontekst, blir selv små feil tyngre å finne. Når loggingen er god, går support, feilsøking og forbedring mye raskere.

Hvordan tenke om logging

Det viktigste er å behandle logger som et arbeidsverktøy for drift og utvikling, ikke bare som et teknisk avfallsprodukt. Du logger ikke for å ha “mest mulig data”. Du logger for å kunne svare på noen konkrete spørsmål: hva skjedde, når skjedde det, hvor i flyten skjedde det, hvem eller hva var berørt, og hva var siste vellykkede steg før noe feilet?

Hvis loggene ikke hjelper med disse spørsmålene, hjelper de sjelden i praksis. Derfor er god logging nesten alltid strukturert, bevisst og koblet til reelle hendelser i systemet, ikke bare tilfeldige utskrifter lagt inn underveis.

1) Bruk strukturert logging

Unngå fritekst-blander. Bruk faste felt så det er enkelt å filtrere i søk og dashboards.

funksjon logg_info(hendelse: tekst, steg: tekst, id: tekst) -> tekst {
    returner "{\"level\":\"info\",\"event\":\"" + hendelse + "\",\"steg\":\"" + steg + "\",\"trace_id\":\"" + id + "\"}"
}

Strukturert logging er verdifull fordi den gjør det mulig å søke på felt i stedet for å tolke lange tekstlinjer manuelt. Hvis alle logger følger et kjent mønster, kan du raskt filtrere på nivå, hendelsestype, trace-id, modul eller status uten å gjette deg frem.

Det betyr også at teamet bør være enige om noen få sentrale felter som går igjen overalt. Det kan være level, event, trace_id, modul, status og eventuelt en kort feilkode. Konsistens er ofte viktigere enn å ha mange felter.

2) Velg riktig loggnivå

Sett nivåene eksplisitt, og unngå at for mye debug slipper til prod.

Loggnivåer fungerer som et språk for alvorlighetsgrad. Hvis alt logges som error, mister nivåene verdi. Hvis viktige feil gjemmes som info, blir det vanskelig å oppdage hva som trenger oppfølging. Derfor bør nivåvalg være bevisste og repeterbare, ikke tilfeldige fra fil til fil.

Et godt mønster er å bruke info for normale, men viktige steg i systemet, warn for avvik som fortjener oppmerksomhet, og error når flyten faktisk bryter eller data ikke kan behandles videre. debug bør være svært nyttig lokalt, men ikke dominere produksjonsmiljøet.

3) Korrelasjon mellom hendelser

Legg alltid med trace_id på requesten. Det gjør det mulig å følge en henvendelse fra første treff til siste svar.

funksjon ny_trace_id() -> tekst {
    returner "trace-001"
}

• Kopier trace-id videre ved intern funksjonssamtale.
• Bruk samme id i svarfelt, logger og eventuelle webhook-kall.

Korrelasjon er noe av det viktigste i systemer med flere steg, integrasjoner eller bakgrunnsjobber. Uten en felles trace-id ender du ofte med å lese mange logglinjer som hver for seg ser riktige ut, men som er vanskelige å knytte til samme hendelse.

Når samme trace-id følger hele reisen, blir det mulig å se rekkefølge, ventetid og bruddpunkt mye raskere. Dette er særlig nyttig i webflyter, webhook-behandling og integrasjoner der en feil kan oppstå langt fra inngangspunktet.

4) Personvern i logger

Ikke lagre rå e-post eller personnummer i klartekst. Sanitér alltid før logging.

funksjon skjul_e_post(e: tekst) -> tekst {
    hvis e == "" da { returner "" }
    returner "***masked***"
}

Logger blir ofte liggende lenge, kopieres til andre systemer og leses av flere enn de som håndterer applikasjonsdata direkte. Derfor må de behandles med samme respekt som andre datakilder. Personopplysninger, tokens, sesjonsverdier og følsomme payloads bør som hovedregel maskeres, oppsummeres eller utelates.

Det er også verdt å huske at “praktisk feilsøking” lett kan bli en unnskyldning for å logge for mye. En bedre strategi er å logge nok metadata til å forstå hendelsen, men ikke så mye rådata at loggene blir en egen sikkerhetsrisiko.

5) Etablér feilsøkingsløp

1. Bekreft hvilken trace-id som er berørt.
2. Les siste vellykkede steg før feilen.
3. Kontroller valideringsfeil mot inputfelt.
4. Sjekk avhengigheter (API, DB, filer) for samtidige feil.
5. Gjenskap feilen i testmiljø med samme payload.

Et fast feilsøkingsløp reduserer panikk og tilfeldig leting. I stedet for å hoppe rett til antagelser, går du systematisk gjennom sporene systemet allerede har gitt deg. Det er ofte nok til å avklare om feilen ligger i input, intern logikk, ekstern avhengighet eller driftsmiljø.

Det er også nyttig å se etter siste vellykkede steg, ikke bare selve feilpunktet. I mange saker er det nettopp overgangen mellom to steg som avslører problemet, for eksempel en verdi som ble validert, men senere ikke kunne brukes av en integrasjon eller database.

6) Hva som kjennetegner gode logger

Det som ofte gjør logger vanskelige å bruke, er ikke at de mangler tekst, men at de mangler mening. “Feil i behandling” eller “Noe gikk galt” er nesten alltid for svakt. En god logglinje sier hva systemet prøvde å gjøre, hvilket steg som feilet og hvilken type feil det var.

7) Meldinger og alarmgrenser

Definer alarmer med terskler som faktisk gir mening i drift.

funksjon skal_varsle_feilrate(feil_per_minutt: heltall) -> bool {
    hvis feil_per_minutt >= 15 da { returner true }
    returner false
}

Alarmgrenser bør være nyttige, ikke bare teknisk mulige. Hvis tersklene er for lave, lærer teamet å ignorere varsler. Hvis de er for høye, reagerer man for sent. Gode alarmer peker på reelle driftsproblemer, som økende feilrate, manglende korrelasjonsfelt eller plutselig endring i svartid.

Det hjelper å koble alarmene til konkrete handlinger. Hvis et varsel går, bør det være klart hvem som ser på det først og hva som skal sjekkes. Uten denne koblingen blir alarmer fort bare støy med høy prioritet.

8) Vanlige feil i loggingoppsett

• for mye debug-støy i produksjon
• for lite kontekst i feil-linjer
• manglende trace-id i sentrale flyter
• følsomme data i logger
• alarmer som enten varsler hele tiden eller nesten aldri

Slike feil gjør logging mindre troverdig over tid. Når teamet ikke stoler på loggene, begynner de å feilsøke på andre måter, ofte med manuell gjetting eller direkte inspeksjon i data. Da mister observability-systemet mye av verdien sin.

9) Daglig og ukentlig sjekkliste

Rutiner er viktige fordi god logging ikke vedlikeholder seg selv. Felter forsvinner, nye flyter blir lagt til uten trace-id, og gamle varsler blir hengende igjen. En liten, jevn gjennomgang er ofte nok til å holde systemet nyttig over tid.

10) Hva du bør ta med deg videre

Den viktigste lærdommen er at logging skal hjelpe mennesker å forstå systemet under press. Derfor må loggene være tydelige, strukturerte, forsiktige med sensitive data og rike nok på kontekst til at man faktisk finner neste steg i feilsøkingen.

Når dette fungerer godt, blir drift roligere, feil blir ras