Observability-stack 2026: OpenTelemetry + Grafana + Tempo + Loki

Det finns en vanlig missuppfattning att observability betyder att samla in så mycket data som möjligt. Resultatet blir oftast det motsatta av vad man hoppades: instrumentpaneler fulla av grafer ingen tittar på, loggar i terabyte ingen söker i, och en faktura som växer snabbare än insikterna. Bra observability handlar inte om mängden data, utan om förmågan att ställa en fråga om ditt system och faktiskt få svar. En modern stack 2026 bygger jag ofta på OpenTelemetry, Grafana, Tempo och Loki.

De tre signaltyperna och vad de svarar på

Observability brukar delas in i tre typer av signaler, och poängen är att de svarar på olika frågor.

• Metrics svarar på vad som händer. De är billiga att lagra över tid och perfekta för larm och trender: hur många förfrågningar, hur lång svarstid, hur stor felandel.
• Loggar svarar på vad som hände i ett enskilt fall. När en metric säger att något är fel går du till loggarna, i den här stacken Loki, för detaljerna kring just den händelsen.
• Traces svarar på var i kedjan det hände. I ett system med flera tjänster visar en trace, lagrad i Tempo, förfrågans hela resa, så att du ser vilket steg som var långsamt eller fallerade.

Tillsammans bildar de en arbetsgång: en metric larmar, en trace pekar ut tjänsten, och loggarna ger detaljerna. Var och en för sig är begränsad, men i samspel besvarar de varför systemet beter sig som det gör.

Varför just den här stacken

Det finns dyra allt-i-ett-plattformar, och de är ofta utmärkta. Men för ett team som vill ha kontroll på kostnaden landar jag ofta i en uppsättning öppna verktyg som fungerar väl ihop. Grafana för att visualisera allt på ett ställe, Loki för loggar, Tempo för traces och OpenTelemetry för att samla in på ett leverantörsneutralt sätt. Den kombinationen ger dig hela bilden utan inlåsning.

Det viktiga med OpenTelemetry är att det är en standard, inte en produkt. Du instrumenterar din kod en gång mot den standarden, och kan sedan byta vart datan skickas utan att röra koden. Det är en försäkring mot att fastna hos en leverantör, och något jag rekommenderar att bygga in från början.

Mät det som betyder något

Frågan är inte vad du kan mäta, utan vad som hjälper dig fatta beslut. Jag utgår från det användaren märker och arbetar inåt. För de flesta tjänster är de mest värdefulla måtten trafikvolym, felandel, svarstid och mättnad, alltså hur nära en resurs är sin gräns. Med de fyra kommer du förvånansvärt långt, och de kopplar direkt till de SLO du vill sätta.

Det betyder också att vara disciplinerad med vad du inte mäter, eller åtminstone inte larmar på. En instrumentpanel med femtio grafer är värdelös i en incident eftersom ingen hinner läsa den. Jag föredrar några få paneler i Grafana som svarar på de viktigaste frågorna direkt, och låter detaljerna finnas tillgängliga för den som gräver vidare. Hur observability hänger ihop med tillförlitlighetsmål beskriver jag i min tjänst för DevOps-plattform.

Larm-trötthet är det verkliga hotet

Den största risken med en observability-stack är inte för lite data, utan för många larm. Ett team som väcks av larm som inte betyder något slutar lita på larmen, och då missar de det verkliga problemet när det kommer. Mitt rättesnöre är enkelt: varje larm ska vara handlingsbart och kräva en människa nu. Om ett larm inte leder till handling ska det inte vara ett larm.

• Larma på symptom användaren märker, inte på varje intern fluktuation.
• Sätt trösklar utifrån dina SLO, så att ett larm betyder att budgeten verkligen hotas.
• Behandla varje falsklarm som en bugg och justera eller ta bort regeln.

Kostnad och kvarhållning

Observability kan bli dyrt fort om du inte tänker på hur länge du sparar saker. Detaljerade loggar och högupplösta metrics är värdefulla i stunden men sällan om sex månader. Jag sätter därför olika kvarhållning för olika data: korta tider för detaljerade loggar i Loki, längre för aggregerade metrics som visar trender. På så sätt behåller du förmågan att se historiska mönster utan att betala för att lagra varje rad i evighet.

Relaterat

• SRE light: SLO:er, error budgets och on-call för små team
• Platform Engineering 2026: Backstage vs Port vs Cortex
• GitOps med ArgoCD vs Flux: Vilket passar er K8s-stack?

Vill du se hur en observability-stack satts upp i ett skarpt projekt finns exempel i min casebook.

Vill du ta det vidare?

Om du har massor av data men ändå inte vet varför systemet beter sig som det gör hjälper jag dig att bygga en stack som ger svar. Hör av dig via kontaktsidan.