Loggning & övervakning

Från ”det fungerar inte” till ett undersökningsbart fel

Ett distribuerat fel kan finnas i klienten, nätverket, brokern, API:t eller lagringen. Observerbarhet handlar om att använda synliga signaler för att förstå vad som händer inne i systemet. Börja med frågor: vad hände, när, var, hur ofta och hur långsamt?

Loggar, mätetal och nätverksspår kompletterar varandra. Ingen enskild vy bevisar att hela kedjan fungerar. Samla signaler vid flera tjänstegränser och jämför samma tidsperiod.

• Logg: beskriver en specifik händelse och dess sammanhang.
• Mätetal: visar mängd, frekvens och tidsåtgång över tid.
• Nätverksspår: visar vad som passerade ett fångat nätverksgränssnitt.

Skriv loggar som går att söka i

Strukturerade loggar använder konsekventa fältnamn, exempelvis JSON, så att du kan filtrera på händelse, nivå, statuskod eller request_id. En tidsstämpel gör det möjligt att jämföra händelser mellan komponenter. Ange enhet för tidsmått, som duration_ms.

I exemplet avvisar API:t en ogiltig mätning. Loggen visar tid, orsak, status och hur lång tid behandlingen tog. WARNING beskriver betydelsen av händelsen; nivån är inte bara en färg i terminalen.

• DEBUG: tillfälliga detaljer för diagnos.
• INFO: en normal händelse, till exempel accepterad mätning.
• WARNING: en avvikelse, till exempel avvisad ogiltig indata.
• ERROR: ett begärt arbete misslyckades.

{
  "timestamp": "2026-09-22T08:21:04.123Z",
  "level": "WARNING",
  "event": "reading_rejected",
  "request_id": "lab-invalid-1",
  "status": 400,
  "duration_ms": 0.42,
  "reason": "value must be a positive number"
}

Låt samma ID följa förloppet

Klienten kan skicka ett korrelations-ID, eller servern kan skapa ett. Samma ID returneras och loggas så att klientens anrop kan kopplas till serverns behandling. Dokumentera hur ID:t överförs i just ert API-kontrakt.

Sök på lab-invalid-1 för att hitta båda sidorna av exempelförloppet. ID:t är till för att hitta samband, inte för att bevisa behörighet. Det ska varken vara ett lösenord eller innehålla persondata.

Klient skickar: request_id = lab-invalid-1
API loggar:     request_id = lab-invalid-1, status = 400
Klient tar emot samma ID i svaret

Välj mätetal utifrån frågan

Samla inte ett mätetal bara för att det är enkelt att samla. Utgå från det du behöver avgöra i drift och bestäm vad värdet betyder. En räknare för accepterade mätningar säger något annat än en räknare för skapade sensorhändelser.

En dashboard kan visa utvecklingen över tid. När valideringsfelen ökar använder du loggarna för att undersöka enskilda avvisade anrop. När svarstiden stiger jämför du med belastning och ködjup i samma tidsintervall.

• Kommer data fram? Räkna accepterade mätningar.
• Avvisas indata? Räkna valideringsfel.
• Är tjänsten långsam? Mät svarstid i millisekunder.
• Tappar enheten kontakt? Räkna återanslutningar.
• Växer kön? Följ aktuellt och maximalt ködjup.

Jämför signalerna och gör felet reproducerbart

Tänk dig att klienten inte får någon ny mätning. Börja med att avgränsa tidsintervallet och hitta ett korrelations-ID. Kontrollera klientens och serverns loggar, jämför räknarna och granska vid behov nätverksspåret. Ett nätverksspår visar trafik, men krypterad payload kan inte läsas som vanlig klartext.

Som övning kan du skicka en ogiltig mätning och jämföra klientens svar, serverns logghändelse och förändringen i räknaren för valideringsfel. Det här arbetssättet gör kursens mål om en reproducerbar felsökningsguide konkret.

• Beskriv symtom, testmiljö och förutsättningar.
• Spara exakt indata och stegen som utlöser felet.
• Ange förväntat respektive observerat resultat.
• Bifoga relevanta tidsstämplar, ID:n och mätetal före och efter.
• Dokumentera åtgärden och hur återställd funktion verifierades.

Logga utfallet, skydda hemligheterna

Logga tid, klientidentitet när det behövs, operation eller topic och om utfallet godkändes eller nekades. Lösenord, access-token och privata nycklar ska inte hamna i loggen. Undvik också onödig persondata, hela certifikat i varje händelse och obegränsad sensordata utan tydligt syfte och lagringstid.

Bestäm varför uppgifterna behövs och hur länge de ska sparas. Bifoga minsta relevanta bevis i felsökningsguiden och kontrollera att varken loggar eller nätverksspår sprider hemligheter.

Tidsstämplar och en klocka för tidsåtgång

Använd UTC, skriv ut tidszonen och håll samma tidsformat i alla komponenter. Z i 2026-09-22T08:21:04.123Z betyder UTC. Synkronisera enheternas klockor för att kunna jämföra klientens och serverns händelser.

Mät duration med en monoton klocka, som ett tidtagarur, mellan tydliga start- och slutpunkter. Väggklockan kan justeras vid tidssynkronisering eller manuellt, och lokal tid påverkas av tidszon och sommartid. En monoton klocka skyddar tidsmätningen mot sådana hopp.

timestamp   → När inträffade händelsen? UTC med tidszon.
duration_ms → Hur lång tid tog arbetet? Monoton sluttid − starttid.

Räknare, mätare och duration

Från föregående del känner du igen tasks som producerar händelser, timers som startar arbete och en kö som skiljer produktion från publicering. Räknare och anslutningshändelser hjälper oss att se återanslutningar och bortfall. Nu behöver varje mätetal också en tydlig definition.

En räknare ökar när något händer, exempelvis requests_total. En mätare visar ett aktuellt tillstånd som kan gå både upp och ned, exempelvis queue_depth. Duration anger tidsåtgången mellan bestämda start- och slutpunkter.

En omstart kan nollställa processens räknare. Visa därför uptime eller starttid i dashboarden. En lägre total efter en omstart betyder inte att tidigare anrop har försvunnit.

Skilj total, feltakt och felandel

Totalen sedan start saknar tidskontext. Feltakt anger hur snabbt nya fel tillkommer: förändringen i antalet valideringsfel delad med förfluten tid. Felandel anger hur stor del av de relevanta anropen som var felaktiga under samma mätintervall.

Om 12 av 240 anrop avvisas under 60 sekunder är feltakten 0,2 fel per sekund och felandelen 5 procent. Ange alltid mätintervall, enhet och vilka anrop som ingår i nämnaren. Blanda inte räknarvärden från före och efter en omstart.

Feltakt  = Δ valideringsfel / Δ tid = 12 / 60 = 0,2 fel/s
Felandel = valideringsfel / relevanta anrop = 12 / 240 = 5 %
Båda beräkningarna avser samma 60 sekunder.

Medelvärde kan dölja långsamma anrop

Svarstiderna 10, 11, 12, 13 och 500 ms ger medelvärdet 109,2 ms och maxvärdet 500 ms. Medelvärdet ensamt visar inte att ett av fem anrop tog mycket längre tid än de andra.

Visa åtminstone antal mätningar och enhet tillsammans med tidsintervallet. Maxvärdet synliggör en topp men beskriver inte hela fördelningen. Percentiler är en möjlig fördjupning när du vill undersöka hur svarstiderna fördelar sig.

Dashboarden är en vy av samma mätetal

I presentationens flöde går mätetal från tjänsten via /api/metrics till dashboarden och vidare till verktyg eller människa. Alla vyer behöver använda samma definitioner av exempelvis accepterade anrop, valideringsfel och svarstid.

Gör uppdateringsintervallet synligt. En tom panel behöver inte betyda noll fel eller noll trafik: insamlingen eller hämtningen kan ha misslyckats. Kontrollera datakällan innan du drar slutsatser om tjänstens tillstånd.

Tjänst → /api/metrics → Dashboard → Verktyg eller människa

Demons roller, trafikfilter och TLS

Terminal 1 kör servern eller gatewayen med logg och mätetal. Terminal 2 kör en simulerad sensorenhet. En valfri tredje terminal observerar nätverkstrafiken passivt. Roller och insamlingspunkter behöver vara tydliga när du jämför bevis.

Ett capture filter begränsar vilken trafik som samlas in. Ett display filter begränsar vilken del av den redan insamlade trafiken som visas. I demon avgränsar port 8090 trafiken från annan trafik; byt port om din tjänst använder en annan.

Med TLS kan observatören normalt se IP-adresser, portar, tidpunkter, paketstorlekar och att en anslutning upprättas. HTTP- eller MQTT-nyttolast, headers och topic inne i tunneln samt sensorvärden och token skyddas. HTTP-filtret visar därför inte automatiskt HTTP-innehållet i en krypterad anslutning.

Capture filter: tcp port 8090
Display filter: tcp.port == 8090 && http