Co je OpenTelemetry a jak může zlepšit kvalitu vašeho backendu?

V minulosti, když jsme mluvili o backendu, obvykle jsme odkazovali na jednu velkou aplikaci s jedinou velkou databází a pro monitorování stačilo protokolování. Nyní se díky technologiím jako Kubernetes staly mikroslužby standardem. Aplikace jsou početnější a distribuovanější a tradiční protokolování již pro ladění a diagnostiku problémů v našich aplikacích nestačí.

Vynikajícím řešením pro organizaci monitorování je OpenTelemetry — moderní sada nástrojů, kterou lze použít pro ladění a analýzu výkonu distribuovaných systémů.

Tento článek je určen pro IT profesionály, kteří chtějí rozšířit své znalosti v oblasti optimalizace backendu. Níže podrobně popíšeme, co je OpenTelemetry, její klíčové koncepty a problémy, které pomáhá řešit. Pokud vás zajímá, jak může OpenTelemetry změnit váš přístup k monitorování a ladění backendových systémů, zvýšit jejich spolehlivost a efektivitu – čtěte dále.

Stručná historie OpenTelemetry

Velké technologické společnosti poprvé čelily výzvě distribuovaného protokolování a sledování na konci roku 2000. V roce 2010 Google zveřejnil článek, Dapper, rozsáhlá infrastruktura pro sledování distribuovaných systémů , která položila základy nástroje pro sledování Twitteru, Zipkin, vydaného v roce 2012.

V roce 2014 se objevil Kubernetes, který výrazně zjednodušil vývoj mikroslužeb a dalších cloudových distribuovaných systémů. To vedlo k tomu, že mnoho společností narazilo na problémy s distribuovaným protokolováním a sledováním v mikroslužbách. Pro standardizaci distribuovaného sledování byl vytvořen standard OpenTracing přijatý společností CNCF a projekt OpenCensus společnosti Google.

V roce 2019 oznámily projekty OpenTracing a OpenCensus fúzi pod názvem OpenTelemetry. Tato platforma kombinuje osvědčené postupy nashromážděné po mnoho let a umožňuje bezproblémovou integraci sledování, protokolování a metrik do jakéhokoli systému bez ohledu na jejich složitost.

OpenTelemetry dnes není jen projekt; je průmyslovým standardem pro sběr a přenos telemetrických dat. Je vyvinut a podporován komunitou specialistů a předních společností na trhu, jako jsou Google a Microsoft. Projekt se nadále vyvíjí a získává nové možnosti pro zjednodušení procesu integrace a používání.

Co je uvnitř?

OpenTelemetry je komplexní sada postupů a nástrojů, které definují, jaké signály může aplikace generovat pro interakci s vnějším světem a jak lze tyto signály shromažďovat a vizualizovat za účelem monitorování stavu aplikací a systému jako celku. Tři hlavní typy signálů jsou trasování, protokolování a shromažďování metrik .

**Podívejme se blíže na jednotlivé komponenty: \

Souvislosti

OpenTelemetry zavádí koncept operačních kontextů. Kontext primárně zahrnuje atributy jako `trace_id` (identifikátor pro aktuální operaci) a `span_id` (identifikátor dílčího požadavku, přičemž každý opakovaný pokus o dílčí požadavek má jedinečný `span_id` ).

Kromě toho může kontext obsahovat statické informace, jako je název uzlu, kde je aplikace nasazena, nebo název prostředí (prod/qa). Tato pole, známá jako zdroje v terminologii OpenTelemetry, jsou připojena ke každému protokolu, metrice nebo trasování pro snadnější vyhledávání. Kontexty mohou také zahrnovat dynamická data, jako je identifikátor aktuálního koncového bodu ( `http_path: "GET /user/:id/info"` ), která lze selektivně připojit ke skupinám protokolů, metrik nebo trasování.

Kontexty OpenTelemetry lze předávat mezi různými aplikacemi pomocí protokolů šíření kontextu. Tyto protokoly se skládají ze sad hlaviček, které se přidávají do každého požadavku HTTP nebo gRPC nebo do hlaviček zpráv pro fronty. To umožňuje následným aplikacím rekonstruovat kontext operace z těchto hlaviček.

Zde je několik příkladů šíření kontextu:

1. B3-Propagation Toto je sada hlaviček ( x-b3-* ) původně vyvinutá pro trasovací systém Zipkin. Byl adaptován do OpenTracing a používán mnoha nástroji a knihovnami. B3-Propagation nese trace_id / span_id a příznak indikující, zda je nutné vzorkování.

   
   

2. W3C Trace Context Tento standard, který vyvinula pracovní skupina W3C, sjednocuje různé přístupy k šíření kontextu do jediného standardu a je výchozí v OpenTelemetry. Dobrým příkladem použití těchto standardů je sledování provádění požadavku procházejícího mikroslužbami implementovanými různými technologiemi, aniž by byla ohrožena přesnost sledování a ladění.

Sledování

Trasování je proces zaznamenávání a následné vizualizace časové osy cesty požadavku přes více mikroslužeb.

Ve vizualizaci se každý pruh nazývá "rozpětí" a má jedinečné "span_id" . Kořenový rozsah je označován jako "trace" a má "trace_id" , který slouží jako identifikátor pro celý požadavek.

Tento typ vizualizace umožňuje:

• Analyzujte dobu provádění požadavků napříč různými systémy a databázemi a identifikujte úzká místa, která vyžadují optimalizaci.
• Detekce cyklických závislostí mezi službami.
• Najděte duplicitní požadavky. Pomocí trasovacích dat můžete také vytvářet další analýzy, jako je vytvoření mapy mikroslužeb nebo rozložení času mezi různé systémy během zpracování operace. I když data trasování nepoužíváte k vizualizaci časových os, OpenTelemetry stále generuje trace_id a span_id pro použití v jiných signálech.

Protokoly

Přes svou zdánlivou jednoduchost zůstává protokolování jedním z nejúčinnějších nástrojů pro diagnostiku problémů. OpenTelemetry vylepšuje tradiční protokolování přidáním kontextových informací. Konkrétně, pokud je přítomno aktivní trasování, atributy `trace_id` a `span_id` se automaticky přidají do protokolů a propojí je s časovou osou trasování. Atributy protokolu mohou navíc obsahovat statické informace z kontextu OpenTelemetry, jako je identifikátor uzlu, a také dynamické informace, jako je aktuální identifikátor koncového bodu HTTP (`http_path: "GET /user/:id"`).

Pomocí `trace_id` můžete najít protokoly ze všech mikroslužeb spojených s aktuálním požadavkem, zatímco `span_id` vám umožňuje rozlišovat mezi dílčími požadavky. Například v případě opakování budou mít protokoly z různých pokusů různé `span_id`. Použití těchto identifikátorů umožňuje rychlou analýzu chování celého systému v reálném čase, urychluje diagnostiku problémů a zvyšuje stabilitu a spolehlivost.

Metriky

Sběr metrik poskytuje kvantitativní data o výkonu systému, jako je latence, chybovost, využití zdrojů a další. Sledování metrik v reálném čase umožňuje pohotově reagovat na změny výkonu, předcházet poruchám a vyčerpání zdrojů a zajistit vysokou dostupnost a spolehlivost aplikace pro uživatele.

Integrace s metrickými úložnými a vizualizačními systémy, jako jsou Prometheus a Grafana, usnadňuje vizualizaci těchto dat a výrazně zjednodušuje monitorování.

Metrické kolektory

Sběrače metrik OpenTelemetry jsou kompatibilní se standardy Prometheus a OpenMetrics, což umožňuje snadný přechod na řešení OpenTelemetry bez významných změn. OpenTelemetry SDK umožňuje exportovat příklady trace_id spolu s metrikami, což umožňuje korelovat metriky s příklady protokolů a trasováním.

Korelace signálu

Protokoly, metriky a trasování společně vytvářejí komplexní pohled na stav systému:

• Protokoly poskytují informace o systémových událostech a umožňují rychlou identifikaci a řešení chyb.
• Metriky odrážejí kvalitativní a kvantitativní ukazatele výkonnosti systému, jako je doba odezvy nebo chybovost.
• Trasování doplňuje tento pohled tím, že ukazuje cestu provádění požadavků přes různé systémové komponenty, což pomáhá pochopit jejich vzájemné vztahy. Jasná korelace mezi protokoly, trasováním a metrikami je charakteristickým rysem OpenTelemetry. Grafana například umožňuje uživatelům vidět odpovídající metriky sledování a požadavků při prohlížení protokolu, což výrazně zvyšuje použitelnost a efektivitu platformy.

Kromě tří hlavních komponent OpenTelemetry zahrnuje koncepty Sampling, Baggage a Operation kontext management.

Odběr vzorků

V systémech s vysokou zátěží je objem protokolů a tras enormní, což vyžaduje značné zdroje pro infrastrukturu a ukládání dat. K vyřešení tohoto problému zahrnují standardy OpenTelemetry vzorkování signálu – možnost exportovat pouze část tras a protokolů. Můžete například exportovat podrobné signály z procenta požadavků, dlouhotrvajících požadavků nebo chybových požadavků. Tento přístup umožňuje dostatečné vzorkování pro vytváření statistik a zároveň šetří značné zdroje.

Pokud se však každý systém nezávisle rozhodne, které požadavky bude podrobně monitorovat, dostaneme roztříštěný pohled na každý požadavek. Některé systémy mohou exportovat podrobná data, zatímco jiné mohou exportovat pouze částečně nebo neexportovat vůbec.

Aby se tento problém vyřešil, mechanismy šíření kontextu OpenTelemetry přenášejí příznak vzorkování spolu s `trace_id`/`span_id`. To zajišťuje, že pokud počáteční služba přijímající požadavek uživatele rozhodne, že by měl být požadavek podrobně sledován, všechny ostatní systémy budou následovat. Jinak by všechny systémy měly částečně nebo vůbec exportovat signály, aby šetřily zdroje. Tento přístup se nazývá „Head Sampling“ – rozhodnutí učiněné na začátku zpracování požadavku, buď náhodně, nebo na základě některých vstupních atributů.

Kromě toho OpenTelemetry podporuje "Tail Sampling", kde všechny aplikace vždy exportují všechny signály podrobně, ale existuje mezilehlá vyrovnávací paměť. Po shromáždění všech dat se tato vyrovnávací paměť rozhodne, zda zachovat celá data nebo pouze částečný vzorek. Tato metoda umožňuje reprezentativnější vzorek každé kategorie požadavků (úspěšný/dlouhý/chybný), ale vyžaduje další nastavení infrastruktury.

Zavazadla

Mechanismus Baggage umožňuje přenášení libovolných párů klíč-hodnota spolu s trace_id / span_id , které se automaticky předávají mezi všemi mikroslužbami během zpracování požadavku. To je užitečné pro přenos dalších informací potřebných v rámci cesty požadavku – jako jsou informace o uživateli nebo nastavení běhového prostředí.

Příklad hlavičky pro přepravu zavazadel podle standardu W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Zde je několik příkladů použití zavazadel:

• Předávání informací o obchodním kontextu , jako je userId , productId nebo deviceId lze předávat všemi mikroslužbami. Aplikace mohou tyto informace automaticky protokolovat, což umožňuje prohledávat protokoly podle kontextu uživatele pro původní požadavek.

• Nastavení specifických konfiguračních parametrů pro sady SDK nebo infrastrukturu.

• Routing Flags Příznaky, které pomáhají vyvažovačům zátěže při rozhodování o směrování. Během testování může být nutné některé požadavky směrovat do simulovaných backendů. Jelikož jsou zavazadla přenášena automaticky všemi službami, není třeba vytvářet další protokoly – stačí nastavit pravidlo na nástroji pro vyrovnávání zatížení.

  
  

Implementace infrastruktury

Implementace OpenTelemetry na úrovni infrastruktury zahrnuje integraci backendů OpenTelemetry do architektury aplikace a konfiguraci infrastruktury pro agregaci dat.

Proces se skládá ze čtyř fází:

1. Integrace aplikací V první fázi jsou sady OpenTelemetry SDK přímo integrovány do aplikací za účelem shromažďování metrik, protokolů a trasování, což zajišťuje nepřetržitý tok dat o výkonu jednotlivých komponent systému.

   
   

2. Konfigurace exportérů Shromážděná data jsou směrována z aplikací přes exportéry do externích systémů pro další zpracování, jako jsou protokolovací, monitorovací, trasovací nebo analytické systémy, v závislosti na vašich potřebách.

   
   

3. Agregace a ukládání Tato fáze může zahrnovat normalizaci dat, jejich obohacení o další informace a slučování dat z různých zdrojů za účelem vytvoření jednotného pohledu na stav systému.

   
   

4. Vizualizace dat Nakonec jsou zpracovaná data prezentována jako řídicí panely v systémech jako Grafana (pro metriky a trasování) nebo Kibana (pro protokoly). To týmům umožňuje rychle vyhodnotit stav systému, identifikovat problémy a trendy a nastavit výstrahy na základě generovaných signálů.

Implementace aplikace

Chcete-li integrovat s aplikací, musíte připojit příslušnou sadu OpenTelemetry SDK pro používaný programovací jazyk nebo použít knihovny a rámce, které přímo podporují OpenTelemetry. OpenTelemetry často implementuje široce používaná rozhraní ze známých knihoven, což umožňuje výměny typu drop-in. Například knihovna Micrometer se běžně používá pro sběr metrik v ekosystému Java. OpenTelemetry SDK poskytuje své implementace rozhraní Micrometer, které umožňují export metrických údajů bez změny hlavního kódu aplikace. OpenTelemetry navíc nabízí implementace starších rozhraní OpenTracing a OpenCensus, což usnadňuje hladkou migraci na OpenTelemetry.

Závěr

V IT systémech se OpenTelemetry může stát klíčem k budoucnosti spolehlivých a efektivních backendů. Tento nástroj zjednodušuje ladění a monitorování a také otevírá příležitosti pro hluboké pochopení výkonu a optimalizace aplikací na nové úrovni. Připojte se ke komunitě OpenTelemetry a pomozte utvářet budoucnost, kde bude vývoj backendů jednodušší a efektivnější!