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

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 Kubernetes , mikrousługi stały się standardem. Aplikacje są liczniejsze i bardziej rozproszone, a tradycyjne rejestrowanie nie wystarcza już do debugowania i diagnozowania problemów w naszych aplikacjach.

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ł, Dapper, infrastruktura śledzenia rozproszonych systemów na dużą skalę , która położyła podwaliny pod narzędzie śledzące Twittera o nazwie Zipkin, wydane w 2012 r.

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 śledzenie, rejestrowanie i zbieranie metryk .

**Przyjrzyjmy się bliżej każdemu komponentowi: \

Konteksty

OpenTelemetry wprowadza koncepcję kontekstów operacji. Kontekst obejmuje przede wszystkim atrybuty takie jak `trace_id` (identyfikator bieżącej operacji) i `span_id` (identyfikator podżądania, przy czym każda ponowna próba podżądania ma unikalny `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 ( `http_path: "GET /user/:id/info"` ), które można selektywnie dołączać do grup dzienników, metryk lub śladów.

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:

1. B3-Propagation To zestaw nagłówków ( x-b3-* ) pierwotnie opracowany dla systemu śledzenia Zipkin. Został zaadaptowany do OpenTracing i używany przez wiele narzędzi i bibliotek. B3-Propagation zawiera trace_id / span_id i flagę wskazującą, czy próbkowanie jest konieczne.

   
   

2. Kontekst śledzenia W3C 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.

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 „span_id” . Główny span nazywany jest „trace” i ma „trace_id” , który służy jako identyfikator całego żądania.

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 trace_id i span_id do wykorzystania w innych sygnałach.

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 trace_id / span_id , 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.

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:

• Przekazywanie informacji o kontekście biznesowym, takich jak userId , productId lub deviceId 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.

• Konkretne ustawienia parametrów konfiguracji dla zestawów SDK lub infrastruktury.

• Flagi routingu 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.

  
  

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:

1. Integracja aplikacji 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.

   
   

2. Konfigurowanie eksporterów 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.

   
   

3. Agregacja i przechowywanie 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.

   
   

4. Wizualizacja danych 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.

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!