V minulosti, keď sme hovorili o backende, zvyčajne sme sa odvolávali na jednu veľkú aplikáciu s jednou veľkou databázou a na monitorovanie postačovalo protokolovanie. Teraz, vďaka technológiám ako   , sa   stali štandardom. Aplikácie sú početnejšie a distribuovanejšie a tradičné protokolovanie už nestačí na   a diagnostiku problémov v našich aplikáciách. Kubernetes mikroslužby ladenie  Vynikajúce riešenie na organizáciu monitorovania je OpenTelemetry — moderný súbor nástrojov, ktorý možno použiť na ladenie a analýzu výkonu distribuovaných systémov.  Tento článok je určený pre IT profesionálov, ktorí si chcú rozšíriť svoje znalosti v oblasti optimalizácie backendu. Nižšie podrobne popíšeme, čo je OpenTelemetry, jej kľúčové koncepty a problémy, ktoré pomáha riešiť. Ak vás zaujíma, ako môže OpenTelemetry zmeniť váš prístup k monitorovaniu a ladeniu backendových systémov, zvýšiť ich spoľahlivosť a efektivitu – čítajte ďalej.  Stručná história OpenTelemetry  Veľké technologické spoločnosti prvýkrát čelili výzve distribuovaného protokolovania a sledovania koncom 21. storočia. V roku 2010 Google zverejnil dokument,  , ktorá položila základy pre nástroj na sledovanie Twitteru, Zipkin, vydaný v roku 2012.   Dapper, veľkorozmerná infraštruktúra na sledovanie distribuovaných systémov  V roku 2014 sa objavil Kubernetes, ktorý výrazne zjednodušil vývoj mikroslužieb a iných systémov distribuovaných v cloude. To viedlo k tomu, že mnohé spoločnosti narazili na problémy s distribuovaným protokolovaním a sledovaním v mikroslužbách. Na štandardizáciu distribuovaného sledovania bol vytvorený štandard OpenTracing, ktorý prijala CNCF, a projekt OpenCensus spoločnosti Google.  V roku 2019 projekty OpenTracing a OpenCensus oznámili zlúčenie pod názvom OpenTelemetry. Táto platforma kombinuje osvedčené postupy nahromadené počas mnohých rokov, čo umožňuje bezproblémovú integráciu sledovania, protokolovania a metrík do akéhokoľvek systému bez ohľadu na ich zložitosť.  OpenTelemetry dnes nie je len projekt; ide o priemyselný štandard pre zber a prenos telemetrických údajov. Je vyvinutý a podporovaný komunitou špecialistov a popredných spoločností na trhu ako Google a Microsoft. Projekt sa naďalej vyvíja a získava nové možnosti na zjednodušenie procesu integrácie a používania.    Čo je vnútri?  OpenTelemetry je komplexný súbor postupov a nástrojov, ktoré definujú, aké signály môže aplikácia generovať na interakciu s vonkajším svetom a ako možno tieto signály zhromažďovať a vizualizovať na monitorovanie stavu aplikácií a systému ako celku. Tri hlavné typy signálov sú   a   . sledovanie, protokolovanie zhromažďovanie metrík  **Pozrime sa bližšie na každý komponent: \   Kontexty  OpenTelemetry predstavuje koncept operačných kontextov. Kontext primárne zahŕňa atribúty ako   (identifikátor pre aktuálnu operáciu) a   (identifikátor pre čiastkovú žiadosť, pričom každý opakovaný pokus čiastkovej požiadavky má jedinečný   ). `trace_id` `span_id` `span_id`  Okrem toho môže kontext obsahovať statické informácie, ako napríklad názov uzla, kde je aplikácia nasadená, alebo názov prostredia (prod/qa). Tieto polia, v terminológii OpenTelemetry známe ako zdroje, sú pripojené ku každému protokolu, metrike alebo sledovaniu, aby sa dali ľahšie vyhľadávať. Kontexty môžu zahŕňať aj dynamické údaje, ako je identifikátor aktuálneho koncového bodu (   ), ktoré možno selektívne pripojiť k skupinám protokolov, metrík alebo stôp. `http_path: "GET /user/:id/info"`  Kontexty OpenTelemetry môžu byť prenášané medzi rôznymi aplikáciami pomocou protokolov šírenia kontextu. Tieto protokoly pozostávajú zo sád hlavičiek, ktoré sa pridávajú ku každej požiadavke HTTP alebo gRPC alebo hlavičkám správ pre fronty. To umožňuje následným aplikáciám rekonštruovať operačný kontext z týchto hlavičiek.   Tu je niekoľko príkladov šírenia kontextu:    Toto je sada hlavičiek (   ) pôvodne vyvinutá pre systém sledovania Zipkin. Bol prispôsobený do OpenTracing a používa ho mnoho nástrojov a knižníc. B3-Propagation nesie   /   a príznak označujúci, či je potrebné vzorkovanie. B3-Propagation x-b3-* trace_id span_id    Tento štandard, ktorý vyvinula pracovná skupina W3C, zjednocuje rôzne prístupy šírenia kontextu do jedného štandardu a je predvolený v OpenTelemetry. Dobrým príkladom aplikácie týchto štandardov je sledovanie vykonania požiadavky prechádzajúcej cez mikroslužby implementované rôznymi technológiami bez ohrozenia presnosti monitorovania a ladenia. W3C Trace Context   Sledovanie     Sledovanie je proces zaznamenávania a následnej vizualizácie časovej osi cesty požiadavky cez viacero mikroslužieb.  Vo vizualizácii sa každý pruh nazýva „rozpätie“ a má jedinečné   . Koreňový rozsah sa označuje ako   a má   , ktorý slúži ako identifikátor pre celú požiadavku. „id_span“ "trace" "trace_id"   Tento typ vizualizácie vám umožňuje:  Analyzujte čas vykonávania požiadaviek v rôznych systémoch a databázach, aby ste identifikovali úzke miesta, ktoré si vyžadujú optimalizáciu.  Zistite cyklické závislosti medzi službami.  Nájdite duplicitné žiadosti. Pomocou údajov sledovania môžete tiež vytvoriť ďalšie analýzy, ako je vytvorenie mapy mikroslužieb alebo rozdelenie času medzi rôzne systémy počas spracovania operácie. Aj keď na vizualizáciu časových línií nepoužívate údaje sledovania, OpenTelemetry stále generuje   a   na použitie v iných signáloch. trace_id span_id   Denníky  Napriek svojej zjavnej jednoduchosti zostáva protokolovanie jedným z najsilnejších nástrojov na diagnostiku problémov. OpenTelemetry vylepšuje tradičné protokolovanie pridaním kontextových informácií. Konkrétne, ak je prítomné aktívne sledovanie, atribúty „trace_id“ a „span_id“ sa automaticky pridajú do denníkov, čím sa prepoja s časovou osou sledovania. Okrem toho môžu atribúty protokolu obsahovať statické informácie z kontextu OpenTelemetry, ako je identifikátor uzla, ako aj dynamické informácie, ako je aktuálny identifikátor koncového bodu HTTP (`http_path: "GET /user/:id"`).  Pomocou parametra `trace_id` môžete nájsť protokoly zo všetkých mikroslužieb spojených s aktuálnou požiadavkou, zatiaľ čo `span_id` vám umožňuje rozlišovať medzi čiastkovými žiadosťami. Napríklad v prípade opakovaných pokusov budú mať protokoly z rôznych pokusov rôzne `span_id`. Použitie týchto identifikátorov umožňuje rýchlu analýzu správania celého systému v reálnom čase, čo urýchľuje diagnostiku problémov a zvyšuje stabilitu a spoľahlivosť.   Metriky  Zhromažďovanie metrík poskytuje kvantitatívne údaje o výkone systému, ako je latencia, chybovosť, využitie zdrojov a ďalšie. Monitorovanie metrík v reálnom čase umožňuje promptne reagovať na zmeny výkonu, predchádzať zlyhaniam a vyčerpaniu zdrojov a zabezpečiť vysokú dostupnosť a spoľahlivosť aplikácie pre používateľov.  Integrácia s metrickými úložnými a vizualizačnými systémami, ako sú Prometheus a Grafana, uľahčuje vizualizáciu týchto údajov a výrazne zjednodušuje monitorovanie.   Metrické kolektory  Kolektory metrík OpenTelemetry sú kompatibilné so štandardmi Prometheus a OpenMetrics, čo umožňuje jednoduchý prechod na riešenia OpenTelemetry bez výrazných zmien. OpenTelemetry SDK umožňuje exportovať príklady trace_id spolu s metrikami, čo umožňuje korelovať metriky s príkladmi protokolov a trasovaním.  Korelácia signálu   Protokoly, metriky a sledovanie spolu vytvárajú komplexný pohľad na stav systému:  Protokoly poskytujú informácie o systémových udalostiach, čo umožňuje rýchlu identifikáciu a riešenie chýb.  Metriky odrážajú kvalitatívne a kvantitatívne ukazovatele výkonnosti systému, ako sú časy odozvy alebo chybovosť.  Sledovanie dopĺňa tento pohľad tým, že ukazuje cestu vykonávania požiadaviek cez rôzne systémové komponenty, čo pomáha pochopiť ich vzájomné vzťahy. Jasná korelácia medzi protokolmi, stopami a metrikami je charakteristickou črtou OpenTelemetry. Napríklad Grafana umožňuje používateľom vidieť zodpovedajúce metriky sledovania a požiadaviek pri prezeraní denníka, čo výrazne zvyšuje použiteľnosť a efektivitu platformy.   Okrem troch základných komponentov OpenTelemetry zahŕňa koncepty Sampling, Baggage a operačné kontextové riadenie.   Odber vzoriek  V systémoch s vysokou záťažou je objem protokolov a stôp obrovský, čo si vyžaduje značné zdroje na infraštruktúru a ukladanie údajov. Na vyriešenie tohto problému štandardy OpenTelemetry zahŕňajú vzorkovanie signálu – možnosť exportovať iba časť stôp a protokolov. Môžete napríklad exportovať podrobné signály z percenta požiadaviek, dlhotrvajúcich požiadaviek alebo chybových požiadaviek. Tento prístup umožňuje dostatočné vzorkovanie na vytváranie štatistík a zároveň šetrí značné zdroje.  Ak sa však každý systém nezávisle rozhodne, ktoré požiadavky bude podrobne monitorovať, skončíme s roztriešteným pohľadom na každú požiadavku. Niektoré systémy môžu exportovať podrobné údaje, zatiaľ čo iné môžu exportovať iba čiastočne alebo vôbec.  Aby sa tento problém vyriešil, mechanizmy šírenia kontextu OpenTelemetry prenášajú príznak vzorkovania spolu s parametrom `trace_id`/`span_id`. To zaisťuje, že ak počiatočná služba prijímajúca požiadavku používateľa rozhodne, že požiadavka by mala byť podrobne monitorovaná, všetky ostatné systémy budú nasledovať tento príklad. V opačnom prípade by všetky systémy mali čiastočne alebo vôbec exportovať signály, aby šetrili zdroje. Tento prístup sa nazýva "Head Sampling" - rozhodnutie urobené na začiatku spracovania požiadavky, buď náhodne alebo na základe niektorých vstupných atribútov.  Okrem toho OpenTelemetry podporuje „vzorkovanie chvosta“, kde všetky aplikácie vždy podrobne exportujú všetky signály, ale existuje medziľahlá vyrovnávacia pamäť. Po zhromaždení všetkých údajov sa táto vyrovnávacia pamäť rozhodne, či si ponechá úplné údaje alebo len čiastočnú vzorku. Táto metóda umožňuje reprezentatívnejšiu vzorku každej kategórie požiadaviek (úspešná/dlhá/chybná), vyžaduje si však dodatočné nastavenie infraštruktúry.   Batožina  Mechanizmus Baggage umožňuje prenos ľubovoľných párov kľúč – hodnota spolu s   /   , pričom automaticky prechádza medzi všetkými mikroslužbami počas spracovania požiadavky. Je to užitočné na prenos dodatočných informácií potrebných v rámci cesty požiadavky – ako sú informácie o používateľovi alebo nastavenia prostredia runtime. trace_id span_id     Príklad hlavičky na prepravu batožiny podľa štandardu W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5   Tu je niekoľko príkladov použitia batožiny:    , ako sú   ,   alebo   možno prenášať cez všetky mikroslužby. Aplikácie môžu tieto informácie automaticky zaprotokolovať, čo umožňuje vyhľadávanie v protokoloch podľa používateľského kontextu pre pôvodnú požiadavku. Odovzdávanie informácií o obchodnom kontexte userId productId deviceId    pre súpravy SDK alebo infraštruktúru. Špecifické nastavenia konfiguračných parametrov    Príznaky, ktoré pomáhajú nástrojom na vyrovnávanie zaťaženia pri rozhodovaní o smerovaní. Počas testovania môže byť potrebné nasmerovať niektoré požiadavky na zosmiešňovanie backendov. Keďže batožina sa prenáša automaticky prostredníctvom všetkých služieb, nie je potrebné vytvárať ďalšie protokoly – stačí nastaviť pravidlo na vyrovnávacom zaťažení. Príznaky smerovania  Všimnite si, že aj keď je vplyv Baggage na výkon minimálny, nadmerné používanie môže výrazne zvýšiť zaťaženie siete a služieb. Starostlivo si vyberte, ktoré údaje skutočne potrebujete preniesť cez Batožinu, aby ste sa vyhli problémom s výkonom.   Implementácia infraštruktúry  Implementácia OpenTelemetry na úrovni infraštruktúry zahŕňa integráciu backendov OpenTelemetry do aplikačnej architektúry a konfiguráciu infraštruktúry na agregáciu dát.   Proces pozostáva zo štyroch fáz:    V prvej fáze sú súpravy OpenTelemetry SDK priamo integrované do aplikácií na zhromažďovanie metrík, protokolov a stôp, čím sa zabezpečuje nepretržitý tok údajov o výkone každého komponentu systému. Integrácia aplikácií    Zhromaždené údaje sú smerované z aplikácií cez exportéry do externých systémov na ďalšie spracovanie, ako sú protokolovacie, monitorovacie, sledovacie alebo analytické systémy, v závislosti od vašich potrieb. Konfigurácia exportérov    Táto fáza môže zahŕňať normalizáciu údajov, ich obohatenie o ďalšie informácie a zlúčenie údajov z rôznych zdrojov, aby sa vytvoril jednotný pohľad na stav systému. Agregácia a ukladanie    Nakoniec sú spracované údaje prezentované ako dashboardy v systémoch ako Grafana (pre metriky a stopy) alebo Kibana (pre protokoly). To umožňuje tímom rýchlo posúdiť stav systému, identifikovať problémy a trendy a nastaviť výstrahy na základe generovaných signálov. Vizualizácia údajov  Implementácia aplikácie  Na integráciu s aplikáciou musíte pripojiť príslušnú súpravu OpenTelemetry SDK pre používaný programovací jazyk alebo použiť knižnice a rámce, ktoré priamo podporujú OpenTelemetry. OpenTelemetry často implementuje široko používané rozhrania zo známych knižníc, čo umožňuje výmeny typu drop-in. Napríklad knižnica Micrometer sa bežne používa na zber metrík v ekosystéme Java. OpenTelemetry SDK poskytuje svoje implementácie rozhraní Micrometer, ktoré umožňujú export metrických údajov bez zmeny hlavného aplikačného kódu. Okrem toho OpenTelemetry ponúka implementácie starších rozhraní OpenTracing a OpenCensus, čo uľahčuje hladkú migráciu na OpenTelemetry.  Záver  V IT systémoch sa OpenTelemetry môže stať kľúčom k budúcnosti spoľahlivých a efektívnych backendov. Tento nástroj zjednodušuje ladenie a monitorovanie a tiež otvára príležitosti na hlboké pochopenie výkonu a optimalizácie aplikácií na novej úrovni. Pripojte sa ku komunite OpenTelemetry a pomôžte formovať budúcnosť, v ktorej bude vývoj backendov jednoduchší a efektívnejší!

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

Tento zvuk je vyrobený v pôvodnom jazyku príbehu!

Čo je OpenTelemetry a ako môže zlepšiť kvalitu vášho backendu?

About Author

KOMENTÁRE

ZAVISTE ŠTÍTKY

TENTO ČLÁNOK BOL PREDSTAVENÝ V

Related Stories

Mutmut: a Python mutation testing system

112 Stories To Learn About Hackernoon Community

Code Smell 298 - How to Fix Microsoft Windows Time Waste

When Blood Told

Mutmut: a Python mutation testing system

112 Stories To Learn About Hackernoon Community

Code Smell 298 - How to Fix Microsoft Windows Time Waste

When Blood Told

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps