Notatka. przeł.: Autorką tego materiału jest Cindy Sridharan, inżynierka w imgix, która specjalizuje się w rozwoju API, a w szczególności testowaniu mikroserwisów. W tym materiale dzieli się swoją szczegółową wizją aktualnych problemów w obszarze rozproszonego śledzenia, gdzie jej zdaniem brakuje naprawdę skutecznych narzędzi rozwiązywania palących problemów.
[Ilustracja zaczerpnięta z o śledzeniu rozproszonym.]
Uważa się, że trudne do wdrożenia i zwrot z tego . Istnieje wiele powodów, dla których śledzenie jest problematyczne, często powołując się na nakład pracy związany z konfiguracją każdego komponentu systemu w celu przesyłania odpowiednich nagłówków przy każdym żądaniu. Chociaż problem ten istnieje, w żadnym wypadku nie jest on nie do pokonania. Nawiasem mówiąc, nie wyjaśnia to, dlaczego programiści tak naprawdę nie lubią śledzenia (nawet jeśli już działa).
Głównym wyzwaniem związanym ze śledzeniem rozproszonym nie jest gromadzenie danych, standaryzacja formatów dystrybucji i prezentacji wyników ani określanie, kiedy, gdzie i jak pobierać próbki. Nie próbuję sobie tego wyobrazić trywialny te „problemy ze zrozumiałością” są w rzeczywistości dość istotne pod względem technicznym i (jeśli rozważamy prawdziwie otwarte oprogramowanie) ) wyzwania polityczne, które należy przezwyciężyć, aby problemy te można było uznać za rozwiązane.
Jeśli jednak wyobrazimy sobie, że wszystkie te problemy zostały rozwiązane, istnieje duże prawdopodobieństwo, że nic się nie zmieni znacząco doświadczenie użytkownika końcowego. Śledzenie może nadal nie być praktyczne w najpopularniejszych scenariuszach debugowania — nawet po jego wdrożeniu.
Taki inny ślad
Śledzenie rozproszone obejmuje kilka odrębnych komponentów:
- wyposażenie aplikacji i oprogramowania pośredniczącego w narzędzia kontrolne;
- rozproszony transfer kontekstu;
- zbieranie śladów;
- przechowywanie śladów;
- ich ekstrakcję i wizualizację.
Wiele mówi się o śledzeniu rozproszonym, traktuje się je jako rodzaj jednoargumentowej operacji, której jedynym celem jest pomoc w pełnym zdiagnozowaniu systemu. Wynika to głównie z historycznego sposobu kształtowania się pomysłów dotyczących śledzenia rozproszonego. W , sporządzony przy otwarciu źródeł Zipkina, wspomniano o tym to [Zipkin] sprawia, że Twitter jest szybszy. Promowano także pierwsze komercyjne oferty śledzenia .
Notatka. przeł.: Aby ułatwić zrozumienie dalszego tekstu, zdefiniujmy dwa podstawowe pojęcia wg :
- Przęsło — podstawowy element śledzenia rozproszonego. Jest to opis określonego przepływu pracy (na przykład zapytania do bazy danych) z nazwą, czasem rozpoczęcia i zakończenia, znacznikami, dziennikami i kontekstem.
- Przęsła zazwyczaj zawierają łącza do innych przęseł, umożliwiając łączenie wielu przęseł Wyśledzić — wizualizacja życia żądania podczas jego przemieszczania się w systemie rozproszonym.
Ślady zawierają niezwykle cenne dane, które mogą pomóc w zadaniach takich jak testowanie produkcyjne, testowanie odtwarzania po awarii, testowanie wstrzykiwania błędów itp. W rzeczywistości niektóre firmy już korzystają ze śledzenia w podobnych celach. Zacznijmy od ma inne zastosowania poza prostym przenoszeniem przęseł do systemu przechowywania:
- Na przykład Ubera śledzenie wyników w celu rozróżnienia ruchu testowego od ruchu produkcyjnego.
- Facebook dane śledzenia do analizy ścieżek krytycznych i przełączania ruchu podczas regularnych testów odzyskiwania po awarii.
- Również sieć społecznościowa Notatniki Jupyter umożliwiające programistom uruchamianie dowolnych zapytań na podstawie wyników śledzenia.
- Zwolennicy (Wstrzykiwanie awarii sterowane liniowo) rozproszone ślady do testowania z wstrzykiwaniem błędów.
Żadna z powyższych opcji nie ma zastosowania w całości do scenariusza debugowanie, podczas którego inżynier próbuje rozwiązać problem patrząc na ślad.
Jeśli chodzi jeszcze osiągnie skrypt debugujący, głównym interfejsem pozostaje diagram podgląd śledzenia (choć niektórzy też tak to nazywają "Wykres Gantta" lub „schemat wodospadu”). Pod podgląd śledzenia я wszystkie zakresy i towarzyszące im metadane, które razem tworzą ślad. Każdy system śledzenia typu open source, a także każde komercyjne rozwiązanie do śledzenia oferuje podgląd śledzenia interfejs użytkownika do wizualizacji, wyszczególniania i filtrowania śladów.
Problem ze wszystkimi systemami śledzenia, jakie do tej pory widziałem, polega na tym, że wynik wizualizacja (traceview) prawie całkowicie odzwierciedla cechy procesu generowania śladów. Nawet jeśli proponowane są alternatywne wizualizacje: mapy cieplne, topologie usług, histogramy opóźnień, ostatecznie sprowadzają się one do podgląd śledzenia.
W przeszłości I do których wydaje się ograniczać większość „innowacji” w śledzeniu interfejsu użytkownika/UX dodatkowe metadane w Trace, inwestując w nie informacje o dużej liczności (wysoka kardynalność) lub zapewnienie możliwości drążenia określonych zakresów lub uruchamiania zapytań międzyśladowe i wewnątrzśladowe... W którym podgląd śledzenia pozostaje głównym narzędziem wizualizacji. Dopóki taki stan rzeczy będzie się utrzymywał, śledzenie rozproszone będzie (w najlepszym wypadku) zajmować 4. miejsce jako narzędzie do debugowania, po metrykach, logach i śladach stosu, a w najgorszym okaże się stratą pieniędzy i czasu.
Problem z widokiem śledzenia
Cel podgląd śledzenia — zapewnić pełny obraz ruchu pojedynczego żądania pomiędzy wszystkimi komponentami systemu rozproszonego, z którym jest ono powiązane. Niektóre bardziej zaawansowane systemy śledzenia umożliwiają wnikanie w poszczególne zakresy i przeglądanie rozkładu w czasie wewnątrz jeden proces (gdy przęsła mają granice funkcjonalne).
Podstawowym założeniem architektury mikrousług jest założenie, że struktura organizacyjna rośnie wraz z potrzebami firmy. Zwolennicy mikrousług argumentują, że podział różnych zadań biznesowych na poszczególne usługi pozwala małym, autonomicznym zespołom programistycznym kontrolować cały cykl życia takich usług, dając im możliwość niezależnego budowania, testowania i wdrażania tych usług. Jednak wadą tej dystrybucji jest utrata informacji o tym, jak poszczególne usługi współdziałają z innymi. W takich warunkach śledzenie rozproszone wydaje się niezbędnym narzędziem debugowanie złożone interakcje pomiędzy usługami.
Jeśli ty naprawdę , to nikt nie jest w stanie utrzymać tego w głowie kompletny zdjęcie. Tak naprawdę opracowywanie narzędzia w oparciu o założenie, że jest to w ogóle możliwe, jest czymś w rodzaju antywzorca (podejście nieskuteczne i nieproduktywne). W idealnym przypadku debugowanie wymaga narzędzia, które pomaga zawęź obszar poszukiwań, dzięki czemu inżynierowie mogą skupić się na podzbiorze wymiarów (usługi/użytkownicy/hosty itp.) istotnych dla rozważanego scenariusza problemu. Ustalając przyczynę awarii, inżynierowie nie muszą rozumieć, co wydarzyło się podczas awarii wszystkie usługi na raz, gdyż taki wymóg byłby sprzeczny z samą ideą architektury mikrousług.
Jednak widok śledzenia jest mianowicie Ten. Tak, niektóre systemy śledzenia oferują skompresowane widoki śledzenia, gdy liczba rozpiętości śledzenia jest tak duża, że nie można ich wyświetlić w jednej wizualizacji. Jednak ze względu na dużą ilość informacji zawartych nawet w tak uproszczonej wizualizacji, inżynierowie nadal wymuszony „przesiać”, ręcznie zawężając wybór do zestawu usług będących źródłem problemów. Niestety na tym polu maszyny są znacznie szybsze od ludzi, mniej podatne na błędy, a ich wyniki są bardziej powtarzalne.
Innym powodem, dla którego uważam, że widok śledzenia jest błędny, jest to, że nie nadaje się do debugowania opartego na hipotezach. U podstaw leży debugowanie wielokrotny proces rozpoczynający się od hipotezy, po którym następuje weryfikacja różnych obserwacji i faktów uzyskanych z systemu wzdłuż różnych wektorów, wnioski/uogólnienia i dalsza ocena prawdziwości hipotezy.
Okazja szybko i tanio testowanie hipotez i odpowiednie ulepszanie modelu mentalnego kamień węgielny debugowanie Każde narzędzie do debugowania powinno być interaktywny i zawęzić przestrzeń poszukiwań lub w przypadku fałszywego tropu pozwolić użytkownikowi cofnąć się i skupić na innym obszarze systemu. Zrobi to doskonałe narzędzie aktywnie, natychmiast zwracając uwagę użytkownika na potencjalne obszary problematyczne.
Niestety, podgląd śledzenia nie można nazwać narzędziem z interaktywnym interfejsem. Najlepsze, na co możesz mieć nadzieję, korzystając z niego, to znaleźć źródło zwiększonego opóźnienia i sprawdzić wszystkie możliwe tagi i dzienniki z nim powiązane. Nie pomaga to inżynierowi w identyfikacji wzory w ruchu drogowym, na przykład specyfikę rozkładu opóźnień, lub wykryć korelacje między różnymi pomiarami. może pomóc w rozwiązaniu niektórych z tych problemów. Naprawdę, udana analiza z wykorzystaniem uczenia maszynowego w celu zidentyfikowania nietypowych zakresów i zidentyfikowania podzbioru tagów, które mogą być powiązane z nietypowym zachowaniem. Jednak nie widziałem jeszcze przekonujących wizualizacji wyników uczenia maszynowego lub eksploracji danych zastosowanych do zakresów, które znacznie różnią się od widoku śledzenia lub DAG (ukierunkowanego wykresu acyklicznego).
Rozpiętości są na zbyt niskim poziomie
Podstawowym problemem związanym z Traceview jest to, że rozpiętości są zbyt prymitywami niskiego poziomu, aby można było je zastosować zarówno do analizy opóźnień, jak i analizy przyczyn źródłowych. To jak analizowanie poleceń poszczególnych procesorów w celu rozwiązania wyjątku, wiedząc, że istnieją znacznie wygodniejsze w użyciu narzędzia wyższego poziomu, takie jak śledzenie wsteczne.
Co więcej, pozwolę sobie stwierdzić, co następuje: w idealnym przypadku nie potrzebujemy Pełne zdjęcie wystąpiło podczas cyklu życia żądania, który jest reprezentowany przez nowoczesne narzędzia do śledzenia. Zamiast tego wymagana jest jakaś forma abstrakcji wyższego poziomu, która zawiera informacje o czym poszło źle (podobnie do śledzenia wstecznego) wraz z pewnym kontekstem. Zamiast oglądać cały ślad, wolę go zobaczyć часть, gdzie dzieje się coś ciekawego lub niezwykłego. Obecnie wyszukiwanie odbywa się ręcznie: inżynier otrzymuje ślad i samodzielnie analizuje przęsła w poszukiwaniu czegoś interesującego. Podejście ludzi wpatrujących się w zakresy poszczególnych śladów w nadziei wykrycia podejrzanej aktywności w ogóle się nie skaluje (zwłaszcza gdy muszą zrozumieć wszystkie metadane zakodowane w różnych zakresach, takie jak identyfikator zakresu, nazwa metody RPC, czas trwania zakresu) 'a, logi, znaczniki itp.).
Alternatywy dla widoku śledzenia
Wyniki śledzenia są najbardziej przydatne, gdy można je zwizualizować w sposób zapewniający nietrywialny wgląd w to, co dzieje się w wzajemnie połączonych częściach systemu. Dopóki to nie nastąpi, proces debugowania w dużej mierze pozostaje obojętny i zależy od umiejętności użytkownika dostrzeżenia właściwych powiązań, sprawdzenia odpowiednich części systemu lub ułożenia elementów układanki – w przeciwieństwie do narzędzie, pomagając użytkownikowi w formułowaniu tych hipotez.
Nie jestem projektantem wizualnym ani specjalistą UX, ale w następnej sekcji chcę podzielić się kilkoma pomysłami na to, jak takie wizualizacje mogą wyglądać.
Skoncentruj się na konkretnych usługach
W czasach, gdy branża konsoliduje się wokół idei rozsądne wydaje się, aby poszczególne zespoły traktowały priorytetowo zapewnienie zgodności swoich usług z tymi celami. Wynika, że zorientowany na usługi dla takich zespołów najlepiej sprawdza się wizualizacja.
Ślady, zwłaszcza bez próbkowania, są skarbnicą informacji o każdym elemencie systemu rozproszonego. Informacje te można przekazać sprytnemu procesorowi, który dostarczy użytkownikom zorientowany na usługi Można je zidentyfikować z wyprzedzeniem – jeszcze zanim użytkownik przejrzy ślady:
- Diagramy rozkładu opóźnień tylko dla bardzo znaczących żądań (żądania odstające);
- Diagramy rozkładu opóźnień dla przypadków nieosiągnięcia celów SLO usług;
- Najczęściej spotykane, „ciekawe” i „dziwne” tagi w zapytaniach powtarzać;
- Podział opóźnień dla przypadków, w których зависимости usługi nie osiągają swoich celów SLO;
- Podział opóźnień dla różnych usług podrzędnych.
Wbudowane wskaźniki po prostu nie dają odpowiedzi na niektóre z tych pytań, co zmusza użytkowników do dokładnej analizy zakresów. W rezultacie mamy mechanizm wyjątkowo wrogi dla użytkownika.
Rodzi się pytanie: co ze złożonymi interakcjami pomiędzy różnymi usługami kontrolowanymi przez różne zespoły? Czyż nie? podgląd śledzenia nie jest uważany za najwłaściwsze narzędzie do uwypuklenia takiej sytuacji?
Deweloperzy mobilni, właściciele usług bezstanowych, właściciele zarządzanych usług stanowych (takich jak bazy danych) i właściciele platform mogą być zainteresowani czymś innym prezentacja system rozproszony; podgląd śledzenia jest zbyt ogólnym rozwiązaniem dla tych zasadniczo różnych potrzeb. Nawet w bardzo złożonej architekturze mikrousług właściciele usług nie potrzebują głębokiej wiedzy na temat więcej niż dwóch lub trzech usług wyższego i niższego szczebla. Zasadniczo w większości scenariuszy użytkownicy muszą jedynie odpowiedzieć na pytania dotyczące ograniczony zestaw usług.
To jakby patrzeć na niewielki podzbiór usług przez szkło powiększające w celu dokładnego ich zbadania. Umożliwi to użytkownikowi zadawanie bardziej palących pytań dotyczących złożonych interakcji pomiędzy tymi usługami i ich bezpośrednimi zależnościami. Przypomina to śledzenie wsteczne w świecie usług, gdzie inżynier wie że źle, a także ma pewne zrozumienie tego, co dzieje się w otaczających usługach, aby zrozumieć dlaczego.
Podejście, które promuję, jest dokładnym przeciwieństwem podejścia odgórnego, opartego na widoku śledzenia, w którym analiza rozpoczyna się od całego śladu, a następnie stopniowo przechodzi do poszczególnych zakresów. Natomiast podejście oddolne rozpoczyna się od analizy małego obszaru w pobliżu potencjalnej przyczyny zdarzenia, a następnie w razie potrzeby rozszerza przestrzeń poszukiwań (z możliwością zaangażowania innych zespołów w celu analizy szerszego zakresu usług). Drugie podejście lepiej nadaje się do szybkiego testowania wstępnych hipotez. Po uzyskaniu konkretnych wyników możliwe będzie przejście do bardziej ukierunkowanej i szczegółowej analizy.
Budowanie topologii
Widoki specyficzne dla usługi mogą być niezwykle przydatne, jeśli użytkownik o tym wie co usługa lub grupa usług jest odpowiedzialna za zwiększanie opóźnień lub powodowanie błędów. Jednak w złożonym systemie identyfikacja usługi powodującej naruszenie może być nietrywialnym zadaniem w przypadku awarii, szczególnie jeśli usługi nie zgłosiły żadnych komunikatów o błędach.
Tworzenie topologii usług może być bardzo pomocne w ustaleniu, w której usłudze występuje gwałtowny wzrost liczby błędów lub wzrost opóźnień, który powoduje zauważalne pogorszenie jakości usługi. Kiedy mówię o budowaniu topologii, nie mam na myśli mapa usług, wyświetlając każdą usługę dostępną w systemie i znaną z niej . Ten widok nie jest lepszy od widoku śledzenia opartego na skierowanym grafie acyklicznym. Zamiast tego chciałbym zobaczyć dynamicznie generowana topologia usług, w oparciu o określone atrybuty, takie jak współczynnik błędów, czas odpowiedzi lub dowolny parametr zdefiniowany przez użytkownika, który pomaga wyjaśnić sytuację w przypadku określonych podejrzanych usług.
Weźmy przykład. Wyobraźmy sobie hipotetyczną witrynę z wiadomościami. Obsługa strony głównej (pierwsza strona) wymienia dane z Redis, z usługą rekomendacji, z usługą reklamową i usługą wideo. Usługa wideo pobiera filmy z S3 i metadane z DynamoDB. Usługa rekomendacyjna odbiera metadane z DynamoDB, ładuje dane z Redis i MySQL oraz zapisuje wiadomości do Kafki. Usługa reklamowa odbiera dane z MySQL i zapisuje wiadomości do Kafki.
Poniżej znajduje się schematyczne przedstawienie tej topologii (topologię tworzy wiele komercyjnych programów routingowych). Może to być przydatne, jeśli chcesz zrozumieć zależności usług. Jednak w trakcie debugowanie, gdy dana usługa (powiedzmy usługa wideo) wykazuje wydłużony czas reakcji, taka topologia nie jest zbyt użyteczna.
Schemat usług hipotetycznej witryny z wiadomościami
Poniższy schemat byłby bardziej odpowiedni. Wystąpił problem z usługą (wideo) przedstawiony w samym środku. Użytkownik natychmiast to zauważa. Z tej wizualizacji jasno wynika, że usługa wideo działa nieprawidłowo ze względu na wydłużenie czasu odpowiedzi S3, co wpływa na szybkość ładowania części strony głównej.
Topologia dynamiczna wyświetlająca tylko „interesujące” usługi
Topologie generowane dynamicznie mogą być bardziej wydajne niż statyczne mapy usług, szczególnie w elastycznych, automatycznie skalowalnych infrastrukturach. Możliwość porównywania i kontrastowania topologii usług pozwala użytkownikowi zadawać bardziej istotne pytania. Bardziej precyzyjne pytania dotyczące systemu z większym prawdopodobieństwem doprowadzą do lepszego zrozumienia jego działania.
Wyświetlacz porównawczy
Inną przydatną wizualizacją może być prezentacja porównawcza. Obecnie ślady nie są zbyt odpowiednie do porównań side-by-side, więc porównania są zwykle rozpiętości. Główną ideą tego artykułu jest właśnie to, że rozpiętości są zbyt niskie, aby wyodrębnić najcenniejsze informacje z wyników śledzenia.
Porównanie dwóch śladów nie wymaga zasadniczo nowych wizualizacji. W rzeczywistości wystarczy coś w rodzaju histogramu przedstawiającego te same informacje, co widok śladu. Co zaskakujące, nawet ta prosta metoda może przynieść znacznie więcej owoców niż zwykłe badanie dwóch śladów osobno. Jeszcze potężniejsza byłaby taka możliwość wyobrażać sobie porównanie śladów W całości. Niezwykle przydatne byłoby sprawdzenie, jak niedawno wdrożona zmiana konfiguracji bazy danych umożliwiająca GC (odśmiecanie) wpływa na czas odpowiedzi usługi niższego szczebla w skali kilku godzin. Jeśli to, co tu opisuję, brzmi jak analiza A/B wpływu zmian w infrastrukturze w wielu usługach korzystając z wyników śledzenia, nie jesteś zbyt daleki od prawdy.
wniosek
Nie kwestionuję użyteczności samego śledzenia. Szczerze wierzę, że nie ma innej metody gromadzenia danych tak bogatych, przyczynowych i kontekstowych jak ta zawarta w śladzie. Uważam jednak również, że wszystkie rozwiązania śledzące wykorzystują te dane wyjątkowo nieefektywnie. Dopóki narzędzia do śledzenia będą tkwić w reprezentacji widoku śledzenia, ich zdolność do maksymalnego wykorzystania cennych informacji, które można wydobyć z danych zawartych w śladach, będzie ograniczona. Ponadto istnieje ryzyko dalszego rozwoju całkowicie nieprzyjaznego i nieintuicyjnego interfejsu wizualnego, który poważnie ograniczy możliwości użytkownika w rozwiązywaniu problemów w aplikacji.
Debugowanie złożonych systemów, nawet przy użyciu najnowszych narzędzi, jest niezwykle trudne. Narzędzia powinny pomóc programiście w sformułowaniu i przetestowaniu hipotezy, aktywnie dostarcza istotne informacje, identyfikując wartości odstające i odnotowując cechy rozkładu opóźnień. Aby śledzenie stało się narzędziem wybieranym przez programistów podczas rozwiązywania problemów z awariami produkcyjnymi lub rozwiązywania problemów obejmujących wiele usług, potrzebne są oryginalne interfejsy użytkownika i wizualizacje, które są bardziej spójne z modelem mentalnym programistów, którzy tworzą i obsługują te usługi.
Zaprojektowanie systemu, który będzie reprezentował różne sygnały dostępne w wynikach śledzenia w sposób zoptymalizowany pod kątem łatwości analizy i wnioskowania, będzie wymagało znacznego wysiłku umysłowego. Należy pomyśleć o tym, jak wyodrębnić topologię systemu podczas debugowania w sposób, który pomoże użytkownikowi pokonać martwe punkty bez patrzenia na poszczególne ścieżki lub przęsła.
Potrzebujemy dobrych możliwości abstrakcji i warstw (szczególnie w interfejsie użytkownika). Takie, które dobrze pasują do procesu debugowania opartego na hipotezach, w którym można iteracyjnie zadawać pytania i testować hipotezy. Nie rozwiążą automatycznie wszystkich problemów z obserwowalnością, ale pomogą użytkownikom wyostrzyć intuicję i formułować mądrzejsze pytania. Wzywam do bardziej przemyślanego i innowacyjnego podejścia do wizualizacji. Jest tu realna perspektywa poszerzenia horyzontów.
PS od tłumacza
Przeczytaj także na naszym blogu:
- «";
- «";
- «".
Źródło: www.habr.com