Mi az az OpenTelemetry, és hogyan javíthatja a háttérrendszer minőségét?

Korábban, amikor a háttérrendszerről beszéltünk, általában egyetlen nagy alkalmazásra hivatkoztunk egyetlen, nagy adatbázissal, és a naplózás elegendő volt a megfigyeléshez. A Kuberneteshez hasonló technológiáknak köszönhetően mára a mikroszolgáltatások szabványossá váltak. Az alkalmazások száma több és elosztottabb, és a hagyományos naplózás már nem elegendő az alkalmazásaink hibakereséséhez és problémáinak diagnosztizálásához.

A figyelés megszervezésére kiváló megoldás az OpenTelemetry – egy modern eszközkészlet, amely elosztott rendszerek hibakeresésére és teljesítményelemzésére használható.

Ez a cikk azoknak az informatikai szakembereknek szól, akik szeretnék bővíteni tudásukat a háttéroptimalizálás terén. Az alábbiakban részletezzük, hogy mi az OpenTelemetry, kulcsfontosságú fogalmai, és milyen problémákat segít megoldani. Ha érdekli, hogyan változtathatja meg az OpenTelemetry a háttérrendszerek megfigyelésére és hibakeresésére vonatkozó megközelítését, növelve azok megbízhatóságát és hatékonyságát – olvasson tovább.

Az OpenTelemetry rövid története

A nagy technológiai vállalatok először a 2000-es évek végén szembesültek az elosztott naplózás és nyomkövetés kihívásával. 2010-ben a Google kiadott egy tanulmányt, Dapper, egy nagyszabású elosztott rendszerek nyomkövetési infrastruktúrája , amely megalapozta a Twitter 2012-ben kiadott nyomkövető eszközét, a Zipkint.

2014-ben jelent meg a Kubernetes, amely jelentősen leegyszerűsítette a mikroszolgáltatások és más felhőalapú rendszerek fejlesztését. Ez ahhoz vezetett, hogy sok vállalat problémákba ütközött az elosztott naplózással és nyomon követéssel a mikroszolgáltatásokban. Az elosztott nyomkövetés szabványosítására létrehozták a CNCF és a Google OpenCensus projektje által elfogadott OpenTracing szabványt.

2019-ben az OpenTracing és az OpenCensus projektek egyesülést jelentettek be OpenTelemetry néven. Ez a platform egyesíti a sok éven át felhalmozott legjobb gyakorlatokat, lehetővé téve a nyomkövetés, naplózás és metrikák zökkenőmentes integrálását bármely rendszerbe, függetlenül azok összetettségétől.

Ma az OpenTelemetry nem csak egy projekt; ez egy ipari szabvány a telemetriai adatok gyűjtésére és továbbítására. Szakértőkből és piacvezető cégekből, például Google-ból és Microsoftból álló közösség fejleszti és támogatja. A projekt folyamatosan fejlődik, új képességeket szerezve az integrációs és használati folyamat egyszerűsítése érdekében.

Mi van benne?

Az OpenTelemetry gyakorlatok és eszközök átfogó készlete, amely meghatározza, hogy egy alkalmazás milyen jeleket generálhat a külvilággal való interakcióhoz, és hogyan lehet ezeket a jeleket összegyűjteni és megjeleníteni az alkalmazások és a rendszer egészének állapotának nyomon követéséhez. A jelek három fő típusa a nyomkövetés, a naplózás és a mérőszámok gyűjtése .

** Nézzük meg közelebbről az egyes összetevőket: \

Kontextusok

Az OpenTelemetry bevezeti a műveleti kontextusok fogalmát. A kontextus elsősorban olyan attribútumokat tartalmaz, mint `trace_id` (az aktuális művelet azonosítója) és `span_id` (az alkérelem azonosítója, ahol az alkérelem minden újrapróbálkozása egyedi `span_id` rendelkezik).

Ezenkívül egy kontextus tartalmazhat statikus információkat, például az alkalmazás telepítési helyének csomópontjának nevét vagy a környezet nevét (prod/qa). Ezek az OpenTelemetry terminológiában erőforrásként ismert mezők minden naplóhoz, metrikához vagy nyomhoz csatolva vannak a könnyebb kereshetőség érdekében. A kontextusok tartalmazhatnak dinamikus adatokat is, például az aktuális végpont azonosítóját ( `http_path: "GET /user/:id/info"` ), amelyek szelektíven csatolhatók naplók, metrikák vagy nyomkövetések csoportjaihoz.

Az OpenTelemetry kontextusok átadhatók a különböző alkalmazások között a kontextusterjesztési protokollok segítségével. Ezek a protokollok fejléckészletekből állnak, amelyeket minden HTTP- vagy gRPC-kérelemhez vagy a várólistákhoz tartozó üzenetek fejlécéhez adnak hozzá. Ez lehetővé teszi a későbbi alkalmazások számára, hogy ezekből a fejlécekből rekonstruálják a műveleti környezetet.

Íme néhány példa a kontextus terjesztésére:

1. B3-Propagation Ez egy fejléckészlet ( x-b3-* ), amelyet eredetileg a Zipkin nyomkövető rendszerhez fejlesztettek ki. Az OpenTracingbe adaptálták, és számos eszköz és könyvtár használta. A B3-Propagation tartalmaz trace_id / span_id és egy jelzőt, amely jelzi, hogy szükséges-e mintavétel.

   
   

2. W3C Trace Context A W3C munkacsoport által kifejlesztett szabvány egyetlen szabványban egyesíti a különböző kontextusterjesztési megközelítéseket, és az OpenTelemetry alapértelmezett beállítása. E szabványok alkalmazásának jó példája a különböző technológiával megvalósított mikroszolgáltatásokon áthaladó kérések végrehajtásának nyomon követése a figyelés és a hibakeresés pontosságának veszélyeztetése nélkül.

Nyomkövetés

A nyomkövetés az a folyamat, amely rögzíti és ezt követően megjeleníti a kérés útvonalának idővonalát több mikroszolgáltatáson keresztül.

A vizualizációban minden sávot "span"-nak neveznek, és egyedi "span_id" -vel rendelkeznek. A gyökértartományt "nyomkövetésnek" nevezik, és van egy "trace_id" , amely a teljes kérés azonosítójaként szolgál.

Ez a fajta vizualizáció lehetővé teszi a következőket:

• Elemezze a kérések végrehajtási idejét a különböző rendszerekben és adatbázisokban, hogy azonosítsa az optimalizálást igénylő szűk keresztmetszeteket.
• A szolgáltatások közötti ciklikus függőségek észlelése.
• Keresse meg az ismétlődő kérelmeket. A nyomkövetési adatok használatával további elemzéseket is készíthet, például mikroszolgáltatási térképet hozhat létre, vagy a műveletek feldolgozása során eloszthatja az időt a különböző rendszerek között. Még ha nem is használ nyomkövetési adatokat az idővonalak megjelenítésére, az OpenTelemetry továbbra is létrehozza trace_id és span_id más jelekben való felhasználáshoz.

Naplók

A látszólagos egyszerűsége ellenére a naplózás továbbra is a problémák diagnosztizálásának egyik leghatékonyabb eszköze. Az OpenTelemetry a kontextuális információk hozzáadásával javítja a hagyományos naplózást. Pontosabban, ha aktív nyomkövetés van jelen, a "trace_id" és "span_id" attribútumok automatikusan hozzáadódnak a naplókhoz, és összekapcsolják őket a nyomkövetési idővonallal. Ezenkívül a naplóattribútumok tartalmazhatnak statikus információkat az OpenTelemetry kontextusból, például a csomópont azonosítóját, valamint dinamikus információkat, például az aktuális HTTP-végpont azonosítót (`http_path: "GET /user/:id"`).

A "trace_id" használatával megtalálhatja az aktuális kérelemhez társított összes mikroszolgáltatás naplóit, míg a "span_id" lehetővé teszi az alkérelmek megkülönböztetését. Például újrapróbálkozások esetén a különböző próbálkozásokból származó naplók eltérő `span_id`-vel rendelkeznek. Ezen azonosítók használata lehetővé teszi a teljes rendszer viselkedésének gyors, valós idejű elemzését, felgyorsítva a probléma diagnosztizálását, valamint növelve a stabilitást és a megbízhatóságot.

Metrikák

A mérőszámok gyűjtése kvantitatív adatokat biztosít a rendszer teljesítményéről, például a késleltetésről, a hibaarányról, az erőforráshasználatról stb. A mérőszámok valós idejű figyelése lehetővé teszi, hogy azonnal reagáljon a teljesítmény változásaira, megelőzze a hibákat és az erőforrások kimerülését, valamint biztosítsa az alkalmazás magas szintű rendelkezésre állását és megbízhatóságát a felhasználók számára.

A metrikus tárolási és vizualizációs rendszerekkel, például a Prometheusszal és a Grafana-val való integráció megkönnyíti az adatok megjelenítését, jelentősen leegyszerűsítve a megfigyelést.

Metrikus gyűjtők

Az OpenTelemetry mérőszámgyűjtők kompatibilisek a Prometheus és az OpenMetrics szabványokkal, lehetővé téve az egyszerű átállást az OpenTelemetry megoldásokra, jelentős változtatások nélkül. Az OpenTelemetry SDK lehetővé teszi a trace_id példák mérőszámokkal együtt történő exportálását, lehetővé téve a metrikák és a naplópéldák és nyomkövetések közötti összefüggést.

Jelkorreláció

A naplók, a metrikák és a nyomkövetés együttesen átfogó képet adnak a rendszer állapotáról:

• A naplók információkat szolgáltatnak a rendszereseményekről, lehetővé téve a hibák gyors azonosítását és megoldását.
• A mérőszámok a rendszer minőségi és mennyiségi teljesítménymutatóit tükrözik, például a válaszidőket vagy a hibaarányt.
• A nyomkövetés kiegészíti ezt a nézetet azáltal, hogy bemutatja a kérések végrehajtásának útját a különböző rendszerkomponenseken keresztül, segítve ezek összefüggéseinek megértését. A naplók, nyomkövetések és metrikák közötti egyértelmű összefüggés az OpenTelemetry megkülönböztető jellemzője. Például a Grafana lehetővé teszi a felhasználók számára, hogy lássák a megfelelő nyomkövetési és kérési mérőszámokat egy napló megtekintésekor, ami nagymértékben javítja a platform használhatóságát és hatékonyságát.

A három alapvető összetevőn kívül az OpenTelemetry tartalmazza a mintavétel, a poggyász és a műveleti környezetkezelés fogalmát.

Mintavétel

A nagy terhelésű rendszerekben a naplók és nyomkövetések mennyisége óriásivá válik, ami jelentős erőforrásokat igényel az infrastruktúra és az adattárolás terén. A probléma megoldására az OpenTelemetry szabványok tartalmazzák a jelmintavételezést – a nyomkövetések és naplók csak egy részének exportálását. Például exportálhat részletes jeleket a kérelmek százalékából, a régóta futó kérésekből vagy a hibakérésekből. Ez a megközelítés elegendő mintavételt tesz lehetővé a statisztikák készítéséhez, miközben jelentős erőforrásokat takarít meg.

Ha azonban minden rendszer önállóan dönti el, hogy mely kéréseket figyelje részletesen, akkor az egyes kérések töredezett nézetét kapjuk. Egyes rendszerek részletes adatokat exportálhatnak, míg mások csak részben vagy egyáltalán nem.

A probléma megoldása érdekében az OpenTelemetry kontextus-terjesztési mechanizmusai mintavételezési jelzőt küldenek a `trace_id`/`span_id` paraméterrel együtt. Ez biztosítja, hogy ha a felhasználói kérést fogadó kezdeti szolgáltatás úgy dönt, hogy a kérést részletesen ellenőrizni kell, minden más rendszer követni fogja a példáját. Ellenkező esetben minden rendszernek részben vagy nem kell jeleket exportálnia az erőforrások megtakarítása érdekében. Ezt a megközelítést "Head Sampling"-nek nevezik – ez a döntés a kérésfeldolgozás elején, véletlenszerűen vagy bizonyos bemeneti attribútumok alapján.

Emellett az OpenTelemetry támogatja a "farok mintavételezést", ahol minden alkalmazás mindig részletesen exportálja az összes jelet, de létezik egy köztes puffer. Az összes adat összegyűjtése után ez a puffer eldönti, hogy a teljes adatot megtartja-e, vagy csak egy részmintát. Ez a módszer lehetővé teszi az egyes kérések kategóriáinak reprezentatívabb mintáját (sikeres/hosszú/hiba), de további infrastruktúra-beállítást igényel.

Poggyász

A Poggyász mechanizmus lehetővé teszi tetszőleges kulcs-érték párok továbbítását trace_id / span_id paraméterekkel együtt, amelyek automatikusan áthaladnak az összes mikroszolgáltatás között a kérésfeldolgozás során. Ez hasznos a kérési útvonalon keresztül szükséges további információk – például felhasználói információk vagy futási környezeti beállítások – továbbításához.

Példa a poggyász W3C szabvány szerinti továbbítására szolgáló fejlécre: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Íme néhány példa a poggyász használatára:

• Az üzleti környezetre vonatkozó információk, például userId , productId vagy deviceId átadása minden mikroszolgáltatáson keresztül továbbítható. Az alkalmazások automatikusan naplózhatják ezeket az információkat, lehetővé téve az eredeti kérés felhasználói kontextusa szerinti naplókeresést.

• Specifikus konfigurációs paraméterek SDK-k vagy infrastruktúra beállításai.

• Routing Flags Jelzők, amelyek segítenek a terheléselosztóknak az útválasztási döntésekben. A tesztelés során előfordulhat, hogy egyes kéréseket hamis háttérprogramokhoz kell irányítani. Mivel a poggyász minden szolgáltatáson keresztül automatikusan továbbításra kerül, nincs szükség további protokollok létrehozására – csak állítson be egy szabályt a terheléselosztón.

  
  

Infrastruktúra megvalósítása

Az OpenTelemetry infrastruktúra szintű megvalósítása magában foglalja az OpenTelemetry háttérrendszerek integrálását az alkalmazásarchitektúrába, és az infrastruktúra konfigurálását az adatgyűjtéshez.

A folyamat négy szakaszból áll:

1. Alkalmazásintegráció Az első szakaszban az OpenTelemetry SDK-kat közvetlenül integrálják az alkalmazásokba, hogy mérőszámokat, naplókat és nyomkövetéseket gyűjtsenek, biztosítva a folyamatos adatáramlást az egyes rendszerkomponensek teljesítményéről.

   
   

2. Exportőrök konfigurálása Az összegyűjtött adatok az alkalmazásokból az exportőrökön keresztül külső rendszerekbe kerülnek további feldolgozásra, például naplózási, megfigyelési, nyomkövetési vagy elemző rendszerekre, az Ön igényeitől függően.

   
   

3. Összesítés és tárolás Ez a szakasz magában foglalhatja az adatok normalizálását, további információkkal való gazdagítását, valamint a különböző forrásokból származó adatok egyesítését, hogy egységes képet hozzon létre a rendszer állapotáról.

   
   

4. Adatvizualizáció Végül a feldolgozott adatok irányítópultokként jelennek meg olyan rendszerekben, mint a Grafana (metrikák és nyomkövetések) vagy a Kibana (naplók). Ez lehetővé teszi a csapatok számára, hogy gyorsan felmérjék a rendszer állapotát, azonosítsák a problémákat és trendeket, és riasztásokat állítsanak be a generált jelek alapján.

Alkalmazás megvalósítása

Egy alkalmazással való integrációhoz csatlakoztatnia kell a használt programozási nyelvhez megfelelő OpenTelemetry SDK-t, vagy olyan könyvtárakat és keretrendszereket kell alkalmaznia, amelyek közvetlenül támogatják az OpenTelemetryt. Az OpenTelemetry gyakran valósítja meg az ismert könyvtárak széles körben használt felületeit, lehetővé téve a beugró cseréket. Például a Micrometer könyvtárat gyakran használják metrikák gyűjtésére a Java ökoszisztémában. Az OpenTelemetry SDK biztosítja a Micrometer interfészek megvalósításait, lehetővé téve a metrikák exportálását a fő alkalmazáskód megváltoztatása nélkül. Ezenkívül az OpenTelemetry régebbi OpenTracing és OpenCensus interfészek megvalósításait kínálja, megkönnyítve az OpenTelemetry-re való zökkenőmentes átállást.

Következtetés

Az informatikai rendszerekben az OpenTelemetry a megbízható és hatékony háttérrendszerek jövőjének kulcsává válhat. Ez az eszköz leegyszerűsíti a hibakeresést és a felügyeletet, valamint lehetőségeket nyit az alkalmazások teljesítményének és optimalizálásának mélyreható megértéséhez egy új szintre. Csatlakozzon az OpenTelemetry közösséghez, és segítsen kialakítani egy olyan jövőt, ahol a háttérfejlesztés egyszerűbb és hatékonyabb!