“Praktycznie każdy vendor umie konsumować Open Telemetry” - nawet DataDog i New Relic przyznają, że przegrały tę wojnę. Ale czy to znaczy, że powinieneś rezygnować z ich “jednej linijki kodu” na rzecz konfigurowania Prometheus + Loki + Tempo + Grafana?
Szymon twierdzi, że to “przyszłość bez dwóch zdań”, podczas gdy Łukasz pyta “po co zmieniać coś, co działa?”. Prawda jest brutalna: kontrola nad kosztami vs wygoda płacenia, przenośność vs vendor lock-in, elastyczność vs “włącz i zapomnij”. 🎯
Problem w tym, że open source observability to nie jest “dla każdego”. Jeśli twój system to “20-letni monolit w maintenance mode”, to możesz przestać czytać. Ale jeśli masz aktywny development i zespoły DevOps, to może czas przestać dokładać się do pensji programistów w Dolinie Krzemowej przez licencje APM.
Czy “future proofing” to wystarczający argument do migracji? Sprawdź, jak Szymon próbuje przekonać Łukasza - i czy argumenty o “standardach na następne 5 lat” brzmią przekonująco. ⚠️
Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: protopia.tech
Discord 👉 https://discord.gg/78zPcEaP22
Linki i ciekawe znaleziska:
| [Grafana Tempo OSS | Distributed tracing backend](https://grafana.com/oss/tempo) |
| [Application Performance Monitoring (APM) | Datadog](https://www.datadoghq.com/product/apm) |
Enable OpenTelemetry in Application Insights - Azure Monitor
| [Grafana Loki OSS | Log aggregation system](https://grafana.com/oss/loki) |
Szymon Warda: Wczoraj działało, dzisiaj nie działa. No to w tym momencie coś się musiało zmienić. Open telemetry jest standardem. Tak to trzeba już nazwać. Tak naprawdę to dojrzałem, bo już wersja 1.0 wyszła. Logi nie działają, logi nie działają. Kulawo. Trochę działają, ale są. Składnia Elastika 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 teologii jawnie przez Open Telemetria Protocol. Cześć, czołem! Kluski z rosołem. Słuchajcie patriotów prowadzą Szymon Warda i Łukasz Kałużny.
Łukasz Kałużny: Wszystkie linki do tego odcinka znajdziecie na pato architekcie ją gdzieś tu na dole. Wierzymy w Was, dacie rade. Dobra i dzisiaj odcinek w trochę w 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 telemetrii. Jeżeli mówimy o observability i słuchaj Szymon, to skąd ta rozmowa?
Szymon Warda: Ta rozmowa stąd właściwie, bo jak popatrzymy sobie na rynek, co się dzieje, no to mamy open telemetria, który się dzieje dość dużo, A ile razy wejdziemy do dowolnego większego klienta WordPressowego, to widzimy duży gracze, widzimy jaka dana trasa Elastika i Datadoga tego typu narzędzia, No nie? Więc w takim razie, skoro tak pijemy od dłuższego czasu, bo zgodzisz się, że chwalimy open telemetrię jakiegoś czasu, to nie jest też super. Nic nowego na chwilę obecną, więc tu 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 telemetria, wchodzić w ten stos open sourceowy? W tym kontekście będziemy mówili głównie o stresie, 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 telemetrii. No to może zejdźmy pierwszą rzecz. Szymon Tak, wracając, znajdzie się do tego chyba 3 albo 4 odcinki. Podlinkujemy je stale 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 co zrobili to rezerwat i jest takim 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 były jakieś sytuacje, że przychodzi załóżmy szef do szefa 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, No nie no tak, trochę tego nie wystarcza. Observability jest takim chęciom 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 my 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ę co się dzieje. Dobra Szymon, a z czego, Bo tam są trzy takie kluczowe składniki, z czego ty observability się składa.
Szymon Warda: I to idziemy od najstarszych, które znamy, 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 one się korelacji i tak dalej. Też często ten tekst, te logi już nie są prostą linią, ale są też często formą ustrukturyzowaną. Strukturę 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 value. Można powiedzieć gdzie kluczem jest nazwa metryki. Tam oczywiście ona jest olabelowana, atakowana, jakkolwiek ją nazwiemy tak naprawdę i mamy też wartość. Jest to z reguły liczba, tudzież tudzież jakiś flow 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 one są super krytyczne tak naprawdę, Bo jeżeli patrzymy właśnie odnośnie monitoringu observability tak naprawdę, to widzimy, że system nie działa, to znaczy, że coś się zmieniło.
Szymon Warda: Z reguły był deployment okay, to zmienił się kod, no to winny jest jasne. Ale jeżeli nie było diplomentu, jeżeli wczoraj działało, dzisiaj nie działa, no to w tym momencie coś się musiało zmienić. I właśnie o to chodzi, żeby. Wracam, 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 takie szybkie możliwość przeczesania i porównania co jest dzisiaj, co było wczoraj, co było tydzień temu, żeby znaleźć te właśnie anomalie, odstępstwo od tego, co dzisiaj raportowane jest inaczej. Tego w logach nie znajdziemy za bardzo. No nie takie długie.
Łukasz Kałużny: Jeżeli teraz tak pójdziemy. Dobra, a czym jest sama Open? Mamy observability. Czym jest open telemetrii?
Szymon Warda: Łukasz Ależ o treściach 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. Często rozróżniam, ale też tam fajne rzeczy można wyciągnąć. Mianowicie widzimy, jak się zachowuje cały flow, jakie systemy ze sobą komunikują? Super ważne. Dobra, teraz czym jest open telemetry? Open telemetry jest standardem. Tak to trzeba już nazwać. Tak naprawdę 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, jakie labellujemy konwencje nazewnicze, to jak są zbierane, jakimi protokołami się komunikują, gdzie właściwie wprowadzamy wzbogacanie tych danych o labele, dodatkowe rzeczy i informacje, gdzie pracujemy, 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ż są.
Szymon Warda: Też mamy pojęcie eksporterów, które ładnie wysyłają nasze dane, logi, telemetria czy metryki do grafany, do Elastika 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. Najtańsze, najtańsze i najmniej zrozumiane i trasy, 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 to. Szymon to jest to co wypychamy z aplikacji. Jakbyś powiedział jak wygląda ta architektura open telemetrii, z czego ona się składa, bo tam też są jakieś pojęcia.
Szymon Warda: Jeżeli mówimy o samej telemetrii, 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 i tym sposobem preferowanym jest oczywiście korzystanie z open telemetrii Protocol, który może iść po PC. może sobie może sobie śmigać po jeszcze po http. Wiadomo, gier PC może się przydać dużo bardziej. I teraz wypychanie może następować do konkretnego, konkretnego, konkretnego konsumenta. Nazwijmy go tak czy jakiegoś elasticka, czy 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ć, wysyłać jakieś labele, przetransportować z buforować, zrobić takie czy słuszne? Jak najbardziej. Przy dowolnym średnim i większym systemie to po drodze wystawiamy sobie kolektora. I co umie robić taki kolektor? On umie robić dość sporawa, bo po pierwsze w tym momencie wszystkie dane wysyłamy do kolektora i on tam sobie umie to buforować, umie sobie wzbogacić, umie zamienić na przykład straców metryki, umie zrobić całe procesowanie, czyli aplikacje się nie martwią, a on w jednym miejscu umie też skrępować niektóre rzeczy.
Szymon Warda: No i on te rzeczy zbiera. Mamy w jednym miejscu całą konfigurację. Co więcej, ta konfiguracja od niedawna może też być dynamicznie podmieniona, co też bardzo fajne. I potem on może odpowiednie dane wysyłać do konkretnych konsumentów. Czyli możemy sobie wstawić takiego open telemetrii, kolektora bądź aplikacji nowego, a dalej przez jakiś czas raportować dane do naszego starego systemu. Jakaś część logów wysyłać na przykład do danych archiwizacyjnych, a część wysyłamy sobie do Elasticka, część wysyłamy sobie na przykład do Datadoga, część wysyłamy sobie na przykład do Any, bo chcemy zrobić poka m.in. case, który obecnie mamy na talerzu właśnie. No 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: Ł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 telemetria jako taki ma też możliwości totalnej 0. Code-Instrumentation nie da wszystkich języków. Co prawda mówimy tutaj dwa główne, gdzie to się rozwija najlepiej. Java stoi w sumie chyba najlepiej jeśli chodzi o dojrzałość, chociaż nie w każdym obszarze, że możemy sobie odpalić naszą aplikację w formie w agencji, który będzie przy zerowej zmianie kodu w naszej aplikacji zbierał te telemetria, zbierał dane i wysyłał właśnie do open telemetrii kolektora. 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 VPN telemetrii, czyli mam, nie wiem, wdrożonego, dajmy na to na trace Datadoga, może Neuralink jak wspomniałeś i jaka jest tak naprawdę wartość schodzenia z takiego sasowego APM a czy promowego? Daj na trasę jak mamy na rzecz tego stosu open source? Bo ja teraz próbuję to zrozumieć. Kiedy? Czy to w ogóle ma sens inwestowanie w dotykanie, w to?
Szymon Warda: Wiesz co, powiem Ci tak rok temu bym powiedział, że tak. A znów my się jeszcze może niekoniecznie teraz. Co się dzieje? Po pierwsze ci duzi gracze, bo cały sprzęt oppendrometry 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 integruje się z jakimś appem, daje to klientowi, a klient z innego ApMA i nagle jest słabo. No więc zacznijmy od tego, że praktycznie dowolny czy to będzie data dog, czy to będzie, czy to będzie neuralink, 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 telemetrii. Czy jestem przenośny? I tu się zgodzimy, że to ma sens. Wpinanie i łączenie się konkretnym SDK np. Elastic czy cokolwiek innego. Średnio ma to na chwilę obecnie wartość. Niewiele tam zyskujemy, no nie? To jest jedna rzecz, więc tu rozwój aplikacji spoko. Problem jest. Drugi problem jest faktycznie auto instrumentacji, bo o ile mówimy, że tak open telemetria ma autoinstrumentacje, to czy ona jest tak samo dojrzała?
Szymon Warda: Nie, nie będziemy tu katowali, że jest super rzecz, której nie ma za bardzo tak naprawdę i nie jest tak bardzo rozwinięta. To jest między innymi Profilink, taki typowy. To co widzimy w Application Insights i tak dalej. No w każdym praktycznie 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 na produkcję albo nie wiemy, co się dzieje. Tak, przydaje się bez dwóch zdań. No 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 dyskusyjna. Jak do tego podejść, 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 APM ów, czyli application performance monitorów. To nie są małe koszty. One są albo liczone od kilku rzeczy, albo od danych wchodzących do nich, albo od CPU, od RAMu, 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, tylko APM, no bo jednak oszczędzamy koszty, a te koszty z reguły są duże. Korzystając z tego, że 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.
Szymon Warda: Inna bajka narzędzia mojej strony. Jest takie narzędzia typu na trasę Neuralink. 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ło jest. Znajomość rynkowa to jednak jak ktoś zna jedno, to potem przychodzi, no to musi się od nowa uczyć. A daj mi dowolnego, a gwarantuję Ci, że znam, ale gwarantuję Ci, że zna te high level, owe narzędzia. Będzie przynajmniej miał znajomość. Kiedyś używał alert menadżera od Prometeusza. To są po prostu standardy rynkowe. To też widzimy. Dostawców chmurowych przechodzą na przykład na Prometeusza.
Łukasz Kałużny: Tak, Prometeusz Grafana się pojawia coraz częściej jako Manage.
Szymon Warda: Dokładnie tak. No po prostu wygrało to, wygrało tą walkę.
Łukasz Kałużny: Słuchaj, popatrzymy. Dobra, bo jedna rzecz, która mnie nadal. Popatrzymy. Wezmę sobie takiego. Daj na fejsa 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 telemetrii? 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 telemetrii to interpretacja jest coraz bliżej, żeby wykluczyć różni providerzy typu dana trace itd. Oni mają już dodatkowe wartości typu security. trochę jeszcze inne rzeczy tak bardziej tego podchodzą holistycznie. Czyli mamy jedno narzędzie, które możemy dać zespołowi, który niewiele czasami wie i będą mieli alerty trochę mądrzejsze, trochę lepszą komunikację, trochę mądrzejsze wykrywanie, co tam się popsuło i tak dalej. No to tutaj w ogóle nie wchodzimy. Open telemetrię do do aplikacji naszego systemu, takie gołe, czyli logi, metryki, trasy. Dobra, pytasz się w takim razie 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 nas kontrolerów, na bazie tego co tam ten nasz agent, który się podłączył próbuje wykoncypować, no nie? 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ą.
Szymon Warda: Będziesz to musiał zrobić teraz, skoro i tak musisz to zrobić. Skoro koszt integracji jest koszt na przykład śledzenia, przekazywania traceów, śledzenia, wywołania http wywołań do baz danych Dla większości języków to jest albo jest wspierane. W bibliotekach natywnych do komunikacji to mamy przy Javie, mamy przy necie, przy nodzie. Tam trochę się 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 query, które są na bazie danych puszczane w danej transakcji.
Szymon Warda: No dobra, no to przejdźmy jak to wygląda, bo to jest bardzo ważne. Po pierwsze tak, jeżeli wykorzystasz auto-instrumentacje Instrumentacje Open telemetry tą która jest zbudowana w Jave i do 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 test aplikacji, mieć jak to wygląda realnie Jest to konfiguracja, dodanie kilku bibliotek i skonfigurowanie, że tak chce SQL. Tak, korzystam z NH Bernata czy Hibernate czy Worka i wpięcie się w ORM y. Wpinasz się i działa z pudełka masz SQL. To jest koniec Twojej roboty. Po prostu jest. Idziemy dalej. Wsparcie wygląda dla http klientów Java Dot. Net działa dla wszystkich gier PC. Działa? Nie ma problemu. Wsparcie przez Springa. Czyli nie oszukujmy się większość Większość aplikacji webowych. Wsparcie dla klientów do kawki. Wsparcie dla kredytów do Rabbita. Wsparcie dla. Załóżmy cały Azure SDK też jest obłożony telemetrią. Ją ma 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, no nie?
Szymon Warda: 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 krzaki na wywołania. No bo node jest bardziej dynamiczny, ale też mamy formę auto instrumentacji. Teraz dalej jeżeli chodzi o dojrzałość wywołań masz do expressa, masz do GraphQL, grpce, maja, SQL Mongo, Redisa, Kafki, masz biblioteki, które wspierają całą telemetrię. Python podobnie też ma podobną autoinstrumentacje. 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, GRPce, SQL, alchemię i tak dalej. Śmiga. I teraz wchodzimy z dojrzałością gorzej Rust go średnio tam nie mamy.
Łukasz Kałużny: Ale ja go zostawię tutaj w tym, bo było gdzieś wylewanie wiadra pomyj na temat implementacji open telemetrii w Go, więc to zostawię.
Szymon Warda: Dlatego mówię to jest tutaj. Tu jest średnio wyraźnie też jest średnio.
Łukasz Kałużny: Gdzie wydawało się powinno być o rock solid.
Szymon Warda: Dobra, może do sterowników nie potrzebujesz mieć open telemetrii, No nie?
Łukasz Kałużny: No to.
Szymon Warda: Jest 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 sytuację, że klient zainstalował agenta tenisowego w klastrze. I nagle aplikacja przestała działać. Czemu? No, okazało się, że klient. Dane adresowe. Żeby robić tracing dla wiadomości, Bo to jest takie trochę trudniejsze po kawce wstrzykiwał w hedery swoje swoje traceid. No i okazało się, że aplikacja wykorzystuje hedery i się zaczęła 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ć czy wpiąć się mimo wszystko jednak ręcznie, a ułatwia to, że większość większość narzędzi umie to zrobić bez większego problemu już 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 telemetria 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 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 o strony 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 bagach od frontendu, zazwyczaj którego teraz mamy do końca. Tak, to ma swoją ma swoją wartość. A 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 nie działają kulawo, trochę działają, ale są, więc tracing mamy. Dobrze mówiłeś, teraz mówiłeś. Teraz odnośnie pytanie było gdzie te logi są wysyłane?
Łukasz Kałużny: No i jak to działa dalej?
Szymon Warda: Tu idziemy po kolei od najprostszych rzeczy. Metryki idą do Prometeusza. Chyba nie musimy narzekać. Albo Prometeusz, albo czegoś Prometeusza podobnego, bo tego trochę jest. Jest to standard rynkowy. Wygrało, wszyscy korzystają, wiem jak korzystać, ma fajny język dokowania, ma całkiem okej system. Do alertów nie możemy mieć większych większość zarzutów. Powiem nawet więcej jeżeli chodzi o metryki, to Prometeusz jest dużo przyjemniejszy niż dostawcy dużych, 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, no to oddajemy UX za to, że to jest tańsze po prostu. Mówiąc bardzo prosto wykorzystanie i składnia elastika. 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 ubijaniu tego serwera.
Łukasz Kałużny: Raczej nie raz. Ok, bo trzeba powiedzieć teraz mówisz konkretnie, bo de facto log kolektorem dla open telemetrii 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 tak z serca.
Szymon Warda: Dokładnie tak. Ma strumienie, jest dużo tańszy, szybszy, szybsze, 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 wydajny. 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 Prometeusza, a tu mamy co innego, bo doskonale wiemy.
Ł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ś rapera, czy w jaki sposób wrzucamy te nogi?
Szymon Warda: No bo jeżeli. Jeżeli mówimy o tym, żeby pchali z autu, no to w tym momencie aplikacja będzie robiła trochę więcej, to te logi mogą się pogubić. Nasza koncepcja jest inna. Skoro już robimy, integrujemy się z aplikacją, to pchajmy teologii jawnie przez open telemetry protocol do naszego kolektora czy 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ą OpenTelem 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 sytuacja pewnie będzie, że jakieś logi się przez OpenMeter Protocol nie wyślą. Także set out dalej trzeba obserwować, bo błędy krytyczne będą się pojawiały w aucie.
Łukasz Kałużny: Rozróżniamy logi aplikacyjne, czysto aplikacyjne od takich logów technicznych, które powinny tam zostać, typu poleciał jakiś stack trace.
Szymon Warda: Dokładnie tak. Może polecieć jakieś auto memory exception, jakiś krytyczny błąd? Framework nam się wywalił błąd w konfiguracji tego typu rzeczy. Spodziewamy się, że będzie w aplikacji, ale nie zawsze tak się dzieje. Trzeba jednak być realistą.
Łukasz Kałużny: Teraz temat w ogóle, bo ciągle się pojawia Prometeusz na 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, Graphana jest frontendem plus cały ich zestaw zabawek do składowania tych danych.
Szymon Warda: Dobrze, tam jest kilka zabawek. Faktycznie dobrze. Dobrze, że o tym powiedziałeś. Idziemy najprostszych. Mamy Graphane, czyli coś, co służy do wyświetlania, łączenia i alertowania. Tyle. Ładne, ładne wykresiki z tego głównie znamy i też jest takim single point of entry głównym punktem wyjścia dla wszystkiego. Teraz idziemy dalej. Prometeusz, który nie jest grafenowy, ale gra fana też ma swój odpowiednik. Czyli tam strzelamy wszystkie metryki. Fajny język, prosty, ładnie się skaluje, możemy fajne rzeczy robić. Dobra, idziemy dalej. Loki. Trzymamy loki, 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 trasy. 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 Tracey jako takie tempo obsługuje trasy w trybie.
Szymon Warda: Nie ma raportowania, nie ma agregacji, czyli wszystkie wyszukiwania robimy w kontekście jednego traca i możemy znaleźć jeden, znaleźć treść, która nas interesuje, ale nigdy nie możemy powiedzieć znajdź mi średnią po wszystkich trasach, którą.
Łukasz Kałużny: 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 transakcje, albo robimy raportowo. Sorry, ale nie jest tak źle, bo tempo zapisuje dane w parkiecie, więc w tym momencie te dane, które przypisujemy parkiecie możemy przerzucić przez jakikolwiek stos do machine learningu, który będzie to rozumiał i raportowania robić na 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 APM dają nam te 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 traca, 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żny.
Łukasz Kałużny: Był ten pech, był ten pech, a nie albo była.
Szymon Warda: 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 w aktualnie.
Szymon Warda: Tak, można to zasypać własnymi rozwiązaniami i nawet jest tam jest parę podejść, ale no 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 to wygląda z przechowywaniem?
Szymon Warda: I to jest ten element, który 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 log i tempo, to w czym to błyszczy, to jest to, że faktycznie jest to system pomyślany na to, żeby przychodzić duże ilości danych. Jak to się dzieje? Dzieje się przez to, że dane są ładnie dzielone, dane są zimowane, dane są przechowywane na głównie storage ublobowym. 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, no to oczywiście są rozwiązania, które będą symulowały. Może nam to trochę wyjść, wyjść trochę trochę drożej.
Łukasz Kałużny: Aktualnie to, co podpowiadamy klientom. Jak się okazuje, czasami okazuje się, że mają licencje 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, 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 jest trójkowe, 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 telemetrii. Ważne, to chyba to trzeba powiedzieć, tak jak ja to rozumiem. Najlepszym odbiorcą telemetrii 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 telemetrii. Jak wygląda proces adopcji tego?
Szymon Warda: Jasne. Znaczy on jest. On jest dwojaki. Bo pytanie jest proste czy klient jest w Kubernetes ie? Bo jeżeli klient Kubernetes, no to nasze życie się znacząco ułatwia. I nie tylko dlatego, że jest Kubernetes, bo wtedy jeszcze możemy ustawić scraping podów, możemy ładnie sobie wdrożyć kolektora, ładnie wdrożyć wszystkie pozostałe rzeczy, czyli mamy do tego niemalże gotowe yamle. No nie jest łatwiej. Drugi jest element, bo jeżeli klient jest Kubernetes, to znaczy, że stos, na którym pracuje jest relatywnie nowy. Słowo kluczowe relatywnie nowe. Czyli nie mówimy na przykład o antycznych aplikacjach, które są rozwijane od lat 20. Zapewne produkują dużo wartości biznesowej. Technicznie mogą być wyzwaniem, no nie? Więc jeżeli. Skup się. Prosta sprawa. Jeżeli na przykład pracuję na VMkach, czyli mówimy już trochę będzie trudniej, no to w tym momencie ok, możemy dalej open telemetrii, kolektor może dalej skrępować logi, może dalej zbierać dane dane. Nie wiem, to też nam się przyda w kontekście samego Kubernetesa, żeby wiedzieć co tam jest hostowane i to wszystko dalej możemy wysyłać.
Szymon Warda: 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. Podstawowe 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 to wyglądają i te dane, które mamy wyglądają po prostu jak coś nieładnego, że tak powiem. Powiem ładnie, więc stawiamy po kolei kolektory, żeby dane dany 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 telemetr kolektor, będziemy go mieli. To jest to, że wdrażamy, zaczynamy wysyłać do nowego celu. Można powiedzieć pewnie do pewnie do tempo. I w tym momencie, jak napełnimy, powiedzmy, danymi z dwóch, trzech miesięcy, w tym momencie możemy robić ładne przeskoczenie. Czemu?
Szymon Warda: Żeby nie było takiej rzeczy, którą widujemy czasami, że ok. Wiesz co, dane odnośnie tego, to które mają tam powiedzmy może tygodnia to są w tym systemie, a te są w tym systemie i w tym 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 u 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 operacyjnych, które są trochę trudniejsze i trochę szorstkie w interakcji, żeby odpowiednio skonfigurować. Dalej pokazujemy, jakie są możliwości, jakie są ficzery, bo czasami do niektórych grzebanie się jest trochę problematyczne. Potem dalej co robimy? To jest konfigurowanie wszystkich ciekawych rzeczy typu generowanie metryk z metryk z traców. Przydaje się szczególnie na starcie. Generowanie serwis, generowanie poszczególnych rzeczy, żeby ten feature set był jak najbardziej bogaty i pełny.
Szymon Warda: I potem pokazanie de facto to jest też bardzo ważne jakie persony, z czego będą 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ć. No nie? Dzielenie które środowiska jak trzymamy Konfiguracja multiagencji, 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? 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 deweloperski, czyli po prostu jest relatywnie niewiele. To jest 5 6 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 telemetria? Nie, to tak nie działa. No nie? 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 tę trasę metryki dorzucić procesy biznesowe. To tak jak z logami, że trzeba te linijki tam wpisać, jak rozumiem.
Szymon Warda: Tak. Trzeba je pisać. Od tego nie uciekniemy. Mówimy godziny per system. Jak zrobimy za jednym razem, to potem realnie wyekstrasujemy 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 dane lecą, a potem możemy to twerkować za pomocą konfiguracji, za pomocą centralnej naszej biblioteki, gdzie 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 na per system, więc czas jest bardzo, bardzo niewielki. Dodatkowo jeszcze możemy zrobić taką opcję, że włączymy albo włączymy za pomocą feature flagi, żeby żeby mieć pewność, że wszystko 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.
Szymon Warda: Więc jeżeli dana organizacja ma jakikolwiek klaster platformowy, monitoringowy a pewnie ma, bo powinna takie rzeczy mieć, no to w tym momencie postawienie tego jest relatywnie szybką akcją. Łączymy się ładnie, jeżeli chodzi o uprawnienia z prawdopodobnie endrą, którą tam będziemy mieli. Będziemy mieli albo dowolny 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 mamy Kubernetesa. Mamy narzędzia, to jest kwestia tylko grzebania de facto, która usługa daje nam S3. Natomiast jeżeli mamy chmurę, jest to jeszcze prostsze. Jest to prosta konfiguracja i stwórz obiekt. Stwórz obiekt dokładnie stwórz obiekt i wygeneruj klucz dostępowy i działa. Kropka. Co się dalej dzieje? Dalej wchodzi ten obszar taki bardziej skomplikowany, czyli wchodzi generalnie gratyfikowanie 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 tu będzie. Włączyliśmy. Będziemy musieli zerknąć na to co się dzieje na przykład w kolektorze czy ile wysyłamy logów, info, ile wysyłamy, jakie dane do logowania i tak dalej.
Szymon Warda: Ta robota, która jest organizacyjna, ona będzie musiała się odbyć znowu. Robimy to raz 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 telemetrii. Budujemy open telemetria, 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ć tracking asynchroniczny przydałoby się. włączamy na naszym Ingress czy gdziekolwiek, przez co przechodzi nasz ruch, włączamy tracing, żeby były treści 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, że te rzeczy robią relatywnie proste, 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: Od szkolenia. Oczywiście w tym czasie są szkolenia.
Łukasz Kałużny: Tak? Dobra, to teraz popatrzymy sobie to dla kogo jest to open telemetrii z tym stosem open sourceowym? Jakbyś teraz tak podsumował całość? Okej, bo powiedzmy, że to jest robione w tym momencie, ale dla kogo to jest? To jest odbiorcą, Kto jest odbiorcą? Kto z tego zyskuje wartość?
Szymon Warda: Wartość największa jest duże organizacje, bo one mogą powiedzieć wszystkim dostawcom swojego softu, software’u, które. Same produkują soft to to jest to. No brainer po prostu lecimy 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 zasadę open telemetry jest fenomenalne, bo mamy jedną konfigurację na wszystko i nie bawimy się w wiele APM. 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 jakikolwiek providera chmurowego, bo mówię o chmurowego, bo pewnie organizacje będą w ogóle siedziały sobie na chmurze i po prostu tam to działa. To 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.
Szymon Warda: 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 jakiejkolwiek W niego jest jakiś wielki monolit. Średnia wartość. Ponownie pytanie czy tam nam dużo pomoże jakikolwiek inny aspekt? Też wątpliwa opcja. No ale coś pewnie zrobi. W sensie inwestycja czasowa w open telemetry może być nie mieć tak dużego zwrotu. Stare technologie jest wsparcie, ono nie jest tak dobre. Mimo wszystko, jeżeli śmigamy sobie po prostu 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 telemetrii.
Szymon Warda: Tak.
Łukasz Kałużny: I to od tego. 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, 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 telemetrii to jest to, że ten stale się rozwija i adopcja jego jest naprawdę, naprawdę szeroka. Dla developera to jest totalny brainer, to po prostu trzeba z tego korzystać. Dla organizacji to jest coś, czemu idziemy tą krzywą. Jeżeli chodzi o techradar to jest coś, czemu trzeba już robić boki, bo za chwilę stanie się to standardem ogólnym.
Łukasz Kałużny: Można powiedzieć chyba jedną rzecz. Warto sobie powiedzieć, że to bardziej żyło w open telemetrii. Żyje bardziej na skraju tej części dostawcy bibliotek, inne rzeczy I duzi Bigthowi 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 nie mam 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 telemetria 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 pomocy, to Szymon Wam bardzo chętnie pomoże. Trzymajcie się.
Szymon Warda: Na razie.
Łukasz Kałużny: Hej, hej!