🥇Rozproszona śledzenie: wszystko zrobiliśmy źle

Przyp. tłum.: Autorem tego materiału jest Cindy Sridharan, inżynier z firmy imgix, zajmującej się rozwojem API, a w szczególności testowaniem mikroserwisów. W tym artykule dzieli się swoim szczegółowym spojrzeniem na aktualne problemy w zakresie rozproszonego śledzenia, gdzie, jej zdaniem, brakuje naprawdę skutecznych narzędzi do rozwiązania bieżących problemów.

[Ilustracja pochodzi z innego materiału na temat rozproszonego śledzenia.]

Uważa się, że rozproszone śledzenie jest trudne do wdrożenia, a jego efekty są co najwyżej wątpliwe. Problematykę śledzenia tłumaczy się wieloma przyczynami, a często wskazuje się na czasochłonność konfiguracji każdego komponentu systemu do przekazywania odpowiednich nagłówków wraz z każdym żądaniem. Choć ten problem rzeczywiście istnieje, nie można go nazywać nieprzezwyciężonym. Jak zresztą nie tłumaczy, dlaczego programiści niechętnie podchodzą do śledzenia (nawet tego, które już działa).

Główna trudność z rozproszonym śledzeniem to nie zbieranie danych, nie standaryzacja formatów ich przekazywania i prezentacji wyników ani określenie, kiedy, gdzie i jak pobierać próbki. Nie próbuję wcale przedstawiać trywialnymi tych "problemów z przyswajalnością" — w rzeczywistości istnieją dość istotne wyzwania techniczne i (jeśli rozważamy naprawdę otwarte standardy i protokoły ) polityczne, które muszą zostać pokonane, aby te problemy mogły zostać uznane za rozwiązane.Jednakże, zakładając, że wszystkie te problemy zostały rozwiązane, istnieje duże prawdopodobieństwo, że nic znaczącego się nie zmieni z punktu widzenia

doświadczenia użytkownika końcowego . Śledzenie wciąż może nie przynosić praktycznych korzyści w najczęstszych scenariuszach debugowania — nawet po jego wdrożeniu.Takie odmienne śledzenie

Rozproszone śledzenie obejmuje kilka odseparowanych komponentów:

wyposażenie aplikacji i middleware w środki kontrolne;

przekazywanie rozproszonego kontekstu;
zbieranie śledzeń;
przechowywanie śledzeń;
ich wydobywanie i wizualizacja.
ich wydobycie i wizualizacja.

Wiele rozmów na temat rozproszonego śledzenia sprowadza się do postrzegania go jako pewnej operacji unarnej, której jedynym celem jest pomoc w pełnej diagnostyce systemu. W dużej mierze wiąże się to z tym, jak historycznie kształtowały się wyobrażenia o rozproszonym śledzeniu. W wpisie na blogu, kiedy otwarte zostały źródła Zipkin, wspomniano, że on [Zipkin] przyspiesza Twittera.Pierwsze komercyjne oferty dla śledzenia były także promowane jako narzędzia APM..

Przyp. tłum.Aby dalszy tekst był lepiej odbierany, zdefiniujmy dwa podstawowe terminy zgodnie z dokumentacją projektu OpenTracing.:

Span — podstawowy element rozproszonego śledzenia. Stanowi opis pewnego procesu roboczego (na przykład zapytania do bazy danych) z nazwą, czasem rozpoczęcia i zakończenia, tagami, logami i kontekstem.
Wiązania (span'y) zazwyczaj zawierają odniesienia do innych wiązań, co pozwala łączyć wiele wiązań w Trace — wizualizację życia zapytania w trakcie jego przemieszczenia się w rozproszonej sieci.

Ślady (trace'y) zawierają niezwykle cenne dane, które mogą pomoc w takich zadaniach jak: testowanie w produkcji, przeprowadzanie testów odzyskiwania awaryjnego, testowanie z wprowadzaniem błędów itd. W rzeczywistości niektóre firmy już wykorzystują śledzenie do podobnych celów. Zaczniemy od tego, że uniwersalne przekazywanie kontekstu ma także inne zastosowania poza prostym przenoszeniem wiązań do systemu przechowywania:

Na przykład, Uber używa wyniki śledzenia do rozdzielania ruchu testowego i produkcyjnego.
Facebook używa dane śladów do analizy krytycznej ścieżki oraz do przełączania ruchu podczas regularnych testów odzyskiwania awaryjnego.
Również sieć społecznościowa stosuje notatniki Jupyter, umożliwiające programistom wykonywanie dowolnych zapytań na podstawie wyników śledzenia.
Zwolennicy LDFI (wstrzykiwanie błędów napędzane przez pokrewieństwo) używają rozproszone ślady do testowania z wprowadzaniem błędów.

Żaden z wymienionych powyżej wariantów nie odnosi się w całości do scenariusza debugowania,w którym inżynier próbuje rozwiązać problem, przyglądając się śladom.

Kiedy już dochodzi do scenariusza debugowania, podstawowym interfejsem pozostaje diagram traceview (choć niektórzy nazywają go także «diagramem Gantta», «diagramem kaskadowym» lub ). Podmam na myśli (choć niektórzy nazywają go także i się odnosi wszystkie span'y oraz towarzyszące metadane, które razem tworzą ślad. Każdy system śledzenia o otwartym kodzie źródłowym, jak również każde komercyjne rozwiązanie do śledzenia oferuje podstawę opartą na (choć niektórzy nazywają go także interfejs użytkownika do wizualizacji, szczegółowego przedstawienia i filtrowania śladów.

Problem ze wszystkimi systemami śledzenia, z którymi miałem do czynienia do tej pory, polega na tym, że końcowa wizualizacja (traceview) praktycznie w całości odzwierciedla cechy procesu generowania śladu. Nawet gdy oferowane są alternatywne wizualizacje: mapy intensywności (heatmap), topologie usług, histogramy opóźnień (latency), ostatecznie wszystkie one sprowadzają się do (choć niektórzy nazywają go także.

W przeszłości narzekałem na to, że większość „innowacji” w obszarze śledzenia dotyczących UI/UX wydaje się ograniczać do włączenia dodatkowych metadanych w ślad, umieszczając w nich informacje o wysokiej kardynalności (high-cardinality) lub dostarczania możliwości szczegółowego przedstawienia konkretnych span'ów lub wykonywania zapytań między- i wewnątrz-śladami. Przy tym (choć niektórzy nazywają go także pozostaje głównym środkiem wizualizacji. Dopóki taka sytuacja będzie się utrzymywać, rozproszone śledzenie zajmie (w najlepszym wypadku) 4. miejsce jako narzędzie debugowania, za metrykami, logami i stack trace'ami, a w najgorszym przypadku okaże się pustą stratą pieniędzy i czasu.

Problem z traceview

Przeznaczenie (choć niektórzy nazywają go także polega na dostarczeniu pełnego obrazu ruchu pojedynczego zapytania przez wszystkie komponenty rozproszonego systemu, z którymi jest ono związane. Niektóre bardziej zaawansowane systemy śledzenia pozwalają na szczegółowe przedstawienie pojedynczych span'ów oraz przegląd czasowego podziału wciąż jednego procesu (gdy span'y mają granice funkcjonalne).

Podstawowym założeniem architektury mikroserwisów jest idea, że struktura organizacyjna rozwija się razem z potrzebami firmy. Zwolennicy mikroserwisów twierdzą, że rozdzielenie różnych zadań biznesowych na osobne serwisy pozwala małym, autonomicznym zespołom programistycznym kontrolować cały cykl życia takich usług, dając im możliwość niezależnego tworzenia, testowania i wdrażania tych serwisów. Jednak wadą tego rozdzielenia jest utrata informacji o tym, jak każdy serwis współdziała z innymi. W takich warunkach zdalne śledzenie staje się niezastąpionym narzędziem dla debugowania, skomplikowanych interakcji między serwisami.

Jeśli masz naprawdę oszałamiająco skomplikowany rozproszony system, to nikt nie jest w stanie zachować w pamięci jego pełnego obrazka. W rzeczywistości opracowanie narzędzia z założeniem, że jest to w ogóle możliwe, jest czymś w rodzaju antywzoru (nieefektywnego i nieproduktywnego podejścia). W idealnym przypadku do debugowania potrzebne jest narzędzie, które pomaga zawęzić obszar poszukiwań, aby inżynierowie mogli skupić się na podzbiorze wymiarów (serwisach/użytkownikach/gospodarzach itp.), które mają związek z rozważanym scenariuszem problemu. Przy ustalaniu przyczyny awarii inżynierowie nie są zobowiązani do rozwiązywania tego, co działo się we wszystkich serwisach jednocześnie, ponieważ takie wymaganie sprzeciwiałoby się samej idei architektury mikroserwisowej.

Jednak traceview stanowi właśnie to. Tak, niektóre systemy śledzenia oferują skompresowane traceview, gdy liczba spanów w śladzie jest tak duża, że nie można ich wyświetlić w ramach jednej wizualizacji. Niemniej jednak z powodu dużej objętości informacji, nawet w tak ograniczonej wizualizacji, inżynierowie i tak muszą «przesiewać» ją, ręcznie zawężając próbkę do zestawu serwisów źródłowych problemów. Niestety, w tej dziedzinie maszyny są zdecydowanie szybsze od ludzi, mniej podatne na błędy, a ich wyniki są bardziej powtarzalne.

Kolejnym powodem, dla którego uważam metodę traceview za niewłaściwą, jest to, że źle nadaje się do debugowania opartego na hipotezach. W swojej istocie debugowanie to iteracyjny proces, który zaczyna się od hipotezy, po której następuje weryfikacja różnych obserwacji i faktów uzyskanych od systemu z różnych wektorów, a następnie wnioski/podsumowania i dalsza ocena prawdziwości hipotezy.

Możliwość szybko i tanio testowanie hipotez i odpowiednie poprawianie modelu mentalnego jest kamieniem węgielnym debugowania. Każde narzędzie debugowania powinno być interaktywne i zawężać przestrzeń poszukiwań lub, w przypadku fałszywego tropu, umożliwiać użytkownikowi powrót wstecz i skupienie się na innej części systemu. Idealne narzędzie powinno to robić z wyprzedzeniem, natychmiast przyciągając uwagę użytkownika do potencjalnych problematycznych obszarów.

Niestety, (choć niektórzy nazywają go także nie można nazwać narzędziem z interaktywnym interfejsem. Najlepiej, na co można liczyć przy jego użyciu, to odkrycie jakiegoś źródła opóźnień i przeglądanie wszelkich tagów i logów związanych z tym. To nie pomaga inżynierowi w identyfikacji wzorców w ruchu, takich jak specyfika rozkładu opóźnień, ani w odkrywaniu korelacji między różnymi pomiarami. Ogólna analiza trace'ów może pomóc w obejściu niektórych z tych problemów. Rzeczywiście, są przykładami udanych analiz z wykorzystaniem uczenia maszynowego do identyfikacji anormalnych span'ów i identyfikacji podzbioru tagów, które mogą być związane z anormalnym zachowaniem. Niemniej jednak, do tej pory nie spotkałem przekonujących wizualizacji wyników uzyskanych dzięki uczeniu maszynowemu lub analizie danych stosowanej do span'ów, które znacznie różniłyby się od traceview lub DAG (skierowanego acyklicznego grafu).

Span'y są zbyt niskopoziomowe

Fundamentalnym problemem z traceview jest to, że span'y są zbyt niskopoziomowymi prymitywami zarówno do analizy opóźnień, jak i analizy przyczyn źródłowych. To tak, jakby analizować pojedyncze instrukcje procesora w próbie rozwiązania wyjątku, wiedząc, że istnieją dużo wyższej poziomu narzędzia, takie jak backtrace, z którymi znacznie łatwiej pracować.

Ponadto, śmiem twierdzić, że w idealnym przypadku nie potrzebujemy pełnego obrazu co miało miejsce podczas cyklu życia żądania, co przedstawiają nowoczesne narzędzia do śledzenia. Zamiast tego potrzebna jest pewna forma wyższej abstrakcji, zawierająca informacje na temat tego, co poszło nie tak (analogicznie do backtrace), wraz z pewnym kontekstem. Zamiast obserwować cały trace, wolę zobaczyć jego cz część, gdzie dzieje się coś interesującego lub nietypowego. Obecnie wyszukiwanie odbywa się ręcznie: inżynier otrzymuje trace i samodzielnie analizuje spany w poszukiwaniu czegoś interesującego. Podejście, w którym ludzie wpatrują się w spany w pojedynczych trace'ach, mając nadzieję na wykrycie podejrzanej aktywności, absolutnie nie skalowalne (szczególnie gdy muszą przetwarzać wszystkie metadane zakodowane w różnych spanach, takie jak ID spanu, nazwa metody RPC, czas trwania spanu, logi, tagi itp.).

Alternatywy traceview

Wyniki śledzenia są najbardziej użyteczne, gdy można je zwizualizować w sposób dający nietrywialne wyobrażenie o tym, co dzieje się w powiązanych częściach systemu. Dopóki tego nie ma, proces debugowania w dużej mierze pozostaje inertny i zależy od umiejętności użytkownika dostrzegania właściwych korelacji, sprawdzania odpowiednich części systemu lub zbierania kawałków mozaiki w całość — w przeciwieństwie do narzędzia, co pomaga użytkownikowi formułować te hipotezy.

Nie jestem projektantem wizualnym ani specjalistą od UX, jednak w następnej sekcji chcę podzielić się kilkoma pomysłami na temat tego, jak mogą wyglądać podobne wizualizacje.

Skupienie na konkretnych serwisach

W warunkach, gdy branża konsoliduje się wokół pomysłów SLO (cele poziomu usług) i SLI (wskaźniki poziomu usług), wydaje się rozsądne, aby poszczególne zespoły przede wszystkim monitorowały zgodność swoich usług z tymi celami. Z tego wynika, że wizualizacja zorientowana na serwis najlepiej nadaje się dla takich zespołów.

Trace'y, szczególnie bez próbkowania, są skarbnicą informacji o każdym komponencie rozproszonego systemu. Te informacje można przetworzyć przez sprytnego narzędzie, które dostarczy użytkownikom odkrycia zorientowane na serwis. Mogą być ujawnione wcześniej — jeszcze zanim użytkownik przyjrzy się trace'om:

Wykresy rozkładu opóźnień tylko dla wyjątkowo wyróżniających się zapytań (zapytania wyjątkowe);
Wykresy rozkładu opóźnień w przypadkach, gdy cele SLO usługi nie są osiągane;
Najbardziej „ogólne”, „interesujące” i „dziwne” tagi w zapytaniach, które najczęściej się powtarzają;
Podział opóźnień w przypadkach, gdy zależności usługi nie osiągają założonych celów SLO;
Podział opóźnień według różnych usług downstream.

Niektóre z tych pytań nie mogą być odpowiedziane przez wbudowane metryki, zmuszając użytkowników do dokładnego badania spanów. Ostatecznie mamy do czynienia z niezwykle nieprzyjaznym mechanizmem dla użytkownika.

W związku z tym pojawia się pytanie: jak wygląda złożona interakcja między różnymi usługami zarządzanymi przez różne zespoły? Czy (choć niektórzy nazywają go także nie jest najbardziej odpowiednim narzędziem do oświetlenia takiej sytuacji?

Programiści mobilni, właściciele usług stateless, właściciele zarządzanych usług stateful (takich jak bazy danych) i właściciele platform mogą być zainteresowani innym przedstawieniem systemu rozproszonego; (choć niektórzy nazywają go także to zbyt uniwersalne rozwiązanie dla tych fundamentalnie różnych potrzeb. Nawet w bardzo złożonej architekturze mikroserwisów właściciele usług nie potrzebują głębokiej wiedzy o więcej niż dwóch lub trzech upstream i downstream usługach. W zasadzie w większości scenariuszy użytkownicy muszą jedynie odpowiadać na pytania dotyczące ograniczonego zestawu usług.

To przypomina przyglądanie się małemu podzbiorowi usług przez powiększalnik w celu skrupulatnego badania. Pozwoli to użytkownikowi zadawać bardziej istotne pytania dotyczące złożonej interakcji między tymi usługami a ich bezpośrednimi zależnościami. To jest analogiczne do backtrace’u w świecie usług, gdzie inżynier wie, co jak to działa, a także ma jakieś pojęcie o tym, co dzieje się w otaczających usługach, by zrozumieć, dlaczego.

Moje podejście jest zupełnym przeciwieństwem podejścia «od góry do dołu», opartego na traceview, gdzie analiza rozpoczyna się od całego trace'a, a następnie stopniowo schodzi do poszczególnych spanów. Przeciwnie, podejście «od dołu do góry» zaczyna się od analizy małego fragmentu, bliskiego potencjalnej przyczynie incydentu, a następnie obszar poszukiwań rozszerza się w razie potrzeby (z możliwością zaangażowania innych zespołów do analizy szerszego zakresu usług). Drugie podejście lepiej nadaje się do szybkiego sprawdzania początkowych hipotez. Po uzyskaniu konkretnych wyników można przejść do bardziej ukierunkowanej i szczegółowej analizy.

Budowanie topologii

Widoki związane z konkretną usługą mogą być niezwykle przydatne, jeśli użytkownik wie, która usługa lub grupa usług może być odpowiedzialna za wzrost opóźnień lub jest źródłem błędów. Jednak w skomplikowanym systemie określenie usługi sprawcy może być nierozwiązywalnym zadaniem podczas awarii, szczególnie jeśli komunikaty o błędach od usług nie były dostarczane.

Budowanie topologii usług może znacząco pomóc w określeniu, która usługa wykazuje wzrost częstości błędów lub zwiększenie opóźnienia, prowadzące do zauważalnego pogorszenia działania usługi. M mówiąc o budowaniu topologii, mam na myśli nie mapę usług, która przedstawia każdą usługę dostępną w systemie i jest znana ze swoich map architektonicznych w formie gwiazdy śmierci. Tego rodzaju przedstawienie nie różni się niczym od traceview opartego na skierowanym acyklicznym grafie. Zamiast tego chciałbym widzieć dynamicznie generowaną topologię usług, opartą na określonych atrybutach, takich jak częstość błędów, czas odpowiedzi lub na dowolnym parametrze użytkownika, który pomaga wyjaśnić sytuację z konkretnymi podejrzanymi usługami.

Przyjrzyjmy się przykładowi. Wyobraźmy sobie hipotetyczną stronę informacyjną. Usługa strony głównej (front page) wymienia dane z Redis, usługą rekomendacji, usługą reklamową oraz serwisem wideo. Serwis wideo pobiera filmy z S3, a metadane z DynamoDB. Usługa rekomendacji otrzymuje metadane z DynamoDB, ładuje dane z Redis i MySQL, a następnie przesyła komunikaty do Kafka. Usługa reklamowa otrzymuje dane z MySQL i przesyła komunikaty do Kafka.

Poniżej znajduje się schematyczny obraz tej topologii (topologię buduje wiele komercyjnych programów do śledzenia). Może być przydatny, gdy trzeba zrozumieć zależności między usługami. Jednak podczas debugowania,, gdy jakaś usługa (powiedzmy, serwis wideo) wykazuje wydłużony czas odpowiedzi, taka topologia nie jest zbyt pomocna.

Schemat usług hipotetycznej strony informacyjnej

Lepiej pasowałaby diagram przedstawiony poniżej. Na nim problematyczna usługa (video) jest umieszczona w samym centrum. Użytkownik od razu ją zauważa. Z tej wizualizacji wynika, że serwis wideo działa nienormalnie z powodu wydłużonego czasu odpowiedzi S3, co wpływa na prędkość ładowania części strony głównej.

Dynamiczna topologia, wyświetlająca tylko "interesujące" usługi

Dynamically generated topological diagrams can be more effective than static service maps, especially in elastic, auto-scaling infrastructures. The ability to compare and cross-reference service topologies allows users to ask more relevant questions. More precise questions about the system are more likely to lead to a better understanding of how the system works.

Widok porównawczy

Inną przydatną wizualizacją będzie widok porównawczy. Obecnie trace’y nie nadają się zbytnio do porównania obok siebie, dlatego zazwyczaj porównywane są span'y. A podstawowa idea tego artykułu polega na tym, że span’y są zbyt niskiego poziomu, aby wydobyć najcenniejsze informacje z wyników śledzenia.

Porównanie dwóch trace’ów nie wymaga dość nowych wizualizacji. W rzeczywistości wystarczy coś w rodzaju histogramu, który przedstawia te same informacje co traceview. Co zaskakujące, nawet ta prosta metoda może przynieść znacznie więcej korzyści niż tylko studiowanie dwóch trace’ów oddzielnie. Jeszcze bardziej potężna stałaby się możliwość wizualizować porównanie trace’ów łącznie. Byłoby niezwykle przydatne zobaczyć, jak niedawno wdrożona zmiana w konfiguracji bazy danych z włączeniem GC (garbage collection) wpływa na czas odpowiedzi downstreamowego serwisu w skali kilku godzin. Jeśli to, co opisuję tutaj, wydaje się podobne do analizy A/B wpływu zmian infrastrukturalnych w wielu serwisach z pomocą wyników śledzenia, to nie jesteś zbyt daleko od prawdy.

Podsumowanie

Nie kwestionuję użyteczności samego śledzenia. Szczerze wierzę, że nie ma innej metody, aby zbierać tak bogate, swobodne i kontekstowe dane, jak te zawarte w trace’ach. Uważam jednak również, że wszystkie rozwiązania do śledzenia wykorzystują te dane w sposób niezwykle nieefektywny. Dopóki narzędzia do śledzenia będą skupiać się na widoku traceview, będą ograniczone w zakresie maksymalnego wykorzystania cennych informacji, które można wydobyć z danych zawartych w trace’ach. Dodatkowo istnieje ryzyko dalszego rozwoju całkowicie nieprzyjaznego i nieintuicyjnego interfejsu wizualnego, który znacznie ograniczy zdolność użytkownika do rozwiązywania problemów w aplikacji.

Debugowanie złożonych systemów, nawet przy użyciu najnowszych narzędzi, jest niezwykle trudne. Narzędzia powinny pomagać programiście formułować i weryfikować hipotezy, aktywne dostarczając istotne informacje, identyfikując odstępstwa i zauważając cechy w rozkładzie opóźnień. Aby śledzenie stało się preferowanym narzędziem dla programistów przy rozwiązywaniu awarii w produkcji lub problemów obejmujących różne serwisy, potrzebne są oryginalne interfejsy użytkownika i wizualizacje, które bardziej odpowiadają mentalnemu modelowi programistów, którzy tworzą i eksploatują te serwisy.

Będzie to wymagać poważnych wysiłków umysłowych, aby zaprojektować system, który będzie przedstawiać różne sygnały dostępne w wynikach śledzenia w sposób zoptymalizowany pod kątem ułatwienia analizy i wnioskowania. Konieczne jest przemyślenie, jak abstrahować topologię systemu podczas debugowania tak, aby pomóc użytkownikowi pokonać ślepe strefy, nie zaglądając w poszczególne trace’y lub spany.

Potrzebujemy dobrych możliwości abstrahowania i podziału na poziomy (szczególnie w UI). Takich, które dobrze wpasują się w proces debugowania oparty na hipotezach, gdzie można iteracyjnie zadawać pytania i weryfikować hipotezy. Nie rozwiążą automatycznie wszystkich problemów z obserwowalnością, ale pomogą użytkownikom udoskonalić intuicję i formułować bardziej przemyślane pytania. Zachęcam do bardziej refleksyjnego i innowacyjnego podejścia w dziedzinie wizualizacji. Istnieje realna szansa na poszerzenie horyzontów.