Utfordringer med serverless-observasjon

Serverless-applikasjoner er ofte svært distribuerte og hendelsesdrevne. En enkelt brukerforespørsel kan utløse en kjede med flere funksjoner, køer og databaser.

Det blir en kompleks oppgave å spore hele reisen til en forespørsel, særlig på tvers av asynkrone grenser (som meldinger i en kø). De må knytte sammen ulike informasjonsbiter.

En «cold start» oppstår når en serverless-funksjon påkalles etter en periode uten aktivitet. Plattformen må initialisere kjøringsmiljøet, noe som øker ventetiden for påkallingen.

• Økt ventetid: Kalde starter kan påvirke brukeropplevelsen betydelig.
• Vanskelig å forutsi: Når de oppstår, avhenger av trafikkmønstre og plattformens håndtering.
• Krever spesifikk overvåking: De må skille varigheten av kalde starter fra normale kjøretider.

Serverless-databehandling prises vanligvis per påkalling og kjøretid. Denne modellen gjør kostnadseffektivitet svært viktig, og observability spiller en avgjørende rolle.

Ved å overvåke antall påkallinger, funksjonsvarighet og minnebruk kan De identifisere ineffektive funksjoner, optimalisere ressursfordelingen og forhindre uventede skyregninger.

Logger er grunnlaget for observability i serverless. De fleste serverless-plattformer fanger automatisk opp stdout/stderr og sender det til en administrert loggingstjeneste (for eksempel AWS CloudWatch Logs eller Azure Monitor Logs).

• Strukturert logging: Skriv alltid ut logger i et strukturert format (som JSON), slik at de kan leses av maskiner og enkelt søkes i.
• Kontekstuell informasjon: Ta med forespørsels-ID-er, funksjonsnavn og andre relevante metadata i hver loggoppføring.
• Sentralisering: Videresend logger fra plattformens innebygde tjeneste til et sentralisert loggsystem (som ELK Stack eller Splunk) for avansert analyse.

Serverless-plattformer tilbyr vanligvis viktige metrikkdata ferdig konfigurert. Disse er avgjørende for å forstå funksjonenes tilstand og ytelse uten manuell instrumentering.

• Påkallinger: Totalt antall ganger en funksjon ble kalt.
• Feil: Antall påkallinger som resulterte i en feil.
• Varighet: Tiden det tar for funksjonen å kjøre (skill mellom gjennomsnitt og p99).
• Begrensninger: Når funksjonskjøringen ble begrenset av samtidighetsgrenser.
• Minnebruk: Hvor mye minne funksjonen faktisk brukte, sammenlignet med den konfigurerte grensen.

Distribuert sporing er avgjørende for å forstå komplekse serverless-arbeidsflyter. Det knytter individuelle funksjonspåkallinger sammen til én samlet forespørselsreise fra start til slutt.

Verktøy som AWS X-Ray eller OpenTelemetry-SDK-er (som dekkes i et senere kurs) bidrar til å videreføre kontekst og sporings-ID-er på tvers av funksjonsgrenser, også for asynkrone kall. Dette gjør det mulig å visualisere hele flyten og finne flaskehalser i ytelsen.

En sporings-ID kan for eksempel sendes i en hendelsesnyttelast eller en HTTP-header:

For å mestre observability i serverless bør De integrere disse praksisene i arbeidsflyten for utvikling:

• Strukturert logging: Bruk alltid JSON for loggene Deres.
• Kontekstpropagering: Implementer mekanismer for å sende sporings-ID-er og annen kontekst på tvers av alle tjenester.
• Detaljerte metrikkdata: I tillegg til standardmetrikk bør De legge til egendefinerte metrikkdata for viktig forretningslogikk.
• Proaktiv varsling: Konfigurer varsler for kritiske metrikkdata som feil, begrensninger og lang varighet.
• Kostnadsbevissthet: Gjennomgå observability-data regelmessig for å optimalisere ressursfordelingen og styre kostnadene.

I denne leksjonen utforsket vi de unike utfordringene ved å observere serverless-funksjoner, blant annet deres kortvarige natur, distribuerte arkitektur og effekten av cold starts.

Vi gikk også gjennom viktige strategier for effektiv observability av serverless-systemer, med fokus på strukturert logging, nødvendige metrikker og betydningen av distribuert tracing for å få ende-til-ende-innsikt i disse dynamiske miljøene.