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.   hasonló technológiáknak köszönhetően mára   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   és problémáinak diagnosztizálásához. A Kuberneteshez a mikroszolgáltatások hibakereséséhez  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,  , amely megalapozta a Twitter 2012-ben kiadott nyomkövető eszközét, a Zipkint.   Dapper, egy nagyszabású elosztott rendszerek nyomkövetési infrastruktúrája  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   és   . a nyomkövetés, a naplózá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   (az aktuális művelet azonosítója) és   (az alkérelem azonosítója, ahol az alkérelem minden újrapróbálkozása egyedi   rendelkezik). `trace_id` `span_id` `span_id`  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 (   ), amelyek szelektíven csatolhatók naplók, metrikák vagy nyomkövetések csoportjaihoz. `http_path: "GET /user/:id/info"`  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:    Ez egy fejléckészlet (   ), 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   /   és egy jelzőt, amely jelzi, hogy szükséges-e mintavétel. B3-Propagation x-b3-* trace_id span_id    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. W3C Trace Context   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   -vel rendelkeznek. A gyökértartományt   nevezik, és van egy   , amely a teljes kérés azonosítójaként szolgál. "span_id" "nyomkövetésnek" "trace_id"   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   és   más jelekben való felhasználáshoz. trace_id span_id   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   /   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. trace_id span_id     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   ,   vagy     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. userId productId deviceId átadása    SDK-k vagy infrastruktúra beállításai. Specifikus konfigurációs paraméterek    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. Routing Flags  Vegye figyelembe, hogy bár a Poggyász teljesítményre gyakorolt hatása minimális, a túlzott használat jelentősen megnövelheti a hálózat és a szolgáltatás terhelését. Gondosan válassza ki, hogy mely adatokat kell valóban átadnia a Poggyászon, hogy elkerülje a teljesítményproblémákat.   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:    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. Alkalmazásintegráció    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. Exportőrök konfigurálása    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. Összesítés és tárolás    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. Adatvizualizáció  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!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Even

Google

Microsoft

Real

reflect

Trace

Read My Stories

Ez a hanganyag a történet eredeti nyelvén készült!

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

About Author

HOZZÁSZÓLÁSOK

HANG TAGOK

EZT A CIKKET BEMUTATTA

Related Stories

HackerNoon Raises $250k at $50M Valuation From Forward Research

How Emoji Credibility Indicators Add Context to HackerNoon Stories

THE LAST DAY OF NEW YORK

The Little Shop at Fishbourne

HackerNoon Raises $250k at $50M Valuation From Forward Research

How Emoji Credibility Indicators Add Context to HackerNoon Stories

THE LAST DAY OF NEW YORK

The Little Shop at Fishbourne

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps