Når jeg jobber med kode er det viktig for meg å få rask tilbakemelding på hvordan endringene mine påvirker koden, og gjøre det lett å få mer innsikt i systemene jeg jobber med. En stor del av dette har vært å gjøre det mulig å observere hva applikasjonen min gjør til en hver tid, og hvordan dette endrer seg hver gang jeg deployer ny kode.
I store og komplekse systemer - som vi ofte jobber med i denne bransjen - er det ikke uhørt at noe går galt. Når dette skjer er evnen til å gå tilbake i tid og skjønne hva som skjedde helt nødvendig for å kunne fikse problemene og hindre at vi opplever det samme igjen.
For at dette skal være mulig, trenger vi gode observerbarhetsverktøy. Problemet er at det praktisk talt finnes et uendelig antall observerbarhetsverktøy der ute, og selv med alle som allerede finnes vil det alltid være etterspørsel etter nye måter å presentere og jobbe med observerbarhetsdata.
Over tid vil behovene våre for observerbarhet utvikle seg i takt med systemene våre, og det er ikke holdbart å måtte re-implementere hvordan observerbarhetsdata genereres og overføres hver gang. Du vil heller ikke at dataene du har generert ender opp låst inne i en en lukket plattform uten noen måte å ta den med deg videre når du skal bytte leverandør.
Ideelt ønsker vi bare å instrumentere applikasjonen vår én gang, og kunne sende tracene, metrikkene og loggene våre til verktøyet som passer best for situasjonen, sånn at vi kan utvikle verktøyene i i takt med kravene våre.
Og det er her OpenTelemetry kommer inn i bildet.
Hva er OpenTelemetry?
OpenTelemetry er et open source observerbarhetsrammeverk for å instrumentere applikasjoner og overføre telemetrisk data på en standardisert måte. Som beskrevet på prosjektsiden:
OpenTelemetry’s Mission: to enable effective observability by making high-quality, portable telemetry ubiquitous.
For å skjønne hva poenget med OpenTelemetry er, er det viktig å skjønne hva det ikke er. OpenTelemetry er ikke en observerbarhetsplattform, sånn som f.eks. Grafana eller Datadog. Observerbarhetsplattformer som disse brukes til å analysere telemetridata gjennom visualisering og søking.
OpenTelemetry, på den andre siden, er en samling komponenter som gjør det lettere å instrumentere applikasjoner og eksportere telemetridata videre inn i disse observerbarhetsplattformene på en en standardisert og konsistent måte, uavhengig programmeringsspråk, rammeverk eller observerbarhetsplattform. OpenTelemetry er ikke et alternativ eller en konkurrent til disse plattformene, men heller et utfyllende verktøy som gjør det lettere å få dataene inn i plattformene.
Kjernen av OpenTelemetry er en samling av spesifikasjoner, protokoller og konvensjoner som standardiserer hvordan telemetridata beskrives og overføres. I tillegg til dette er det et stort økosystem av verktøy og biblioteker for å instrumentere alle de mest brukte programmeringsspråkene og rammeverkene til å sende telemetridata med dette formatet til et hvilket som helst kompatibelt verktøy. Resultatet er at vi kan instrumentere så godt som hva som helst på en konsekvent måte, uansett hva hvilken kontekst vi jobber i.
Hva er poenget med OpenTelemetry?
OpenTelemetryprosjektet har to hovedprinsipper som oppgis på prosjektsiden:
- Du eier din egen data, og kan ikke låses til én leverandør
- De trenger bare å lære ett API og tilhørende konvensjoner
Siden OpenTelemetry gjør det mulig å generere og eksportere telemetridata på en standardisert måte som er kompatibelt med et stort antall forskjellige leverandører, er det vanskelig for én enkelt leverandør å låse deg til deres produkt. Du kan bruke så mange kompatible verktøy du vil samtidig, og du kan lett legge til eller fjerne verktøy som du ønsker.
Uten OpenTelemetry ender du ofte opp med å måtte installere en egen agent for hver leverandør, som ikke fungerer med andre verktøy. Disse agentene gjør det vanskelig å skjønne hvordan dataene genereres, samles inn og sendes, og hver gang du skal bytte leverandør må du sette opp alt på nytt igjen. Om du har flere applikasjoner (noe man ofte har), ender du ofte opp med å måtte sette opp alt på nytt igjen for hver applikasjon, noe som raskt kan ta mye tid og krefter. Hvis observerbarhetsleverandøren din plutselig bestemmer seg for å øke prisen, eller du oppdager et nytt og bedre verktøy, må du alltid vurdere om det er verdt å investere arbeidet med å flytte til en ny leverandør.
Med OpenTelemetry trenger du bare å instrumentere applikasjonen én gang, og du kan eksportere til et hvilket som helst kompatibelt verktøy med minimal ekstra jobb. Og siden måten man instrumenterer applikasjoner er likt på tvers av hele økosystemet, trenger man bare å lære hvordan man gjør det én gang, og det vil være relativt likt hvis du bytter leverandør eller starter i et nytt firma som også bruker OpenTelemetry.
Så hva kan du bruke OpenTelemetry til?
Uansett hvilken kontekst du jobber i, kan du ha stor nytte av å ha en standardisert måte å håndtere telemetridata.
Greenfield-prosjekter
Hvis du starter opp et helt nytt prosjekt kan det være en god idé og integrere med OpenTelemetry med en gang man trenger noen form for observerbarhet. Alt du trenger å gjøre er å instrumentere applikasjonen din og velge et kompatibelt verktøy som passer for behovene dine.
Etter hvert som applikasjonen og behovene dine utvikler seg, kan du lett la observerbarhetsverktøyene utvikle seg i samme takt. Selv om du mest sannsynligvis kan dekke observerbarhetsbehovene dine med et enkelt verktøy i starten, kan du lett integrere med en mer komplisert og komplett plattform senere uten å måtte re-instrumentere applikasjonen på nytt.
Etablerte prosjekter
Som oftest har man ikke luksusen av å starte opp et helt nytt prosjekt fra starten av og kunne gjøre alle valgene. Typisk sett jobber man med en godt etablert tjeneste men mangler observerbarheten man trenger for å gjøre jobben sin effektivt.
Som konsulent har jeg vært hos mange forskjellige kunder, helt fra små startups til store multinasjonale selskaper med flere tusen ansatte, bare for å oppdage at alt de har av observerbarhet er en bortgjemt .txt-fil på en obskur SSH-host hvor alle applikasjonsloggene ender opp. Hos kunder som dette kunne det lett ta timevis med leting og søking for å finne nålen i høystakken når vi fikk inn en feilmelding. Når hovedårsaken skyldtes interaksjoner mellom flere distribuerte systemer kunne det lett ta flere dager å korrelere logger på tvers av tjenester.
Bare det å få helt grunnleggende strukturerte logger, tracer og metrikker, og å ha muligheten til å korrelere på tvers av forskjellige systemer med trace- og span-IDer i situasjoner som dette ville vært en stor forbedring, og ikke spesielt vanskelig å implementere. En rask løsning her kan være å instrumentere applikasjonen med OpenTelemetry, og sette opp en av de mange kompatible open source observerbarhetsverktøyene til å kjøre på intern infrastruktur og sende telemtridataene dit. Så fort du har instrumentert applikasjonen til å sende generere OpenTelemetry-data, er det lett å ta i bruk nye verktøy etter hvert som behovene utvikler seg.
Evaluere observerbarhetsplattformer.
I noen tilfeller har man allerede grunnleggende observerbarhet på plass, men har behov for bedre eller mer dekkende verktøy. Dette var tilfellet på en kunde jeg var hos tidligere, hvor vi hadde grunnleggende verktøy for å se tracer og logger, men ønsket en sentralisert plattform med flere egenskaper.
Etter å ha bestemt oss for to alternativer, ba vi om proof-of-concept-miljøer fra hver av leverandørene, og bruke OpenTelemetry collector for å sende dataene til begge plattformene samtidig.
Med dataene i begge plattformene, kunne vi lett sammenligne hvordan det var å jobbe med ekte data i hver plattform, og kunne lett sammenligne fordeler og ulemper.
Veien videre
Om dette virker interessant, anbefaler jeg den offisielle getting-started-dokumentasjonen.
