Observabilitet inden for hosting: Hvorfor overvågning alene ikke længere er nok

At skelne klart mellem overvågning og observabilitet

Overvågning besvarer først og fremmest på forhånd kendte driftsrelaterede spørgsmål. Det kontrollerer for eksempel, om et websted er tilgængeligt, om et TLS-certifikat snart udløber, om lagerpladsen er ved at løbe tør, eller om andelen af HTTP-5xx-svar overstiger en fastsat værdi. Sådanne kontroller skaber pålidelighed i hverdagen, fordi de omdanner forventede afvigelser til konkrete alarmer.

Observability erstatter ikke disse kontroller, men supplerer dem i tilfælde af uklare fejl. Hvis startsiden svarer med HTTP 200, men enkelte betalingsprocesser tager usædvanligt lang tid, er det afgørende spørgsmål ikke blot, om tjenesten kører. Det handler om, hvad der præcist skete i forbindelse med netop denne forespørgsel, hvilken komponent der tog tid, og hvilken sammenhæng der forklarer afvigelsen.

Forskellen er altså praktisk, ikke begrebsmæssig: En alarm om stigende fejlrater synliggør et symptom, der er relevant for brugeren. Den efterfølgende undersøgelse kræver dog ofte mere kontekst, end en enkelt kurve kan give. God Observerbarhed forbinder derfor signaler i stedet for forhastet at betragte en isoleret måleværdi som årsagen.

De tre telemetriniveauer i hosting

Inden for hosting opstår der relevante signaler på tre niveauer. Infrastrukturen omfatter CPU, RAM, lagringsmedier, netværk samt ressourcer fra virtuelle maskiner (VM’er) eller containere. Dertil kommer trafiklaget med forbindelser, anmodningstider, statuskoder, TLS og adfærden hos reverse proxy eller webserver. Det tredje niveau udgøres af applikationen og dens afhængigheder: for eksempel PHP, database, cache, kø eller en ekstern betalingstjeneste.

Ubetydelige hostværdier er ikke et tegn på en god brugeroplevelse. En databaseforespørgsel, en blokerende session-store eller et langsomt API-kald kan bremse enkelte sider, selvom CPU og RAM viser tilstrækkelig kapacitet. Omvendt er høj CPU-udnyttelse under en kampagne ikke automatisk et problem, så længe forespørgsler behandles hurtigt og succesfuldt inden for det forventede omfang.

Trafiklaget forbinder begge perspektiver. Hos NGINX omfatter den dokumenterede anmodningstid behandlingen fra modtagelsen af den første anmodningsbyte til afsendelsen af den sidste svarbyt. Hvis denne værdi stiger, er det endnu ikke afgjort, om webserveren, applikationen eller upstream er ansvarlig. Den angiver dog på en meningsfuld måde, hvilke anmodninger og tidsperioder der bør undersøges nærmere.

For driftsorganisationen medfører dette en opgaveadskillelse. Symptomorienteret alarmering fokuserer på tilgængelighed, fejlrate eller mærkbar latenstid og giver besked, når der er behov for handling. Ressourcemetrikker, upstream-tider og interne køer understøtter derimod diagnosticering i dashboards eller ved fejlfinding. Prometheus anbefaler denne opdeling, så tilgængelighedsindikatorer ikke overbelastes med rene årsagsindikatorer.

Sammenkæde målinger, logfiler og sporinger

Når man betragter en enkelt HTTP-anmodning, giver de tre telemetrisignaler forskellige perspektiver. Metrikker samler mange processer i tidsbaserede mønstre, såsom ventetid, trafik eller fejlprocent. Logfiler registrerer enkelte hændelser, for eksempel en timeout med en fejlmeddelelse. Traces viser derimod den konkrete forespørgsels vej gennem webserver, applikation, cache, database og eksterne tjenester.

En trace består af spans. Hvert span repræsenterer et trin i processen, såsom udførelse af en controller, cache-adgang, en SQL-operation eller et udgående API-kald, og indeholder tidsoplysninger samt klassificerende attributter. Et sporings-ID forbinder trinene i den samlede forespørgsel, mens et span-ID identificerer den respektive delproces. På den måde kan man se, hvor tiden blev brugt, uden at skulle udlede en årsag ud fra en enkelt måling.

Logs bliver særligt informative, når de er strukturerede og indeholder trace- og span-kontekst. Så kan et team gå direkte fra en langsom trace til fejlmeddelelser, retry-henvisninger eller timeout-hændelser for den samme forespørgsel. Aktiv kontekst kan berige eksisterende logfiler; inden anvendelsen skal det dog kontrolleres, hvilke felter det konkrete kørselsmiljø rent faktisk eksporterer.

En typisk telemetristak ser således ud: Applikation, webserver og infrastruktur genererer data; en collector eller agent modtager dem, filtrerer eller beriger dem; et backend lagrer og visualiserer dem. Fra en alarm fører analysen derefter via en metrik til spor og log. OpenTelemetry tilbyder et åbent rammeværk til dette, men modenhedsgraden varierer: Sporing-Specifikationen, API’et, SDK’en og protokollen betragtes som stabile, mens metrik-SDK’erne kan være på forskellige udviklingsstadier afhængigt af sproget.

Systematisk begrænsning af langsomme betalingsprocesser

En vellykket oppetidskontrol og en startside med HTTP 200 beviser blot, at denne testede rute svarer på dette tidspunkt. Det udelukker ikke, at enkelte indkøbskurve, adressekontroller eller betalingsgodkendelser er langsomme eller mislykkes. For en webshop er den observerede forsinkelse ved kassen derfor sammen med fejlprocenten et fornuftigt udgangspunkt for undersøgelsen.

Først viser tidsserierne, om problemet er koncentreret om et bestemt tidsrum, en rute eller en statusklasse. Hvis for eksempel ventetiden for checkout-anmodninger stiger, og der efterfølgende opstår enkelte fejl, vil der blive oprettet en tilhørende Spor Interessant: Dens spans opdeler den samlede varighed i arbejdsfaser som f.eks. anvendelse, cache, database og eksternt kald. En trace beskriver således forløbet af en konkret forespørgsel, men ikke nødvendigvis dens påviste årsag.

Hvis der f.eks. ses et langt opkald til en betalingstjeneste, fører korrelerede strukturerede logfiler videre. Trace- og span-identifikatorer gør det muligt at søge efter relevante timeout-meddelelser, gentagne forsøg eller fejldetaljer vedrørende den samme forespørgsel. Strukturerede logfiler letter denne automatiske tilknytning, forudsat at den aktive kontekst rent faktisk overføres til de eksporterede logdata.

Tabellen beskriver sammenhænge, ikke årsagssammenhænge. En langsom betalingsperiode kan f.eks. skyldes udbyderen, en netværksfejl, en overbelastet forbindelse eller en genforsøgsadfærd i den egne applikation. Netop eksterne afhængigheder skal derfor vurderes sammen med status, tidsvindue, fejltekst og håndteringen i applikationen.

Indstil konteksten for forespørgsler korrekt

En brugbar minimumskonfiguration starter ikke med så mange felter som muligt, men med pålidelige oplysninger om klassificeringen. Disse omfatter servicenavn, miljø og implementeringsversion samt HTTP-metode og statusklasse. Disse attributter gør det muligt at se, om en forringelse kun vedrører produktionen, en bestemt version eller en enkelt tjeneste; de bør anvendes konsekvent i metrikker, logfiler og sporinger.

Forespørgselskonteksten skal følge vejen fra proxyen til applikationen og derfra til databasen, cachen eller eksterne tjenester. Hvis denne videreformidling ikke allerede findes i den anvendte kombination af proxy, kørselsmiljø og framework, er der behov for yderligere instrumentering. Et synligt spor ved applikationens indgang beviser derfor ikke, at hvert opstrømsopkald eller hver log automatisk kan tilknyttes.

Efter en opdatering af et plugin eller et tema kan en WordPress-side reagere langsommere, selvom host-ressourcerne umiddelbart ser normale ud. I så fald kan webserverdata om anmodningstid og statuskoder sammenlignes med applikationsdata tæt knyttet til PHP og databasetider. I NGINX omfatter den dokumenterede anmodningstid behandlingen fra indlæsning af den første anmodningsbyte til afsendelse af den sidste svarbyte; den lokaliserer dog ikke i sig selv flaskehalsen.

I praksis giver det en kæde, der kan kontrolleres: Har responstiden kun ændret sig efter den nye implementeringsversion, viser bestemte stier længere applikationstid, eller er det først varigheden af enkelte databaseoperationer, der stiger? Hvis man desuden ønsker at indplacere de strukturelle belastnings- og skaleringsgrænser for et CMS, kan man finde artiklen om dette under WordPress' skaleringsgrænser. Telemetrien erstatter ikke denne tekniske vurdering, men leverer konkrete holdepunkter til den.

Det er også vigtigt at være opmærksom på grænserne for standardiseringen: OpenTelemetry betegner tracing-specifikationen, API’et, SDK’et og protokollen som stabile, mens modenhedsgraden for metrik-SDK’er kan variere fra sprog til sprog. Inden en udrulning bør teamet derfor for det pågældende sprog og bibliotek undersøge, hvilke signaler, attributter og kontekstoverførsler der rent faktisk er tilgængelige.

Vurdering af latenstidsmål og databasetider

Serviceindikatorer bør afspejle en målbar egenskab, f.eks. vellykkede checkout-anmodninger inden for et defineret tidsrum eller andelen af fejlbehæftede svar. Herfra kan man udlede et servicemål. En høj CPU-udnyttelse er således en vigtig diagnostisk værdi, men udløser ikke nødvendigvis en eskalering, så længe brugermålene fortsat opfyldes.

Et gennemsnit kan skjule korte og meget langsomme forespørgsler. Et Percentil besvarer et andet spørgsmål: p95 angiver den værdi, som 95 procent af de observerede værdier ligger under. Den er hverken den gennemsnitlige brugeroplevelse eller et bevis på, at alle de øvrige forespørgsler var acceptable. Fejlprocent, trafik og det betragtede tidsvindue er en del af vurderingen.

For latenstider, der er sammenlagt på tværs af flere instanser, gælder Histogrammer ofte hensigtsmæssigt: Buckets kan aggregeres, og der kan ud fra dem beregnes kvantiler som en tilnærmelse. Derimod må forudberegnede kvantiler fra sammenfatninger af forskellige replikater ikke gennemsnitsberegnes, da dette ikke giver et statistisk meningsfuldt samlet kvantil.

Et rent illustrativt mål kunne lyde således: 95 procent af de vellykkede checkout-anmodninger skal tage under 300 millisekunder. Dette indebærer hverken en ydelsesgaranti eller en passende grænseværdi for hver enkelt webshop. Det viser blot tankegangen: Hvis målet ikke nås, hjælper sporinger med at opdele tiden; database-spans kan derefter skelne mellem mistænkelige forespørgselsgrupper og den generelle belastning.

Databasen behøver ikke at være nede for at dette kan være tilfældet. En vellykket sundhedstest og normale CPU-værdier udelukker ikke, at nogle få langsomme forespørgsler dominerer en kritisk sti. Først kombinationen af latenstidsfordeling, andele af sporingstid og fejl- eller ventetidskontekst viser, om det er værd at undersøge en lokal afvigelse, et voksende mønster eller et andet led i forespørgselsforløbet nærmere.

Integration af alarmering og fejlfinding

Alarmregler bør først og fremmest registrere det, som brugerne rent faktisk bemærker: utilgængelige tjenester, stigende 5xx-procenter eller en vedvarende for lang svartid. Sådanne symptomorienterede alarmer giver et klart grundlag for handling. CPU-udnyttelse, køer, ledig plads i filsystemet eller upstream-tider er stadig vigtige, men egner sig ofte bedre til diagnosticering end som den eneste udløsende faktor for en beredskabstilstand.

Ved en ophobning af 502- eller 504-svar begynder undersøgelsen derfor med omfang og tidspunkt: Hvilke ruter, værter, regioner eller implementeringsversioner er berørt? Statuskoden viser blot, at kommunikationen mislykkedes et sted i behandlingsforløbet eller tog for lang tid. Den beviser hverken, at reverse-proxyen fungerer fejlagtigt, eller at applikationen eller en bestemt upstream er årsagen.

I det næste trin hjælper proxy-data såsom anmodningstid, upstream-tid, statusklasse og antal aktive forbindelser med at indsnævre fejlen tidsmæssigt. NGINX dokumenterer for eksempel sin anmodningstid som tidsrummet fra indlæsning af den første anmodningsbyte til afsendelse af den sidste svarbyte. Dette giver et nyttigt overblik over den samlede varighed, men adskiller ikke – uden yderligere data – andele fra applikation, netværk og afhængigheder.

Derefter fører et relevant spor fra modtagelsen af anmodningen til applikationen, cachen, databasen eller en ekstern tjeneste. Strukturerede applikationslogfiler med sporings- og span-kontekst kan her synliggøre timeouts, forbindelsesafbrydelser eller gentagne forsøg. Denne sammenkædning er kun mulig, hvis konteksten videregives via de involverede komponenter, og logudvidelsen rent faktisk er blevet konfigureret.

For driften giver dette en robust fremgangsmåde: Bekræft alarmen ud fra symptomet, indsnæv det berørte antal forespørgsler og tidsvinduet, sammenlign proxy- og ressourceværdier, gennemgå en repræsentativ trace og skift derefter til de tilhørende logfiler. Signaler tæt på årsagen De gør søgningen hurtigere, men erstatter ikke en gennemgang af ændringer, afhængigheder og fejlmeddelelser. Korrelation viser, hvilke observationer der forekommer sammen; den er endnu ikke et bevis på årsagssammenhæng.

En høj serverbelastning under en kampagne kan være normal, mens en enkelt langsom databaseadgang – selvom CPU-belastningen er normal – kan forringe checkout-oplevelsen. Dashboards bør derfor både vise brugerens mål og diagnosekæden. På den måde varetager overvågningen ansvaret for forventede afvigelser, mens korreleret telemetri understøtter undersøgelsen af et konkret fejlbillede.

Styring af datamængde, databeskyttelse og kardinalitet

Når trafikken stiger, giver det sjældent mening at gemme hver eneste forespørgsel permanent som en fuldstændig sporingslog. Prøveudtagning begrænser datamængden og omkostningerne uden helt at opgive analysen. Udvælgelsen skal stå i forhold til risikoen: Fejl, usædvanligt langsomme transaktioner og kritiske forespørgselsforløb er som regel mere værdifulde end en tilfældig, ensartet mængde ubetydelige spor.

Ved tail sampling træffes beslutningen først, når en trace er fuldstændig eller næsten fuldstændig tilgængelig. Derved kan man f.eks. prioritere spor med fejlstatus eller lang varighed. Da dette kræver tilstand og buffer, skal telemetrikomponenten være tilstrækkeligt dimensioneret; overbelastning kan føre til, at data kasseres, og at netop relevante spor mangler.

Collector, agent og eksportvej skal derfor selv indgå i overvågningen. Afgørende faktorer er for eksempel modtagelses- og eksportfejl, køer, forsinkelser samt kasserede data. Hvis disse signaler udbliver, eller hvis datatabet stiger, må et tomt dashboard ikke betragtes som bevis på, at tjenesten fungerer korrekt. Telemetripipeline er en driftsmæssig afhængighed og kræver gennemsigtige grænser.

Dataminimering begynder inden eksporten: Vælg attributter målrettet, kontroller indtastningerne regelmæssigt, og fjern følsomme værdier ved hjælp af filtre, redigering eller transformationstrin. Især overskrifter, cookies, fuldstændige brødtekster og identifikatorer bør underkastes en eksplicit godkendelseskontrol. Selv felter, der umiddelbart virker tekniske, kan indeholde personoplysninger eller fortrolige data.

Når det gælder måleparametre, er der desuden kardinalitet Afgørende: Hver ny kombination af labelværdier genererer endnu en tidsserie. Bruger-, session- eller ordre-id'er er derfor ikke egnede labels. Prometheus anbefaler, at man overvejer en anden datamodel, hvis der er omkring 100 mulige eller kraftigt voksende værdier. I enkelte tilfælde er traces eller strukturerede logs med begrænset opbevaringstid bedre egnet.

Indfør observabilitet på en passende og trinvis måde

Den rette indgang afhænger af arkitekturen og risikoen, ikke af det størst mulige funktionsomfang. Et lille statisk websted drager primært fordel af tilgængelighedstests, overvågning af TLS-udløb, HTTP-status og grundlæggende ressourcer. Fuldstændig applikationssporing medfører i sådanne tilfælde ofte en ekstra arbejdsbyrde uden tilsvarende indsigt.

I et CMS eller en webshop følger der som regel efter basisvisningen en sammenhæng mellem webserver, applikation og database. Først når flere tjenester eller containere samarbejder, bliver en konsistent kontekstoverførsel særligt vigtig for kritiske stier. AWS anbefaler at betragte observabilitet på tværs af applikationer og afhængigheder og at koble tekniske nøgletal sammen med forretnings- og brugermål.

CDN, DNS, betalings-, forsendelses- eller e-mail-tjenester er en del af den faktiske forespørgselsvej, men kan kun kontrolleres i begrænset omfang. Egne spans samt latenstid og fejlkarakteristika kan afsløre, hvornår der var tale om en afhængighed. Dette medfører ikke automatisk en skyldtilskrivning: Netværksforhold, gentagne forsøg, den egne timeout-konfiguration og tjenestestatus skal vurderes samlet. For spørgsmål vedrørende tilgængelighed og routing supplerer artiklen om Multi-CDN-strategier inden for hosting analysen med hensyn til udvælgelse og failover.

En pragmatisk implementering definerer i første omgang nogle få brugerorienterede mål og de tilhørende signaler. Derefter afgrænses datafelter, opbevaring og adgangsrettigheder, inden sporing gradvist indføres for forretningskritiske processer. Stikprøveudtagning er i denne sammenhæng ikke en mangel, men en kontrolleret beslutning, forudsat at fejl- og forsinkelsestilfælde målrettet bevares, og at udvælgelsesprocessen foregår på en gennemsigtig måde.

Observability erstatter hverken en robust arkitektur, test, sikkerhedskopier eller en proces til håndtering af hændelser. Den leverer en kontekst, der muliggør beslutningstagning I forbindelse med disse opgaver: Teams får et bedre overblik over, hvilke brugerforløb der er berørt, hvilke komponenter der bør kontrolleres, og hvilke antagelser der understøttes af data. Fordelen øges med klare spørgsmål og omhyggeligt afgrænset telemetri, ikke ved at indsamle så mange rådata som muligt.