W przeszłości, gdy mówiliśmy o zapleczu, zwykle odnosiliśmy się do jednej dużej aplikacji z pojedynczą, dużą bazą danych, a rejestrowanie było wystarczające do monitorowania. Teraz, dzięki technologiom takim jak   ,   stały się standardem. Aplikacje są liczniejsze i bardziej rozproszone, a tradycyjne rejestrowanie nie wystarcza już do   i diagnozowania problemów w naszych aplikacjach. Kubernetes mikrousługi debugowania  Doskonałym rozwiązaniem do organizacji monitoringu jest OpenTelemetry — nowoczesny zestaw narzędzi, który można wykorzystać do debugowania i analizy wydajności systemów rozproszonych.  Niniejszy artykuł jest przeznaczony dla specjalistów IT, którzy chcą poszerzyć swoją wiedzę na temat optymalizacji zaplecza. Poniżej szczegółowo opisujemy, czym jest OpenTelemetry, jego kluczowe koncepcje i problemy, które pomaga rozwiązać. Jeśli interesuje Cię, w jaki sposób OpenTelemetry może zmienić Twoje podejście do monitorowania i debugowania systemów zaplecza, zwiększając ich niezawodność i wydajność — czytaj dalej.  Krótka historia OpenTelemetry  Duże firmy technologiczne po raz pierwszy stanęły przed wyzwaniem rozproszonego rejestrowania i śledzenia pod koniec lat 2000. W 2010 r. Google opublikowało artykuł,  , która położyła podwaliny pod narzędzie śledzące Twittera o nazwie Zipkin, wydane w 2012 r.   Dapper, infrastruktura śledzenia rozproszonych systemów na dużą skalę  W 2014 r. pojawił się Kubernetes, znacznie upraszczając rozwój mikrousług i innych rozproszonych systemów w chmurze. Spowodowało to, że wiele firm napotkało problemy z rozproszonym rejestrowaniem i śledzeniem w mikrousługach. Aby ujednolicić rozproszone śledzenie, stworzono standard OpenTracing, przyjęty przez CNCF i projekt OpenCensus firmy Google.  W 2019 r. projekty OpenTracing i OpenCensus ogłosiły fuzję pod nazwą OpenTelemetry. Platforma ta łączy najlepsze praktyki gromadzone przez wiele lat, umożliwiając bezproblemową integrację śledzenia, rejestrowania i metryk w dowolnym systemie, niezależnie od ich złożoności.  Obecnie OpenTelemetry nie jest tylko projektem; jest to standard branżowy do zbierania i przesyłania danych telemetrycznych. Jest rozwijany i wspierany przez społeczność specjalistów i wiodące na rynku firmy, takie jak Google i Microsoft. Projekt nadal ewoluuje, zyskując nowe możliwości, aby uprościć proces integracji i użytkowania.    Co jest w środku?  OpenTelemetry to kompleksowy zestaw praktyk i narzędzi, które definiują, jakie sygnały aplikacja może generować, aby wchodzić w interakcję ze światem zewnętrznym, oraz w jaki sposób te sygnały mogą być zbierane i wizualizowane, aby monitorować stan aplikacji i całego systemu. Trzy główne typy sygnałów to   i   . śledzenie, rejestrowanie zbieranie metryk  **Przyjrzyjmy się bliżej każdemu komponentowi: \   Konteksty  OpenTelemetry wprowadza koncepcję kontekstów operacji. Kontekst obejmuje przede wszystkim atrybuty takie jak   (identyfikator bieżącej operacji) i   (identyfikator podżądania, przy czym każda ponowna próba podżądania ma unikalny   ). `trace_id` `span_id` `span_id`  Ponadto kontekst może zawierać informacje statyczne, takie jak nazwa węzła, w którym wdrożono aplikację lub nazwa środowiska (prod/qa). Te pola, znane jako zasoby w terminologii OpenTelemetry, są dołączane do każdego dziennika, metryki lub śladu w celu łatwiejszego wyszukiwania. Konteksty mogą również zawierać dane dynamiczne, takie jak identyfikator bieżącego punktu końcowego (   ), które można selektywnie dołączać do grup dzienników, metryk lub śladów. `http_path: "GET /user/:id/info"`  Konteksty OpenTelemetry mogą być przekazywane między różnymi aplikacjami za pomocą protokołów propagacji kontekstu. Protokoły te składają się z zestawów nagłówków, które są dodawane do każdego żądania HTTP lub gRPC lub nagłówków komunikatów dla kolejek. Umożliwia to aplikacjom downstream rekonstrukcję kontekstu operacji z tych nagłówków.   Oto kilka przykładów propagacji kontekstu:    To zestaw nagłówków (   ) pierwotnie opracowany dla systemu śledzenia Zipkin. Został zaadaptowany do OpenTracing i używany przez wiele narzędzi i bibliotek. B3-Propagation zawiera   /   i flagę wskazującą, czy próbkowanie jest konieczne. B3-Propagation x-b3-* trace_id span_id    Opracowany przez grupę roboczą W3C, ten standard ujednolica różne podejścia do propagacji kontekstu w jeden standard i jest domyślny w OpenTelemetry. Dobrym przykładem zastosowania tych standardów jest śledzenie wykonania żądania przechodzącego przez mikrousługi zaimplementowane przy użyciu różnych technologii bez uszczerbku dla dokładności monitorowania i debugowania. Kontekst śledzenia W3C   Rysunek kalkowy     Śledzenie to proces rejestrowania i późniejszej wizualizacji osi czasu ścieżki żądania poprzez wiele mikrousług.  W wizualizacji każdy pasek nazywany jest „span” i ma unikalny   . Główny span nazywany jest   i ma   , który służy jako identyfikator całego żądania. „span_id” „trace” „trace_id”   Ten typ wizualizacji pozwala na:  Analizuj czas realizacji żądań w różnych systemach i bazach danych, aby zidentyfikować wąskie gardła wymagające optymalizacji.  Wykrywanie zależności cyklicznych pomiędzy usługami.  Znajdź duplikaty żądań. Używając danych śledzenia, możesz również tworzyć dodatkowe analizy, takie jak tworzenie mapy mikrousług lub dystrybuowanie czasu w różnych systemach podczas przetwarzania operacji. Nawet jeśli nie używasz danych śledzenia do wizualizacji osi czasu, OpenTelemetry nadal generuje   i   do wykorzystania w innych sygnałach. trace_id span_id   Dzienniki  Pomimo pozornej prostoty, rejestrowanie pozostaje jednym z najpotężniejszych narzędzi do diagnozowania problemów. OpenTelemetry rozszerza tradycyjne rejestrowanie, dodając informacje kontekstowe. W szczególności, jeśli obecny jest aktywny ślad, atrybuty `trace_id` i `span_id` są automatycznie dodawane do dzienników, łącząc je z osią czasu śladu. Ponadto atrybuty dziennika mogą obejmować statyczne informacje z kontekstu OpenTelemetry, takie jak identyfikator węzła, a także dynamiczne informacje, takie jak bieżący identyfikator punktu końcowego HTTP (`http_path: "GET /user/:id"`).  Używając `trace_id` możesz znaleźć logi ze wszystkich mikrousług powiązanych z bieżącym żądaniem, podczas gdy `span_id` pozwala na rozróżnianie podżądań. Na przykład w przypadku ponownych prób logi z różnych prób będą miały różne `span_id`. Używanie tych identyfikatorów umożliwia szybką analizę zachowania całego systemu w czasie rzeczywistym, przyspieszając diagnostykę problemów i zwiększając stabilność i niezawodność.   Metryka  Zbiór metryk dostarcza ilościowych danych o wydajności systemu, takich jak opóźnienia, wskaźniki błędów, wykorzystanie zasobów i inne. Monitorowanie metryk w czasie rzeczywistym pozwala szybko reagować na zmiany wydajności, zapobiegać awariom i wyczerpywaniu się zasobów oraz zapewniać wysoką dostępność i niezawodność aplikacji dla użytkowników.  Integracja z systemami przechowywania i wizualizacji danych metrycznych, takimi jak Prometheus i Grafana, ułatwia wizualizację tych danych, znacznie upraszczając monitorowanie.   Kolektory metryczne  Kolektory metryk OpenTelemetry są zgodne ze standardami Prometheus i OpenMetrics, umożliwiając łatwe przejście do rozwiązań OpenTelemetry bez znaczących zmian. OpenTelemetry SDK umożliwia eksportowanie przykładów trace_id wraz z metrykami, co umożliwia korelację metryk z przykładami logów i śladami.  Korelacja sygnału   Łącznie logi, metryki i śledzenie tworzą kompleksowy obraz stanu systemu:  Dzienniki dostarczają informacji o zdarzeniach systemowych, umożliwiając szybką identyfikację i rozwiązywanie błędów.  Metryki odzwierciedlają jakościowe i ilościowe wskaźniki wydajności systemu, takie jak czasy reakcji lub wskaźniki błędów.  Tracing uzupełnia ten widok, pokazując ścieżkę wykonania żądania przez różne komponenty systemu, pomagając zrozumieć ich wzajemne powiązania. Wyraźna korelacja między logami, śladami i metrykami jest charakterystyczną cechą OpenTelemetry. Na przykład Grafana pozwala użytkownikom zobaczyć odpowiadające im metryki śledzenia i żądania podczas przeglądania logu, co znacznie zwiększa użyteczność i wydajność platformy.   Oprócz trzech podstawowych komponentów, OpenTelemetry obejmuje koncepcje pobierania próbek, bagażu i zarządzania kontekstem operacyjnym.   Próbowanie  W systemach o dużym obciążeniu objętość logów i śladów staje się ogromna, wymagając znacznych zasobów na infrastrukturę i przechowywanie danych. Aby rozwiązać ten problem, standardy OpenTelemetry obejmują próbkowanie sygnałów — możliwość eksportowania tylko części śladów i logów. Na przykład możesz eksportować szczegółowe sygnały z procentu żądań, długotrwałych żądań lub żądań błędów. To podejście umożliwia wystarczające próbkowanie w celu tworzenia statystyk przy jednoczesnym oszczędzaniu znacznych zasobów.  Jednakże jeśli każdy system niezależnie decyduje, które żądania monitorować szczegółowo, kończymy z fragmentarycznym widokiem każdego żądania. Niektóre systemy mogą eksportować szczegółowe dane, podczas gdy inne mogą eksportować tylko częściowo lub wcale.  Aby rozwiązać ten problem, mechanizmy propagacji kontekstu OpenTelemetry przesyłają flagę próbkowania wraz z `trace_id`/`span_id`. Zapewnia to, że jeśli początkowa usługa odbierająca żądanie użytkownika zdecyduje, że żądanie powinno być monitorowane szczegółowo, wszystkie inne systemy pójdą w jej ślady. W przeciwnym razie wszystkie systemy powinny częściowo lub wcale eksportować sygnały, aby oszczędzać zasoby. To podejście nazywa się „Head Sampling” — decyzja podejmowana na początku przetwarzania żądania, losowo lub na podstawie pewnych atrybutów wejściowych.  Poza tym OpenTelemetry obsługuje „Tail Sampling”, gdzie wszystkie aplikacje zawsze eksportują wszystkie sygnały szczegółowo, ale istnieje bufor pośredni. Po zebraniu wszystkich danych bufor ten decyduje, czy zachować pełne dane, czy zachować tylko częściową próbkę. Ta metoda umożliwia bardziej reprezentatywną próbkę każdej kategorii żądania (pomyślne/długie/błąd), ale wymaga dodatkowej konfiguracji infrastruktury.   Bagaż  Mechanizm Baggage umożliwia przesyłanie dowolnych par klucz-wartość wraz z   /   , automatycznie przekazując je między wszystkimi mikrousługami podczas przetwarzania żądania. Jest to przydatne do przesyłania dodatkowych informacji potrzebnych w całej ścieżce żądania — takich jak informacje o użytkowniku lub ustawienia środowiska wykonawczego. trace_id span_id     Przykład nagłówka do przesyłania bagażu zgodnie ze standardem W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5   Oto kilka przykładów wykorzystania bagażu:    takich jak   ,   lub   może być przekazywane przez wszystkie mikrousługi. Aplikacje mogą automatycznie rejestrować te informacje, umożliwiając przeszukiwanie logów według kontekstu użytkownika dla oryginalnego żądania. Przekazywanie informacji o kontekście biznesowym, userId productId deviceId    dla zestawów SDK lub infrastruktury. Konkretne ustawienia parametrów konfiguracji    Flagi, które pomagają modułom równoważenia obciążenia podejmować decyzje dotyczące routingu. Podczas testowania niektóre żądania mogą wymagać skierowania do pozorowanych zapleczy. Ponieważ bagaż jest przesyłany automatycznie przez wszystkie usługi, nie ma potrzeby tworzenia dodatkowych protokołów — wystarczy skonfigurować regułę w module równoważenia obciążenia. Flagi routingu  Należy pamiętać, że chociaż wpływ Baggage na wydajność jest minimalny, nadmierne użytkowanie może znacznie zwiększyć obciążenie sieci i usług. Ostrożnie wybierz dane, które naprawdę musisz przekazać przez Baggage, aby uniknąć problemów z wydajnością.   Wdrażanie infrastruktury  Wdrożenie OpenTelemetry na poziomie infrastruktury wiąże się ze zintegrowaniem zaplecza OpenTelemetry z architekturą aplikacji i skonfigurowaniem infrastruktury pod kątem agregacji danych.   Proces składa się z czterech etapów:    Na pierwszym etapie zestawy SDK OpenTelemetry są bezpośrednio integrowane z aplikacjami w celu zbierania metryk, dzienników i śladów, co zapewnia ciągły przepływ danych o wydajności każdego komponentu systemu. Integracja aplikacji    Zebrane dane są przesyłane z aplikacji poprzez eksportery do systemów zewnętrznych w celu dalszego przetwarzania, np. rejestrowania, monitorowania, śledzenia lub analizowania w zależności od potrzeb użytkownika. Konfigurowanie eksporterów    Na tym etapie dane mogą być normalizowane, wzbogacane o dodatkowe informacje i scalane z różnych źródeł w celu utworzenia ujednoliconego obrazu stanu systemu. Agregacja i przechowywanie    Na koniec przetworzone dane są prezentowane jako pulpity nawigacyjne w systemach takich jak Grafana (dla metryk i śladów) lub Kibana (dla logów). Pozwala to zespołom na szybką ocenę kondycji systemu, identyfikację problemów i trendów oraz skonfigurowanie alertów na podstawie wygenerowanych sygnałów. Wizualizacja danych  Wdrażanie aplikacji  Aby zintegrować się z aplikacją, musisz połączyć odpowiedni zestaw SDK OpenTelemetry dla używanego języka programowania lub zastosować biblioteki i frameworki, które bezpośrednio obsługują OpenTelemetry. OpenTelemetry często implementuje szeroko stosowane interfejsy ze znanych bibliotek, umożliwiając zamienniki typu drop-in. Na przykład biblioteka Micrometer jest powszechnie używana do zbierania metryk w ekosystemie Java. Zestaw SDK OpenTelemetry zapewnia implementacje interfejsów Micrometer, umożliwiając eksport metryk bez zmiany głównego kodu aplikacji. Ponadto OpenTelemetry oferuje implementacje starszych interfejsów OpenTracing i OpenCensus, ułatwiając płynną migrację do OpenTelemetry.  Wniosek  W systemach informatycznych OpenTelemetry może stać się kluczem do przyszłości niezawodnych i wydajnych back-endów. To narzędzie upraszcza debugowanie i monitorowanie, a także otwiera możliwości głębokiego zrozumienia wydajności aplikacji i optymalizacji na nowym poziomie. Dołącz do społeczności OpenTelemetry, aby pomóc kształtować przyszłość, w której rozwój back-endów jest prostszy i bardziej efektywny!

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

Ten dźwięk jest produkowany w oryginalnym języku historii!

Czym jest OpenTelemetry i jak może poprawić jakość Twojego zaplecza?

About Author

UWAGI

ZAWIEŚĆ TAGI

ARTYKUŁ TEN ZOSTAŁ PREZENTOWANY W

Related Stories

MashRadar Reviewed HackerNoon - Everything You Need to Know

Verified Writers

Google's Gemini AI: A Thought Experiment in Deception

How HackerNoon Feels About AI Generated Content (Hint: 👎🏽)

MashRadar Reviewed HackerNoon - Everything You Need to Know

Verified Writers

Google's Gemini AI: A Thought Experiment in Deception

How HackerNoon Feels About AI Generated Content (Hint: 👎🏽)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps