Praktisk guide
"Vi har observability" betyder som regel at en monitoring-leverandør er installeret og et par dashboards findes et sted. Det betyder sjældent at når noget går i stykker klokken to om natten, kan on-call-ingeniøren svare på "hvad ændrede sig, hvem er ramt, og hvor skal jeg kigge nu" på få minutter. Det hul — mellem at have værktøjet og at have svaret — er det vi kalder observability-teater.
Det sker af en forståelig grund: dashboards er synlige og nemme at vise frem, så de bliver bygget først. Alert-disciplin og struktureret logging er usynlige indtil den nat I har brug for dem, så de bliver udskudt. Det her handler om at lukke det hul bevidst — uden at gøre det til et halvårs platform-projekt.
TL;DR
De vigtigste pointer
- Et dashboard er kun nyttigt hvis nogen åbner det under en incident. Hvis ingen kan navngive de tre dashboards de ville tjekke først, har I teater — ikke observability.
- Strukturerede logs (konsistente felter, correlation IDs, maskinlæsbart) slår en væg af console.log hver gang I skal spore en request på tværs af services.
- Alerts bør ringe på symptomer brugerne mærker (fejlrate, latency, fejlede checkouts) — ikke på hver metric der krydser en vilkårlig tærskel. Alert-træthed er værre end ingen alerting.
- Traces betaler sig mest i det øjeblik I har mere end én service der taler med en anden. Én vel-instrumenteret request-trace svarer på spørgsmål som hundrede log-linjer ikke kan.
- Den reelle omkostning ved observability er instrumentationstid, ikke leverandørregningen. Budgetér engineering-tid til det eksplicit — ellers sker det aldrig.
- Start med de tre spørgsmål I rent faktisk ville stille under en incident, og byg baglæns til de dashboards og alerts der svarer på dem.
Hvorfor det her betyder mere end oppetidstal
Prisen for dårlig observability viser sig ikke som nedetid — den viser sig som tid-til-diagnose. To systemer kan have identisk oppetid og fuldstændig forskellig driftsomkostning: det ene hvor en incident forstås på kort tid og fixes hurtigt, og et andet hvor teamet bruger lang tid på at finde ud af hvad der overhovedet er galt, før selve fixet tager fem minutter. Det andet team ser fint ud på en oppetidsgraf og brænder ud ved hver incident.
Observability-teater er dyrt på en anden, mindre åbenlys måde: falsk tryghed. Et team med fyrre dashboards og ingen alert-disciplin tror det er overvåget. Det opdager det modsatte ved den første incident ingen så komme — fordi den metric der betød noget ikke var på nogen af de fyrre paneler, eller var der men begravet mellem niogtredive andre som ingen tjekker.
Pynt-dashboards vs. observability der kan handles på
Pynt-dashboards
Bygget til at demo godt, sjældent åbnet under en rigtig incident.
- Dusinvis af paneler der dækker hver metric platformen kan udsende
- Bygget én gang ved opsætning, sjældent genbesøgt når systemet ændrer sig
- Ingen klar ejer af hvad "sundt" betyder på hvert panel
- Alerts (hvis nogen) affyres på rå metric-tærskler, ikke bruger-synlige symptomer
- Logs er ustruktureret tekst, svær at søge på tværs af services
- Ingen kan navngive hvilke tre paneler de ville tjekke først under en incident
Observability der kan handles på
Bygget omkring de spørgsmål I rent faktisk stiller når noget er galt.
- Et lille antal dashboards, hver med et specifikt drifts-spørgsmål
- Gennemgået og trimmet når systemet ændrer sig — døde paneler slettes
- Hver alert har en ejer og en dokumenteret forventet respons
- Alerts ringer på symptomer (fejlrate, latency, fejlede transaktioner), ikke hver tærskel-breach
- Logs er strukturerede med correlation IDs så en request kan spores end-to-end
- On-call-ingeniøren ved præcis hvor der skal kigges først — fordi det er øvet
Hvordan minimal, ærlig observability ser ud
I behøver ikke en fuld observability-platform fra dag ét. Gulvet er lavere end de fleste teams tror: strukturerede logs med request/trace-ID, en håndfuld metrics der mapper direkte til hvad brugerne oplever (fejlrate, p95-latency, kø-dybde, fejlet betalingsrate), og alerts der ringer til et menneske kun når et af de symptomer krydser en tærskel der faktisk betyder at noget er i stykker for nogen.
Næste lag — distribueret tracing — tjener sin pris i det øjeblik jeres system har mere end én service, eller en request rører mere end én datastore. Uden det betyder debugging af en langsom request på tværs af et API, en kø og en database at korrelere timestamps på tværs af tre separate log-streams i hånden. Med det ser I hele requesten som én tidslinje — og det langsomme span er tydeligt.
Hvor teams bruger for meget er at købe en enterprise observability-platform før de har fortjent den kompleksitet den håndterer. En lille Next.js-app med Postgres og én background worker behøver ikke tracing-infrastruktur dimensioneret til et hundred-microservice-flåde. Match værktøjet til den faktiske topologi, og voks det efterhånden som systemet gør.
Byg minimal, handlingsbar observability
Det her er rækkefølgen der hurtigst bringer jer fra intet til noget I kan stole på — uden at overbygge.
- 01
Skriv de tre spørgsmål I ville stille under en incident
Før I rører værktøj: hvad ville I rent faktisk vide først når noget går i stykker? Det er typisk en version af "hvad ændrede sig", "hvem er ramt" og "bliver det værre". Byg alt andet for at svare på det.
- 02
Tilføj struktureret logging med correlation ID
Hver log-linje bør bære request- eller trace-ID, timestamp, severity og konsistente feltnavne. Det alene gør debugging på tværs af services markant hurtigere end fri-tekst logs.
- 03
Instrumentér de få metrics der mapper til brugeroplevelsen
Fejlrate, latency-percentiler og den forretningskritiske sti (checkout gennemført, login lykkes, job completion rate) — ikke hver metric jeres framework eksponerer som default.
- 04
Sæt alerting op på symptomer, ikke rå metrics
Alert når fejlraten krydser en tærskel der betyder brugere er ramt — ikke når CPU tikker op i tredive sekunder. Giv hver alert en dokumenteret, specifik respons.
- 05
Tilføj tracing når mere end én service er involveret
Hvis en enkelt request kun rører én service og én database, er tracing nice-to-have. I det øjeblik en request forgrener sig på tværs af services, stopper tracing med at være valgfrit.
- 06
Kør en incident-øvelse og trim det ingen brugte
Simulér en incident (eller gennemgå en rigtig) og tjek hvilke dashboards og logs der faktisk blev brugt. Slet eller genbyg dem der ikke hjalp — det er trinnet de fleste teams springer over, og det er trinnet der holder observability ærlig over tid.
Spørgsmål vi får igen og igen
Hvad er minimum viable observability for en lille produktions-app?
Strukturerede logs med request-ID, fejlrate- og latency-metrics på jeres kritiske stier, og et lille antal alerts koblet til de metrics med en dokumenteret respons. Det er nok til at håndtere de fleste incidents kompetent. Tilføj tracing og mere granulære dashboards efterhånden som systemet får flere services.
Hvor mange dashboards bør vi faktisk have?
Færre end I tror. En håndfuld formålsbyggede dashboards der svarer på specifikke spørgsmål ("er checkout-flowet sundt", "bagger background job-køen op") slår dusinvis af generiske. Hvis et dashboard ikke svarer på et spørgsmål nogen faktisk stiller, hjælper det ikke.
Skal vi have en dedikeret observability-leverandør, eller kan vi bygge det selv?
Begge dele virker. Leverandører (Datadog, Grafana Cloud, Better Stack og andre) sparer opsætningstid og tilføjer polish; en self-hosted stack (Grafana, Loki, Prometheus) koster mere engineering-tid men undgår vendor lock-in og per-seat-skaleringsomkostninger. Valget betyder mindre end disciplinen bag — en dårlig alert-strategi er dårlig på enhver platform.
Hvordan stopper vi alert-træthed når det allerede er et problem?
Audit hver alert der affyrede i sidste måned og spørg hvilken handling den burde have udløst. Hvis svaret er "ingen, egentlig", så gør den til et dashboard-panel i stedet for en page. Genbyg pager-listen ud fra de symptomer der genuint har brug for et menneske — og vær nådesløs med at trimme.
Er tracing det værd for en monolit med én database?
Typisk ikke endnu. Tracing tjener sin pris når en request forgrener sig på tværs af flere services eller datastores. For en single-service monolit giver god struktureret logging med request-ID jer det meste af samme debugging-værdi til en brøkdel af opsætningsomkostningen.
Hvor ofte bør observability genbesøges?
Når systemets form ændrer sig meningsfuldt — en ny service, et nyt kritisk brugerflow, en ny datastore — og som minimum efter hver rigtig incident. Post-incident review bør altid spørge om observability-opsætningen hjalp eller hæmmede, og justere derefter.
Hvis I vil have en ærlig vurdering af jeres nuværende setup
Vi gennemgår jeres dashboards og alerting — uden forpligtelser.
Vi fortæller hvilke dele der faktisk hjælper under en incident, hvilke der er teater, og hvordan det mindste nyttige næste skridt ser ud.