Szymon: Cześć! Słuchacie Pato Architektów. Prowadzą Szymon Warda…

Łukasz:…i Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na patoarchitekci.io/22 Dobra Szymonie, to co z linków?

**S:**To ja mam długi wpis, taki konkretny. Jest to ciekawa historia w ogóle rozwoju usługi – Cliqz – tak się chyba to wymawia. I wpis jest naprawdę ciekawy. Czemu? Po pierwsze zaczyna się od rysu historycznego, czyli jaki mieli problem biznesowy, od którego momentu zaczynali, itd. A potem przechodzą praktycznie w całościowy opis ich stack word architektonicznego łącznie z wyborami czemu i nawet z takimi rzeczami jak cały stack do ML, wyszukiwania, itd. Co jest dla mnie ciekawe to praktycznie jest takie przejście od problemu do rozwiązania, więc widzimy ewolucję całego rozwiązania, widzimy decyzje które zapadły i do czego doprowadziły. Fajne podsumowanie, dużo linków dalej prowadzących. Dla mnie osobiście fajnie napisany artykuł, jakby ktoś chciał faktycznie udokumentować swoją architekturę. Do przeczytania też faktycznie ciekawe.

Ł: Dla mnie jak patrzę tam na jeden zlog tego co używają to jakbym widział grafikę z CNCF, tyle mają tego stosu.

S: Tak. Stos jest naprawdę duży i opisują tego też sporo.

Ł: Jakby popatrzeć to tak rzucając patrzę Consul, Kafka, Cassandra, etcd, widzę Flager’a tutaj, jeżeli dobrze patrzę na logo, Argo, Prometheus, Core DNS. Tak naprawdę taki czysty Cloud Native Style stos jeżeli popatrzylibyśmy z definicji aktualnie latających.

S: Tak. I co więcej to jest opis tak naprawdę pełnego Stacku. To nie jest mały wycinek, więc tam każdy znajdzie kawałek dla siebie. Wpis jest długi, chyba zgodzisz się.

Ł: Tak. Jest duży. Są przykłady nawet, kawałki rbacków, skryptów pythonowych których używają w niektórych miejscach, więc jest dość wyczerpująco o ich, jak sami to określili, drodze do mikroserwisów Kubernetesa oraz tego co powyżej.

S: Tak. A u Ciebie znowu skrajność inna.

Ł: Tak. Szymon, wybrałeś dłuższy. Ja mam Tweeta na temat Kubecon europejskiego, który nadchodzi i będzie niedługo pod koniec kwietnia bodajże. Albo marca? Nieważne. Najważniejsze, że pokazała się agenda i wygląda na bardzo ciekawą rzecz, ponieważ nie będzie istio, nie będzie talków o Istio ani o Knative.

S:: Uuu…

Ł: Właśnie. Jest to bardzo podsumowujący tweet, że: „ Nie dołączasz do fundacji? Koniec darmowych przejażdżek". CNC przestaje promować technologie, które nie dołączają.

S: W takim razie może zobaczymy większą adopcję Linkerd.

Ł: Tak. Po sesjach widać tam , więc pewnie będzie o Linkerd 2, a może o Consulu, bo on gdzieś tam jest obok. Trzeba wiedzieć, że jeżeli chodzi o Istio i Knative, to w sumie w Google’u, bo oni się wypowiedzieli, nie oszukujmy się, mają większość w radach tych projektów, że nie oddają tego, nie planują aktualnie oddawać tego do CNCF.

S: Ja się z tego cieszę, bo właściwie obecnie stan powiedzmy hype’u jest taki, że o Istio słyszy się dużo więcej niż o alternatywnych meshach. Więc taka dobra konkurencja tu się jak najbardziej przyda.

Ł: Raczej tak, tylko teraz patrząc z mentalności, coraz częściej patrzymy żeby mieć ten cały ekosystem CNCF, i ludzie mogą patrzeć na to, że te Istio no jednak nie weźmiemy, bo tam Linkerd jest. Też w pewnym momencie może być taka zagwozdka.

S: Dokładnie. Linkerd też powinien być jak najbardziej rozważany, bo jest bardzo przyjemnym meshem, dużo łatwiejszym niż Istio.

Ł: Dobra, to teraz przejdźmy do tematu dzisiejszego odcinka. Powtarzając, kontynuujemy Observability.

S: Tak. Trzeci filar.

Ł: Trzeci filar. Jakie są dwa jeszcze wcześniejsze o których nagrywaliśmy Szymonie?

S: Oczywiście logi i metryki.

Ł: Tak. I o nich można posłuchać wcześniej. A dziś zajmiemy się tracingiem , a dokładniej distributed tracingiem, bo o to chodzi w observability. I jakbyś mógł Szymonie w dwóch zdaniach powiedzieć, czym jest tracing.

S: To teraz ze strony open tracing jest metodą wykorzystywaną do profilowania i monitorowania aplikacji, szczególnie w architekturach mikroserwisowych.

Ł: Dobra. To nawet nie brzmi jak definicja w żaden sposób.

S: To nie brzmi jak definicja i widać, że trochę brakuje definicji. Brakuje pomysłu jak nazwać i powiedzieć, czym jest tracing. Dla mnie to jest możliwość wglądu w to jak przebiegają procesy w aplikacji. Tyle tak naprawdę.

Ł: Tak. Niektórzy kojarzą tracing tak naprawdę z najwyższego trybu logowania w swoim kodzie.

S: Tak. Też może być. Niee….Ustalmy!

Ł: To nie o to chodzi. Dobra. To może zacznijmy od historii, bo to będzie już dziesięć lat praktycznie, sama definicja skąd takiego pierwszego publicznego hype’u to zaczyna mieć dziesięć lat, sama idea.

S: Tak.

Ł: To jakbyś powiedział, od czego to się zaczęło. Od jakiej publikacji.

S: Zaczęło się od Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Od Google’a. Jak to często bywa z papierami od Google’a , takie ogólne pojęcia, to potem one znajdują jakąś implementację. Implementacją pierwszą, którą się uznaje, którą oficjalnie wiemy jest Zipkin. 2012 rok wydane przez Twitter’a. Obecnie on jest zgodny z całą zasadą OpenTracing. Potem 2016 rok – cztery lata przerwy, pojawia się Jaeger od Ubera. Obecnie jest to projekt CNCF, też zgodny ze standardem OpenTracing. Sam OpenTracing jako taki jest zdefiniowany w 2016 roku, dołącza do CNCF. Potem pojawia się OpenCensus w 2018 roku od Google’a, oczywiście alternatywa.

Ł: Ale i też Microsoftu. To jest właśnie bardzo ciekawe.

S: Tak.

Ł: to była opozycja do OpenTracing wydawana przez Google’a i Microsoft. To jest bardzo ciekawe w tym miejscu.

S: Tak. Ciekawe połączenie, dzieje się. To się potem zamieniło w OpenTelemetry w 2019 roku. Połączyło się to razem z OpenCensus. Obecnie OpenTelemetry jest chyba w Becie, tak?

Ł: Dochodzi do Bety.

S: Tak.

Ł: Specyfikacja dochodzi do Bety, przy czym tam stos językowy jest naprawdę masywny, bo wspierane są od strony specyfikacji bibliotek implementacyjnych do tego. Tak naprawdę mamy wspierany cały stos, że tak powiem, korporacyjnych języków, ich hype-driven, jak niektórzy określają.

S: Tak, bo w sumie Tracing nabrał wiatru w 2018 roku. Od tego momentu słychać o nim dość dużo. Jest na konferencjach obecnie widoczny.

**Ł:**Tak. To możesz patrzeć z drugiej strony – projekty SaaS na przykład, o których będziemy potem wspominali, implementują to już dłużej. Samą ideę Distributed Tracingu już o dawien dawna.

S: Chodzi mi bardziej o OpenTracing jako o standard. Zaczęto o tym słyszeć i tak już się cementuje, mimo, że to stara idea.

Ł: Tak. W 2018 to było na rynku, gdzie można to było zobaczyć jakoś bardziej.

S: Dokładnie. Co jest ważne tutaj, to OpenTelemetry nie jest standardem w rozumieniu słowa, jak mamy standard akceptowany, jest bardziej takim implementowalnym zestawem interfejsów i kontraktów.

Ł: Tak, tylko że patrząc do czego to dąży, to stanie się standardem.

S: Tak. To będzie taka niechęć CNCF do nazywania go standardem.

Ł: Oni to bardzo ładnie nazywają „specyfikacją".

S: Dokładnie tak.

Ł: To jest ich nazwa. Dobra. To może teraz przejdźmy przez pojęcia, bo przy tracingu jest trochę z mojej perspektywy mind fucków, które się znajdują.

S: Jest.

Ł: To zacznijmy od takiego podstawowego pojęcia w środku, czyli trace.

S: To trace jest acyklicznym grafem spanów.

Ł: Dobra! Teraz przegiąłeś zdecydowanie Dobra. Weźmy sobie to wytłumaczmy, bo trace jest tak naprawdę zbiorem informacji.

S: Tak, dokładnie.

Ł: jeżeli to uprościmy jest na temat pojedynczej, kompleksowej transakcji w naszym systemie.

S: Pojedynczych informacji – tak bym to nazywał. I te pojedyncze informacje nazywane są spamem. L: Dobra, to czym jest ten span, bo teraz zaczyna się mięcho.

S: Tak. Tutaj znowu brakuje nam trochę nazewnictwa. Widać, że nie ubiło się tak dokładnie. Jest to pojedynczy log – raport aplikacji o jednym kroku wykonania. I co jest ważne, bo niejako ten span jest definiowany przez to co on zawiera, bo zawiera takie kluczowe elementy. Pierwszym jest trace ID. I czym on jest? Jest to globalny i unikalny identyfikator całego procesu, nie tylko pojedynczej relacji, tylko całego procesu. Od startu on zostaje taki sam.

Ł: Czyli powiedzmy sobie wprost, w zależności gdzie zaczynamy robić nasz distributed tracing, on może być już wygenerowany na front-endzie, albo gdzieś na pierwszym API gateway’u na pierwszym mikroserwisie, serwisie do którego uderzamy.

S: Dokładnie tak. Potem lecimy span ID, i to jest unikalny identyfikator naszej operacji. Pojedynczej. Potem mamy nazwę, żeby to można było odczytać po ludzku. Potem mamy czas startu i czas końca, bo span jest mocno umiejscowiony w czasie. Potem mamy jeszcze określenie relacji do innych spanów.

Ł: W szczególności, że patrząc się na wywołania, te spany mogą być… z jednej na przykład procedury w kodzie możemy zapisać kilka takich trace’ów spanów.

S: Jak najbardziej tak. To jest generalnie cała sztuka jak schodzić nisko i co de facto „logować", to chyba będzie odpowiednie słowo w tym momencie. Bo jak już mówimy o spanach, to spany mogą mieć dwa typy relacji między sobą. Jedna to jest ChildOf i kolejna to jest FollowsFrom.

Ł: FollowsFrom. Zacznijmy od ChildOf, bo on jest prostszy.

S: Jest zdecydowanie dużo łatwiejszy i łatwiej go zrozumieć. I teraz na przykładzie mamy synchroniczne wywołanie po http. Więc w kodzie wołającym robimy spana, gdzie zaczynamy request i skończymy jak ten request otrzymamy. To jest pierwszy span. Teraz drugi span jest w serwisie odbierającym to wywołanie. Tam na odebraniu tego wywołania zaczynamy spana, jak wyślemy odpowiedź, kończymy spana. I te dwa spany będą bardzo bliskie siebie. Różnica między nimi to jest tylko ta latencja sieci po drodze.

Ł: To opóźnienie sieci i wywołanie, bo span będzie od tego momentu, kiedy zalogujemy to wywołanie u siebie, po swojej stronie.

S: Tak, dokładnie. Ale teraz jaka jest między nimi relacja? Ten span pierwszy zawiera span drugi tak naprawdę. Czyli span wołającego musi być, to znaczy powinien być większy niż span wołany.

Ł: Możemy na to popatrzeć jak na takiego drill down’a, że wklikujemy się, patrzymy co tam się działo pod spodem, czasy. Trochę tak jak robimy zwykły tracing w kodzie i patrzymy na to, jak się po kolei wywołują metody. To jest dokładnie ten sam graficzny zapis.

S: Tak, mamy zwykłego profilera, wchodzimy coraz niżej i tak właśnie te trace’y wyglądają. To samo może być z SQL-kami, wywołanie ORM-a, jak to się przekłada na pojedyncze SQL-ki. Tu jest ciekawiej, bo jak mamy na ORM save’a wywołujemy, to potem mamy pojedynczego spana na każde execute SQL. Więc dokładnie wiemy co, ile było wywołanych, więc każdy span może mieć dowolną ilość dzieci, tak naprawdę. Tu nie ma ograniczeń. I możemy dowolnie w dół schodzić. Więc jak tu widzimy ChildOf jest do sygnalizacji zależności między spanami synchronicznej.

Ł: Ja bym jeszcze dorzucił jeszcze jedną rzecz, z której sobie tam ludzie nie zdają, że taki span jak mamy logowany async/await’a, to widzimy całość, mamy cały wielki span, mimo, że tworzyliśmy sobie coś ładnie wyrzuciliśmy, czekamy.

S: Async jest ładnym ulepszeniem na nieczekanie, a mimo wszystko ten request tam dalej, jakiś wątek będzie na niego czekał.

Ł: To teraz coś ciężkiego – FollowsFrom.

S: Tu definicja jest taka, że dziecko nie zależy od rodzica. Przykład najprostszy: wysyłamy wiadomość, czyli na samym wysłaniu wiadomości mamy jednego spana, drugiego wysyłamy jak odbieramy wiadomość, ale te dwa spany będą miały między sobą dziurę czasową.

Ł: I to sporą. Mogą mieć czasami sporą dziurę czasową, jeżeli będą jakieś problemy.

S: Tak.

Ł: Bo trzeba powiedzieć, że to jest do komunikacji takiej prawdziwej, synchronicznej po wiadomościach, kolejkach, jakiś integracjach.

S: Dokładnie. Mówimy, że one, jak sama nazwa wskazuje, jedno następuje po drugim, ale w czasie niezależnym. To nie jest drill down, tak jak porównałeś poprzednio.

Ł: Dobra. To jeszcze wróćmy sobie, bo powiedzieliśmy o relacjach spana, ale ten span oprócz tych metadanych, o których powiedziałeś, on ma jeszcze swoje bebechy, może mieć bardziej szczegółowe bebechy, takie chyba będą tagi, logi i batch item. Dobrze mówię? Nie. Baggage item.

S: Tak.

Ł: To może zacznijmy od tagów w spanie.

S: Dobrze. To jest w ogóle fajne rozróżnienie, bo takie rozróżnienie jest w Kubernetesie. Od czego są tagi? Zdefiniowane przez użytkownika adnotacje do spanów, których celem, i to jest najważniejsze, jest wyszukiwanie konkretnych traceów. Przykład: chcemy spany o zapytania do SQLa, z konkretnego systemu, dla na przykład konkretnego procesu biznesowego, itd. To są takie proste tagi, po których wyszukujemy, i co jest też bardzo ważne, jest spisana cała semantic conventions na stronie OpenTracing w Repo GitHubowym, ona jest dość złożona, dotyczy błędów logowanych, dotyczy jakie są standardy przy wiadomościach, przy wywołaniach http, odwołaniach do różnych baz danych. Jest tego sporo i warto przeczytać, bo jest naprawdę dobrze napisane.

Ł: Znaczy ten semantic conventions tak naprawdę powoduje, że nie musimy myśleć i nazywać czegoś, tylko jest na to zestaw takiego standardowego podejścia.

S: Tak. Co jest ważne: większość bibliotek ma od razu constrainy wbudowane na te nazwy, więc nie trzeba się tym martwić, więc żeby tam magicznych stringów nie wklepywać.

Ł: Tak. Można polecieć enumem i tyle.

S: Tak. Kolejne elementy to są logi. O co chodzi z logami? Z logami chodzi o to, że w tym momencie do konkretnego trace’u umieszczamy konkretne wpisy, takie typowo logowe, z tą różnicą że ten wpis jest umiejscowiony na konkretny moment w czasie, bo span jest przedziałem tak naprawdę, a log będzie, że w tym spanie, w tym momencie, wystąpił ten log. Więc daje nam konfirmację, że nie musimy korelować jak szaleni, tylko mamy to w jednym miejscu, ładnie umiejscowione.

Ł: Przy czym też trzeba popatrzeć na te logi, że to nie będzie full text search, to nie będą logi z takiej definicji, o której mówiliśmy we wcześniejszych odcinkach.

S: Absolutnie nie. To są takie bardziej informacje, że coś się wydarzyło, to powinno być proste. Nie rzucajmy do systemów tracing zbyt dużo informacji.

Ł: Ja ze swojego przykładu staram się w ogóle omijać te logi, jeżeli ich nie potrzeba. Niektóre rozwiązania takie jak service meshup próbują nawet tam całe body wrzucić. Ja nie wiem, osobiście nie kupuję tej informacji. On rzadko jest aż tak bardzo wartościowy.

S: Ja też nie wrzucałbym tam zbyt dużo informacji. Tym bardziej, że będziemy mówili o tym w podsumowaniu, to z ilością informacji trzeba uważać, bo ona rośnie naprawdę szybko przy tracingu.

Ł: Dobra, teraz ostatni element.

S: Baggage items. I o co z nimi chodzi? To jest zestaw klucz-wartość, jak w sumie prawie każde poprzednie. One żyją w spanie i to jest kontekst informacji który jest przekazywany między każdym kolejnym spanem. Czyli ogólne informacje biznesowe, że użytkownik tam zaczął proces, co się działo, itd. Czyli takie informacje kopiowane do spana, do spana, do spana. Ł: I zazwyczaj generowane przy pierwszym starcie rozpoczęcia tracingu.

S: Część tak. Na przykład takie rzeczy typu na przykład SpanId, TraceId. Jak użytkownika zalogujemy, to mamy jego nazwę i w tym momencie możemy to rozszerzać na przykład. Przyjęło się faktycznie, że ta baggage items przekopiowujemy między kolejnymi. Nie jest to wymuszone, jest to mocno zalecane przez standard.

Ł: Dobra. To mamy teorię. To może ją podsumujmy. Całość takiego procesu nazywamy tracem.

S: Tak.

Ł: Jeżeli popatrzymy, to do niego są zapięte spany. Czyli trace to jest tak naprawdę zbiór spanów.

S: Acykliczny zbiór spanów, dokładnie.

Ł: Grafów, jak to powiedziałeś. Czyli tak naprawdę połączony ze sobą zestaw spanów. I dla każdego spanu można zrobić doszczegółowienie kolejnymi spanami, czyli tak jak w profilingu powiedzieliśmy, schodzimy w głąb do pewnego momentu. Następnie, jeżeli popatrzymy, to każdy span będzie miał swoje podstawowe informacje.

S: Tak.

Ł: To będzie trace, same czasy start – stop, relacje do rodzica, oprócz tego przypadku, kiedy mamy asynchroniczną komunikację. I na koniec logi i tagi nie są obowiązkowe, przy czym…

S: Tagi wskazane są bardzo mocno.

Ł: Tak. Są nieobowiązkowe, jeżeli popatrzymy na implementacje tracingowe.

S: Tak.

Ł: Z mojej perspektywy tagi są obowiązkowe do używania bardzo często.

S: Znaczy, poruszanie się po traceach bez tagów jest nierealne. Z mojego doświadczenia to musi być. I ich będzie przybywało razem z czasem.

Ł: Najprościej się po nich wyszukuje. To co powiedzieliśmy, że nie robimy fulltech searchów na jakimś logu, to nie jest rozwiązanie.

S: Nie zrobimy tam fulltech searcha.

Ł: Dobra. Mieliśmy teorię, teraz przejdźmy do praktyki. Jak to technicznie działa?

S: Bardzo prosto. W http przyjęło się, nawet service meshe też tak robią, że po prostu są odpowiednie http header’y. Proste. Wystarczy na przykład w Isio je przekopiowywać i wszystko działa. W messageingu to samo: mamy albo metadane albo mamy headery, dodawne jest i przekopiowywane. Większość bibliotek które są do na przykład mass transita… Są odpowiednie biblioteki które przekopiowują, odpowiednio wstawiają kontekst wywołania i to po prostu działa bardzo ładnie.

Ł: Tak. I teraz najciekawsze pytanie z mojej perspektywy. W którym miejscu zbieramy to jak budujemy taki tracing?

S: W kodzie aplikacji. Tutaj magii nie ma, trzeba jednak zmienić trochę aplikację, zainicjalizować, potrzebujemy tych tagów, potrzebujemy kontekstu. Możemy robić taką magię jaką robi Application Insights, o czym będziemy mówili. To ,że na przykład wpinamy się w wysyłanie SQL commandów, itd. Ale mimo wszystko to się skończy na tym, że będzie modyfikacja aplikacji. Application Insights wpina się jako proces debugujący niejako i dzięki temu to ma. Ale jak chcemy coś więcej, będzie to kod aplikacji.

Ł: Druga rzecz, nazwijmy ją infrastrukturą naszej aplikacji. Czyli są to jakieś reverse proxy, które mamy na wejściach przed aplikacjami, niektórzy to wykorzystują bądź service meshe, które obiecują ten distributed tracing z pudełka, bez naszej dużej ingerencji.

S: Dokładnie. Może niedużej, ale pamiętajmy, że service meshe operują na http, wywołań do SQLa nam już nie zmonitorują, więc przydałoby się. Jednak musimy te headery i z wiadomości przekopiować.

Ł: Dlatego używam tego słowa „obiecują".

S: Słusznie.

Ł: Zwiększam naszą świadomość. Dobra. Zobaczmy co mamy teraz, bo tego aż tak dużo nie ma jak sobie popatrzymy na popularne rzeczy. Co mamy dostępne?

S: Zaczęło się od Zipkina. I ja bym powiedział, że wyszedł dwa lata temu i faktycznie dyskusja czy Zipikin czy Jaeger była aktualna, jak się przygotowywaliśmy do tego odcinka, no to żaden z nas nie widział systemu, który by faktycznie używał Zipkin’a. Wszyscy używają Jagera.

Ł: Tak. Albo przeszli na Jaegera.

S: Tak, dokładnie. Tak więc Jaeger napisany w go od Ubera. Co jest w nim ciekawego? Ciekawe jest w nim to, że ma różne storages. Może być Cassandra, Elastic, Kafka i InMemory. Ja osobiście korzystałem z Elastica i daje rade, jest spoko.

Ł: Chyba tak, bo jeśli ktoś pójdzie potem kompleksowo jak mówiliśmy, to tak naprawdę Elasticiem może obgonić dwa problemy. Jedną kompetencją może obgonić dwa problemy.

S: Tak i co jest fajne jeszcze to Grafana umożliwia odpytywanie się Elastica i wyciąganie z tego metryk. A w sumie nasze trace’y mają metryki, więc możemy mieć detaliczny widok pojedynczych requestów w formie trace’a, ale zagregowany widok dla metryk i statystyk.

Ł: Tak, ale przejedziemy się w szczególności jak nasz system rośnie, nie wolno się przyzwyczajać do tego, że tam są metryki.

S: Tak, to się też zgadza.

Ł: Dobra. W sumie to jest to i SaaS’y, które są najwygodniejsze, bo jeżeli sobie popatrzymy na to mamy open-source’owo Jaegera, gdzieś tam sobie był Zipkin, ale większość jest w formie SaaSowej.

S: I nie ma się co dziwić, bo SaaS’y odwalają kawał dobrej roboty. W Application Insights – super usługa!

Ł: To jest od Microsoftu w ramach Azure’a , więc to warto dodać.

S: Tak. W ramach Azure’a, głównie dla dotnetu, ale jest też dla Node’a, jest też dla Javy.

Ł: Jest też dla Golanga. Teraz Microsoft dorobił do tego Forwarder po prostu, że można z OpenCesus’a z Golanga wysłać na Forwarder w tym formacie i on to sobie już przekaże i zrozumie. Microsoft bierze udział w budowie tych specyfikacji, więc natywnie będzie to też obsługiwał.

S: Tak, i co jest fajne, to tam jest minimalny próg instalacji, więc to się włącza błyskawicznie.

Ł: Przepraszam, Szymon. W Dotnecie jest minimalny próg instalacji.

S: W Node też jest bardzo łatwo.

Ł: Ale tam trzeba popatrzeć potem na biblioteki i takie inne rzeczy. Nie zawsze wszystko dobrze działa.

S: Tak. Kolejność, itd. Takie triki.

Ł: Tak. Kolejność w szczególności, Server Side jest jednak w Node. Trzeba mieć tam świadomość z tyłu głowy, w którym momencie zainicjalizować ten Application.

S: Zgadza się, jak najbardziej. Walczyłem z tym.

Ł: No właśnie. Więc aż tak bajecznie nie jest.

S: Tak.

Ł: Ale jest już udokumentowane.

S: Tak. Jest Dynatrace.

Ł: I oni też się udzielają przy specyfikacji, tej najnowszej. To chyba warto dodać. I to jest niezależna platforma, czyli to jest niezależny SaaS.

S: Dokładnie. Od Google’a jest…

Ł:…*Stack Driver Trace, zerknę w notatkę. Tak. Czyli tak samo jest odpowiednik Application Insights nastawiony przez Google’a.

S: I na końcu AWS.

Ł: AWS ma swojego X-ray’a. Z nim miałem akurat najmniej do czynienia, jeżeli chodzi o X-ray’a.

S: Też nie miałem, parę razy o nim czytałem, ale tu się też faktycznie nie wypowiem. Dobrze. Dobre praktyki – przydałoby się jakieś podsumowanie.

Ł: Chyba najważniejszą jest, o czym wspominałem przy Twoich metrykach, że nie zrzucamy wszystkiego potem.

S: Sampling jest krytyczny.

Ł: Tak.

S: Żeby dać skalę. Duże organizacje zbierają tysięczne części procenta i to im się przekłada na dziesiątki gigabajtów dziennie. Sampling jest krytyczny. Co jest bardzo fajne – większość z narzędzi ma dość sporo samplerów: statystycznych, probabilistycznych, o różnym rozkładzie, itd. Więc dodanie tego samplingu jest bardzo, bardzo proste.

Ł: Ewentualnie tak jak niektórzy – bardzo krótka referencja.

S: Tak też można. Zgadza się.

Ł: Niektórzy trzymają trace’y tylko jeden dzień.

S: Powiedziałbym, że dla mnie trochę za krótko.

Ł: Tak, ale są niektórzy, co traktują je jako bieżące sprawdzanie do szybkiej diagnostyki.

S: Może być.

Ł: Gdzie się zaczęło nam coś sypać, żeby znaleźć szczegóły. Więc albo sampling albo bardzo krótkie retencje.

S: Tak. To co już wspominałem, to że na bazie naszych trace’ów możemy zbudować metryki.

Ł: Już bardzo szczegółowe metryki.

S: Szczegółowe – tak, schodzące na poziom detalu ale widząc zagregowany widok naszego systemu, zagregowane czasy. To jest bardzo użyteczne, bo nie dublujemy kodu.

Ł: Tak. Potem przejdziemy, to jest bardzo istotne. Możemy trace’a połączyć z procesem biznesowym.

S: Nawet wskazane, bym powiedział.

Ł: Tak. Jest to wskazane. Teraz bardzo istotna rzecz: powinniśmy to zrobić w tagach jako adnotację i id procesu, tylko te kluczowe informacje, które pomogą nam żyć, nie wszystko.

S: Tak, bo naprawdę one będą puchnąć i to są typy wyszukiwania, gdzie warto żeby wpisy były dość niewielkie.

Ł: Kolejny punkt będzie istotny dla Ciebie.

S: Tak. Tracing jest techniczny. I czemu to jest ważne? Tracing niejako pokazuje nam, w którym momencie jest proces biznesowy. Błagam, nie wystawiajmy tego do biznesu, bo jak biznes zobaczy te wykresy Gantt’a, to będziemy mieli mały problem. Nie, to jest coś technicznego, co umożliwia nam debugowanie, sprawdzenie, zobaczenie gdzie mamy dziury, zobaczenie co możemy zoptymalizować, gdzie jest wartość, jak nasz system się zachowuje. NIE do wystawiania dla biznesu. Tyle.

Ł: Dobra. Teraz kontekst i to jest chyba tak jak w całym observability umieszczaliśmy to, kontekst jest bardzo ważny, czyli w tagach tak naprawdę w całym spanie powinno się dobrze zdefiniować cały kontekst naszego wywołania: środowisko, instancję, żebyśmy mogli namierzyć co tam się działo i połączyć to z logami jak i z metrykami, jeżeli tego potrzebujemy.

S: Tak, i ja tu jeszcze raz odeślę do tego linku w kontekście konwencji a propos tagów dla spanów. Tam jest naprawdę dobrze opisane to, co jest używane, jakie są standardy, co powinno być. Dobry punkt wyjścia. Bardzo!

Ł: Ostatnie, w sumie prawie ostatnie: optymalizacje wydajności.

S: I tak. Czemu warto jest mieć tracing? To jest fenomenalne spojrzenie generalnie gdzie w systemie jesteśmy, no bo odpalenie lokalne, że coś działa wolno – ok , interesuje nas jak to będzie się zachowywało w globalnym scopie na jakimś serwerze. Nie naszym lokalnym. I to zbieranie tych metryk i tych traców dla mnie osobiście jest krytyczne, żeby po prostu wiedzieć, co w ogóle system robi.

Ł: Czy da się po nich…to tak jak z profilingiem. Da się szczegółowo zobaczyć, w którym momencie ten nasz długi request ssie.

S: Tak. Nie prosząc się o podpięcie Profiler’a do aplikacji na produkcji. To powinno być absolutnie zabronione.

Ł: No dobra. Sami robiliśmy takie rzeczy, więc nie ma sensu. Czasami jest najprościej.

S: Trzeba zabronić, ale ewentualnie są wyjątki.

Ł: Tak. Pokazuje nam dokładnie czarne dziury w naszym systemie, w szczególności przy mikroserwisach. Jeżeli ktoś idzie lub idzie jeszcze niżej i robi nanoserwisy, to można, pomaga nam znaleźć czarne dziury.

S: Czarne dziury i przede wszystkim przerwy, gdzie przerywa, dlaczego nasz proces biznesowy trwa tak długo, bo mamy dziurę na ileś wiadomości, nie skalujemy się poprawnie.

S: Czas na podsumowanie. SaaS’y są tutaj super. Próg wejścia – minimalny, duża wartość – mogą być drogie.

Ł: Raczej tak. Tutaj trzeba być świadomym, bo płacimy za gigabajty danych w SaaS’ach. Za te wchodzące gigabajty, przechowywane też, ale bolą nas te wchodzące. SaaS’y są okej, w szczególności że mają ten próg wejścia tak jak dla mnie te Application Insights przy Dotnecie: „kliknij prawym, dodaj…"

S: Tym bardziej, że też dość często się integrują z usługami faktycznymi, są bardziej dokładne tracy na wejściu. Często nie musimy go na wejściu do aplikacji włączać. To jest też fajne.

Ł: Czyli po pierwsze, jeżeli możesz, bo to też dodajmy, nie wszystkie branże, sektory mogą sobie na to pozwolić aktualnie, bo jest różne podejście do tego. Więc SaaS’y są naprawdę genialne by zacząć. Cena może zabić, ale wartość też może być duża. Na starcie w szczególności, kiedy się zaczyna. Dobra. Następnie?

S: Tracing dla mnie często jak rozmawiam z ludźmi to jest na zasadzie: „fajnie by było mieć". Jak się spróbuje raz już systemu z tracingiem, to już się nie wraca. Tak samo jak raz się użyło Kibany z Elasticiem, to potem już nie chce się remote’ować na maszyny i przeglądać pliki logów z wielu maszyn.

Ł: Nie lubię Kibany jako takiej, więc bym się z tym nie zgodził.

S: Cokolwiek innego generalnie. Nie chcesz się remote’ować do dwudziestu maszyn

Ł: Tak, pomaga. Distributed tracing, jeżeli go mamy, pomaga w szczególności jeżeli przechodzimy dalej do tego koniecznego samplingu.

S: Zdecydowanie.

Ł: Tak, bo jeżeli coś się dzieje z systemem, zwalnia cokolwiek, to możemy na jakiś czas wyłączyć ten sampling i wrzucić wszystko. Trzeba pamiętać, że sampling jest konieczny, ale w sytuacjach, kiedy trzeba zrobić trouble shooting, można przełączyć wajchę i go przerzucić.

S: Można. Najbardziej polecam ten probabilistyczny. On faktycznie dba o dobry rozkład, nie pomija zbyt wolnych requestów, itd. Naprawdę jest cała sekcja dokumentacyjna do przeczytania. Dobra. Chyba tyle.

Ł: No to na razie!

S: Na razie!