Systemet virker. Indtil det ikke gør
Forestil dig en webshop, hvor kunder kan gennemse produkter, lægge dem i kurven og gå videre til betaling. Serveren svarer, siden åbner, og de grundlæggende infrastrukturmålinger viser intet alvorligt problem. Umiddelbart ser alt ud til at fungere korrekt.
Samtidig kan en del af kunderne ikke gennemføre deres ordre. For nogle tager betalingen flere sekunder, for andre opstår der en fejl. Det tekniske team modtager henvendelser, men ved endnu ikke, om årsagen er betalingsgatewayen, databasen, den seneste opdatering af applikationen eller måske et problem i kommunikationen mellem tjenesterne.
Det er en situation, hvor almindelig overvågning kan vise sig utilstrækkelig. Den kan pege på, at antallet af fejl er steget, eller at svartiden er blevet længere, men den giver ikke altid de oplysninger, der er nødvendige for hurtigt at finde årsagen.
Det er netop dette hul, observability – altså systemets observerbarhed – adresserer. Dets mål er ikke kun at fastslå, at applikationen ikke fungerer korrekt. Det handler om muligheden for at analysere dens adfærd, genskabe hændelsesforløbet og finde kilden til problemet, også når man på forhånd ikke har forudset et bestemt fejlscenarie.
Overvågning og observability - lignende mål, forskellige muligheder
Overvågning og observability er tæt forbundne, men betyder ikke det samme.
Overvågning handler om systematisk indsamling og analyse af data om applikationens og infrastrukturenes tilstand. Det gør det muligt at følge bestemte parametre, opdage afvigelser fra fastsatte normer og udløse alarmer, når der opstår en situation, som kræver handling.
Eksempler på spørgsmål, som overvågning besvarer, er:
- Er serveren tilgængelig?
- Hvad er API'ets gennemsnitlige svartid?
- Overskrider antallet af HTTP 500-fejl den fastsatte grænse?
- Hvad er forbruget af hukommelse og processor?
- Vokser opgavekøen hurtigere, end systemet kan nå at behandle den?
Observability går videre. Det gør det muligt at analysere data fra forskellige dele af systemet og forbinde dem i en kontekst, som hjælper med at forstå, hvorfor en bestemt adfærd opstod.
Det kan sammenfattes i tre spørgsmål:
- Overvågning: Er der noget galt?
- Diagnostik: Hvor opstod problemet?
- Observability: Hvad skete der, hvorfor, og hvad var påvirkningen på systemets drift?
Observerbarhed erstatter ikke overvågning. Det er en tilgang, der bruger overvågning og korrekt forberedte telemetridata til at muliggøre dybere analyse af applikationens adfærd. OpenTelemetry beskriver observability som muligheden for at stille systemet spørgsmål om dets adfærd på basis af signaler som logs, metrics og distributed traces. <Cite ref="turn154932search0"/>
Observabilitys tre søjler: logs, metrics og tracing
Grundlaget for observerbarhed er tre typer telemetridata: logs, metrics og traces. Hver af dem viser et forskelligt aspekt af applikationens drift. Først når de korreleres, får man et bredere billede af situationen.
1. Logs - hvad skete der i applikationen?
Logs er strukturerede registreringer af hændelser genereret af applikationen, operativsystemet, servere, databaser og andre elementer i infrastrukturen.
De kan for eksempel registrere:
- start og afslutning af en proces,
- et forsøg på at logge ind som bruger,
- afsendelse af en forespørgsel til et eksternt API,
- en fejl i datavalidering,
- en mislykket transaktion,
- en undtagelse udløst af applikationen,
- en ændring i ordrestatus.
En log kan indeholde tidsstempel, alvorlighedsgrad, tjenestens navn, besked, forespørgsels-id samt yderligere attributter, der beskriver hændelsen.
Det er værd at skelne mellem tekstlogs og strukturerede logs. En tekstregistrering kan se sådan ud:Fejl under behandling af ordren
En sådan besked informerer om, at der er opstået et problem, men siger ikke meget om konteksten. En struktureret log kan derimod indeholde separate felter som ordre-id, operationsnavn, fejlkode, udførelsestid og trace-id. Det gør det muligt automatisk at filtrere, gruppere og analysere dataene.
God praksis: logs bør designes med henblik på senere analyse og ikke kun til at gemme beskeder. Det er en god idé at bruge konsekvent navngivning, alvorlighedsniveauer og korrelations-id'er, som gør det muligt at forbinde hændelser fra forskellige komponenter.
Samtidig kræver logging omtanke. Hvis man registrerer hver eneste operation i fuldt omfang, kan det generere enorme datamængder, øge lagringsomkostningerne og gøre det sværere at finde de væsentlige oplysninger. Lige så vigtigt er det, at logs ikke må afsløre adgangskoder, adgangstokens, betalingskortdata eller andre fortrolige oplysninger. Man bør anvende maskering, adgangskontrol, passende opbevaringsperioder og regler for sikker databehandling.
2. Metrics - hvordan opfører systemet sig over tid?
Metrics er aggregerede numeriske data, der beskriver systemets tilstand, ydeevne og adfærd over en bestemt periode.
Eksempler på metrics omfatter:
- antallet af forespørgsler behandlet i sekundet,
- andelen af forespørgsler afsluttet med fejl,
- API'ets svartid,
- CPU- og hukommelsesforbrug,
- antallet af aktive sessioner,
- længden af opgavekøen,
- antallet af afsluttede transaktioner,
- ventetiden på forbindelse til databasen.
Deres største fordel er muligheden for at observere tendenser. En enkelt fejl kan være en hændelse, men en gradvist stigende svartid, et voksende antal mislykkede transaktioner eller en tiltagende opgavekø kan pege på et problem under udvikling.
I praksis hjælper metrics ikke kun med at besvare spørgsmålet om, hvorvidt applikationen virker, men også om dens ydeevne lever op til brugernes forventninger og forretningens krav.
Især er svartidspercentiler som p95 og p99 nyttige. Gennemsnittet kan skjule en situation, hvor størstedelen af brugerne får svar hurtigt, men en lille del oplever meget store forsinkelser. Percentiler viser, hvor lang tid de langsommere forespørgsler tager at behandle, og hjælper med at afsløre problemer, der ikke er synlige i gennemsnitsværdierne.
God praksis: vælg metrics, der har betydning for brugeren og forretningsprocessen. Oplysningen om CPU-belastning alene fortæller ikke, om kunden kan gennemføre en ordre. Det er derfor også værd at overvåge indikatorer knyttet til de vigtigste funktioner, såsom betalingssucces, ordrebehandlingstid eller tilgængeligheden af de vigtigste handlinger.
3. Tracing - hvor gik forespørgslen hen?
Tracing, og især distributed tracing, altså sporbarhed på tværs af systemet, gør det muligt at følge et enkelt forespørgsels vej gennem forskellige komponenter i systemet.
I en moderne applikation kan en brugerhandling omfatte mange trin. Et klik på knappen „Gennemfør ordre” kan udløse en forespørgsel i browseren, som sendes til API'et, videre til ordreservicen, databasen, lagersystemet og den eksterne betalingsudbyder.
Hvis processen forsinkes, er information om hele API'ets svartid måske ikke nok. Tracing gør det muligt at opdele denne tid i enkelte operationer og se, hvilket trin der forårsager forsinkelsen.
Det grundlæggende element i et spor (trace) er en span, altså en registrering af en enkelt operation. En span kan indeholde start- og sluttidspunkt, navnet på operationen, status og metadata. Forbundne spans danner et spor, der viser forløbet af hele forespørgslen.
For eksempel:
- API'et modtager forespørgslen og sender den videre.
- Ordreservicen validerer dataene.
- Databasen gemmer ordren.
- Lagerservicen kontrollerer produktets tilgængelighed.
- Den eksterne betalingsgateway behandler transaktionen.
- Applikationen returnerer resultatet til brugeren.
Hvis hele processen tager 8 sekunder, kan tracing vise, at 6,5 sekunder blev brugt på svar fra den eksterne betalingsgateway, mens de øvrige operationer forløb korrekt. Teamet får dermed et konkret udgangspunkt for den videre analyse i stedet for at begynde fejlsøgningen med tilfældige komponenter.
Tracing er især nyttigt i mikroservicearkitekturer, distribuerede systemer, applikationer baseret på køer og løsninger, der integrerer mange eksterne tjenester. <Cite ref="turn154932search0"/>
Alarmer - informationen skal nå den rigtige person
Telemetridata er kun nyttige, når man kan handle på baggrund af dem. Derfor er et alarmsystem en vigtig del af observability.
En alarm er en besked om en hændelse eller tilstand, som kræver opmærksomhed. Den kan udløses, når en metrik overskrider en tærskel, når et bestemt mønster af fejl opdages, eller når det konstateres, at en vigtig funktion i applikationen ikke fungerer som forventet.
Ikke enhver stigning i belastning bør dog generere en alarm. Hvis systemet regelmæssigt håndterer høj trafik i myldretiden, vil en besked om hver stigning i antallet af forespørgsler skabe støj. For mange alarmer fører til, at de ignoreres, og dermed til, at en reelt vigtig hændelse overses.
Det er derfor værd at fastlægge:
- hvilke hændelser der kræver øjeblikkelig reaktion,
- hvilke problemer der kan analyseres i den normale driftstilstand,
- hvem der er ansvarlig for den konkrete type alarm,
- hvilke oplysninger en alarm bør indeholde,
- hvilke handlinger der skal foretages efter modtagelsen.
Et godt udgangspunkt er at definere alarmer ud fra påvirkningen på brugeren og pålidelighedsmålene, ikke kun ud fra infrastrukturparametre. For eksempel kan en alarm om en stigende andel mislykkede betalinger have større forretningsmæssig betydning end et kortvarigt hop i CPU-forbruget.
En alarm bør føre til handling. Hvis det ikke er klart, hvem der skal håndtere den, eller hvad der skal gøres, er den blot endnu en besked i systemet.
Praktisk eksempel: hvordan hjælper observability med at finde årsagen til et nedbrud?
Lad os antage, at brugere af en B2B-applikation rapporterer, at generering af rapporter tager betydeligt længere tid end normalt. Overvågningen opdager en stigning i svartiden og udløser en alarm.
Teamet begynder analysen:
- Metrikker viser, at problemet primært vedrører rapporter med store datamængder. De øvrige funktioner fungerer normalt.
- Tracing viser, at den største forsinkelse opstår under udførelsen af forespørgslen til databasen.
- Logfiler indeholder detaljer om forespørgslen, dens driftsparametre og fejloplysninger uden at afsløre følsomme data.
- Datakorrelation gør det muligt at forbinde et bestemt spor med relevante logposter og ændringer, der ses på metrikgraferne.
- Ændringsanalyse viser, at problemet opstod efter implementeringen af den nye rapportversion, som begyndte at udføre en dyr forespørgsel.
Takket være dette behøver teamet ikke i blinde at gennemgå hele infrastrukturen. Det kan fokusere på en konkret operation, sammenligne adfærden før og efter implementeringen og derefter optimere forespørgslen eller rulle ændringen tilbage.
Observability fjerner ikke nedbrud og garanterer ikke, at hver årsag findes automatisk. Det hjælper dog med at begrænse søgeområdet, forkorte diagnosticeringstiden og træffe beslutninger baseret på data frem for antagelser.
Datakorrelation - den største værdi opstår sammen
Logfiler, metrikker og tracing er nyttige hver for sig, men deres sande værdi viser sig, når de kan forbindes med hinanden.
Forestil dig, at dashboardet viser en pludselig stigning i svartiden. Metrikken viser, hvornår og i hvilket omfang problemet opstod. Sporet viser, hvilke operationer der indgik i den langsomme forespørgsel. Logfilerne gør det muligt at se, hvilke hændelser der fandt sted i et bestemt trin.
For at dette er muligt, bør systemet konsekvent overføre konteksten for forespørgslen mellem tjenesterne. Trace- og span-id'er kan bruges til at knytte logposter sammen med spor. Det er også en fordel at bevare ensartede oplysninger om tjenestenavn, miljø, applikationsversion og andre attributter, der beskriver datakilden.
Uden korrelation kan teamet have adgang til mange dashboards, filer og værktøjer, men stadig bruge tid på manuelt at afgøre, hvilke hændelser der hænger sammen. OpenTelemetry peger på korrelation af logfiler, spor og ressourcekontekst som et vigtigt element i opbygningen af brugbar telemetri. <Cite ref="turn154932search1"/>
OpenTelemetry - en fælles standard for telemetridata
Implementering af observability behøver ikke at betyde afhængighed af én leverandør af værktøjer. En af løsningerne, der understøtter interoperabilitet, er OpenTelemetry (OTel) - et åbent sæt standarder, API'er, biblioteker og værktøjer til instrumentering, generering, indsamling og eksport af telemetridata.
OpenTelemetry gør det muligt for applikationen at udsende metrikker, logfiler og spor i en sammenhængende model. Dataene kan derefter sendes til et valgt observability-backend, som står for lagring, søgning, visualisering og analyse.
Et vigtigt element i økosystemet er OpenTelemetry Collector. Den kan modtage data fra forskellige kilder, behandle dem, berige dem med ekstra kontekst og eksportere dem til konfigurerede systemer. Dermed behøver applikationen ikke være direkte koblet til hvert enkelt værktøj, der bruges til analyse.
Denne tilgang er især nyttig, når virksomheden bruger mange teknologier, videreudvikler systemarkitekturen eller ønsker at bevare muligheden for at skifte værktøjsleverandør. Selve standarden sikrer dog ikke fuldstændig observability. Der er fortsat behov for korrekt instrumentering, en gennemtænkt strategi for dataindsamling, passende dashboards, alarmer og reaktionsprocedurer. <Cite ref="turn154932search3"/>
Hvornår er det værd at implementere observability?
Observability kan være nyttigt både i store distribuerede systemer og i mindre applikationer, hvor nedetid eller en sværtdetekterbar fejl har væsentlige forretningsmæssige konsekvenser.
Det er især værd at overveje denne tilgang, når:
- applikationen består af mange tjenester eller integrationer,
- problemerne opstår uregelmæssigt og er svære at genskabe,
- brugerne rapporterer fejl, som ikke ses i standardtests,
- tiden til at diagnosticere hændelser er for lang,
- efterfølgende udrulninger medfører svære at forudsige konsekvenser,
- virksomheden udvikler systemet og har brug for data til planlægning af ydeevne,
- applikationen håndterer kritiske salgs-, drifts- eller finansprocesser,
- teamet har brug for bedre at forstå eksterne tjenesters indflydelse på hele løsningens drift.
Det betyder dog ikke, at hver hjemmeside har brug for et omfattende telemetrimiljø. I en lille, simpel tjeneste kan grundlæggende logs, oppetidskontrol og nogle få nøglemetrikker være tilstrækkelige. Løsningens omfang bør svare til applikationens kompleksitet, trafikskala, krav til pålidelighed samt omkostningerne ved potentielle nedetider.
Hvornår kan observability være form over indhold?
Implementering af omfattende værktøjer uden et klart defineret mål kan medføre flere omkostninger end fordele.
De mest almindelige fejl er:
- At indsamle alt uden en plan. For meget data øger omkostningerne og gør det sværere at finde information, der er vigtig for fejlfinding.
- Mangel på spørgsmål, som systemet skal besvare. Dashboards kan se flotte ud, men ikke hjælpe med at løse reelle problemer.
- At sende alarmer ved hver afvigelse. For mange notifikationer fører til alarmtræthed og øger risikoen for at overse en hændelse.
- Mangel på ansvar for reaktion. Selv et godt opdaget problem kan vare længe, hvis ingen ved, hvem der skal tage sig af det.
- Mangel på databeskyttelse. Telemetri kan indeholde følsomme oplysninger, brugeridentifikatorer eller driftsdata, som kræver begrænset adgang og passende opbevaringsperiode.
- At ignorere instrumenteringsomkostningen. Indsamling af detaljerede traces og logs i stor skala kan påvirke applikationens ydeevne og generere betydelige omkostninger til lagring og behandling.
- At betragte værktøjet som en færdig løsning. Selve installationen af platformen sikrer ikke korrekt instrumentering eller en effektiv diagnoseproces.
Observability kræver derfor ikke kun teknologi, men også organisatoriske beslutninger: hvilke data der er nødvendige, hvem der analyserer dem, hvordan teamet reagerer, og hvordan erfaringer fra hændelser omsættes til ændringer i systemet.
Hvordan planlægger man implementeringen af observability?
Det sikreste er at udvikle observability trin for trin, begyndende med de processer og funktioner, hvis fejl har størst indflydelse på brugerne og virksomheden.
1. Definér de vigtigste forretningsprocesser
Identificér de vigtigste operationer, såsom login, ordreafgivelse, betalinger, dokumentgenerering eller datasynkronisering. Det er dem, der bør være udgangspunktet for at definere, hvad korrekt drift af applikationen betyder.
2. Fastlæg pålidelighedsindikatorer
Vælg metrikker, der afspejler brugeroplevelsen, for eksempel tilgængeligheden af nøglefunktioner, svartid eller andelen af operationer, der afsluttes succesfuldt. For vigtige tjenester kan man definere SLI (Service Level Indicator), dvs. tjenesteniveauindikator, samt SLO (Service Level Objective), dvs. målet for denne indikator.
3. Sørg for strukturerede logs
Ensret logformat, vigtighedsniveauer og grundlæggende attributter. Sørg for korrelationsidentifikatorer og en politik for sletning eller maskering af fortrolige data. Logs bør være læselige for teamet og mulige at behandle med værktøjer.
4. Tilføj tracing i kritiske spor
Start med processer, der omfatter mange tjenester, databaser eller eksterne integrationer. Følg forespørgslens forløb gennem systemet og sørg for kontekstpropagering mellem komponenterne.
5. Byg dashboards omkring konkrete spørgsmål
I stedet for at skabe ét stort panel, lav visninger, der opfylder behovene hos forskellige roller. Det tekniske team kan have brug for information om fejl og forsinkelser, mens produktejeren har brug for data om nøgleprocessers effektivitet og fejlens indvirkning på brugerne.
6. Design alarmer og reaktionsprocedurer
Fastlæg tærskler, prioriteter, ansvarlige personer og handlingsinstruktioner. En alarm bør indeholde kontekst, der hjælper med hurtigt at starte fejlfinding, og ikke blot informere om en overskridelse af en værdi.
7. Test observability
Kontrollér, om teamet kan finde årsagen til en eksempel-fejl ud fra de tilgængelige data. Man kan gennemføre kontrollerede fejltests i et testmiljø eller øvelser i håndtering af hændelser. Det er også værd at verificere, om alarmerne udløses, når de skal.
8. Udvikl løsningen på baggrund af hændelser
Efter hvert væsentligt problem er det værd at undersøge, hvilke oplysninger der var tilgængelige, hvad der manglede, og hvordan instrumentering, alarmering eller procedurer kan forbedres. Observability er ikke et engangsprojekt, men en proces for løbende at forbedre viden om systemets drift.
Omkostninger og sikkerhed - to aspekter, man ikke må overse
Telemetridata har en pris. Omkostninger kan opstå fra instrumentering, overførsel, indeksering, lagring, retention og dataanalyse. I systemer med høj trafik kan det især være dyrt at indsamle alle traces eller meget detaljerede logs.
Derfor er det en god idé at bruge retention tilpasset behovene, datafiltrering, sampling af traces og forskellige detaljeringsniveauer afhængigt af miljøet. For eksempel kan et produktionssystem indsamle fulde data for fejl og udvalgte kritiske operationer, mens en del af de korrekte forespørgsler samples for at begrænse volumen.
Lige så vigtig er databeskyttelse. Logs og traces kan uforvarende indeholde personoplysninger, sessionsidentifikatorer, fragmenter af forespørgsler eller oplysninger om infrastrukturs opbygning. Adgang til telemetri bør begrænses, unødvendige data bør fjernes, fortrolige oplysninger maskeres, og opbevaringsperioder kontrolleres. Det er også værd at betragte observability-systemer som en del af produktionsmiljøet, som selv kræver beskyttelse, backups og adgangskontrol.
Observability som ledelsesværktøj, ikke kun til diagnostik
Selvom observability oftest forbindes med arbejdet for udviklere, DevOps og administratorer, rækker værdien langt ud over IT-området.
Data om svartider, fejl, tilgængelighed og proces-effektivitet kan hjælpe virksomheden med at forstå, hvilke teknologiske elementer der understøtter driften, og hvilke der begrænser den. De gør det muligt at identificere gentagne problemer, vurdere konsekvenserne af ændringer og planlægge udviklingen på baggrund af systemets faktiske adfærd.
Hvis for eksempel ordresystemet regelmæssigt bliver langsomt på bestemte tidspunkter, kan telemetridata hjælpe med at afgøre, om der er behov for optimering af forespørgsler, ændring af måden opgaver behandles på, eller udbygning af infrastrukturen. I stedet for at investere i ekstra ressourcer baseret på intuition kan virksomheden først identificere den reelle flaskehals.
Observability understøtter også analysen af effekten af implementeringer. Sammenligning af metrics, traces og logs før og efter en ændring gør det muligt hurtigere at opdage regressioner og vurdere, om opdateringen gav den forventede effekt.
Det er dog ikke korrekt at sidestille observability med automatisk beslutningstagning. Dataene viser systemets adfærd, men deres fortolkning kræver kendskab til arkitekturen, forretningsprocesserne og konteksten for den konkrete hændelse.
Begrebsordbog
- Observability (observability) - evnen til at forstå et systems indre adfærd på baggrund af de data, det udsender.
- Monitoring - løbende overvågning af udvalgte parametre og opdagelse af bestemte tilstande, der kræver opmærksomhed.
- Telemetry (telemetri) - data indsamlet og sendt fra applikationer og infrastruktur med henblik på at analysere deres drift.
- Logs (logs) - registreringer af hændelser, der opstår i applikationen eller infrastrukturen.
- Metrics (metrics) - numeriske målinger af systemets tilstand, ydeevne eller adfærd over tid.
- Tracing - sporing af et forløb af operationer gennem applikationens komponenter.
- Distributed tracing - sporing af en enkelt anmodning i et system, der består af mange tjenester eller processer.
- Span - en registrering af en enkelt operation, som er en del af et trace.
- Trace - et sæt relaterede spans, der viser et operationsforløb.
- Alert - en notifikation om en registreret tilstand eller hændelse, der kræver reaktion.
- SLI - en indikator, der måler et konkret aspekt af en tjenestes drift.
- SLO - et fastsat mål for en valgt pålidelighedsindikator.
- Sampling - en teknik til at begrænse mængden af indsamlede telemetridata ved at vælge en repræsentativ del af hændelserne.
- OpenTelemetry - et åbent sæt standarder og værktøjer, der understøtter instrumentering og eksport af telemetridata.
Opsummering
Et nedbrud i en applikation starter ikke altid med en utilgængelig server eller en fejlmeddelelse. Nogle gange fungerer systemet formelt set, men en vigtig funktion bliver for langsom, nogle transaktioner gennemføres ikke, eller en integration fejler kun under bestemte forhold.
Monitoring hjælper med at opdage uregelmæssigheder. Observability gør det muligt at forstå, hvad der førte til dem, og hvilken indvirkning de havde på applikationens drift. Logs, metrics, tracing og veludformede alerts skaber tilsammen grundlaget for mere effektiv fejlsøgning, bevidst udvikling og reduktion af den operationelle risiko.
Det handler ikke om at indsamle så mange data som muligt eller skabe de mest omfattende dashboards. Det handler om, at man i det øjeblik et problem opstår, ikke kun skal spørge: „Virker systemet?”, men kunne fastslå: „Hvad skete der præcist i systemet, hvorfor, og hvad skal vi gøre nu?”
En moden applikation er ikke kun en, der virker. Det er også en, hvis adfærd kan forstås, diagnosticeres og forbedres.
