Som startup er logning og observability ofte noget, man først tænker på, når noget går galt: en uventet fejl i checkout, et API der svarer langsomt, eller en alarm der aldrig kom. Denne guide giver dig et praktisk sæt valgkriterier, så du kan vælge logging-setup uden at brænde tid og budget af – og uden at ende med en platform, der spænder ben for skalering.
Du får en konkret gennemgang af TCO, setup-tid, query-hastighed, retention, alerting, integrations, sikkerhed/compliance og skaleringsbreakpoints. Undervejs peger jeg på typiske faldgruber, viser hvornår “billigt” bliver dyrt, og slutter med en beslutningsmatrix, du kan kopiere direkte ind i jeres interne evaluering.
Hvad du egentlig vælger: logging som produktionskritisk infrastruktur
Logging er processen, hvor din applikation og din infrastruktur skriver strukturerede hændelser (events) til et system, så de kan søges, analyseres og bruges til alarmer. Det betyder noget, fordi logs ofte er det hurtigste bevismateriale, når noget fejler: de viser hvad der skete, hvor og hvornår.
Valget handler ikke kun om “en logplatform”, men om et workflow: hvordan udviklere logger, hvordan drift/engineering finder fejl, og hvordan virksomheden bevarer data sikkert. Det bedste valg er det, der minimerer tid til årsagsanalyse (MTTR) uden at sprænge TCO.
TCO i praksis: pris pr. event/log er kun starten
TCO (Total Cost of Ownership) er den samlede omkostning ved at eje og drive en løsning over tid: licens/forbrug, driftstid, vedligehold, support, samt indirekte omkostninger som udviklertid og nedetid. Mange vurderer kun “pris pr. GB” eller “pris pr. event”, men en startup bør se på hele kæden fra ingestion til søgning og retention.
Hvad koster det reelt pr. måned?
Lav en model, der tager udgangspunkt i jeres nuværende logvolumen og forventet vækst. Typiske prisdrivere er ingestion (events/GB), indeksering, query, retention og data egress. Spørg leverandøren: Hvad koster en standardmåned med 30 dages retention, 5 dashboards, og 50 alarmer?
- Ingestion: pris pr. event/log eller pr. GB, ofte med minimumsforbrug
- Indeksering: hvor meget data der gøres søgbart, og hvor længe
- Queries: begrænsninger på antal, concurrency eller “compute”
- Retention og arkiv: varm/kold lagring og gendannelse
- Data egress: udtræk til S3, BigQuery eller SIEM kan koste
- Overhead: tid til tuning, parsing, og håndtering af støj
Mini-konklusion: Den billigste line-item pris kan være den dyreste løsning, hvis du betaler med teamets tid og langsommere fejlfinding.
Skjulte omkostninger, teams ofte overser
“Gratis” starter ofte med få features og ender med add-ons: flere brugere, SSO, audit logs, længere retention eller avanceret alerting. En anden klassiker er uforudsigelige spikes: en fejl loop’er og sender millioner af events. Hvis prissætningen er hårdt koblet til ingestion, kan én bug give en stor regning. En god praksis er at kræve rate limiting, budget alerts og klare overage-regler.
Setup-tid: fra første log til driftssikkert setup
Setup-tid er tiden fra “vi har valgt” til “vi kan stole på data”. Det inkluderer instrumentering, logformat, pipelines, adgangsstyring og standarddashboards. For startups er tempo vigtigt: du vil hurtigt have værdi, men uden at bygge et skrøbeligt setup.
Minimumssetup, der virker fra dag 1
Start med strukturerede JSON-logs, et fælles felt-sæt (service, environment, request_id, user_id) og et simpelt retentionmål. Brug en agent eller SDK, der passer til jeres runtime. Hold antallet af logkilder lavt i starten, men sørg for, at det er repræsentativt for produktion.
Undgå “parsing-helvede”
Hvis logs er ustrukturerede, ender du med regex, specialcases og usikre dashboards. Kræv understøttelse af strukturerede felter, og skriv en lille intern logging-guide. Hvis logformatet ikke er standardiseret, betaler du TCO i vedligehold hver uge.
Mini-konklusion: Vælg den løsning, der gør det let at få ensartede logs ind, og svært at gøre det forkert.
Query-hastighed og søgbarhed: når minutter bliver til timer
Query-hastighed er ikke en luksus; det er produktivitet. Når et incident kører, betyder 10 sekunders ventetid pr. søgning hurtigt 30 minutter ekstra. Kig efter feltbaseret søgning, god facettering, og muligheden for at lave saved searches og dashboards.
Test med jeres egne data: typiske fejl, høj volumen, og forskellige tidsvinduer. Vurder også, om platformen kræver fuld indeksering for at være hurtig, eller om den kan søge effektivt uden at indeksere alt. Det sidste kan gøre pris og hastighed mere balanceret.
- Lav 5 standard-queries (fejlrate, latency, en specifik bruger, en deploy, en timeout)
- Mål svartider ved 15 min, 6 timer og 7 dage
- Test concurrency: 3 udviklere der søger samtidig
- Se om query-resultater er forståelige uden “ekspertfilter”
- Kontrollér om sampling skjuler vigtige events
Mini-konklusion: Hurtige queries og gode filtre er ofte mere værd end fancy grafer, fordi de forkorter vejen til en forklaring.
Retention: lovkrav, produktbehov og læring over tid
Retention er hvor længe logs gemmes. Nogle teams kan klare sig med 7–14 dage i varm søgbar storage, mens andre har compliance- eller sikkerhedskrav på 90 dage eller mere. Derudover er der produktlæring: fejl, der kun sker ved månedsskifte, kræver historik.
Tænk i lag: kort retention i “hot” for hurtige queries, og længere retention i “cold” eller arkiv, hvis du sjældent søger i det. Spørg konkret: Hvad koster 30, 90 og 365 dage? Kan arkiv gendannes uden store engangsgebyrer?
Midt i evalueringen kan det være nyttigt at sammenligne pris og retention-modeller hos et logging tool til startups for at se, hvordan event-baseret prissætning og retentionniveauer spiller sammen med jeres vækst.
Mini-konklusion: Retention er et forretningsvalg: den rigtige længde er den, der dækker jeres risici og læringsbehov uden at indeksere alt for evigt.
Alerting: fra støj til signal, og hvem der vækkes kl. 03
Alerting er ofte der, hvor en løsning enten redder jer eller skaber alarmtræthed. En god alarm er handlingsorienteret, har klare thresholds, og peger på næste skridt. Se efter deduplikering, routing (Slack, email, PagerDuty), og muligheden for at knytte alarmer til deploys eller feature flags.
Best practices for alarmer, der ikke spammer
- Start med få, kritiske alarmer: 5xx-rate, latency, queue backlog, login-fejl
- Brug “burn rate” eller tidsvinduer, så spikes ikke giver falske alarmer
- Tilføj runbooks og links til relevante dashboards
- Brug tagging per service/team, så ansvar er tydeligt
Fejl du kan forvente – og hvordan du undgår dem
Den klassiske fejl er at alarmer baseres på rå logcount uden kontekst. En anden er at alarmer ikke tager højde for deploys. Kræv annotationer, og lav en regel: “ingen alarm uden ejer”. Alerting skal reducere reaktionstid, ikke øge støjniveauet.
Mini-konklusion: Den bedste alarm er den, der kun går, når nogen skal handle, og som fortæller dem præcis hvor de skal kigge.
Integrations: hvor godt passer løsningen ind i jeres stack?
Integrations er ikke bare “har de en integration til Kubernetes”. Det handler om, hvor hurtigt I kan skabe en samlet fejlsøgningshistorie på tværs af logs, metrics og traces. Hvis I allerede bruger OpenTelemetry, er det et stærkt signal at vælge noget, der spiller friktionsfrit med det.
Tjek også CI/CD: kan deploys tagges automatisk? Kan du koble en fejl til en commit, en release eller et feature flag? Og kan data sendes videre til jeres data warehouse eller sikkerhedsværktøj uden dyre exports?
Mini-konklusion: Gode integrations sparer tid hver gang der er incident, fordi kontekst følger med – på tværs af værktøjer.
Sikkerhed, compliance og skaleringsbreakpoints: når kravene strammer til
Logdata indeholder ofte persondata, tokens eller interne identifiers. Derfor bør du vurdere adgangskontrol, kryptering, audit logs og data residency tidligt, også selv om du “kun” er 10 personer. Spørg: Har de SSO/SAML? Kan du lave RBAC pr. team? Kan du maskere felter og sikre PII?
Compliance-krav, der typisk rammer startups
GDPR er næsten altid relevant, men også SOC 2 eller ISO 27001 kan blive et salgskrav. Vælg en løsning med klare databehandleraftaler, logning af admin-handlinger og mulighed for slette-/retentionspolitikker. Compliance er nemmest, før du har tusind dashboards.
Skaleringsbreakpoints og hvornår “billigt” bliver dyrt
Breakpoints opstår ofte ved: flere services, højere trafik, længere retention, flere brugere eller når sikkerhedsfeatures bliver nødvendige. En løsning kan være billig ved 5 GB/dag, men dyr ved 200 GB/dag, især hvis alt skal indekseres. Omvendt kan self-hosted være billig ved høj volumen, men dyr i driftstid og on-call.
Mini-konklusion: Kig efter pris- og feature-trin, der matcher jeres næste 12–18 måneder, ikke kun jeres nuværende situation.
Beslutningsmatrix: sådan vælger I med ro i maven
En beslutningsmatrix gør valget mindre mavefornemmelse og mere disciplin. Sæt vægte efter jeres situation: en B2B SaaS med compliance-krav vægter sikkerhed højere end en early prototype. Brug en 1–5 score pr. kriterium, og kræv at alle i teamet scorer uafhængigt før I diskuterer.
- TCO (25%): forbrug, add-ons, overage, egress, driftstid
- Setup-tid (10%): instrumentering, standardfelter, onboarding
- Query-hastighed (15%): svar tid, filterbarhed, concurrency
- Retention (10%): hot/cold, pris pr. periode, restore
- Alerting (10%): routing, dedupe, runbooks
- Integrations (10%): OTel, cloud, CI/CD, data export
- Sikkerhed/compliance (10%): RBAC, SSO, audit, PII masking
- Skaleringsbreakpoints (10%): klare tiers, caps, budget alerts
Scor derefter 2–3 finalister med en simpel testplan: 48 timers prøve, ingestion af rigtige logs, 10 standard-queries, 3 alarmer, og et retention-scenarie. Det vigtigste er, at I kan gentage testen om 6 måneder og stadig få samme konklusion.
Mini-konklusion: En matrix og en kort testplan reducerer risikoen for at vælge ud fra demo-effekt frem for daglig drift.
