Szymon Warda: Wczoraj działało a dzisiaj nie działa, to w tym mTmencie coś się musiało zmienić. Open telemetry jest standardem, tak to trzeba już nazwać tak naprawdę i to dojrzałym, bo już wersja 1.0 wyszła. Logi nie działają, logi, znaczy nie działają, kulawo trochę działają, ale są. Składnia Elastica, jeżeli chodzi o wyszukiwanie, jest prosta, że można postawić tam juniora i będzie korzystał z tego dobrze. Skoro już robimy, integrujemy się z aplikacją, to pchajmy te logi jawnie przez Open Telemetry Protocol. Cześć, czołem, kluski z rosołem. Słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na patoarchitekci.io, gdzieś tu na dole, wierzymy w Was, dacie radę. Dobra i dzisiaj odcinek w trochę innym stylu. Wracamy do observability i Szymon ma dziś bardzo ciężkie zadanie. Musi mnie przekonać, że jest sens i czas w ogóle inwestować w Open Telemetry, jeżeli mówimy o observability. I słuchaj Szymon, to skąd ta rozmowa?

Szymon Warda: Ta rozmowa jest stąd właściwie, bo jak popatrzymy sobie na rynek, co się dzieje, to mamy Open Telemetry, w który się dzieje dość dużo. A ile razy wejdziemy do dowolnego większego klienta (…), to widzimy dużych graczy, widzimy New Relic’a, Dynatrace’a, Elastica i Datadoga, tego typu narzędzia. Więc w takim razie, skoro tak piejemy od dłuższego czasu, bo zgodzisz się, że chwalimy Open Telemetrię od jakiegoś czasu, to nie jest też super nic nowego na chwilę obecną, się ustabilizował. To czemu dalej w ogóle widzimy tych graczy? Czemu w ogóle to istnieje i mają się całkiem dobrze? Bo dochody mają zacne, nazwijmy to tak delikatnie. Stąd ta rozmowa właściwie. Więc w takim razie czy jest sens w ogóle w takich dużych instytucjach wchodzić w Open Telemetry, wchodzić w ten stos open sourceowy? W tym kontekście będziemy mówili głównie o stosie grafanowym, bo nie oszukujmy się, wygrał tą wojnę jeżeli chodzi o o to jak widzimy, co widzimy i tak dalej.

Łukasz Kałużny: Wiesz co, dobra, zróbmy chwilę cofnięcia się, bo nie wszyscy wiedzą tak naprawdę czym jest observability i czym jest Open Telemetry. To może zejdźmy pierwszą rzecz Szymon, tak wracając, znajdziecie do tego chyba 3 albo 4 odcinki, podlinkujemy je, stare na ten temat, gdzie spędziliśmy tam z godzinę 20, tłumacząc pewne pojęcia pod spodem. Ale czym jest observability tak naprawdę?

Szymon Warda: Czym jest observability? Observability jest taką chęcią tego, żeby widzieć czemu coś nie działa. Różnica observability kontra monitoring. Monitoring to było, że patrzyliśmy na CPU, RAM i tak dalej i czy aplikacja działa. Wtedy załóżmy były takie sytuacje, że przychodzi załóżmy szef do zespołu, mówi: aplikacja mi nie działa. Zespół monitorujący patrzy, CPU jest ok, RAM jest okej, działa z naszej perspektywy. Tak trochę tego nie wystarcza. Observability jest taką chęcią i ruchem, żeby zobaczyć co się dzieje wewnątrz tej aplikacji tak naprawdę, jak ona przepływa po całości, całe nasze kochane mikroserwisy tudzież serwisy, jakkolwiek to nazwiemy i chęcią zrozumienia, co się dzieje wewnątrz i zbierania sygnałów i danych, które będą tłumaczyły zachowanie naszego systemu.

Łukasz Kałużny: Ja lubię to pojęcie trochę też z mechaniki w ogóle, takie inżynierskie, że jesteśmy w stanie zmierzyć stan systemu na podstawie właśnie tych sygnałów wychodzących, wchodzących, co się dzieje. Dobra Szymon, a z czego, bo tam są trzy takie kluczowe składniki, z czego to observability się składa?

Szymon Warda: I to idziemy od najstarszych, które znamy doskonale. Mamy logi, logów się nie pozbędziemy, nie oszukujmy się. Czyli tekst, mówiąc bardzo prosto. Tekst, ale też często okraszony dodatkowymi rzeczami, takimi metadanymi właśnie, które powiemy, że odnośnie korelacji i tak dalej. Też często ten tekst, te logi już nie są prostą linią, ale są też często formą ustrukturyzowaną. Structured Logging, już istnieje pojęcie od dawna, weszło, ma się dobrze, promujemy jak najbardziej, jest ok. Idziemy dalej. Dalej mamy metryki, czyli zbiór key value można powiedzieć, gdzie kluczem jest nazwa metryki. Tam oczywiście ona jest olabelowana, otagowana, jakkolwiek ją nazwiemy tak naprawdę. I mamy też wartość. Jest to z reguły liczba, tudzież jakiś float tak naprawdę. I to są wartości liczbowe, które są zbierane z różnych systemów, które mówią, jak często coś się dzieje, co się dzieje i tak dalej. Czyli dają nam takie ogólne pojęcie jak i co system właściwie robi. I z mojej perspektywy one są super krytyczne tak naprawdę, bo jeżeli patrzymy właśnie odnośnie monitoringu observability tak naprawdę, to… Załóżmy, widzimy, że system nie działa, to znaczy, że coś się zmieniło z reguły. Był deploy’ment, okay, to zmienił się kod, to winny jest jasne. Ale jeżeli nie było deploy’mentu, jeżeli wczoraj działało a dzisiaj nie działa, to w tym momencie coś się musiało zmienić. I właśnie o to chodzi, żeby… Wracam do tego, co Ty powiedziałeś, określenie, co się dzieje wewnątrz aplikacji. Czyli musimy namierzyć to, co się zmieniło, bo coś się musiało zmienić, albo więcej ruchu, albo coś innego. I właśnie monitoring daje nam taką szybką możliwość przeczesania i porównania co jest dzisiaj, co było wczoraj, co było tydzień temu, żeby znaleźć tą właśnie anomalię, odstępstwo od tego, co dzisiaj raportowane jest inaczej. Tego w logach nie znajdziemy za bardzo.

Łukasz Kałużny: Jeżeli teraz tak, pójdziemy, dobra, a czym jest samo Open… Mamy observability, czym jest Open Telemetry?

Szymon Warda: Łukasz, ale jeszcze o trace’ach zapomnieliśmy. Czyli sposób na śledzenie rzeczy pomiędzy serwisami, co jest bardzo krytyczne i to jest fenomenalna rzecz. Natomiast bardziej dla developerów, mniej do monitorowania właśnie, tak to często rozróżniam. Ale też tam fajne rzeczy można wyciągnąć. Mianowicie widzimy, jak się zachowuje cały flow, jak się systemy ze sobą komunikują. Super ważne. Dobra, teraz czym jest Open Telemetry? Open Telemetry jest standardem, tak to trzeba już nazwać tak naprawdę i to dojrzałym, bo już wersja 1.0 wyszła, wszystko jest fajnie. Jest sposobem w jaki raportujemy dane z serwisów i zarówno sposobem, jak je nazywamy, jak je labelujemy, konwencje nazewnicze, to jak są zbierane, jakimi protokołami się komunikują, gdzie właściwie wprowadzamy wzbogacanie tych danych ma przykład o labele, dodatkowe rzeczy i informacje, gdzie procesujemy. To jest zbiór bardzo dużej ilości takich dobrych praktyk, jeżeli chodzi właśnie o monitorowanie observability. Mówiąc bardzo prosto, receptą na to, jak wejść, zarówno jeżeli tworzymy jakiś system, jesteśmy dostarczycielem jakiegoś softu, czy też nawet jesteśmy dostarczycielem softu, który zbiera dane o monitoringu, bo tam też mamy pojęcie eksporterów, które ładnie wysyłają nasze dane, logi, telemetrię czy metryki do Grafany, do Elastica i do wszystkich innych tak naprawdę.

Łukasz Kałużny: Dobra, czyli mamy sobie te trzy filary w postaci tych najprostszych logów, metryk, które są najbardziej wartościowe wbrew pozorom, jak popatrzymy.

Szymon Warda: I najtańsze.

Łukasz Kałużny: Najtańsze i najmniej zrozumiane. I trace’y, które robią efekt wow dopóki nie odpalimy na produkcji. Czemu? To możemy pod koniec się jeszcze poznęcać. To te trzy rzeczy. Szymon, to jest to, co wypychamy z aplikacji. Jakbyś powiedział jak wygląda ta architektura Open Telemetry, z czego ona się składa? Bo tam też są jakieś pojęcia.

Szymon Warda: Jeżeli mówimy o samej architekturze Open Telemetry, to działa tak. Mamy sobie naszą aplikację. Aplikacja, i teraz będę upraszczał, aplikacja w jakiś sposób, jeszcze nie mówimy w jaki, wypycha te dane. Tym sposobem preferowanym jest oczywiście korzystanie z Open Telemetry Protocol, który może iść po gRPC, może sobie śmigać jeszcze po http. Wiadomo, tutaj gRPC może się przydać dużo bardziej. I teraz wypychanie może następować do konkretnego konsumenta, nazwijmy go tak, czyli jakiegoś Elastica, czy to będzie Loki, czy to będzie cokolwiek innego, co konsumuje. I tak, przy małych systemach to będzie działało. Natomiast jeżeli mamy coś bardziej sensownego i chcielibyśmy tych źródeł mieć trochę więcej i trochę pokombinować, trochę wzbogacić, na przykład wysyłać jakieś labele, przetransportować, zbuforować, zrobić takie słuszne jak najbardziej przy dowolnym średnim i większym systemie, to po drodze wystawiamy sobie collectora. I co umie robić taki collector? On umie robić dość sporawo, bo po pierwsze, w tym momencie wszystkie dane wysyłamy do collectora i on tam sobie umie to zbuforować, umie sobie wzbogacić, umie zamienić na przykład z trace’ów metryki, umie zrobić całe procesowanie. Czyli aplikacje się nie martwią, a on w jednym miejscu. Umie na przykład też scrape’ować niektóre rzeczy. I on te rzeczy zbiera, mamy w jednym miejscu całą konfigurację. Co więcej, ta konfiguracja od dość niedawna może też być dynamicznie podmieniana, co też jest bardzo fajne. I potem on może odpowiednie dane wysyłać do konkretnych konsumentów. Czyli możemy sobie załóżmy wstawić takiego Open Telemetry Collectora, przepiąć aplikację na coś nowego, a dalej przez jakiś czas na przykład raportować dane do naszego starego systemu i na przykład część logów wysyłać na przykład do danych archiwizacyjnych, a część wysyłamy sobie do Elastica, część wysyłamy sobie na przykład do Datadoga, część wysyłamy sobie na przykład do Grafany, bo chcemy zrobić poka m.in., case, który obecnie mamy na talerzu właśnie. Czyli tak to wygląda z dużej perspektywy, jeżeli chodzi o duże klocki.

Łukasz Kałużny: Czyli idziemy sobie aplikacja do niej SDK, Collector i eksporter.

Szymon Warda: Nie do końca Łukaszu. Właśnie, bo teraz wchodzimy w ten element, który jest często pojęciem, że to SDK musi być. A nie tylko, bo Open Telemetry jako taki ma też możliwości totalnej zero code instrumentation. Nie dla wszystkich języków co prawda, mówimy tutaj dwa główne, gdzie to się rozwija najlepiej. Java stoi w sumie chyba najlepiej, jeżeli chodzi o dojrzałość, chociaż nie w każdym obszarze, że możemy sobie odpalić naszą aplikację w formie w agencie, który będzie przy zerowej zmianie kodu w naszej aplikacji zbierał tę telemetrię, zbierał dane i wysyłał właśnie do Open Telemetry Collectora. Czyli to nie jest tylko SDK, ale tak, SDK jest tą wersją jak najbardziej zalecaną.

Łukasz Kałużny: Teraz powiedziałeś, że SDK jest zalecane, daje tam jakieś autoinstrumentation również z pudełka. Ale wróćmy sobie, bo zacząłeś od tego, że gdzieś znajdują się ciężkie, klasyczne kobyły. I tak naprawdę jaka jest zaleta, że ja zacznę inwestować teraz w Open Telemetry? Czyli mam, nie wiem, wdrożonego dajmy na to na trace’a Datadoga, może New Relic jak wspomniałeś, i jaka jest tak naprawdę wartość schodzenia z takiego SAS-owego APM-a czy on prem’owego Dynatrace’a, jak mamy na rzecz tego stosu open source? Bo ja teraz próbuję to zrozumieć kiedy, czy to w ogóle ma sens inwestowanie i dotykanie w to?

Szymon Warda: Wiesz co, powiem Ci tak, rok temu bym powiedział, że tak: a zastanówmy się jeszcze, może niekoniecznie. Teraz co się dzieje? Po pierwsze, ci duzi gracze, bo cały standard Open Telemetry został wymyślony częściowo właśnie po to, żeby nie było takiej sytuacji, że na przykład ja jako dostawca jakiegoś softu integruję się z jakimś APM-em, daję to klientowi, a klient ma innego APM-a i nagle jest słabo. Więc zacznijmy od tego, że praktycznie dowolny, czy to będzie Datadog, czy to będzie New Relic i tak dalej, umieją konsumować Open Telemetry. Więc ja pisząc moją aplikację nie muszę w tym momencie, po pierwsze, łączyć się z SDK konkretnego providera, mogę korzystać z SDK Open Telemetry. Czyli jestem przenośny. I tu się zgodzimy, że to ma sens. Wpinanie i łączenie się konkretnym SDK, na przykład Elastic’a czy kogokolwiek innego, średnio ma to na chwilę obecną wartość, niewiele tym zyskujemy. To jest ta jedna rzecz. Więc tu rozwój aplikacji spoko. Problem jest drugi, problem jest faktycznie autoinstrumentacji. Bo o ile mówimy, że tak, Open Telemetry ma autoinstrumentację, to czy ona jest tak samo dojrzała? Nie, nie będziemy tu kitowali, że jest super. Rzecz, której nie ma za bardzo tak naprawdę i nie jest tak bardzo rozwinięta, to jest między innymi profiling taki typowy. To co widzimy w Application Insights i tak dalej, w każdym praktycznie, że widzimy sobie, że klikamy profile i widzimy wszystkie przejścia, wszystkie wywołania i tak dalej, i tak dalej, i tak dalej. Taki bardzo dokładny wgląd w to, co się dzieje w aplikacji. Czy tego potrzebujemy zawsze? Nie. Czy powinniśmy mieć cały czas włączone? Też absolutnie nie. Czy przydaje się raz na jakiś czas, kiedy jest wywał na produkcji albo nie wiemy, co się dzieje? Tak, przydaje się bez dwóch zdań. Więc tutaj trzeba być świadomym. Pytałeś się w takim razie, czemu warto inwestować w Open Telemetry?

Łukasz Kałużny: No właśnie.

Szymon Warda: Tak. Dlatego, że to jest przyszłość. Bez dwóch zdań cały rynek idzie w tym kierunku. To jest pierwsza rzecz. Druga rzecz, to jest ta dyskusyjna, jak do tego podejść i jak to policzyć. A wiemy, że księgowość jest bardzo, bardzo kreatywna. Tak, to jest to, że znamy, słyszeliśmy, widzieliśmy jakie są cenniki dużych AP-ów, czyli Application Performance Monitorów. To nie są małe koszty. One są liczone od kilku rzeczy. Albo od danych wchodzących do nich, albo od CPU, od RAM-u, od hostów, tego typu rzeczy. Więc jeżeli mamy trochę instancji, mamy środowisko, jakieś performance testowe, developerskie, testowe, to często widzimy taką opcję, że one tam nie są te rzeczy włączone, typu APM-y, bo jednak oszczędzamy koszty, a te koszty z reguły są duże. Korzystając z tego, gdzie trzymanie tego samemu nas to ratuje? Oczywiście płacimy za dane, płacimy za ludzi, płacimy za bardzo wiele rzeczy, ale możemy te dane usuwać, możemy pewnymi danymi w inny sposób zarządzać, więc staje się to bardziej elastyczne i ta kontrola nad tymi kosztami staje się po prostu lepsza.b Inna bajka, narzędzia, mojej zdanie jest takie, narzędzia typu Dynatrace, New Relic, to są bardzo fajne narzędzia ogólne. To nie są narzędzia, na bazie których zbudujesz taki dobry zespół do monitorowania, do utrzymania i taki szeroki. Co więcej, są to narzędzia, których mała jest znajomość rynkowa. To jednak jak ktoś zna jedno, to potem przechodzi, to musi się od nowa uczyć. A daj mi dowolnego SRE, gwarantuję Ci, że zna Grafanę, gwarantuję Ci, że zna te high level’owe narzędzia, będzie przynajmniej miał znajomość, kiedyś używał Alert Manager’a od Prometheus’za. To są już po prostu standardy rynkowe. Co też widzimy u dostawców chmurowych, przechodzą na przykład na Prometheus’za.

Łukasz Kałużny: Tak, Prometheus, Grafana się pojawia coraz częściej jako manage.

Szymon Warda: Dokładnie tak. Po prostu wygrało tą walkę.

Łukasz Kałużny: Słuchaj, popatrzymy, dobra, bo jedna rzecz, która mnie nadal… Popatrzymy, wezmę sobie takiego Dynatrace’a, Datadoga, wepchnę go w coś, co jest w trybie maintenance. To działa i monitoruje.

Szymon Warda: Zgadza się, działa i monitoruje.

Łukasz Kałużny: No właśnie. I teraz jaki jest sens tak naprawdę przesiadania się na Open Telemetry? W którym momencie?

Szymon Warda: Łukasz, to taki sam… Sens jest taki, że działa i monitoruje. Tak, tylko pomyślmy o tym, to samo możesz zrobić, działa i monitoruje w ramach Open Telemetry, ta autoinstrumentacja jest coraz bliżej, żeby inną rzecz wykluczyć. Różni providerzy typu Dynatrace, New Relic i tak dalej, oni mają na przykład dodatkowe wartości typu, że zarządzają security, trochę jeszcze inne rzeczy, tak bardziej do tego podchodzą holistycznie. Czyli mamy jedno narzędzie, które możemy dać zespołowi, który niewiele czasami wie i będą na przykład mieli alerty trochę mądrzejsze, trochę lepszą komunikację, trochę mądrzejsze wykrywanie, co tam się popsuło i tak dalej. To tutaj w ogóle nie wchodzimy. Open Telemetry jest do do aplikacji naszego systemu, takie gołe, czyli logi, metryki, trace’y. Dobra, pytasz się w takim razie: możesz włączyć? Możesz. Tylko jakość tego co będziesz miał będzie taka, doskonale wiesz jaka będzie. Nie będzie najlepsza. Czyli patrzysz, próbujesz wywnioskować dane biznesowe, które realnie Cię interesują na bazie nazw kontrolerów, na bazie tego co tam ten nasz agent, który się podłączył, próbuje wykoncypować. Jakość tego wątpliwa. Więc żeby ją poprawić realnie i tak będziesz musiał jakieś zmiany w kodzie zrobić, żeby mieć lepszą widoczność i tak dalej, żeby stworzyć te wszystkie linie, warstwy, generalnie odpowiedzi i jak zespoły reagują. Będziesz to musiał zrobić. Więc teraz moja opcja, skoro i tak musisz to w pewien sposób zrobić, skoro koszt integracji, koszt na przykład przekazywania trace’ów, śledzenia, wywołań http, wywołań do baz danych, dla większości języków to albo jest wspierane w bibliotekach natywnych do komunikacji, to mamy przy Javie, mamy przy .Necie. Przy Node’zie tam trochę to idzie…

Łukasz Kałużny: No właśnie miałem Ciebie zapytać jak jest, bo są dwie rzeczy, które widzimy po prostu z pudełka, które się zaczynają pojawiać tam, to distributed tracing niskim kosztem od strony takich gotowców. I druga rzecz pokazanie sobie drzewa zależności w ładny sposób. Do tego stopnia, że jak mamy popularniejszych języków i ORM-ów, to zobaczymy sobie querki, które są na bazie danych puszczane w danej transakcji.

Szymon Warda: No dobra, to przejdźmy jak to wygląda, bo to jest bardzo ważne. Po pierwsze tak, jeżeli wykorzystasz autoinstrumentacje, Open Telemetry, tą która jest wbudowana w Jave i .Neta, to to działa. Czy jest idealne? Nie. My dalej będziemy, ja będę dalej zachęcał do tego, żeby jednak zrobić przez SDK, czyli jednak to z aplikacji mieć. Jak to wygląda? Realnie jest to konfiguracja, dodanie kilku bibliotek i skonfigurowanie, że tak, chcę SQL-e. Tak, korzystam z NHibernate’a czy Hibernate’a czy Entity Frameworka i wpięcie się w ORM-y, wpinasz się i działa z pudełka, masz SQL-e. To jest koniec Twojej roboty. Po prostu jest. Idziemy dalej, jak wsparcie wygląda. Dla http klientów Java, .Net działa. Dla wszystkich gRPC? Działa, nie ma problemu. Wsparcie przez Springa? Czyli nie oszukujmy się, większość aplikacji java’owych. Wsparcie dla klientów do Kafki. Wsparcie dla klientów do Rabbita. Wsparcie dla załóżmy cały Azure SDK, też jest obłożony telemetrią. Mass Transit, czyli właśnie rabbitowy, to wszystko generalnie działa Ci z pudełka. Idziemy teraz trochę dalej, bo to nie jest tak bardzo różowo. Teraz tak, mamy Node’a, kolejny popularny język. Tam czy mamy wersję agentową? Taka nie do końca, bo tam wpinamy się w ten sposób, że dodajemy, odpalamy jak agent, ale on po prostu podmienia niektóre wywołania i robi takie proxiaki na wywołania, bo Node jest bardziej dynamiczny, ale też mamy formę autoinstrumentacji. Teraz dalej, jeżeli chodzi o dojrzałość wywołań, masz do Expressa, masz do GraphQL, gRPC, MySQL, Mongo, Reddisa, Kafki, masz biblioteki, które wspierają całą telemetrię. Python podobnie, też ma podobną autoinstrumentację. Nie jest tak stabilna jak pozostałe, ale mimo wszystko… Nie jest tak dojrzała, może tak. Dobra, dalej idziemy. Wsparcie dla Flaska, Django, Fast API, gRPC, SQL Alchemy i tak dalej. Śmiga. I teraz wchodzimy z dojrzałością. Gorzej Rust. Go - średnio, tam nie mamy autoinstrumentacji.

Łukasz Kałużny: Dobra, ja z Go zostawię tutaj w tym, bo były gdzieś wylewane wiadra pomyj na temat implementacji Open Telemetry w Go, więc to zostawię.

Szymon Warda: Dlatego mówię, to jest tutaj, tu jest średnio, w Rust’cie też jest średnio.

Łukasz Kałużny: Gdzie wydawało się powinno być rock solid. Dobra.

Szymon Warda: Może do sterowników nie potrzebujesz mieć Open Telemetry. To jest żart oczywiście.

Łukasz Kałużny: Dobra, teraz powiedziałeś sobie o tych rzeczach. Okej, czyli distributed, tracing i inne takie rzeczy dostajemy, wypychamy. Tylko całość i tak wymaga jakiejś tam, tak jak z logami, jakiejś naszej pracy w tym kodzie.

Szymon Warda: Wiesz co, tak. Przykład, który dam Ci, anegdotę z życia wziętą, to jest na przykład mówimy sobie o tym, że idziemy scenariuszem, że nie potrzebujemy. Mieliśmy ostatnio taką sytuację, że klient zainstalował agenta dynatrace’owego w klastrze i nagle aplikacja przestała działać. Czemu? Okazało się, że klient dynatrace’owy, żeby robić tracing dla wiadomości, bo to jest takie trochę trudniejsze po kafce, wstrzykiwał w headery swoje swoje trace ID. I okazało się, że aplikacja wykorzystuje headery i się zaczyna wywalać na twarz. Więc niestety to jest taka opcja, że jak mamy jakąkolwiek magię, to ta magia może nas dość mocno ugryźć w tyłek, mówiąc bardzo prosto i się wywalić. Więc prędzej czy później będziemy zmuszeni, powinniśmy właśnie przekazywać te rzeczy, wpiąć się mimo wszystko jednak ręcznie. A ułatwia to, że większość narzędzi umie to zrobić bez większego problemu już na chwilę obecną.

Łukasz Kałużny: Dobra, powiedzieliśmy sobie mamy narzędzia, powiedziane wpinanie tego. Okej, zaczynamy to wypychać z aplikacji. Czyli aplikacja zaczyna to wypychać. Tak naprawdę co dalej po tym, czyli gdzie to wypychamy? Bo tak jak powiedziałeś, Open Telemetry działa w trybie pushowania głównie. To gdzie to wypycha?

Szymon Warda: Zanim tam pójdziemy, bo jeszcze jednego obszaru nie dotknęliśmy - przeglądarki.

Łukasz Kałużny: Ok, bo APM-y ok, faktycznie APM-y dają nam często plugin frontendowy.

Szymon Warda: Plugin frontendowy, jedną linię do włączamy i wszystko jest wysyłane i działa.

Łukasz Kałużny: Tak mówi teoria.

Szymon Warda: Ale lepiej lub gorzej działa. W sensie mamy tracing od strony przeglądarki do tego, co się dzieje na naszym backendzie. Przez jakiś czas, dłuższy czas nie było tego po stronie Open Telemetry. To już jest, co nie wiem czemu nie obiło się większą wrzawą, że tak powiem. Co więcej, to możemy zrobić taki myk, że będziemy te dane telemetryczne raportowali do naszego endpointu pod naszą domeną. Więc w tym momencie jest mniejsza szansa, że telemetria nasza będzie blokowana przez wszystkie adblockery i tak dalej, jako elementy śledzące.

Łukasz Kałużny: Ok.

Szymon Warda: Co przyznasz, że jest dużą wartością.

Łukasz Kałużny: Tak, można prześledzić transakcje przy bugach od frontendu zazwyczaj, którego teraz mamy do końca. Tak, to ma swoją wartość, o tak, to jest taka rzecz, która jest, o której faktycznie zapomniałem, że to nawet weszło, a z czego zdarza nam się w Application Insights bardzo często korzystać.

Szymon Warda: Bo działa bardzo dobrze i też ta integracja jest, no nie jest tak super dojrzała, jednak jest i działa dobrze. Taka czwórka z plusem spokojnie możemy powiedzieć. Logi nie działają, logi tam trochę… Znaczy nie działają, kulawo trochę działają, ale są, więc tracing mamy. Dobrze, mówiłeś teraz odnośnie, pytanie było: gdzie te logi są wysyłane?

Łukasz Kałużny: Tak i jak to działa dalej?

Szymon Warda: Tu idziemy po kolei, od najprostszych rzeczy. Metryki idą do Prometheus’za. Chyba nie musimy narzekać. Albo do Prometheus’za, albo do czegoś prometheus’zo podobnego, bo tego trochę jest. Jest to standard rynkowy, wygrało, wszyscy korzystają, wiemy jak korzystać, ma fajny język do querowania, ma całkiem okej system do alertów, nie możemy mieć większych zarzutów. Powiem nawet więcej, jeżeli chodzi o metryki, to Prometheus jest dużo przyjemniejszy niż dostawcy dużych APM-ów. Takie moje zdanie. Dobrze, idziemy sobie dalej. Logi teraz rzućmy. No i tu trzeba być szczerym tak naprawdę. Jeżeli chodzi o logi, jeżeli chodzi o duże systemy typu właśnie Loki, to oddajemy UX za to, że to jest tańsze po prostu mówiąc bardzo prosto. Wykorzystanie i składnia Elastica, jeżeli chodzi o wyszukiwanie, jest proste, że można postawić tam juniora i będzie korzystał z tego dobrze. Jak doskonale wiemy składnia Loki już nie jest taka intuicyjna i tam wykorzystywanie złe, albo bez przeszkolenia, bez jakiejś wiedzy jak to działa, skończy się z reguły średnio, bo po prostu ubijaniem tego serwera.

Łukasz Kałużny: Ok, bo trzeba powiedzieć teraz, bo mówisz konkretnie, bo log collectorem dla Open Telemetry nadal może być Elastic, jeżeli sobie tego życzymy.

Szymon Warda: Oczywiście, że tak.

Łukasz Kałużny: Nadal od tej strony. Jeżeli popatrzymy na Lokiego, to on ma swoją wadę, że nie mamy całej replikacji, nie jest bazą danych tak naprawdę w takim rozumieniu jak Elastic i nie ma full text search’a.

Szymon Warda: Dokładnie tak. Ma strumienie, jest dużo tańszy, szybszy… Znaczy szybszy, szybszy w pewnych obszarach, ale query będą zajmowały dłużej na przykład. Jest z punktu widzenia osoby, która wykorzystuje system jako taki, jest mniej fajny. I tu nie będziemy kitować, że jest inaczej.

Łukasz Kałużny: A frontendem do wszystkiego będzie, jak rozumiem, Grafana.

Szymon Warda: To jest ten duży plus. Mamy jedno miejsce, gdzie spinamy wszystkie systemy i nie musimy mieć wielkiej strony wiki, że logi to tu, a performance monitoring to tu, a tu mamy Prometheus’za, a tu mamy co innego, bo doskonale wiemy jakie użyjemy.

Łukasz Kałużny: Dobra, czyli teraz tak, pytanie jest, czy w takim razie, czyli te logi z aplikacji pchamy sobie z stdout’u, z jakiegoś wrapera, czy w jaki sposób wrzucamy te logi?

Szymon Warda: Właśnie nie, bo jeżeli mówimy o tym, żebyśmy pchali z stdout’u, to w tym momencie aplikacja będzie robiła trochę więcej, to te logi mogłyby się pogubić. Nasza droga jest inna. Skoro już robimy, integrujemy się z aplikacją, to pchajmy teologii jawnie przez Open Telemetry Protocol do naszego collectora, czyli do jakiegoś endpointu Open Telemetry. Co więcej, taki Elastic też może takie dane w tym formacie konsumować i też się nie obrazi. Większość vendorów przyjmie z wielką chęcią Open Telemetry Protocol.

Łukasz Kałużny: Czyli po prostu zamiast stdout pushujemy je sobie dalej.

Szymon Warda: Tak. Przy czym tu bądźmy realistami, może być taka sytuacja, taka sytuacja pewnie będzie, że jakieś logi się przez Open Telemetry Protocol nie wyślą. Tak że stdout dalej trzeba obserwować, bo błędy krytyczne będą się pojawiały w stdout’cie.

Łukasz Kałużny: Rozróżniamy logi czysto aplikacyjne od takich logów technicznych, które powinny tam zostać, typu poleciał jakiś stack trace.

Szymon Warda: Dokładnie tak. Może inaczej, poleciał jakiś auto memory exception, jakiś krytyczny błąd, framework nam się wywalił, błąd w konfiguracji, tego typu rzeczy. Spodziewamy się, że będzie z aplikacji, ale nie zawsze tak się dzieje. Trzeba jednak być realistą.

Łukasz Kałużny: Przewijasz teraz temat w ogóle, bo ciągle się pojawia Prometheus, Grafana, ten stos open sourceowy. To tak naprawdę co tam jest i do czego w tym stosie opensourceowym? Bo to rozumiem, to jest dla nas cały, że tak powiem, Grafana jest frontendem, plus cały ich zestaw zabawek do składowania tych danych.

Szymon Warda: Dobrze, tam jest kilka zabawek faktycznie. Dobrze, że o tym powiedziałeś. Idziemy najprostszych. Mamy Grafanę, czyli coś, co służy do wyświetlania, łączenia i alertowania. Tyle. Ładne, ładne wykresiki, z tego głównie ją znamy. I też jest takim single point of entry, głównym punktem wejścia dla wszystkiego. Teraz idziemy dalej. Prometheus, który nie jest grafanowy, ale Grafana też ma swój odpowiednik. Czyli tam trzymamy wszystkie metryki. Fajny język, prosty, ładnie się skaluje, możemy fajne rzeczy robić. Dobra, idziemy dalej. Loki, trzymamy logi, czyli trzymamy tekst. Działa, umie… I bardzo cenię Loki za to, że może skalować się do absurdalnych rozmiarów, absurdalnych wolumenu logów i jest dość przyjemny jeżeli chodzi o stawianie. Ma też alerting na logach, ma dość dużo rzeczy generalnie i integracja z całym stosem jest fenomenalna. Idziemy dalej. Wchodzimy w Tempo, czyli element do trace’ów. Czyli tam trzymamy wszystkie trace’y, możemy je wyświetlać. Jedna ważna uwaga to jest taka, żeby też być, to ładnie też Ty powiedziałeś odnośnie tego, że jest pewne rozczarowanie odnośnie trace’ów, to jest to, że trace’y jako takie, Tempo obsługuje trace’y w trybie… Nie ma raportowania, nie ma agregacji. Czyli wszystkie wyszukiwania robimy w kontekście jednego trace’a i możemy znaleźć jeden, możemy znaleźć trace, który nas interesuje, ale na przykład nie możemy powiedzieć: znajdź mi średnią po wszystkich trace’ach, która metoda…

Łukasz Kałużny: Czyli nie da się zrobić tych ładnych grafów z metrykami, ze statystykami.

Szymon Warda: Tak, takie rzeczy raportowe niestety nie działają. Czemu? No bo albo robimy transakcyjnie, albo robimy raportowo, sorry. Ale nie jest tak źle, bo Tempo zapisuje dane w parquet’cie. Więc w tym momencie te dane, które zapisujemy w parquet’cie możemy przerzucić przez jakikolwiek stos do machine learningu, który będzie to rozumiał i raportowanie robić w tym miejscu. Nie jest to wbudowane w Tempo, sorry, ja też tego żałuję. Rozumiem tą decyzję jeżeli chodzi o produkt.

Łukasz Kałużny: Tak, wiesz, bo ja teraz tak, to jest właśnie ta rzecz chyba, która w APM-ach, jak popatrzymy, bo to, co mówisz jest dobre, tylko w APM-ach dają nam przyjemny view, który pozwala, nawet jeżeli mamy włączony tylko sampling, to zobaczyć sampling z trace’ów i zobaczyć względnie rzeczywiste statystyki, co, jak wygląda.

Szymon Warda: Tak, na przykład rozkład czasu wywołań do bazy danych. Dzięki temu nie patrzymy na pojedynczego trace’a, nie mamy takiego wąskiego widoku, że to wywołanie zachowuje się wolno. Może ok, może ono wykonało się wolno, ale jeżeli 99% wykonuje się w czasie szybszym znacząco, to po prostu mamy ten jeden element, który odstaje. To jest bardzo ważne.

Łukasz Kałużny: Był ten pech, był ten pech, a nie…

Szymon Warda: Albo była czkawka, albo cokolwiek innego, albo to było abnormalnie duże względem reszty systemu. Tak, więc z tego takiego kontekstu, co się w ogóle dzieje, niestety nie mamy. I to jest, tu przyznaję, jak najbardziej jest to element bolący.

Łukasz Kałużny: Dobra, jeżeli teraz tak popatrzymy sobie dobra, czyli tutaj od tej strony Tempo troszeczkę odstaje aktualnie.

Szymon Warda: Tak, można to zasypać własnymi rozwiązaniami i nawet jest parę podejść, ale niestety trzeba się trochę nagłowić.

Łukasz Kałużny: No dobra, i teraz tak, bolączka, jeżeli popatrzymy, to jest przechowywanie danych w tych systemach, więc jak ogólnie w monitoringu. Więc jeżeli nie masz rozwiązania SAS-owego, które pobiera od Ciebie stosowną opłatę za to, że zdejmuje Ci to z głowy. Więc jak tu wygląda z przechowywaniem?

Szymon Warda: I to jest ten element, który błyszczy i trzeba to rozbić trochę na dwie opcje. Po pierwsze, jeżeli w czym błyszczy, bo skupimy się tu głównie na tam, gdzie danych mamy dużo, czyli mówimy o Loki, Tempo. To w czym to błyszczy? To jest to, że faktycznie jest to system pomyślany na to, że przychodzi duże ilości danych. Jak to się dzieje? Dzieje się przede wszystkim to, że dane są ładnie dzielone, dane są zipowane, dane są przechowywane na głównie storage’u blobowym. Czy to będzie Azure Blob Storage, czy to będzie S3, cokolwiek co ten interfejs implementuje będzie działało. Więc jeżeli jesteśmy w chmurze tak naprawdę, to możemy sobie to robić bardzo niskim kosztem, storage naprawdę dużego zbioru danych. Jeżeli jesteśmy na on premie, to oczywiście są rozwiązania, które będą symulowały. Może nam to wyjść trochę drożej.

Łukasz Kałużny: Ewentualnie to, co podpowiadamy klientom, jak się okazuje, czasami okazuje się, że mają licencję np. do storage’u, który wystawia te S3 API.

Szymon Warda: Tak, dokładnie sporo w ogóle vendor’ów, to co mówiliśmy wiele lat temu o tym właśnie, że sporo właśnie vendor’ów takich macierzowych mówi, że okej, wystawiają w ogóle właśnie API S3, bo ono stało się standardem, można powiedzieć.

Łukasz Kałużny: Tak, dobra, to zrobiliśmy. To teraz kolejny element, o którym myślę. Jak podejść w takim razie, dobra, to powiedzmy, że przekonałeś mnie do Open Telemetry. Ważne, to chyba to trzeba powiedzieć, tak jak ja to rozumiem, najlepszym odbiorcą Open Telemetry to jest coś, co ma aktywny maintenance, aktywny development.

Szymon Warda: Dokładnie tak.

Łukasz Kałużny: I mamy kontrolę nad kodem.

Szymon Warda: Dokładnie tak.

Łukasz Kałużny: Dobra. I teraz powiedzmy sobie Szymon, to co się znajduje z naszej codziennej praktyki z klientami, to co robimy? Przychodzisz i klient powiedział, że: chcemy Open Telemetry. Jak wygląda proces adopcji tego?

Szymon Warda: Jasne. Znaczy on jest dwojaki. Bo pytanie jest proste, czy klient jest w Kubernetes’ie? Bo jeżeli klient jest w Kubernetes’ie, to nasze życie się znacząco ułatwia. I nie tylko dlatego, że jest w Kubernetes’ie, bo w tym momencie możemy ustawić scraping podów, możemy ładnie sobie wdrożyć collectora, ładnie wdrożyć wszystkie pozostałe rzeczy, czyli mamy do tego niemalże gotowe YAML-e. W tym momencie jest łatwiej. Drugi jest element, bo jeżeli klient jest w Kubernetes’ie, to znaczy, że stos, na którym pracuje jest relatywnie nowy. Słowo kluczowe: relatywnie nowy. Czyli nie mówimy na przykład o antycznych aplikacjach, które są rozwijane od lat dwudziestu. Zapewne produkują dużo wartości biznesowej. Technicznie mogą być wyzwaniem. Więc jeżeli jest w Kubernetes’ie, prosta sprawa. Jeżeli na przykład pracuje na VM-kach, czyli mówimy już trochę będzie trudniej, to w tym momencie ok, Open Telemetry Collector może dalej scrapować logi, może dalej zbierać dane z VM-ek, to też nam się przyda w kontekście samego Kubernetesa, żeby wiedzieć co tam jest hostowane i to wszystko dalej możemy wysyłać. Czyli plus, który widzimy, to jest to, że idziemy od najłatwiejszych, obcinamy i budujemy cały pipeline, gdzie nasz Collector i jego rola podstawowa jest to, żeby nie mieć tego co często widzimy w narzędziach do APM-u, że mamy takie warstwy jakości, że okej, dla tego systemu to wygląda dobrze, ale potem wchodzimy do tego systemu, to te logi wyglądają i te dane, które mamy, wyglądają po prostu jak coś nieładnego, że tak powiem ładnie. Więc wstawiamy po kolei collectory, żeby dane wzbogacać, żeby jak najbardziej zbliżać je do tego finalnego miejsca. Jak to wygląda, jeżeli chodzi o samo wysyłanie, czyli ten cały proces migracji? Nie robimy wielkiego skoku hopsasa na nowy system. To robimy tak, że ponieważ możemy mieć Open Telemetry Collector, pewnie będziemy go mieli, to jest to, że wdrażamy, zaczynamy część danych wysyłać do nowego celu można powiedzieć, pewnie do Loki, pewnie do Tempo. I w tym momencie, jak ten system napełnimy powiedzmy danymi z dwóch, trzech miesięcy, w tym momencie możemy robić ładne przeskoczenie. Czemu? Żeby nie było takiej rzeczy, którą widujemy czasami, że ok, wiesz co, dane odnośnie tego, to które mają tam powiedzmy powyżej tygodnia to są w tym systemie, a te są w tym systemie i w tym momencie budujemy absurdalną frustrację. Co jest dalej ważne? Jeżeli chodzi o sam proces w ogóle przejścia, to jest to, że muszą być jakieś szkolenia, które pokażą, jak się z tego korzysta. To też jest w ogóle często duży problem dla APM-ów wszelkich, że one są rzucone na pożarcie, że tak powiem, zespołom i teraz uczcie się. No sorry, tak to nie będzie działało. Nie przy systemach open source’owych, które są trochę trudniejsze i trochę szorstkie w interakcji, żeby odpowiednio pokonfigurować. Dalej przede wszystkim pokazujemy jakie są możliwości, jakie są feature’y, bo czasami do niektórych dogrzebanie się jest trochę problematyczne. Potem dalej co robimy? To jest konfigurowanie wszystkich dodatkowych rzeczy typu generowanie metryk z trace’ów, przydaje się szczególnie na starcie, generowanie service grapha, generowanie poszczególnych rzeczy, żeby ten feature set był jak najbardziej bogaty i pełny. I potem pokazanie, co jest też bardzo ważne, jakie persony z czego będą pewnie najbardziej korzystały. Admini będą mieli zupełnie inny przypadek użycia, że tak powiem, inny scenariusz użycia niż developerzy. To będą zupełnie inne rzeczy. I dalej idziemy. Konfiguracja retencji i dla performance testowych nie ma sensu pewnych logów trzymać. Dzielenie które środowiska jak trzymamy, konfiguracja multitenancy, podzielenia widoków, dostępów i tak dalej, i tak dalej.

Łukasz Kałużny: Dobra, ile to czasu zajmuje? Bo teraz tak, powiedziałeś o tym całym procesie, który może dla niektórych brzmieć w diabły długo. Więc ile to jest takiej… Wiesz co, może inaczej, decydujemy się, ile to jest takiej faktycznej pracy?

Szymon Warda: I tu jest super nowina, bo trzeba podzielić tę pracę dwojako. Bo realnie, jeżeli mamy w miarę nowy stos, to pracy po stronie zespołu developerskiego, czyli po prostu jest relatywnie niewiele. To jest 5-10 bibliotek, albo jeżeli byśmy bardzo chcieli, to na starcie to w ogóle użycie podejścia agentowego. Czyli to nie jest totalna wywrotka, że nagle zatrzymujemy development na najbliższe dwa tygodnie i wszyscy robią Open Telemetry. Nie, to tak nie działa. Więc to jest duża wartość.

Łukasz Kałużny: Ale inaczej jest robota, bo teraz jest jedna rzecz, ale to będzie też przy APM-ach, kiedy chcemy faktycznie w te trace’y, metryki dorzucić procesy biznesowe. To tak jak z logami, że trzeba te linijki tam wpisać, jak rozumiem?

Szymon Warda: Tak. Trzeba je wpisać, od tego nie uciekniemy. Mówimy godziny per system. Jak zrobimy za jednym razem, to potem realnie wyekstrachujemy z tego jakąś prostą naszą wewnętrzną bibliotekę. Prostą, którą po prostu dodajemy do aplikacji i ona ma domyślną konfigurację. Na samym starcie włączmy, niech dane lecą, a potem możemy to tweekować za pomocą konfiguracji, za pomocą centralnej naszej biblioteki, która zawiera jakąś konfigurację domyślną, zawiera możliwości, definiuje co domyślnie włączamy i jak włączamy i tak dalej. I to wystarczy. I tu mówimy to jest kilka godzin per system, więc czas jest bardzo, bardzo niewielki. Dodatkowo jeszcze możemy zrobić taką opcję, że włączymy albo wyłączymy za pomocą feature flagi, żeby mieć pewność, że wszystko jest w porządku. Co więcej, jest to bardzo scentralizowane, bo z reguły to robimy na samym starcie aplikacji w jednym konkretnym miejscu. Więc też ryzyko eksplozji po tej zmianie jest relatywnie niewielkie. Teraz drugi koszt. Koszt, który mówimy, jeżeli chodzi o samą infrastrukturę, cały ten stos chodzi sobie bardzo wesoło i przaśnie i dobrze na Kubernetes’ie. Więc jeżeli dana organizacja ma jakikolwiek klaster platformowy, monitoringowy, a pewnie ma, bo powinna takie rzeczy mieć, to w tym momencie postawienie tego jest relatywnie szybką akcją. Łączymy się ładnie, jeżeli chodzi o uprawnienia z prawdopodobnie Entrą, którą tam będziemy mieli, albo dowolnym providerem tożsamości. Kolejna rzecz to jest podłączenie się, jeżeli chodzi o storage, o którym mówiliśmy. W tym momencie, jeżeli znowu mamy Kubernetesa, mamy narzędzia, to jest pewnie kwestia tylko wygrzebania, która usługa daje nam S3. Natomiast jeżeli mamy chmurę, jest to jeszcze prostsze, jest to prosta konfiguracja i…

Łukasz Kałużny: Stwórz obiekt, tak.

Szymon Warda: To jest stwórz obiekt, dokładnie, stwórz obiekt i wygeneruj klucz dostępowy i działa. Kropka. Co się dalej dzieje? Dalej wchodzi trochę obszar taki bardziej skomplikowany, czyli wchodzi generalnie tweekowanie i symulowanie jak ten ruch bedzie realnie wyglądał. Bo musimy się dostosować pod to właśnie jak, ile logów, co, gdzie się dzieje. Bo w tym momencie włączyliśmy. Będziemy musieli zerknąć na to, co się dzieje na przykład w collectorze, chociażby ile wysyłamy logów info, ile wysyłamy, jakie mamy stany do logowania i tak dalej. Ta robota, która jest organizacyjna, ona będzie musiała się odbyć. Znowu, robimy to raz, z zasady i tak powinniśmy mieć, ustalamy… Bo zauważmy jedno, te rzeczy były słabe też w APM albo w innych systemach wcześniej, więc teraz tylko przy okazji je porządkujemy. I tu jest też bardzo duża wartość. Znowu, jak damy własną bibliotekę do Open Telemetry, budujemy Open Telemetry, własną bibliotekę, to zmiana formatu logowania we wszystkich systemach staje się relatywnie prostą bajką. Więc tu ponownie dobre praktyki. I znowu, jak chcemy iść dalej, prosta biblioteczka. Obudowujemy naszego klienta do wysyłania, odbierania wiadomości, żeby mieć tracing asynchroniczny, przydałoby się. Włączamy na naszym Ingress’ie czy gdziekolwiek, przez co przechodzi nasz ruch, włączamy tracing, żeby były trace’y generowane. To są z reguły włączenie konfiguracji pakietów w istniejące rozwiązania. Bo pamiętajmy, nie jesteśmy pierwszymi, którzy mają te problemy i którzy te rzeczy robią, relatywnie proste rzeczy. Więc wiele rzeczy robimy, w 3 miesiące góra się wyrobimy z całością rozwiązania.

Łukasz Kałużny: W zależności.

Szymon Warda: (…) szkolenia oczywiście, w tym czasie są szkolenia.

Łukasz Kałużny: Tak, dobra. To teraz popatrzymy sobie, to dla kogo jest to Open Telemetry z tym stosem open sourceowym? Jakbyś teraz tak podsumował całość. Okej, bo powiedzmy, że to jest rabialne w tym momencie, ale dla kogo to jest? Kto jest odbiorcą? Kto z tego zyskuje wartość?

Szymon Warda: Wartość największa jest duże organizacje, bo one mogą powiedzieć wszystkim dostawcom swojego software’u… Inaczej, jeżeli same produkują soft to jest to no brainer, po prostu lećmy w tym kierunku, bo po prostu to jest przyszłościowe. Jeżeli organizacje zamawiają soft, to danie specyfikacji, powiedzenie macie być zgodni jeżeli chodzi o observability, zasady Open Telemetry, jest fenomenalne, bo w tym momencie mamy jedną konfigurację na wszystko i nie bawimy się w wiele APM-ów w wielu organizacjach. Dla super małych, dla małych firm, które mają kilkadziesiąt osób i jest to powiedzmy sobie jakiś startup, nie do końca, bo tam czasowo łatwiej jest po prostu włączyć sobie Application Insights, włączyć sobie jakiegokolwiek providera chmurowego, mówię chmurowego, bo pewnie organizacje będą w ogóle siedziały sobie na chmurze i po prostu tam to działa. Natomiast organizacje, które mają zespoły do monitorowania, gdzie nie tylko developerzy na żywca debugują produkcje i patrzą, co się dzieje, bo jeżeli aplikacje utrzymują 3 osoby, 5, 10 osób, które doskonale wiedzą i to one reagują, zysk tam będzie niewielki, bo nie ujednolicamy tego całego stosu. Jeżeli, to co powiedziałeś też Ty, jeżeli mamy soft, który utrzymujemy od bardzo wielu lat, rozwijamy go, nie mamy w planach inwestycji jakichkolwiek w niego, jest jakiś wielki monolit - średnia wartość. Ponownie, pytanie czy tam nam dużo pomoże jakikolwiek inny APM? Też wątpliwa opcja. No ale coś pewnie zrobi. W sensie inwestycja czasowa w Open Telemetry może nie mieć tak dużego zwrotu. Stare technologie, jest wsparcie, ono nie jest tak dobre mimo wszystko, jeżeli na przykład śmigamy sobie po prostu na VM-kach albo na jakichś dziwnych hostach.

Łukasz Kałużny: Czyli tak trochę podsumowując, pierwszą taką rzeczą jest aktywny development, jest wyznacznikiem, że można się zainteresować Open Telemetry.

Szymon Warda: Tak.

Łukasz Kałużny: I to od tego można podejmować resztę decyzji, czy to sprawdzać czy nie.

Szymon Warda: Druga opcja to jest to, jeżeli chcemy faktycznie budować zespoły SRA, czyli taki zamordyzm, żeby ujednolicić bałagan, który z reguły providerzy softu dla naszej organizacji wprowadzili, bo to też jest bardzo, bardzo ważny przypadek.

Łukasz Kałużny: Albo sama organizacja swoją bezwładnością i silosowością to wprowadziła.

Szymon Warda: Nie chciałem tego mówić, chciałem to zwalić na innych.

Łukasz Kałużny: Dobra i chyba tym można to podsumować. Chyba, że chciałbyś coś dodać.

Szymon Warda: Wiesz co, to co mnie zaskakuje z Open Telemetry to jest to, że stale się rozwija i adopcja jego jest naprawdę, naprawdę szeroka. Dla developera to jest totalny no brainer, to po prostu trzeba z tego korzystać. Dla organizacji to jest coś, czemu idziemy tą krzywą, jeżeli załóżmy chodzi o Tech Radar, to jest coś, czemu trzeba już robić PoC-i, bo za chwilę stanie się to standardem ogólnym można powiedzieć.

Łukasz Kałużny: Chyba jedną rzecz warto sobie powiedzieć, że to bardziej żyło w Open Telemetry, żyje bardziej na skraju tej części dostawcy bibliotek, inne rzeczy i duzi Big Tech’owi vendorzy niż końcowi użytkownicy, że tam teraz było bardzo dużo inwestycji, pracy ze strony właśnie dużych dostawców, żeby to działało spójnie.

Szymon Warda: Tak i działa spójnie. To jest to, że praktycznie też nie ma się co martwić, jeżeli chodzi o przepięcie, bo praktycznie każdy duży vendor Open Telemetry przyjmie z wielką chęcią. Więc dla mnie wchodźcie, po prostu patrzcie, nie lokujcie się z jakimś konkretnym vendorem. Open Telemetry też jest tą warstwą uniwersalną. To jest taki, nie lubimy tego, taki future proofing aplikacji na najbliższe powiedzmy 2, 3, 4, 5 lat.

Łukasz Kałużny: Dobra, a jeżeli potrzebujecie z tym pomocy, to Szymon Wam bardzo chętnie pomoże. Trzymajcie się.

Szymon Warda: Na razie. Hej!

Łukasz Kałużny: Hej!