Wprowadzenie do OpenTelemetry dla początkujących

Porozmawiajmy o OpenTelemetry — standardowym sposobie gromadzenia danych telemetrycznych niezależnym od dostawców.

Zapewnienie lepszej widoczności w aplikacji jest dużym wyzwaniem dla każdego programisty, ponieważ musi on przechwytywać dane telemetryczne aplikacji. Słownik Cambridge definiuje telemetrię jako naukę lub proces zbierania informacji o odległych obiektach i przesyłania tych informacji gdzieś drogą elektroniczną.

Na przykład pojedyncze kliknięcie lub sesja użytkownika na stronie internetowej generuje wiele żądań i śledzenia przepływających między sieciami, mikroserwisami, bazami danych itp.

OpenTelemetry to platforma umożliwiająca obserwację, zestaw dobrze dobranych komponentów, których można używać razem lub a la carte. Co więcej, twórcy frameworków i bibliotek, z których wszyscy dziś korzystamy, mają teraz standardowy sposób zapisywania danych telemetrycznych w tych bibliotekach i frameworkach, dając użytkownikom końcowym wiele gotowych wglądów w to, co te frameworki robią pod maską .

Aby zrozumieć OpenTelemetry, musisz najpierw wiedzieć, czym jest śledzenie rozproszone.

Co to jest śledzenie rozproszone?

Ponieważ nasze aplikacje stają się coraz bardziej złożone, a coraz więcej usług jest zaangażowanych w obsługę ruchu użytkowników i realizację transakcji, coraz ważniejsze staje się zrozumienie, w jaki sposób żądania przechodzą przez nasze usługi i w jaki sposób każda usługa przyczynia się do ogólnego opóźnienia. To właśnie robi rozproszone śledzenie. Przechwytuje opóźnienia żądań użytkowników i czas potrzebny każdej mikrousłudze na ścieżce do zwrócenia odpowiedzi.

Kiedy przychodzi żądanie użytkownika, chcemy utworzyć ślad, tj. wszystkie informacje opisujące, w jaki sposób nasz system odpowiada na żądanie użytkownika. Ślady składają się z zakresów, a każdy zakres oznacza określoną parę żądań i odpowiedzi zaangażowanych w obsługę żądania użytkownika. Rozpiętość nadrzędna opisuje opóźnienie zaobserwowane przez użytkownika końcowego. Rozpiętość podrzędna jest używana do zrozumienia, w jaki sposób określona usługa w systemie rozproszonym została wywołana i odpowiedziała za pomocą informacji o opóźnieniu.

Co to jest OpenTelemetry?

OpenTelemetry to projekt typu open source obsługiwany przez CNCF, który zapewnia standardowy sposób generowania danych telemetrycznych. Powstała z połączenia OpenTracingstandard generowania danych śledzenia, oraz OpenCensusktóry był standardem generowania danych metryk.

OpenTelemetry oferuje pojedynczy zestaw interfejsów API, agentów, usług kolektora i bibliotek do przechwytywania rozproszonych śladów i metryk z Twojej aplikacji. OpenTelemetry standaryzuje sposób, w jaki gromadzimy dane telemetryczne i wysyłamy je do wybranego przez Ciebie zaplecza. Zapewnia to niezależną od dostawcy ścieżkę do instrumentacji i zapewnia elastyczność zmiany zaplecza bez ponownego instrumentowania kodu.

Możesz więc instrumentować swoje aplikacje za pomocą agenta niezależnego od dostawcy, nadal wysyłając swoje metryki i ślady do dostawcy SaaS, takiego jak Datadog. Następnie, jeśli chcesz zmienić dostawcę (np. z Datadog na Dynatrace), możesz to zrobić bez zmiany kodu aplikacji.

Projekt OpenTelemetry ma na celu udostępnienie pojedynczego zestawu bibliotek API i agentów do przechwytywania metryk i rozproszonych śladów z aplikacji. Dotyczy to wielu języków i platform. Projekt OpenTelemetry obejmuje również opcjonalną usługę kolektora i ma dedykowane repozytorium specyfikacji. Żeby było jasne, OpenTelemetry to nie Jaeger ani Prometheus, które są obserwowalnymi back-endami. Ale pomaga w eksportowaniu danych do back-endów open-source i komercyjnych.

Poniżej znajdują się funkcje udostępniane przez OpenTelemetry:

  • Standaryzacja zbierania danych telemetrycznych, którą mogą śledzić organizacje, co ułatwia przechodzenie między dostawcami
  • Niezależna od dostawcy, oparta na otwartym standardzie konwencja semantyczna dla procesu gromadzenia danych
  • Collector, który można wdrożyć jako agenta lub bramy lub na wiele różnych sposobów
  • Obsługuje wiele formatów propagacji kontekstu na potrzeby migracji
  • Kompleksowe rozwiązanie do generowania, emitowania, gromadzenia, przetwarzania i eksportowania danych telemetrycznych
  • Możliwość równoległego wysyłania danych do różnych miejsc docelowych z pełną kontrolą nad nimi

Komponenty OpenTelemetry

Poniżej znajdują się podstawowe elementy OpenTelemetry:

  • Proto: Ten komponent służy do definiowania kolektorów, bibliotek oprzyrządowania itp., które są niezależnymi od języka typami interfejsów dla OpenTelemetry.
  • Kolektor: Kolektory służą do odbierania, przetwarzania i eksportowania danych telemetrycznych. Ta implementacja kolektorów musi być niezależna od dostawcy. Domyślnie wszystkie dane telemetryczne są eksportowane przez biblioteki Instrumentacji w tej lokalizacji.
  • Specyfikacja: Ten komponent opisuje wymagania i oczekiwania implementacji w różnych językach, składających się z API, SDK i danych. Interfejs API generuje dane telemetryczne, możliwości przetwarzania i eksportowania w celu implementacji interfejsów API udostępnianych przez zestawy SDK. Dane mają konwencje semantyczne umożliwiające obsługę wszystkich rodzajów dostawców bez zmiany kodu.
  • Biblioteki oprzyrządowania: Są one dostępne w wielu językach w ramach projektu OpenTelemetry. Biblioteki te służą do zapewnienia obserwowalności dla innych bibliotek, aby wszystkie aplikacje były obserwowane przez wywołania API OpenTelemetry.

Architektura OpenTelemetry

Zdjęcie z New Relic

Na wysokim poziomie OpenTelemetry składa się z trzech głównych elementów:

  • Zestaw interfejsów API służących do instrumentowania aplikacji, bibliotek i platform.
  • SDK implementuje interfejsy API.
  • Opcjonalny kolektor może pozyskiwać, agregować i eksportować dane telemetryczne w dowolnym miejscu.

Celem API jest umożliwienie tworzenia instrumentacji dla bibliotek i kodu aplikacji. Interfejs API ma cztery główne sekcje: śledzenie, liczniki, wspólny kontekst i konwencje semantyczne.

  • Tracer API obsługuje tworzenie, dodawanie adnotacji i uzupełnianie zakresów.
  • Interfejs API miernika składa się z wielu instrumentów metrycznych. Przykładami takich instrumentów są obserwatorzy, rejestratory wartości, liczniki.
  • Możesz śledzić i wykonywać kontekst zakresu, włączając interfejs API kontekstu i propagując ten kontekst zarówno w systemie, jak i poza nim.
  • Wszystkie wytyczne i zasady dotyczące głównie nazewnictwa, takie jak nazewnictwo przęseł, atrybutów, etykiet i instrumentów metrycznych, zawarte są w konwencjach semantycznych. Konwencje te są wdrażane w celu zapewnienia spójności między różnymi implementacjami językowymi i zewnętrznymi instrumentami.

We współdzielonym kontekście implementacja kontekstu znajduje się między modułem śledzącym a miernikiem i umożliwia wszystkim zapisom metryk niebędącym obserwatorami w kontekście rozpiętości wykonania. Funkcja, która umożliwia zestawom SDK przechwytywanie przykładowych rozpiętości dla wartości metryk. Możesz dostosować kontekst za pomocą propagatorów, które umożliwiają propagowanie kontekstu zakresu do iz systemu, co umożliwia prawdziwie rozproszone śledzenie.

Collector jest istotną częścią architektury OpenTelemetry. Jest to samodzielna usługa, która może odbierać, przetwarzać i eksportować dane telemetryczne z różnych źródeł, w tym z protokołów OpenCensus, Zipkin, Jaeger i OpenTelemetry. Za pomocą kolektorów można eksportować zakresy i metryki do wielu dostawców i systemów telemetrycznych typu open source.

Architektura OpenTelemetry oferuje kompletne rozwiązanie telemetryczne od razu po wyjęciu z pudełka. Możesz także dostosować, używając wielu punktów rozszerzeń zgodnie z potrzebami.

Jak działa OpenTelemetry?

Wewnątrz każdej usługi we wdrożeniu zainstaluj klienta OpenTelemetry. Klientem jest SDK; SDK z kolei ma interfejs API. Struktury i biblioteki aplikacji używają tego interfejsu API instrumentacji do opisywania wykonywanej przez nie pracy. SDK następnie eksportuje zebrane obserwacje do usługi przesyłania danych o nazwie Collector.

OpenTelemetry ma swój własny protokół danych, OTLP, ale kolektor może tłumaczyć OTLP na różne formaty, w tym Zipkin, Jaegeroraz Prometeusz. Warto zauważyć, że OpenTelemetry nie zapewnia własnego zaplecza ani narzędzia analitycznego; dzieje się tak, ponieważ jest to wysiłek standaryzacyjny w sercu OpenTelemetry. Celem jest wypracowanie uniwersalnego języka opisu działania komputerów w środowisku chmurowym. Celem nie jest ujednolicenie sposobu, w jaki analizujemy te dane. Zamiast tego mamy nadzieję, że OpenTelemetry pomoże popchnąć świat obserwowalności do przodu, umożliwiając szybkie uruchomienie nowych narzędzi analitycznych bez przebudowy całego ekosystemu oprogramowania telemetrycznego.

Gdy wysyłasz dużo danych przez system, musisz wziąć pod uwagę wiele kwestii. Na szczęście OpenTelemetry pomyślało o wszystkich rzeczach i ma rozwiązania na każde z tych pytań. Przede wszystkim OpenTelemetry jest elastyczny i obsługuje wiele formatów propagacji kontekstu. Oznacza to, że nawet jeśli istnieje standard, nadal istnieje możliwość wyboru w ramach tego standardu. Tak więc, jeśli używasz czegoś takiego jak format kontekstu śledzenia w3c lub propagacja b3, są to różne standardy w ramach standardu, które pozwalają twoim usługom łączyć kropki.

Wniosek

OpenTelemetry gromadzi różnorodne obserwacje, z których najważniejsze są rozproszone metryki śledzenia i zasoby systemowe. Zamiast traktować je jako osobne sygnały, OpenTelemetry łączy je razem i zapewnia indeksowanie oraz kontekst, który umożliwia agregację i indeksowanie krzyżowe wszystkich tych sygnałów na zapleczu.

Oprócz gromadzenia danych OpenTelemetry zapewnia funkcję przetwarzania danych i potokowania, która umożliwia zmianę formatów danych, manipulowanie danymi oraz wszystkie narzędzia potrzebne do zbudowania solidnego potoku telemetrycznego w nowoczesnym systemie.

Więc to było wszystko o OpenTelemetry, śmiało wypróbuj to narzędzie.