9.2 Observerbarhet och telemetri

Översikt och motivation

Telemetri är den data ett system sänder ut om sitt eget beteende: de mått, loggar, spår och händelser som samlas in från körande programvara. Övervakning besvarar frågor ni redan visste att ställa utifrån den telemetrin. Är disken full? Ligger felfrekvensen över en tröskel? Är tjänsten uppe? Observerbarhet är bredare. Det är förmågan att ställa nya frågor om ett systems inre tillstånd utifrån, utan att leverera ny kod, så att ni kan förstå beteende ni aldrig förutsåg. När system växer till distribuerade, mikrotjänst- och händelsedrivna arkitekturer är de fel som skadar mest de som ingen såg komma, och observerbarhet är det som låter er felsöka dem. Övervakning talar om att något är fel. Observerbarhet hjälper er ta reda på varför.

För stora team är denna skillnad avgörande. Man kunde förstå en monolit genom att läsa loggar på en maskin. En modern plattform spänner över hundratals tjänster, många team, flera regioner och tredjepartsberoenden, där en enda användarbegäran kan röra dussintals komponenter. Ingen enskild person håller hela systemet i huvudet. Gemensam telemetri av hög kvalitet blir bindväven som låter vilken ingenjör som helst följa en begäran över gränser, linjera symptom över tjänster och resonera om ett system ingen fullt ut äger. Utan den drar incidenter ut, skuld flyger mellan team och rotorsaker förblir dolda.

Företags- och myndighetssystem höjer insatserna med regelefterlevnad, granskningsbarhet och offentlig ansvarsskyldighet. Tillsynsmyndigheter kan kräva belägg för vem som kom åt vad och när. Säkerhetsteam behöver telemetri för att upptäcka intrång. Medborgarvända tjänster måste visa att de uppfyller sina publicerade prestandaåtaganden. God observerbarhet tjänar alla dessa på en gång: den är ett ingenjörsverktyg, en säkerhetskontroll och en ansvarsmekanism i ett. Att standardisera på öppen instrumentering undviker inlåsning hos en enskild leverantörs proprietära agenter, vilket spelar enorm roll när system måste hålla i årtionden och överleva upphandlingscykler.

Se även: kapitel 9.1 (site reliability engineering och SLO:er), kapitel 9.3 (incidenthantering) och kapitel 3.3 (distribuerade system).

Nyckelprinciper

Instrumentera för okända frågor. Designa telemetri så att ni kan undersöka nya fel, bortom de ni förutsåg.
Tre pelare, en berättelse. Mått, loggar och spår är kompletterande vyer. Deras värde multipliceras när de korreleras, inte siloeras.
Strukturera allt. Strukturerad, maskintolkbar telemetri med konsekventa fält slår fritext som bara människor kan läsa.
Korrelera med gemensamma identifierare. Spår- och begärans-ID:n propagerade överallt låter er sy ihop en enda händelse över tjänster.
Larma på symptom, inte orsaker. Larma människor för användarsynliga problem. Låt paneler och undersökning lyfta fram den underliggande orsaken.
Varje larm måste vara åtgärdbart. Ett larm som inte kräver någon mänsklig åtgärd är brus som urholkar förtroende och orsakar trötthet.
Hög kardinalitet är en funktion. Förmågan att skiva per användare, begäran, region och version är det som gör felsökning i produktion möjlig.
Äg din instrumentering. Standardisera på öppen, leverantörsneutral telemetri så att du kontrollerar din data och kan byta backend.

Rekommendationer

Bygg på de tre pelarna och bortom

Mått är numeriska tidsserier, billiga att lagra och idealiska för paneler, trender och larmtrösklar. Loggar är diskreta, tidsstämplade register över händelser, rika på detaljer och väsentliga för kriminalteknisk undersökning. Spår följer en enda begäran när den rör sig genom tjänster och visar latens och beroenden över den distribuerade anropsgrafen. Bortom dessa, överväg händelser (meningsfulla tillståndsändringar som driftsättningar), profiler (var kod lägger CPU och minne) och övervakning av verkliga användare av den faktiska klientupplevelsen. Ingen enskild pelare räcker ensam. Målet är att röra sig flytande mellan dem under en undersökning.

Standardisera på OpenTelemetry och strukturerad loggning

Anta OpenTelemetry som den leverantörsneutrala standarden för att generera och samla in mått, loggar och spår. Den skiljer instrumentering från analysbackenden, så att ni kan byta leverantör utan att omintrumentera hundratals tjänster. Den egenskapen är kritisk för långlivade företags- och myndighetssystem. Sänd ut loggar som strukturerade poster (till exempel JSON) med konsekventa fältnamn för tidsstämpel, allvarlighetsgrad, tjänst och identifierare. Propagera ett spår- eller korrelations-ID från kanten genom varje nedströmsanrop och inkludera det i varje loggrad och måttexemplar, så att de tre pelarna länkas ihop automatiskt.

Designa larmning för åtgärdbarhet och lågt brus

Din larmfilosofi avgör om jour är hållbar. Larma främst på symptom som användare känner, uttryckta som förbränningstakter av SLO (servicenivåmål). Larma när ni bränner genom er felbudget (den tillåtna bristen från det målet) tillräckligt fort för att överskrida den, med flerfönsterlarm på förbränningstakt för att balansera snabb upptäckt mot falska larm. Reservera larmning för problem som behöver omedelbar mänsklig åtgärd och dirigera allt annat till ärenden eller paneler. Rensa bort larm som slår till utan att kräva åtgärd, utan nåd, eftersom larmtrötthet är en ledande orsak till missade verkliga incidenter och jourutbrändhet. Varje larm bör länka till en körbok.

Modellera hälsa med paneler och SLO-övervakning

Bygg paneler kring en tydlig hälsomodell, inte en vägg av varje mått ni har. Ett bra utgångsramverk är de “fyra gyllene signalerna”: latens, trafik, fel och mättnad. Skapa tjänstenivåpaneler som visar SLO-status och återstående felbudget på ett ögonkast, plus paneler på högre nivå som modellerar övergripande system- och användarresehälsa. Kurera dem medvetet, eftersom paneler som visar allt kommunicerar ingenting. Håll dem nära larmen och körböckerna så att de som svarar rör sig snabbt från signal till sammanhang till åtgärd.

Möjliggör felsökning i produktion med hög kardinalitet

De svåraste produktionsproblemen drabbar en smal skiva: en kund, en region, en API-version, en enhetstyp. För att undersöka dem behöver ni telemetri med hög kardinalitet, förmågan att gruppera och filtrera efter fält med många distinkta värden som användar-ID eller begärans-ID. Breda, rikt attribuerade händelser som bär många dimensioner per post låter er ställa godtyckliga frågor i efterhand. Behåll tillräcklig kardinalitet och urvalsfidelitet för att isolera avvikare och föredra exemplarlänkade spår så att en topp i ett mått leder er rakt till representativa långsamma begäranden.

Hantera kostnad, lagring och urval

Telemetrivolymen växer med systemet och kan bli en stor utgift. Sätt lagringspolicyer efter dataklass: behåll högupplöst data kort och aggregat längre. Tillämpa intelligent urval på spår, vinklat mot att behålla fel och långsamma begäranden, så att ni behåller den intressanta svansen utan att betala för varje rutinframgång. Granska er telemetriutgift regelbundet, eftersom ohanterade observerbarhetskostnader kan konkurrera med den infrastruktur de observerar.

Avvägningar: för- och nackdelar

Beslut	Fördelar	Nackdelar
Händelser med hög kardinalitet	Kraftfull felsökning, fråga vad som helst	Högre lagrings- och frågekostnad
Aggressivt urval	Lägre kostnad, mindre brus	Kan missa sällsynta händelser
Symptombaserad larmning	Färre, åtgärdbara larm	Behöver goda SLO:er för att fungera väl
OpenTelemetry-standard	Leverantörsneutral, portabel	Migreringsinsats, mognande verktyg
Lång loggbevarande	Bättre kriminalteknik och revision	Lagringskostnad, integritetsexponering

Observerbarhetsbeslut handlar i grunden om en spänning mellan fidelitet och kostnad. Att fånga allt i full upplösning ger perfekt efterklokhet, men i skala är det oöverkomligt dyrt. Skär aggressivt och ni sparar pengar, men ni kan kasta bort den enda posten som skulle ha förklarat ett avbrott. Urval och lagringsnivåer är hur mogna team går på den linjen, behåller fel och avvikare medan rutindata tunnas ut. Larmavvägningen är mellan känslighet och brus: för många larm orsakar trötthet och missade incidenter, för få låter problem ruttna. Symptombaserad, SLO-driven larmning löser mycket av detta, men bara om ni har meningsfulla SLO:er på plats.

Frågor att diskutera med ditt team

Vad är er plan för att flytta äldre tjänster till OpenTelemetry, och hur undviker ni att betala för två instrumenteringsstackar under övergången? Leverantörsneutral instrumentering är egenskapen som låter er byta backend utan att omintrumentera hundratals tjänster, och den spelar störst roll för de långlivade företags- och myndighetssystem som överlever varje enskilt leverantörsavtal. Migreringen är där goda föresatser stannar av: halvinstrumenterade egendomar lämnar luckor just där en begäran korsar från en ny tjänst till en gammal och bryter spåret från början till slut. Ta med en inventering till diskussionen: vilka tjänster som sänder ut proprietära agentdata, vilka som sänder ut OpenTelemetry och var spårkontext tappas vid gränsen. Avgör en ordning som följer verkliga begäransvägar snarare än organisationsscheman och budgetera för fönstret där ni kör båda insamlarna. Svaret avgör om ni faktiskt äger er telemetri eller förblir inlåsta hos en leverantörs agenter.
När granskade ni senast varje larm för åtgärdbarhet, och hur många larm förra månaden krävde ingen mänsklig åtgärd? Larmtrötthet är en ledande orsak till missade verkliga incidenter och jourutbrändhet, så ett larm som inte behöver någon åtgärd är inte ofarligt brus, det urholkar aktivt det svar ni beror på. Ta med kvittona: dra förra månadens larm, markera vart och ett som åtgärdat eller ignorerat och räkna hur många som mappade till en körbok. För ett stort team som spänner över många tjänster desensibiliserar bullriga larm från ett team den delade jouren för alla. Sätt en standard att varje larm länkar till en körbok och knyts till en SLO-förbränningstakt och radera sedan resten utan nåd. Resultatet av denna revision bör direkt skära er larmvolym och tala om vilka tjänster som saknar en meningsfull SLO bakom sina larm.
Vad är er spårurvalsstrategi, och hur säkra är ni på att den behåller felen och den långsamma svansen? Telemetrivolymen växer med systemet och ohanterad observerbarhetskostnad kan konkurrera med den infrastruktur den observerar, så ni kommer att välja ut, och frågan är om ni väljer ut intelligent. Att skala bort kardinalitet eller välja ut blint tar bort just de poster som behövs för att felsöka de smala problem som drabbar en kund, en region eller en API-version. Ta med era nuvarande lagringsnivåer och urvalsregler: vinklar ni mot att behålla fel och långsamma begäranden, med exemplarlänkade spår så att en måtttopp leder till en representativ långsam begäran? För reviderade och integritetsbundna system, förena lagring med dataminimeringsregler så att ni inte hamstrar personuppgifter för att felsöka. Svaret avgör var ni spenderar telemetribudget och om ert nästa svåra avbrott är förklarbart eller ett mysterium.
Vilka av era SLO:er är verkliga åtaganden för användarresor, och vilka är proxymått ingen utanför det ägande teamet tror på? Symptombaserad larmning fungerar bara när symptomen mappar till saker användare faktiskt känner, så ett larm kopplat till en CPU-tröskel eller ett påhittat tillgänglighetsmål larmar människor för problem som kanske inte spelar roll medan det förblir tyst på de som gör det. För en stor organisation är SLO:er också kontraktet som låter oberoende team dela en jourrotation utan att omförhandla allvarlighetsgrad under varje incident. Ta med den nuvarande SLO-katalogen, den användarresa varje mål är avsett att skydda och förra kvartalets överskridanden med huruvida kunder faktiskt klagade. I företags- och myndighetssammanhang, knyt de mest synliga SLO:erna till de publicerade prestandaåtaganden tjänsten hålls till, så att samma förbränningssignal som larmar en ingenjör också är de belägg ni visar en tillsynsmyndighet eller ett tillsynsorgan. Diskussionen bör avveckla proxymåtten och lämna er med en kort lista över mål som en icke-ingenjör skulle känna igen som löften till användare.
Vem äger styrningen av telemetridata, och kan ni bevisa att personuppgifter redigeras bort innan de landar i er observerbarhetsbackend? Händelser med hög kardinalitet och lång loggbevarande är just de funktioner som gör felsökning möjlig, och just de som förvandlar ett observerbarhetslager till en ohanterad kopia av era användares personuppgifter. Det konkurrerande draget är verkligt: ingenjörer vill ha rikare attribut och längre lagring, medan integritet och juridik vill ha dataminimering och korta livslängder. Ta med en dataflödeskarta som visar vilka fält som bär personuppgifter eller känslig data, var redigering eller tokenisering sker i pipelinen och vilka era lagringsnivåer är per dataklass. För reglerade och offentliga system, namnge den ansvariga ägaren, mappa lagring mot den rättsliga grunden och de dataminimeringsregler ni verkar under och var redo att visa en revisor att åtkomst till själva telemetrin loggas och kontrolleras. Svaret avgör om er observerbarhetsplattform är en tillgång eller ett stående intrång som väntar på att upptäckas.
När en incident korsar flera teams tjänster, låter er telemetri en enda som svarar följa begäran från början till slut, eller bryts spåret vid varje ägarskapsgräns? Hela löftet med korrelerad, ID-propagerad telemetri är att en enda ingenjör kan resonera om ett system ingen fullt ut äger, och det löftet kollapsar just vid gränsen där spårkontext tappas eller där två team använder inkompatibla identifierare och verktyg. Väg dragningen mot autonomi per team vid val av observerbarhetsverktyg mot den gemensamma kostnaden för en fragmenterad egendom där varje överlämning är en återvändsgränd under ett avbrott. Ta med en nylig tidslinje för en incident över flera team och markera var den som svarade tappade tråden, plus en inventering över vilka tjänster som propagerar ett gemensamt korrelations-ID och vilka som inte gör det. För ett stort företag eller en myndighetsplattform sammansatt av många leverantörer och långlivade system, avgör hur mycket ni centralt påbjuder, en gemensam spårkontextstandard och ett gemensamt ID-schema, mot vad ni lämnar till team, eftersom de komponenter ni återupphandlar under årtionden ändå måste samverka på samma begäran. Svaret talar om för er om er nästa incident över flera team blir en samordnad undersökning eller en omgång fingerpekande.

Sektorsperspektiv

Startup. Med en handfull tjänster och inga lediga händer, instrumentera med OpenTelemetry från dag ett och leverera strukturerade JSON-loggar som bär ett begärans-ID från början till slut. Den lilla investeringen förvandlar “appen är långsam” till ett spår du kan läsa, och den håller dig fri att flytta från en gratisnivå till en betald backend senare utan att omintrumentera. Hoppa över genomarbetade paneler och SLO-maskineri tills du har användare vars upplevelse du faktiskt kan mäta.

Småföretag. Du har ingen observerbarhetsspecialist och en snäv budget, så lita på en hanterad backend där instrumentering, lagring och paneler kommer ihop i stället för att sätta ihop din egen stack. Köpa-mot-bygga-valet gynnar att köpa nästan varje gång här. Din knappa uppmärksamhet är bättre använd på de två eller tre larmen på gyllene signaler som talar om att tjänsten ligger nere än på att driva en telemetripipeline. Sätt en hård lagringsgräns så att telemetrikostnaden inte i tysthet kan gå om den infrastruktur den bevakar.

Storföretag. Arbetet är styrning över många team: en gemensam OpenTelemetry-standard, ett gemensamt korrelations-ID-schema och kurerade SLO-paneler så att en enda som svarar kan följa en begäran över dussintals tjänster. Hantera telemetri som en kostnadsställe med lagringsnivåer och urvalspolicy, standardisera larmning på SLO-förbränningstakter för att hålla en gemensam jour hållbar och rensa bullriga larm centralt så att ett teams trötthet inte desensibiliserar alla. Behandla instrumenteringslagret som leverantörsneutral infrastruktur som överlever varje enskilt backendavtal.

Offentlig sektor. Upphandlingsregler, transparens och offentlig ansvarsskyldighet formar designen. Standardisera på öppen instrumentering så att ett system som förväntas köras i årtionden överlever återupphandling av olika leverantörer utan att hållas gisslan av proprietära agenter och kräv den portabiliteten i avtalet. Använd strukturerade revisionsloggar för att visa vem som kom åt vilken post och när, redigera bort eller tokenisera personuppgifter innan de når telemetrilagret och förena lagring med dataminimeringslagstiftning. Publicera SLO-paneler för medborgarvända tjänster så att samma signaler era ingenjörer bevakar är synliga belägg för de åtaganden ni hålls till.

Exempel

Startup. Ett startup på fyra personer levererar en mobil backend och får ständigt vaga klagomål om att “appen är långsam” som det inte kan reproducera. Teamet lägger till OpenTelemetry i sin handfull tjänster och byter till strukturerade JSON-loggar med ett begärans-ID som bärs från appen genom varje hopp. Nästa rapport om långsamhet löses på minuter: ett spår visar ett saknat databasindex på ordertabellen under en specifik fråga. Eftersom de valde öppen instrumentering tidigt flyttar de senare från en gratisnivå till en betald backend utan att omintrumentera något.

Storföretag. En stor e-handelsplattform instrumenterar varje tjänst med OpenTelemetry och propagerar ett spår-ID från kundens webbläsare genom kassa, betalning, lager och leverans. När konverteringen sjunker startar en jourhavande ingenjör från ett SLO-förbränningslarm, öppnar kassans gyllene signaler på panelen, upptäcker förhöjd latens i en region och följer ett exemplarspår till ett långsamt databasanrop i en enda tjänst. Attribut med hög kardinalitet visar att problemet är begränsat till en produktkategori, vilket vägleder en riktad rättelse på minuter snarare än timmar.

Offentlig sektor. En nationell hälso- och sjukvårdstjänst driver en patientjournalplattform under strikta revisions- och integritetsregler. Strukturerade loggar fångar vem som kom åt vilken post och när och matar både säkerhetsövervakning och regelefterlevnadsrapportering, medan personidentifierande fält redigeras bort eller tokeniseras i telemetri. Publika SLO-paneler visar tillgänglighet och latens för medborgarvänd tidsbokning. Genom att standardisera på öppen instrumentering undviker myndigheten proprietär inlåsning över ett system som förväntas köras i årtionden och återupphandlas av olika leverantörer under sin livstid.

Affärsnytta: motiv, ROI och TCO

Den främsta avkastningen på observerbarhet är en dramatisk minskning av tiden det tar att upptäcka och lösa incidenter. För en tjänst där avbrott är kostsamma betalar en minskning av genomsnittlig tid till lösning från timmar till minuter verktygen många gånger om i en enda stor incident. Observerbarhet sparar också den ingenjörstid ni annars skulle lägga på att gissa, reproducera buggar och bråka om vilket team som har fel, och den förkortar den återkopplingsslinga som låter team leverera med tillförsikt. Säkerhets- och regelefterlevnadsvärdet är också verkligt: samma telemetri stöder intrångsupptäckt och revisionsbelägg.

Total ägandekostnad inkluderar instrumenteringsinsats, telemetrilagrings- och frågekostnader och disciplinen att kurera signal ur brus. Dessa kostnader är synliga och återkommande, vilket frestar ledningen att underinvestera. Kostnaden för att inte anta är större men svårare att se: utdragna avbrott, odiagnostiserade prestandaproblem, säkerhetsincidenter som upptäcks sent eller aldrig och ingenjörer som bränner ut sig på larm de inte kan göra något åt. Driv ärendet med konkret incidentdata. Visa lösningstiden och affärspåverkan av nyliga avbrott och projicera den minskning bättre telemetri skulle leverera. Att ramma in observerbarhet som en försäkring som också snabbar upp leverans, snarare än som ett rent kostnadsställe, vinner argumentet.

Antimönster och fallgropar

Larma på allt. Att larma för varje avvikelse lär de som svarar att ignorera larm, så verkliga incidenter slinker igenom.
Orsaksbaserad larmning. Att larma på interna orsaker snarare än användarsymptom översvämmar jouren med brus och missar nya fel.
Ostrukturerade loggar. Fritextloggar som inte kan frågas eller korreleras tvingar fram långsamt, manuellt greppande under incidenter.
Tre siloerade pelare. Mått, loggar och spår i frånkopplade verktyg utan gemensamma ID:n hindrar att en händelse följs från början till slut.
Panelspridning. Hundratals okurerade paneler betyder att ingen vet vilken som visar om systemet är friskt.
Kardinalitetskollaps. Att skala bort fält med hög kardinalitet för att spara kostnad tar bort just den data som behövs för att felsöka smala problem.
Leverantörsinlåsning. Proprietära agenter överallt gör byte av backend oöverkomligt dyrt och håller er data som gisslan.

Mognadsmodell

Nivå 1, Initiera. Observerbarhet är ad hoc och reaktiv. Grundläggande drifttidskontroller och ostrukturerade loggar bor på enskilda maskiner, felsökning betyder att logga in på servrar för att greppa och det finns ingen gemensam telemetri. Larm är bullriga, orsaksbaserade och ofta ignorerade, så verkliga incidenter dyker upp genom användarklagomål snarare än signaler.

Nivå 2, Utveckla. Grundläggande praxis dyker upp men varierar per team. Vissa tjänster skickar mått och loggar till en central plats, några paneler och tröskellarm finns, men loggar är bara halvstrukturerade och spår saknas eller är partiella. Korrelation över tjänster är manuell, och om en ingenjör kan följa en begäran från början till slut beror på vilka team som råkar vara inblandade.

Nivå 3, Standardisera. Instrumentering är dokumenterad och upprätthållen i hela organisationen. OpenTelemetry över tjänster med ett propagerat spår- eller korrelations-ID, strukturerad loggning med konsekventa fältnamn, distribuerad spårning, kurerade paneler med gyllene signaler och SLO-baserad symptomlarmning är standarden varje team följer. Varje larm länkar till en körbok och knyts till en SLO, och jour är hållbar snarare än en källa till utbrändhet.

Nivå 4, Hantera. Själva observerbarhetsegendomen mäts och styrs mot utgångslägen. Ni följer instrumenteringstäckning och andel propagerad spårkontext över tjänster, andelen larm som åtgärdades mot ignorerades, genomsnittlig tid till upptäckt och lösning, SLO-uppfyllnad och felbudgetförbränning samt telemetrikostnad per tjänst mot en budget. Luckor och larmbrus drivs ned med data mot uttryckliga mål, urvalsfidelitet verifieras så att fel- och långsamma-svansposterna överlever, och beslut att gå eller inte gå om täckning och lagring fattas på belägg snarare än åsikt.

Nivå 5, Orkestrera. Observerbarhet förbättras kontinuerligt och är integrerad i hela organisationen. Händelserik telemetri med hög kardinalitet möjliggör ad hoc-undersökning av vilken skiva som helst, larmning är SLO-förbränningsdriven med minimalt brus och urval och lagring anpassas till ändrad kostnad och risk. Telemetri matar kapacitetsplanering, säkerhetsupptäckt och produktbeslut som rutin, och plattformen justerar om sina egna signaler, budgetar och täckning när systemet, hotbilden och de regulatoriska skyldigheterna skiftar.

Idéer för diskussion

Var går den rätta balansen mellan telemetrifidelitet och kostnad för era mest kritiska tjänster?
Hur avgör ni vad som förtjänar ett larm mot ett ärende mot endast en panelpost?
Vad är er strategi för att propagera korrelations-ID över team som inte delar kodbas eller releasecykel?
Hur bevarar ni felsökningskraften hos hög kardinalitet samtidigt som ni uppfyller integritets- och dataminimeringskrav?
Bör observerbarhetsverktyg påbjudas centralt eller väljas per team, och vilka blir konsekvenserna åt båda hållen?
Hur skulle ni visa för revisorer att er telemetri är fullständig och manipuleringssäker?

Viktigaste punkter

Övervakning upptäcker kända problem. Observerbarhet låter er undersöka okända utan att leverera ny kod.
Mått, loggar och spår är mest värdefulla när de korreleras genom gemensamma identifierare, inte siloeras.
Standardisera på OpenTelemetry och strukturerad loggning för att förbli leverantörsneutral och portabel över långa systemlivstider.
Larma på användarsynliga symptom via SLO-förbränningstakter, gör varje larm åtgärdbart och rensa brus obevekligt.
Kurera paneler kring en tydlig hälsomodell som de gyllene signalerna i stället för att visa varje mått.
Händelserik telemetri med hög kardinalitet är det som gör felsökning av smala produktionsproblem möjlig.

Referenser och vidare läsning

Charity Majors, Liz Fong-Jones, George Miranda, Observability Engineering: Achieving Production Excellence
Cindy Sridharan, Distributed Systems Observability
Betsy Beyer et al., Site Reliability Engineering (chapters on monitoring and alerting)
Brendan Gregg, Systems Performance: Enterprise and the Cloud
OpenTelemetry project, specification and documentation (Cloud Native Computing Foundation)
Google, The Four Golden Signals (Site Reliability Engineering, monitoring chapter)