Mikä OpenTelemetry on ja miten se voi parantaa taustasi laatua?

Aiemmin, kun puhuimme taustajärjestelmästä, viittasimme yleensä yhteen suureen sovellukseen, jossa oli yksi suuri tietokanta, ja seurantaan riitti kirjaaminen. Nyt Kubernetesin kaltaisten teknologioiden ansiosta mikropalveluista on tullut standardi. Sovelluksia on enemmän ja hajautetumpia, eikä perinteinen kirjaus enää riitä virheenkorjaukseen ja sovelluksiemme ongelmien diagnosointiin.

Erinomainen ratkaisu valvonnan järjestämiseen on OpenTelemetry – moderni työkalupakki, jota voidaan käyttää hajautettujen järjestelmien virheenkorjaukseen ja suorituskyvyn analysointiin.

Tämä artikkeli on tarkoitettu IT-ammattilaisille, jotka haluavat laajentaa tietämystään taustajärjestelmän optimoinnista. Alla kerromme yksityiskohtaisesti, mikä OpenTelemetry on, sen keskeiset käsitteet ja ongelmat, joita se auttaa ratkaisemaan. Jos olet kiinnostunut siitä, kuinka OpenTelemetry voi muuttaa lähestymistapaasi taustajärjestelmien valvontaan ja virheenkorjaukseen, mikä parantaa niiden luotettavuutta ja tehokkuutta – lue.

OpenTelemetryn lyhyt historia

Suuret teknologiayritykset kohtasivat hajautetun kirjaamisen ja jäljittämisen haasteen ensimmäisen kerran 2000-luvun lopulla. Vuonna 2010 Google julkaisi paperin, Dapper, laajamittainen hajautettujen järjestelmien jäljitysinfrastruktuuri , joka loi pohjan Twitterin vuonna 2012 julkaistulle Zipkin-jäljitystyökalulle.

Vuonna 2014 syntyi Kubernetes, joka yksinkertaisti merkittävästi mikropalvelujen ja muiden pilvipohjaisten järjestelmien kehitystä. Tämä johti siihen, että monet yritykset kohtasivat ongelmia hajautetun kirjauksen ja jäljityksen kanssa mikropalveluissa. Hajautetun jäljityksen standardoimiseksi luotiin CNCF:n ja Googlen OpenCensus-projektin hyväksymä OpenTracing-standardi.

Vuonna 2019 OpenTracing- ja OpenCensus-projektit ilmoittivat yhdistyvänsä nimellä OpenTelemetry. Tämä alusta yhdistää useiden vuosien aikana kertyneet parhaat käytännöt, mikä mahdollistaa jäljityksen, kirjaamisen ja mittareiden saumattoman integroinnin mihin tahansa järjestelmään niiden monimutkaisuudesta riippumatta.

Nykyään OpenTelemetry ei ole vain projekti; se on alan standardi telemetriatietojen keräämiseen ja lähettämiseen. Sen on kehittänyt ja tukee joukko asiantuntijoita ja markkinoiden johtavia yrityksiä, kuten Google ja Microsoft. Projekti kehittyy edelleen ja saa uusia ominaisuuksia integrointi- ja käyttöprosessin yksinkertaistamiseksi.

Mitä sisällä?

OpenTelemetry on kattava joukko käytäntöjä ja työkaluja, jotka määrittelevät, mitä signaaleja sovellus voi tuottaa ollakseen vuorovaikutuksessa ulkomaailman kanssa, ja kuinka nämä signaalit voidaan kerätä ja visualisoida sovellusten ja koko järjestelmän tilan seuraamiseksi. Signaalien kolme päätyyppiä ovat jäljitys, lokikirjaus ja mittareiden kerääminen .

** Katsotaanpa kutakin komponenttia tarkemmin: \

Kontekstit

OpenTelemetry esittelee toimintakontekstien käsitteen. Konteksti sisältää ensisijaisesti attribuutteja, kuten `trace_id` (nykyisen toiminnon tunniste) ja `span_id` (alipyynnön tunniste, jossa jokaisella alipyynnön uudelleenyrityksellä on yksilöllinen `span_id` ).

Lisäksi konteksti voi sisältää staattista tietoa, kuten solmun nimen, jossa sovellus on otettu käyttöön, tai ympäristön nimen (tuote/qa). Nämä kentät, jotka tunnetaan OpenTelemetry-terminologiassa resursseina, on liitetty jokaiseen lokiin, mittariin tai jäljiin haun helpottamiseksi. Kontekstit voivat sisältää myös dynaamisia tietoja, kuten nykyisen päätepisteen tunnisteen ( `http_path: "GET /user/:id/info"` ), jotka voidaan liittää valikoivasti loki-, mittaus- tai jäljitysryhmiin.

OpenTelemetry-konteksteja voidaan siirtää eri sovellusten välillä kontekstin leviämisprotokollia käyttämällä. Nämä protokollat koostuvat otsikkojoukoista, jotka lisätään jokaiseen HTTP- tai gRPC-pyyntöön tai jonojen viestien otsikoihin. Tämä sallii alavirran sovellusten rekonstruoida toimintakontekstin näistä otsikoista.

Tässä on esimerkkejä kontekstin levittämisestä:

1. B3-Propagation Tämä on joukko otsikoita ( x-b3-* ), jotka on alun perin kehitetty Zipkin-jäljitysjärjestelmää varten. Se mukautettiin OpenTracingiin ja sitä käyttivät monet työkalut ja kirjastot. B3-Propagation sisältää trace_id / span_id ja lipun, joka osoittaa, onko näytteenotto tarpeen.

   
   

2. W3C Trace Context W3C-työryhmän kehittämä standardi yhdistää erilaiset kontekstin leviämismenetelmät yhdeksi standardiksi ja on OpenTelemetryn oletusasetus. Hyvä esimerkki näiden standardien soveltamisesta on eri tekniikoilla toteutettujen mikropalvelujen kautta kulkevan pyynnön suorittamisen seuranta vaarantamatta valvonta- ja virheenkorjaustarkkuutta.

Jäljitys

Jäljitys on prosessi, jossa tallennetaan ja myöhemmin visualisoidaan pyynnön polun aikajana useiden mikropalvelujen kautta.

Visualisoinnissa jokaista palkkia kutsutaan "span"ksi ja sillä on yksilöllinen "span_id" . Juurialuetta kutsutaan "jäljiksi" ja sillä on "trace_id" , joka toimii koko pyynnön tunnisteena.

Tämän tyyppisen visualisoinnin avulla voit:

• Analysoi pyyntöjen suoritusaikaa eri järjestelmissä ja tietokannassa tunnistaaksesi optimointia vaativat pullonkaulat.
• Tunnista sykliset riippuvuudet palveluiden välillä.
• Etsi päällekkäisiä pyyntöjä. Jäljitystietojen avulla voit myös rakentaa lisäanalytiikkaa, kuten luoda mikropalvelukartan tai jakaa aikaa eri järjestelmien kesken toiminnan käsittelyn aikana. Vaikka et käyttäisi jäljitysdataa aikajanan visualisointiin, OpenTelemetry luo silti trace_id ja span_id käytettäväksi muissa signaaleissa.

Lokit

Ilmeisestä yksinkertaisuudestaan huolimatta kirjaus on edelleen yksi tehokkaimmista työkaluista ongelmien diagnosoinnissa. OpenTelemetry parantaa perinteistä kirjaamista lisäämällä kontekstitietoja. Erityisesti, jos aktiivinen jäljitys on olemassa, "trace_id"- ja "span_id"-attribuutit lisätään automaattisesti lokeihin ja linkitetään ne jäljityksen aikajanalle. Lisäksi lokiattribuutit voivat sisältää staattista tietoa OpenTelemetry-kontekstista, kuten solmun tunnisteen, sekä dynaamisia tietoja, kuten nykyisen HTTP-päätepisteen tunnisteen (`http_path: "GET /user/:id"`).

Trace_id-tunnisteen avulla voit löytää lokit kaikista nykyiseen pyyntöön liittyvistä mikropalveluista, kun taas span_id-argumentin avulla voit erottaa alipyynnöt. Esimerkiksi uudelleenyritysten tapauksessa eri yritysten lokeilla on erilainen span_id. Näiden tunnisteiden käyttö mahdollistaa koko järjestelmän toiminnan nopean analysoinnin reaaliajassa, mikä nopeuttaa ongelmien diagnosointia ja lisää vakautta ja luotettavuutta.

Mittarit

Mittareiden kokoelma tarjoaa kvantitatiivisia tietoja järjestelmän suorituskyvystä, kuten viiveestä, virhemääristä, resurssien käytöstä ja muusta. Mittareiden reaaliaikaisen seurannan avulla voit reagoida nopeasti suorituskyvyn muutoksiin, estää vikoja ja resurssien kulumista sekä varmistaa sovelluksen korkean käytettävyyden ja luotettavuuden käyttäjille.

Integrointi metrien tallennus- ja visualisointijärjestelmiin, kuten Prometheus ja Grafana, helpottaa näiden tietojen visualisointia, mikä yksinkertaistaa merkittävästi seurantaa.

Metrinen keräilijät

OpenTelemetry-mittariston kerääjät ovat yhteensopivia Prometheus- ja OpenMetrics-standardien kanssa, mikä mahdollistaa helpon siirtymisen OpenTelemetry-ratkaisuihin ilman merkittäviä muutoksia. OpenTelemetry SDK mahdollistaa trace_id-esimerkkien viennin mittareiden kanssa, mikä mahdollistaa mittareiden korreloinnin lokiesimerkkien ja jäljitysten kanssa.

Signaalin korrelaatio

Yhdessä lokit, mittarit ja jäljitys luovat kattavan kuvan järjestelmän tilasta:

• Lokit tarjoavat tietoa järjestelmätapahtumista, mikä mahdollistaa virheiden nopean tunnistamisen ja ratkaisemisen.
• Mittarit heijastavat järjestelmän laadullisia ja kvantitatiivisia suorituskykyindikaattoreita, kuten vasteaikoja tai virheprosentteja.
• Jäljitys täydentää tätä näkymää näyttämällä pyynnön suorituspolun eri järjestelmäkomponenttien kautta, mikä auttaa ymmärtämään niiden keskinäisiä suhteita. Lokien, jäljitysten ja mittareiden välinen selkeä korrelaatio on OpenTelemetryn erottuva piirre. Esimerkiksi Grafana antaa käyttäjille mahdollisuuden nähdä vastaavat jäljitys- ja pyyntömittarit lokia tarkasteltaessa, mikä parantaa merkittävästi alustan käytettävyyttä ja tehokkuutta.

Kolmen ydinkomponentin lisäksi OpenTelemetry sisältää näytteenoton, matkatavaroiden ja toimintakontekstin hallinnan käsitteet.

Näytteenotto

Suuren kuormituksen järjestelmissä lokien ja jälkien määrä kasvaa valtavaksi, mikä vaatii huomattavia resursseja infrastruktuuriin ja tietojen tallentamiseen. Tämän ongelman ratkaisemiseksi OpenTelemetry-standardit sisältävät signaalin näytteenoton - mahdollisuuden viedä vain osa jäljistä ja lokeista. Voit esimerkiksi viedä yksityiskohtaisia signaaleja tietyistä pyyntöjen prosenteista, pitkäaikaisista pyynnöistä tai virhepyynnöistä. Tämä lähestymistapa mahdollistaa riittävän otoksen tilastojen laatimiseksi ja samalla säästää merkittäviä resursseja.

Jos kukin järjestelmä kuitenkin päättää itsenäisesti, mitä pyyntöjä tarkkaillaan yksityiskohtaisesti, saamme jokaisesta pyynnöstä hajanaisen näkymän. Jotkut järjestelmät voivat viedä yksityiskohtaisia tietoja, kun taas toiset voivat viedä vain osittain tai olla viemättä ollenkaan.

Tämän ongelman ratkaisemiseksi OpenTelemetryn kontekstin etenemismekanismit lähettävät näytteenottolipun yhdessä "trace_id"/"span_id"-tunnisteen kanssa. Tällä varmistetaan, että jos ensimmäinen palvelu, joka vastaanottaa käyttäjäpyynnön, päättää, että pyyntöä tulee tarkkailla yksityiskohtaisesti, kaikki muut järjestelmät seuraavat perässä. Muussa tapauksessa kaikkien järjestelmien tulisi viedä signaaleja osittain tai ei ollenkaan resurssien säästämiseksi. Tätä lähestymistapaa kutsutaan "Head Sammpling" -päätökseksi, joka tehdään pyynnön käsittelyn alussa, joko satunnaisesti tai joidenkin syöteattribuuttien perusteella.

Lisäksi OpenTelemetry tukee "Tail Sampling" -toimintoa, jossa kaikki sovellukset vievät aina kaikki signaalit yksityiskohtaisesti, mutta välipuskuri on olemassa. Kun kaikki tiedot on kerätty, tämä puskuri päättää, säilytetäänkö kaikki tiedot vai säilytetäänkö vain osa näyte. Tämä menetelmä mahdollistaa edustavamman otoksen kustakin pyyntöluokasta (onnistunut/pitkä/virhe), mutta vaatii lisäinfrastruktuurin määrittämistä.

Matkatavarat

Matkatavaramekanismi mahdollistaa mielivaltaisten avainarvoparien lähettämisen yhdessä trace_id / span_id kanssa, jolloin ne kulkevat automaattisesti kaikkien mikropalvelujen välillä pyynnön käsittelyn aikana. Tämä on hyödyllistä pyyntöpolulla tarvittavien lisätietojen, kuten käyttäjätietojen tai ajonaikaisen ympäristön asetusten, lähettämisessä.

Esimerkki otsikosta matkatavaroiden lähettämiseksi W3C-standardin mukaisesti: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Tässä on esimerkkejä matkatavaroiden käytöstä:

• Liiketoimintakontekstitietojen , kuten userId , productId tai deviceId välittäminen voidaan välittää kaikkien mikropalvelujen kautta. Sovellukset voivat kirjata nämä tiedot automaattisesti, mikä mahdollistaa lokihaun alkuperäisen pyynnön käyttäjän kontekstin mukaan.

• Erityiset määritysparametrit SDK:iden tai infrastruktuurin asetukset.

• Reititysliput Liput, jotka auttavat kuormituksen tasaajia tekemään reitityspäätöksiä. Testauksen aikana jotkin pyynnöt saatetaan joutua reitittämään pilaamaan taustaohjelmia. Koska matkatavarat välitetään automaattisesti kaikkien palvelujen kautta, lisäprotokollia ei tarvitse luoda – määritä vain sääntö kuormantasauslaitteeseen.

  
  

Infrastruktuurin käyttöönotto

OpenTelemetryn käyttöönotto infrastruktuuritasolla sisältää OpenTelemetry-taustaohjelmien integroinnin sovellusarkkitehtuuriin ja infrastruktuurin konfiguroinnin tietojen yhdistämistä varten.

Prosessi koostuu neljästä vaiheesta:

1. Sovellusten integrointi Ensimmäisessä vaiheessa OpenTelemetry SDK:t integroidaan suoraan sovelluksiin keräämään mittareita, lokeja ja jälkiä, mikä varmistaa jatkuvan tiedonkulun kunkin järjestelmäkomponentin suorituskyvystä.

   
   

2. Viejien määrittäminen Kerätyt tiedot reititetään sovelluksista viejien kautta ulkoisiin järjestelmiin jatkokäsittelyä, kuten loki-, seuranta-, jäljitys- tai analytiikkajärjestelmiä varten tarpeidesi mukaan.

   
   

3. Kokoaminen ja tallennus Tämä vaihe voi sisältää tietojen normalisoinnin, sen rikastamisen lisätiedoilla ja eri lähteistä peräisin olevien tietojen yhdistämisen yhtenäisen kuvan luomiseksi järjestelmän tilasta.

   
   

4. Tietojen visualisointi Lopuksi käsitellyt tiedot esitetään kojelaudoina järjestelmissä, kuten Grafana (mittareita ja jälkiä varten) tai Kibana (lokit). Näin tiimit voivat nopeasti arvioida järjestelmän kunnon, tunnistaa ongelmat ja trendit sekä määrittää hälytyksiä luotujen signaalien perusteella.

Sovelluksen toteutus

Integroidaksesi sovellukseen, sinun on yhdistettävä käytettävälle ohjelmointikielelle sopiva OpenTelemetry SDK tai käytettävä kirjastoja ja kehyksiä, jotka tukevat suoraan OpenTelemetryä. OpenTelemetry toteuttaa usein laajalti käytettyjä rajapintoja tunnetuista kirjastoista, mikä mahdollistaa drop-in-korvaukset. Esimerkiksi Micrometer-kirjastoa käytetään yleisesti mittareiden keräämiseen Java-ekosysteemissä. OpenTelemetry SDK tarjoaa Micrometer-rajapintojen toteutukset, jotka mahdollistavat mittareiden viennin muuttamatta pääsovelluskoodia. Lisäksi OpenTelemetry tarjoaa vanhojen OpenTracing- ja OpenCensus-rajapintojen toteutuksia, mikä helpottaa sujuvaa siirtymistä OpenTelemetryyn.

Johtopäätös

IT-järjestelmissä OpenTelemetrystä voi tulla avain luotettavien ja tehokkaiden taustajärjestelmien tulevaisuuteen. Tämä työkalu yksinkertaistaa virheenkorjausta ja seurantaa ja avaa myös mahdollisuuksia syvälliseen ymmärtämiseen sovellusten suorituskyvystä ja optimoinnista uudelle tasolle. Liity OpenTelemetry-yhteisöön auttaaksesi muotoilemaan tulevaisuutta, jossa taustakehitys on yksinkertaisempaa ja tehokkaampaa!