Dette er de tre søjler i observability. De besvarer forskellige spørgsmål: metrics fortæller dig at noget er galt, logs fortæller dig hvad der skete, og traces fortæller dig i en distribueret flow tiden eller fejlen gik.
Dette er de tre søjler i observability. De besvarer forskellige spørgsmål: metrics fortæller dig at noget er galt, logs fortæller dig hvad der skete, og traces fortæller dig i en distribueret flow tiden eller fejlen gik.
METRICS aggregate numbers over time (counters, gauges, histograms)
→ cheap, low cardinality, great for trends & ALERTING
→ e.g. error rate = 2%, p99 latency = 800ms
LOGS discrete, timestamped events with detail (often structured JSON)
→ rich context for DEBUGGING a specific request
→ e.g. {"level":"error","user":123,"msg":"payment declined"}
TRACES the path of one request across services, with timing per span
→ shows latency BREAKDOWN and where a call fails
→ e.g. checkout 800ms = api 50ms + db 700ms + email 50ms
1. METRIC alerts: "checkout p99 latency jumped to 2s" → you know THERE's a problem
2. TRACE a slow request: 1.8s of 2s is spent in the inventory service
→ you know WHERE it is
3. LOGS of the inventory service at that time: "slow query: missing index"
→ you know WHAT happened
Metrics indsnævrer dig til et symptom og tidsvindue; traces lokaliserer det til en service eller kald; logs giver dig den nøjagtige årsag. At gå direkte til logs uden metrics betyder at søge blindt.
Metrics er aggregeret, så de forbliver billige selv ved større skala — ideelt til altid-tændt dashboards og alerts. Logs og traces er per-event og dyre, så de bliver normalt samplet og forespurgt efter behov under undersøgelse.
Brug af den forkerte søjle spilder tid: du kan ikke alertere effektivt på råloggs (for støjende, for dyrt), og du kan ikke debugge en specifik fejlet request fra en aggregeret metric. Hvis du ved, at metrics detekterer, traces lokaliserer og logs forklarer, giver det dig en hurtig, gentagelig vej fra "noget går galt" til grundårsag.