Observability

Dette kapitlet hjelper deg å følge med på driftshelse i praksis. Når hjemmesiden og APIet er ute i verden, må du måle, logge og reagere før kundene merker problemene.

Observability er mer enn å ha noen logger og et grønt health-endepunkt. Målet er at teamet raskt skal kunne forstå hva systemet gjør, hva som endret seg, hvor en feil startet og hvilke deler som faktisk er berørt. God observability gjør altså ikke bare feil lettere å finne. Den gjør hele driften roligere og beslutningene mer presise.

Hvordan tenke om observability

Det viktigste er å skille mellom signaler og støy. Mange systemer samler store mengder data, men lite av det hjelper når noe faktisk skjer. Gode observability-signaler svarer på noen konkrete spørsmål: er tjenesten oppe, er den klar for trafikk, går den tregere enn normalt, øker feilraten, og hvilke requests eller moduler er involvert?

Derfor bør observability bygges rundt få, tydelige signaler som henger sammen: health, logger, metrikker, korrelasjon og varsler. Når disse peker i samme retning, blir det langt enklere å forstå både små avvik og større hendelser.

1) Health-check som grunnmur

Ha egne, enkle endepunkter: /healthz for enkel sjekk, og gjerne /ready for klar-til-trafikk-status.

funksjon health_handler(method: tekst, path: tekst, query: tekst, body: tekst) -> tekst {
    hvis method != "GET" da {
        returner web.http_respons_tekst(405, web.http_content_type_json(), "{\"error\":\"method_not_allowed\"}")
    }
    returner web.http_json_respons("{\"ok\":true,\"service\":\"norscode\",\"version\":\"1.0.0\",\"ready\":true}")
}

Et godt health-endepunkt er ikke en full systemrapport. Det er et raskt og stabilt signal som kan brukes av lastbalansering, deploy-verktøy og driftsovervåking. Hvis health-sjekken er tung eller avhenger av mange ustabile komponenter, blir den fort mindre nyttig nettopp når systemet er under press.

Det er også nyttig å skille mellom “lever” og “klar”. En tjeneste kan være oppe som prosess, men fortsatt ikke være klar for trafikk fordi migrasjon pågår, cache ikke er bygd opp eller en nødvendig avhengighet ikke svarer. Når dette skillet er tydelig, blir deploy og incident-håndtering mye tryggere.

2) Strukturert logging

Strømmen din blir lettere å debugge hvis logger er forutsigbare og lette å filtrere.

{\n  \"event\": \"request_ok\",\n  \"route\": \"/api/kontakt\",\n  \"status\": 200,\n  \"duration_ms\": 5,\n  \"request_id\": \"req_1291\"\n}

Strukturert logging er viktig fordi den lar teamet søke etter mønstre i stedet for å lese fritekst linje for linje. Når feltene er faste, kan du lettere filtrere på status, route, hendelsestype eller request-id og forstå hvordan en hendelse utviklet seg.

Dette er spesielt nyttig når observability skal brukes av flere roller samtidig. Utviklere, drift og support trenger ofte ulik inngang til samme data, men drar nytte av at loggene er konsistente og ikke krever tolkning av forskjellige skrivestiler fra ulike deler av koden.

3) Feilsøking med korrelasjon

Knytt en request_id gjennom alle logger og svar om mulig, slik at ett brukercase kan følges fra første request til endepunkt.

funksjon request_id() -> tekst {
    returner "req_" + tekst_fra_heltall(tid_nå_ms())
}

funksjon logg_forespørsel(id: tekst, rute: tekst) -> tekst {
    returner "[" + id + "] " + rute + " - mottatt"
}

Korrelasjon er det som gjør observability brukbar i praksis. Uten en felles id ender man lett opp med mange riktige logglinjer som ikke kan knyttes sammen sikkert. Da blir feilsøking tregere og mer preget av gjetting.

Når én id følger hele request-kjeden, kan du se rekkefølgen mellom handler, validering, integrasjon, database og respons. Dette er spesielt nyttig i systemer som ellers ser “friske” ut på overflaten, men hvor enkelte brukerreiser fortsatt feiler eller blir trege.

4) Grunnleggende metrikker

Du trenger ikke et gigantisk observability-oppsett for å starte. Begynn med fire nøkkeltall.

• Gjennomsnittlig responstid per endpoint.
• Antall feil (4xx/5xx) siste 5 minutter.
• Antall aktive forbindelser eller requests.
• Antall vellykkede og avviste valideringer.

Metrikker er nyttige fordi de viser mønstre over tid, ikke bare enkelthendelser. En logglinje kan fortelle at én request feilet. En metrikk kan fortelle at feilraten har doblet seg den siste halvtimen, eller at responstiden sakte stiger under økende last.

Det hjelper også å velge noen få metrikker som faktisk betyr noe for tjenesten. For mange dashboards starter med alt mulig teknisk, men mangler tallene som forteller om brukerflytene faktisk lykkes. Start heller smalt og nyttig enn bredt og uklart.

5) Dashboards som faktisk hjelper

Et dashboard bør være lett å lese raskt. Hvis drift må hoppe mellom mange paneler for å forstå en hendelse, mister visualiseringen mye av verdien sin.

Et godt dashboard svarer raskt på om problemet er generelt eller avgrenset, nytt eller pågående, lokalt eller relatert til en avhengighet. Det betyr ofte at enkle oversikter er viktigere enn veldig mange spesialpaneler.

6) Varsler og eskalering

Sett opp terskler tidlig, før de blir store. De fleste team bruker to nivåer: warning og critical.

Varsler fungerer best når de er få nok til å bli tatt alvorlig og presise nok til å peke mot et første tiltak. Hvis alt varsles, blir det raskt alarmtretthet. Hvis nesten ingenting varsles, får teamet vite om problemer for sent.

Det hjelper å tenke på varsler som en prioriteringsmekanisme, ikke bare en måling. Hvilke signaler betyr at noen bør se på tjenesten i løpet av dagen, og hvilke betyr at noen må reagere med en gang? Når dette er tydelig, blir responsen roligere og mer forutsigbar.

7) Daglig drift-sjekkliste

1. Verifiser /healthz og /ready.
2. Les siste 200 logglinjer for advarsler.
3. Bekreft at feilkoder ikke øker ukritisk.
4. Bekreft at rollback-planen fortsatt er gyldig.
5. Oppdater driftsnotater fra dagens hendelser.

Rutiner er viktige fordi observability ellers lett blir et passivt system som bare brukes når noe allerede er galt. Den daglige gjennomgangen gjør at små avvik, stigende feilrater eller nye mønstre blir oppdaget før de vokser seg større.

8) Hva som ofte går galt

• health-endepunktet er for tungt eller for utydelig
• logger mangler request-id eller faste felt
• det finnes metrikker, men ingen vet hvilke som betyr mest
• dashboards er for detaljerte til å brukes under press
• varsler er enten for mange eller for slappe

Slike problemer gjør observability mindre troverdig. Når teamet ikke stoler på signalene, begynner de å feilsøke manuelt eller basert på magefølelse. Da mister systemet mye av sin verdi, selv om dataene teknisk sett finnes.

9) Hva du bør ta med deg videre

Den viktigste lærdommen er at observability skal hjelpe mennesker å forstå systemet raskt. Derfor må signalene være tydelige, sammenhengende og knyttet til hvordan tjenesten faktisk oppfører seg for brukere og drift.

Når health, logging, metrikker, dashboards og varsler virker sammen, får du ikke bare bedre debugging. Du får også et system som er lettere å forbedre, tryggere å deploye og enklere å drive over tid.

Neste steg

Gå videre med deploy-guiden for å lukke løkken mellom distribusjon, observability og forbedring.