Observability w działaniu: plan wdrożenia stosu Grafana i demo

Stos jest otwarty i nie jest małym produktem jednej firmy.

Jeśli wyślesz dane różnej jakości prosto do centralnego systemu, dostaniesz wynik słabej jakości.

Nie wystarczy postawić Prometheusa i przekazać go ludziom. Muszą też umieć prawidłowo z niego korzystać.

Szymon Warda: Ogólnie nazywam to lekkim bałaganem. I to nie jest nic negatywnego. To po prostu sytuacja, w której Twój system do monitorowania rósł razem z czasem i nie był porządkowany. Kubernetes wydaje się tu najłatwiejszy do monitorowania, ale absolutnie nie jest jedyną możliwością.

Dość często widzimy, że organizacja zaczyna limitować, kto ma dostęp. A chyba nie o to chodzi, prawda? Stoi jakaś wydmuszka, która zbiera dane z 10–20% tego, co może być zbierane, i nie zapewnia widoku całościowego. Przychodzi awaria i nie wiemy, co właściwie było główną przyczyną. Łatwiej zrobić szkolenie, które potrwa jeden dzień, 4 godziny, i pokaże, co można z tego wycisnąć i jaka będzie wartość.

Mikołaj Szczerbicki: Cześć! Witajcie w Powered by Protopia. Nazywam się Mikołaj Szczerbicki i dzisiaj jest ze mną w studio Szymon Warda.

Szymon Warda: Witam ponownie.

Mikołaj Szczerbicki: Szymon, muszę Ci powiedzieć, że jestem entuzjastycznie nastawiony do dzisiejszego spotkania. Po naszym ostatnim odcinku o observability, o którym dziś będziemy mówić dalej, rozpaliłeś wiele emocji i nadziei. Wytłumaczyłeś mi i nam wszystkim, czym jest observability i czym jest nowy standard OpenTelemetry. Przede wszystkim zainteresowały mnie jednak zmiany organizacyjne, które to za sobą pociąga: organizacja staje się proaktywna, a nie reaktywna.

Bardzo fajnie, że mamy observability i że tak szumnie się o tym mówi. Chciałbym jednak, żebyśmy dziś przeszli od ogółu do szczegółu. Interesuje mnie, jak to mogłoby działać w mojej organizacji i czy to w ogóle jest dla mnie.

Szymon Warda: Pytanie, w jakim zakresie. Jeżeli mówimy o całym observability i podejściu, to może Cię zaskoczę: część klocków tego systemu już masz w organizacji. Rzucisz kamieniem i znajdziesz je u siebie.

Mikołaj Szczerbicki: No dobrze, to powiedzmy, że mam Zabbixa, mam oczywiście ELK dla bezpieczeństwa. Środowisko jest hybrydowe, czyli trochę on-premises, trochę chmura. Dodajmy do tego jeszcze multicloud. Różne języki programowania też się u mnie znajdą.

Szymon Warda: Jakiś Kubernetes też się pewnie znajdzie.

Mikołaj Szczerbicki: Bardzo możliwe. Powiedz mi więc, czy to w ogóle ma sens?

Szymon Warda: Ma sens, ale jak zwykle zależy od wielkości Twojej organizacji. Podejście, które proponujemy, to stos oparty na Grafanie: hostowany samodzielnie, bez limitów licencyjnych i bez limitów, jeżeli chodzi o ilość wykorzystania. Zaczyna mieć duży sens, kiedy organizacja nie jest mikro, tylko mała plus albo średniego rozmiaru. Wtedy narzut na zbieranie i ilość informacji, które możesz zbierać, są na tyle znaczące, że warto się temu przyjrzeć. Będąc totalnie szczerym: jeżeli masz zespół 10–20 programistów i jeden monolityczny system, to weź coś z pudełka. Po prostu będzie tańsze w utrzymaniu. Dobry start, szybkie wdrożenie, szybki zwrot z inwestycji. Totalnie się nada.

Mikołaj Szczerbicki: No właśnie. Z biznesowego punktu widzenia bardzo istotne jest dla mnie, żeby na początku określić, czy w ogóle poświęcać temu czas i rozpatrywać taką platformę w swojej organizacji. Teraz już wiem, że tak.

Szymon Warda: Powiedziałeś, że masz kilka środowisk i że tego trochę jest. Mogę więc spokojnie założyć, że masz zjawisko, które ma praktycznie każdy: jeden system monitoruje to, inny kawałek kodu monitoruje coś innego. Masz ogólnie lekki bałagan, podejrzewam. I to nie jest nic negatywnego. To po prostu sytuacja, w której Twój system do monitorowania rósł razem z czasem i nie był porządkowany. Masz różne wysepki dla każdego systemu. Developer patrzy w system A, a admin w system B, czasem nawet dla tego samego systemu.

Naszą wartość w observability widzimy tak: w pierwszej fazie wracamy do monitoringu, ale porządkujemy wszystko i zbieramy informacje do jednej kupy, że tak to nazwę. Widzimy wtedy wszystkie systemy w jednym miejscu. To pierwszy element. Drugi, który często słyszymy u klientów, brzmi: „ale ja mam stare systemy, nie mam wszystkiego w Kubernetesie”.

Szymon Warda: Często jesteśmy w chmurze. Super, nawet lepiej, jeżeli chodzi o podejście, które rekomendujemy z racji naszego doświadczenia. Kubernetes jest tu najłatwiejszy do monitorowania, ale absolutnie nie jest jedyną możliwością. Bez problemu można monitorować maszyny wirtualne, a nawet aplikacje na serwerach fizycznych. Możemy agregować w jednym miejscu monitoring chmury, on-premises i wszelkich hybryd z więcej niż jedną chmurą, i widzieć wszystkie dane w jednym miejscu.

Mikołaj Szczerbicki: Czyli observability jest bardzo uniwersalne.

Szymon Warda: Jest bardzo uniwersalne i pozwala widzieć wszystko w jednym miejscu, tak żeby wszyscy patrzyli na to samo i wyciągali te same wnioski. Najgorsza sytuacja jest wtedy, kiedy admini mówią, że mamy awarię, a developerzy, że u nich wszystko działa, bo nie widzą tego błędu. Pewnie kiedyś to słyszałeś albo Ci się przydarzyło.

Mikołaj Szczerbicki: Wspominałeś o tym podczas naszego ostatniego spotkania, więc jak najbardziej to rozumiem. Dlatego zależało mi, żebyśmy dziś poszli krok dalej i powiedzieli, jak zweryfikować, czy to jest dla mnie. Wiemy już, że w przypadku mojej organizacji jak najbardziej tak. Powiedziałeś też, kiedy nie, więc myślę, że to jest jasne. Pójdźmy krok dalej. Jeżeli mam podjąć decyzję biznesową, to chciałbym usłyszeć jakieś liczby i konkrety.

Szymon Warda: Jasne. Wyjaśnijmy najpierw podejście. Jeżeli wpiszesz „observability” albo „monitoring” w Google, wyskoczy Ci cała masa wyników. Pytanie brzmi: czemu akurat to? To bardzo ważne. Dziś relatywnie łatwo jest wdrożyć gotowy system z pudełka typu Datadog, Dynatrace i masę innych. Problemy zaczynają się, i to bardzo ostre, w kwestii finansów, bo te programy są licencjonowane z reguły na bazie liczby użytkowników. To nie zachęca do tego, żeby system był widziany na poziomie całej organizacji. To pierwsza rzecz.

Mikołaj Szczerbicki: Wracając do tego, co powiedziałeś: małe organizacje dobrze, żeby sięgały po rozwiązania pudełkowe.

Szymon Warda: Oczywiście. Ale jak mamy 100 czy 200 osób, które chcemy, żeby z tego korzystały, to nagle liczba tak zwanych stołków zaczyna nas boleć. I wracamy do sytuacji, którą widzimy dość często: organizacja zaczyna limitować, kto ma dostęp. A chyba nie o to chodzi, prawda?

Mikołaj Szczerbicki: Nie brzmi to najlepiej.

Szymon Warda: Nie brzmi najlepiej. Nie pomaga, żeby podczas awarii ludzie, na przykład poszczególne linie wsparcia, wiedzieli, co mogą zrobić. Prowadzi też do tego, że za chwilę powstanie kolejny system do monitorowania, bo ktoś się wkurzy, że czegoś nie widzi i nie może korzystać. I rozwiązujemy problemy przez dodanie kolejnego klocka do utrzymania? Nie za bardzo.

Drugi element licencyjny to liczba procesorów albo monitorowanych systemów. Jeżeli budujemy platformę do monitorowania, to chodzi nam o widoczność całej organizacji: co się dzieje i jak przebiegają przepływy pomiędzy wieloma systemami. Zależy nam, żeby monitorować jak najwięcej zespołów, bo one na siebie wpływają. Nie skupiamy się tylko na aplikacjach klienckich, ale zbieramy informacje z baz danych, kolejek, cache'y, nawet serwerów DNS. Chodzi o informację całościową, żeby w przypadku awarii czy jakichkolwiek problemów widzieć, co się dokładnie zdarzyło i gdzie coś się zmieniło.

Mikołaj Szczerbicki: Czyli dzięki temu, że koszty nie są liczone per użytkownik, ten system może działać dużo szerzej.

Szymon Warda: Może. Co więcej, to systemy używane w większości organizacji od wielu lat. Założę się o własne pieniądze, że gdzieś u Ciebie funkcjonuje Prometheus, bo tak z reguły jest. Pewnie nie jest wykorzystany w całości i we wszystkich możliwościach. Czy wiesz, z ilu systemów Prometheus może zbierać metryki? Dziesiątek? Setek? Tysięcy?

Mikołaj Szczerbicki: Aż się boję strzelać.

Szymon Warda: Mówimy o grubych tysiącach. Cała społeczność, która korzysta z Prometheusa, umożliwia podłączenie się pod niemal wszystko, także pod systemy, które często tego nie wykorzystują. Właśnie na uzupełnieniu tego się skupiamy. Bywa tak: „zróbmy sami, postawimy sobie system szybko”. Wtedy stoi jakaś wydmuszka, która zbiera dane z 10–20% tego, co może być zbierane, i nie zapewnia widoku całościowego. Przychodzi awaria i nie wiemy, co było główną przyczyną. Czy to był DNS, który się przepełnił? Zdarzają się takie rzeczy. Czy macierz dyskowa? Czy może serwer tożsamości? Ze wszystkiego trzeba zbierać dane, żeby potem wiedzieć, co się wydarzyło.

Mikołaj Szczerbicki: Okej. Znowu mnie przekonałeś, bo liczby mówią dużo. Jeżeli podejmuję decyzje biznesowe, to muszą być na nich oparte. To, że dobrze zrobiony system observability może być wdrożony szerzej w organizacji, przemawia do mnie. Każdy Excel po prostu powie, że światełko świeci się na zielono, a nie na czerwono. Wiem więc, że mogę to robić u siebie i że jest to ekonomicznie uzasadnione.

Szymon Warda: Jak najbardziej.

Mikołaj Szczerbicki: To teraz chciałbym wiedzieć, jak to wdrożyć i ile zasobów ludzkich muszę na to poświęcić przy gigantycznym backlogu, który zawsze jest w organizacjach.

Szymon Warda: Zaczyna się od kilku faz. Ucieszę Cię i powiem od razu: nie będzie to wymagało dużego zaangażowania z Twojej strony.

Mikołaj Szczerbicki: Czyli duże zmiany, małe zaangażowanie. Coraz bardziej mi się to podoba.

Szymon Warda: Dokładnie tak. Pierwsza rzecz, którą zalecamy organizacjom, to inwentaryzacja, czyli dowiedzenie się, kto z czego korzysta i co właściwie mamy w organizacji. To ważne, bo zmiany typu Wielki Wybuch ładnie brzmią na papierze. Jeżeli jednak nagle zabierzemy administratorom i osobom z pierwszej i drugiej linii wsparcia systemy, z których korzystają, i nie zmigrujemy ich poprawnie, spowodujemy chaos. Ludzie nie będą wiedzieli, co jest gdzie. Więc pierwszym elementem jest inwentaryzacja: kto z czego i do czego korzysta.

Drugim krokiem, kiedy już wiemy, co i jak, jest postawienie Grafany. Dlaczego? Żeby system był wykorzystywany i żeby uniknąć tego, co na pewno istnieje w organizacji: strony wiki z opisem, co można znaleźć pod którym adresem URL, o której część osób wie, a część nie. Stawiamy Grafanę, która agreguje te wszystkie dane. To jeden punkt wejścia do wszystkich danych metrycznych i monitoringowych w całej Twojej organizacji.

Mikołaj Szczerbicki: Czyli na tym etapie zobaczymy rzeczy, o których zapomnieliśmy.

Szymon Warda: Dokładnie. Odkrywamy skarby i trupy w szafie. Odkrywamy, za co płacimy, a czego nie wykorzystujemy, co jest jak używane i który system służy do czego. Mamy inwentaryzację i decydujemy, co dalej z tymi systemami: usuwamy je, zastępujemy czy coś innego. Większość przewodników w internecie powie Ci, żeby teraz wdrażać te systemy i budować platformę. My mówimy: hola, hola. Sztuką nie jest wysłać wszystkie dane różnej jakości do centralnego systemu i powiedzieć „robota zrobiona”. Jest takie powiedzenie, że dane słabej jakości dają wynik słabej jakości, żeby użyć ładnych słów. Zalecamy więc postawienie czegoś, co się nazywa Grafana Alloy. To elementy, które umieją zbierać dane z różnych systemów: maszyn wirtualnych, Kubernetesa, chmury czy czegokolwiek innego.

Szymon Warda: Stawiamy je i to one zajmują się uzdatnianiem danych, czyli podnoszeniem ich jakości, pilnowaniem ich, buforowaniem i tak dalej. U Ciebie pewnie też się znajdą jacyś szaleni developerzy, którzy postawili Kafkę, żeby móc wysyłać logi. Bardzo częsta sytuacja. Kafka się do tego trochę nie nadaje.

Mikołaj Szczerbicki: Wiem, słyszałem. Zdarza się to notorycznie.

Szymon Warda: Notorycznie. Trochę szkoda wykorzystywać Kafkę do tego typu celów. Potem, jak już zbieramy te elementy, czyli wiemy co, gdzie i jak możemy wzbogacić, i wiemy, jak zapisywać dane, żeby dane z systemu A były podobne do danych z systemu B, stawiamy platformę monitorującą. Zaczynamy od prostych rzeczy, czyli od Prometheusa do metryk, liczb, które pokazują, jak system się zachowuje. To daje podgląd, jak wygląda cały nasz ekosystem, jakie ma tendencje i jak się zachowuje w cyklach dziennych. Mamy liczby, więc możemy zacząć myśleć o alertach i o prognozowaniu, kiedy coś się wywali. Mówiąc bardzo prosto.

Mikołaj Szczerbicki: Poproszę Cię tylko, żebyś doprecyzował jedną rzecz, bo chcę to dobrze zrozumieć. Kiedy mówisz „stawiamy”…

Szymon Warda: To nasze rekomendacje.

Mikołaj Szczerbicki: …to kto to stawia?

Szymon Warda: My to robimy. Od Ciebie oczekuję dostępu do klastra Kubernetes, albo postawimy go sami, i dostępu do CI/CD, czy to będzie GitHub, Bitbucket, czy cokolwiek innego, co na pewno istnieje w organizacji. Stawiamy wszystko z kodu, żeby było odporne i trwałe. I to jest koniec Twojego zaangażowania w tej formie. Z kodu stawiamy wszystkie kolektory i to jest nasza część roboty. Ty wskazujesz systemy, bo robimy to w fazach: wybieramy systemy, robimy PoC-e i tak dalej. My przygotowujemy testy obciążeniowe, żeby upewnić się, że system będzie działał, i podpinamy go pod podstawową Grafanę. Zapewniamy widoczność.

Na co kładziemy duży nacisk: oddając kolejne systemy do użycia, mówimy „ten system jest gotowy, możecie korzystać” i wprowadzamy szkolenia, żeby ludzie umieli z niego prawidłowo korzystać. Sztuką nie jest postawić Prometheusa i powiedzieć: macie, korzystajcie.

Szymon Warda: Sam mówisz, że masz pełen backlog. Twoi pracownicy nie mają czasu na dokształcanie się, szukanie i kombinowanie, jak to działa. Łatwiej zrobić szkolenie, które potrwa jeden dzień, 4 godziny, i pokaże, co mogą z tego wycisnąć i jaka będzie wartość. Zamiast 20% wartości otrzymujemy nagle 90 parę procent, bo okazuje się, że to się przyda. Dzięki temu zachęcamy pracowników do korzystania z nowych narzędzi, a nie siedzenia na starych.

Mikołaj Szczerbicki: Tym bardziej że, jak wspomniałeś, te narzędzia mogą być stosowane dużo szerzej w organizacji. Dla niektórych osób to będzie zupełna nowość.

Szymon Warda: Zakładam, że tak. Z drugiej strony wybieramy stos, który jest znany i wykorzystywany przez CNCF i organizacje na całym świecie. To nie jest tak, że nowa osoba w Twojej organizacji powie: „w życiu tego na oczy nie widziałem”. Jak nie widziała, to nie wiem, czy powinieneś ją zatrudniać. Warto o tym pomyśleć w procesie rekrutacji. Usuwamy więc cały ten onboarding i wykorzystujemy standardy rynkowe, które możemy rozbudowywać i wzmacniać. Budujemy na bazie dziesiątek, setek tysięcy ludzi, którzy używają tych systemów do monitorowania ogromnych, ale też mniejszych systemów.

Mikołaj Szczerbicki: Okej, Szymon, uspokoiłeś mnie. Po pierwsze, proces wdrażania nie wymaga bardzo dużego zaangażowania mojego zespołu. Po drugie, jest zaplanowany i idzie fazami. Po trzecie, to, co zostaje wdrożone, zostaje też przygotowane do użytku przez ludzi: wdrożenie zawiera szkolenie. To nie jest tak, że idziemy do galerii sztuki, patrzymy na obraz i mówimy, że ładny. Faktycznie jesteśmy w stanie coś powiedzieć, patrząc na ten obraz.

Szymon Warda: Tak. Mamy element monitoringu: zbieramy metryki, zbieramy logi, wszystko fajnie. Drugi element, który jest super kluczowy dla Twojej organizacji, to standardy, których będziemy wymagali od developerów aplikacji. Tu też wchodzimy i przeprowadzamy wywiady z kilkoma grupami developerów, żeby zrozumieć charakterystykę Twojej organizacji: jak działacie, jakie macie standardy i gdzie jest Wasz punkt startowy. Na tej bazie przygotowujemy rekomendacje standardów i to, do czego zespoły się zobowiązują. Ewentualnie wprowadzamy je fazami i doradzamy, jak możecie do tego standardu dojść. Jak mówiliśmy w pierwszym odcinku, monitoring możemy zrobić bez integracji z aplikacjami i bez wsparcia developerów. Więcej wartości wyciśniemy jednak z całego systemu, jeżeli aplikacje będą w to włączone.

Mikołaj Szczerbicki: Pamiętajmy, że to jest właśnie ta różnica, którą mi wytłumaczyłeś, pomiędzy zwykłym monitoringiem a ideą observability: to pociąga za sobą zmiany organizacyjne, zmianę kultury i sposobu patrzenia na pewne rzeczy. To, o czym mówisz, jest świetne.

Szymon Warda: Pracujemy więc z Twoim zespołem developerskim i wytwarzamy standardy, bo, jak podkreślałem w poprzednim odcinku, współpraca z Wami musi istnieć, żeby wycisnąć jak największą wartość. I tu mówimy o niewielkim nakładzie per system. W nowoczesnych technologiach typu Java, .NET, Python, JavaScript to od pół godziny do 3 godzin per system: dodanie kilku bibliotek i działa. Zakładam, że developerzy u Ciebie i tak już tego próbowali i te biblioteki pewnie istnieją. Może są niedokonfigurowane, może paru rzeczy brakuje, ale niewielkimi ruchami na poziomie konfiguracji możemy uzyskać bardzo dużo wartości.

Możesz powiedzieć: okej, ale mam systemy, które kupiłem, nie utrzymuję ich albo nie są aktualnie rozwijane. Jednym z podejść, które stosujemy, jest autoinstrumentacja z zerowymi zmianami w kodzie. Uruchamiamy Twoją aplikację przez agenta i w tym momencie zyskujesz dużo.

Szymon Warda: Nie wszystko, nie będę ukrywał, że to jest idealne. Ale jest dużo lepiej. Zyskujesz telemetrię, tracing i metryki aplikacji z zerowymi zmianami w jej kodzie. Jest to bardzo bezpieczne. Co więcej, czasami kończy się na zmianie obrazu docelowego, w którym aplikacja jest uruchamiana.

Mikołaj Szczerbicki: No dobrze. Mamy standardy dla developerów. Dla kogo jeszcze?

Szymon Warda: Dla adminów. Mamy też standardy dla DevOpsów. Mając tych trzech aktorów w jednym kręgu, możemy zacząć się skupiać na tym, co możemy wyciągnąć więcej i jak możemy być proaktywni. Dopiero kiedy są razem, patrzą na to samo, a dane są zbierane i są głębokie, możemy zapytać: kiedy wykryć, że system się za chwilę wykrzaczy? Kiedy system ma problemy? Jaki jest główny powód? To nie jest tak, że ktoś na chwilę powie „patrzę na tę metrykę”, bo tak to z reguły nie działa. Łączymy wiedzę tych ludzi i nie zamykamy jej w spotkaniu, po którym wiedza plemienna za chwilę wyparuje. Przekuwamy ją w alerty i predykcyjne metryki. Dodajemy je do systemu i wiedza systemu rośnie.

Szymon Warda: Co jest fajne, i zaraz zobaczymy to na demo: dodając dowolny system, jakąś bazę PostgreSQL, Redisa czy masę innych systemów, które pewnie masz u siebie, nie musisz teraz zbierać ludzi. Korzystamy z otwartego systemu, którego używa bardzo wiele organizacji, więc tę wiedzę możemy wziąć. Większość obecnych systemów ma już gotowe, oficjalne, często promowane przez samych dostawców zestawy alertów. Nie mówimy o dwóch, trzech czy czterech. Mówimy często o dziesiątkach, jak nie setkach alertów, które mówią, czy Twój system działa dobrze.

Mikołaj Szczerbicki: Taki zbiór dobrych praktyk.

Szymon Warda: Dobrych praktyk, na które nawet nie musisz patrzeć, bo same Cię poinformują, że coś się dzieje. Niektóre wdrożenia Kubernetesa domyślnie wgrywają reguły alertów. Nie musisz się nimi interesować, po prostu je widzisz, znowu w jednym centralnym miejscu, więc niczego nie musisz szukać. Konfigurujesz tylko, kto i kiedy będzie powiadamiany. I tyle. Całą widoczność dostajesz z pudełka, bo korzystasz z czegoś, co jest wykorzystywane na rynku, a nie z małego rozwiązania utrzymywanego przez jedną firmę, której musisz płacić grube pieniądze.

Mikołaj Szczerbicki: Szymon, opowiedziałeś nam o wdrożeniu, podzieliłeś je na etapy i zdradziłeś, że możesz nam dziś coś pokazać. Bardzo chciałbym zobaczyć, o czym tak naprawdę rozmawiamy.

Szymon Warda: Dobrze, ruszajmy. Mógłbym Cię zanudzić technicznymi elementami, pewnie też je poruszymy: co istnieje i jak te zabawki ze sobą grają. Dla mnie nie jest to jednak największa wartość tego, co chcemy pokazać. Największa wartość pojawia się wtedy, kiedy te systemy zaczynają ze sobą grać, a operator czy użytkownik, jakkolwiek to nazwiemy, nie martwi się, skąd ma dane i jak je pobiera. Może po prostu wejść i zobaczyć, co się w systemie dzieje. Kluczowym elementem jest tu dla mnie dashboard drilldown, czyli spojrzenie na dane z tracingu. Ma trzy elementy: liczbę błędów, liczbę requestów i czas tych requestów, czyli ich rozkład w czasie. Jeżeli słyszałeś cokolwiek o observability, to może Ci się zaświecić nazwa RED, czyli Request, Error, Duration. To jedno z trzech podstawowych spojrzeń na dowolny system. Operator, dowolna osoba, siada i ma zaproponowane dobre spojrzenie na to, jak ten system monitorować.

Szymon Warda: Zobaczmy, co daje nam pierwszy, najbardziej krytyczny ekran, czyli błędy. Możemy na nie spojrzeć dwojako. Pierwsze to błędy widoczne dla klienta, z reguły bardziej interesujące. Drugie to błędy połykane przez nasz system, które nie są widoczne, ale przydałoby się je zaadresować.

Mikołaj Szczerbicki: Czyli to ta sytuacja, kiedy różne zespoły patrzą w jedno miejsce i każdy widzi tam coś dla siebie.

Szymon Warda: Tak, dokładnie. I to jest potęga interakcji pomiędzy tymi systemami. Po pierwsze mamy rozkład: które systemy ile błędów produkują, bo liczba jest ważna. Kolejny krok to tzw. root cause errors, czyli źródło tych błędów dla każdego serwisu, statystycznie z ostatniego pół godziny. Sztuką nie jest zobaczyć, że jeden system się wywalił, bo powód błędu jest z reguły gdzieś niżej w łańcuchu. Mamy więc prosty wgląd w to, co się stało i który system czemu miał problemy. Bardzo szybkie spojrzenie. To jedna zakładka. Kolejna to porównanie: jak system zachowuje się teraz względem poprzedniego okresu. Jak coś przestało działać, możemy zapytać, co się zmieniło. Jakieś błędy zawsze będą się pojawiać i wiemy, że ekonomicznie nie ma sensu gonić każdego, bo zawsze coś się zdarzy.

Szymon Warda: Dalej mamy szybkie spojrzenie na to, jakie błędy są rzucane i jakie trace'y, czyli ślady, one zostawiają w systemach. Możemy prześledzić nasze systemy po całym łańcuchu wywołań: gdzie coś nie zadziałało, na które serwisy miało to wpływ i czy faktycznie było to widoczne dla użytkownika. Bardzo potężne spojrzenie na to, czy w ogóle warto się tym interesować. Do tracingu jeszcze wrócimy, bo tam możemy zrobić parę fajnych rzeczy.

Idziemy dalej. Możemy spojrzeć na liczbę requestów i na strukturę serwisów: które odwoływały się do których. Znowu porównanie i znowu przejście do trace'ów. Ostatni element tej zakładki to rozkład czasów. Podejście jest podobne jak przy błędach. Patrzymy na dwie podstawowe rzeczy: jaki jest główny element opóźnień, czyli czemu nasz system działa wolno, i który obszar najlepiej zoptymalizować, żeby działał szybciej.

Szymon Warda: Znowu mamy odpowiedź na bardzo skomplikowane pytania w bardzo prosty sposób. Mamy porównanie z wcześniejszym zachowaniem, możemy analizować różne segmenty i przedziały czasu. Oczywiście mamy też automatyczne filtrowanie requestów, które realnie były wolne, i możemy wejść w ich szczegóły.

Mikołaj Szczerbicki: Chciałbym skorzystać z tego, że masz przygotowane demo. Często pojawiają się hasła takie jak logi, trace'y, metryki, a także nazwy konkretnych części systemu: Grafana, Prometheus, Grafana Alloy. Czy możesz opowiedzieć, jak te klocki się ze sobą łączą i gdzie są w systemie, który teraz widzimy?

Szymon Warda: Jasne. Łączą się właściwie wszystkie ze wszystkimi. Bazą, którą proponujemy, jest Alloy do zbierania danych i Prometheus, absolutny standard rynkowy, do metryk. Loki do zbierania logów: jest w stanie przyjąć terabajty danych, optymalnie czasowo i kosztowo, i praktycznie nie wymaga utrzymania. Te systemy po prostu działają. Na koniec Tempo do zbierania trace'ów. To nasza bazowa struktura. Teraz pokażę Ci, co można zrobić, jeżeli rozszerzymy ją o coś, co nie jest nowością na rynku, ale bardzo się rozwija w ogromnych organizacjach, czyli o profiling oparty na eBPF.

Mikołaj Szczerbicki: Bo już się bałem, że powiesz, że AI też będzie.

Szymon Warda: Będzie, za chwilę.

Mikołaj Szczerbicki: No dobrze.

Szymon Warda: Monitoring daje nam spojrzenie w skali dni i godzin. Logi i trace'y to dalej skala minut. Czasami jednak, na przykład kiedy developerzy robią profiling wydajnościowy albo coś się wywaliło, chcemy mieć wgląd poniżej 20 milisekund i wejść w drobne rzeczy. Co możemy zrobić? To właśnie pokazuję na ekranie: bez żadnej integracji, aplikacja nawet o tym nie wie. Wykorzystujemy eBPF, żeby podłączyć się pod Linuksa. Niestety dotyczy to tylko aplikacji na Linuksie, najlepiej na Kubernetesie. Można na maszynach wirtualnych, ale tego nie zalecamy, bo nie jest to tak łatwe, jak powinno być. Możemy zejść do poziomu wywołań poszczególnych metod w serwisie. Robimy to w czasie rzeczywistym, nie musimy nic włączać. I teraz zagadka: jak myślisz, jaki jest narzut wydajnościowy przy tak dokładnym wglądzie w to, co robi aplikacja?

Mikołaj Szczerbicki: Dziesiątki procent.

Szymon Warda: Od jednego do trzech procent. Jeżeli weźmiesz dowolny inny system APM, czyli do monitorowania wydajności aplikacji, to z reguły jest 5–10%. Często trzeba go włączać, często masz dużo gorszy sampling i aplikacja musi o tym wiedzieć, bo wpinasz się w aplikację. Tutaj siedzimy na warstwie dużo niżej i nic nie musimy robić. Włączasz i masz. Możesz powiedzieć: okej, Szymon, mam dokładny stos wywołań metod, ale mój operator nie wie, co tam się dzieje, to poziom szczegółu dla programisty. I teraz magia tego, że korzystamy z otwartego stosu, w którym ludzie rozwiązali pewne problemy. Klikam mały, prosty przycisk Explain flame graph. On zbiera dane użyte w naszym flame graphie i wysyła je do modelu. Tu skonfigurowaliśmy to z OpenAI. Model tłumaczy dokładnie, co się stało: w tym kawałku kodu może być kod, który się wywala, zużywa dużo pamięci albo cokolwiek innego.

Szymon Warda: Proponuje rozwiązania na bazie dobrych praktyk i wyciąga informacje, co powinno się zmienić, ładnym, słownym opisem. Dzięki temu operator nie musi tego wiedzieć, a developer, który ma system w utrzymaniu, widzi problem, ale nie zna go dobrze, dostaje konkretną odpowiedź. Czy jest idealna? Nie, ale wartość, którą generuje, jest bardzo dobra. Nie jesteśmy też przywiązani do konkretnego modelu. Możemy korzystać z Anthropica, z [niezrozumiałe] czy z dowolnego systemu zgodnego z API OpenAI.

Mikołaj Szczerbicki: Szymon, pokazałeś mi naprawdę dużo ciekawych rzeczy. Wygląda na to, że pod taką platformę można podłączyć mnóstwo rozwiązań.

Szymon Warda: Tak, jest tego bardzo dużo. Jak widzisz na ekranie, nasze platformy mają duże zasoby do monitorowania, łącznie z takimi rzeczami jak Redis i Postgres. Ile razy zdarzyła się sytuacja, że jest awaria, bo baza rzuca jakimś wyjątkiem, i nagle trzeba szukać DB admina, żeby się dostał i zobaczył, co się dzieje? Brzmi jak scenariusz z horroru. Kontrolując dostępy, możemy połączyć nasze bazy tak, żeby były widoczne w Grafanie. Mając na przykład wyjątek na poziomie trace'a, że komenda się nie udała, klikasz jeden przycisk i zapytanie wykonuje się w trybie odczytu na tej bazie danych. Od problemu do rozwiązania mamy nagle ułamki sekund, a nie godziny szukania osoby z odpowiednimi uprawnieniami. Oczywiście trzeba to zbudować i zabezpieczyć. Szybkość działania jest jednak ogromna. Ostatnia rzecz, którą chcę pokazać: Grafana umie się dogadać z wieloma systemami.

Szymon Warda: Możemy objąć prawie całą Twoją organizację, łącznie z Datadogiem. Grafana łączy się z systemami, które już istnieją, żeby zrobić płynne przejście do jednego centralnego miejsca: centrum informacji o zdrowiu wszystkich systemów w całej organizacji.

Mikołaj Szczerbicki: Czyli jeżeli mamy systemy mocno zakorzenione w organizacji, to nie muszę ich wyrzucać. Grafana i Prometheus współpracują na przykład z Zabbixem albo ELK.

Szymon Warda: Oczywiście, że tak. Nie proponujemy Wielkiego Wybuchu. Proponujemy ewolucję i przekonanie organizacji i osób w tej organizacji do nowego podejścia. Wierzymy, że przez wartość, którą te systemy generują, to po prostu przejdzie. Nie trzeba będzie robić niczego siłą.

Mikołaj Szczerbicki: Super. Szymon, bardzo Ci dziękuję, że nam to pokazałeś. Mam wrażenie, że nie tylko mnie, ale nam wszystkim dużo to wyjaśniło. Poproszę Cię teraz o podsumowanie naszej rozmowy.

Szymon Warda: Jasne. Dla mnie najważniejsze jest to, że w całym procesie mówimy głównie o uporządkowaniu wszystkiego, co się dzieje w organizacji, i o jednym centralnym miejscu. To nie jest rozwiązanie typu „tak albo nie”. To zadanie, które możemy wdrażać fazami i częściami. Możemy zacząć od porządków. Możemy zacząć od lepszej widoczności. Jeżeli chcemy szybszych sukcesów, możemy zacząć od Prometheusa albo dodać na przykład [niezrozumiałe]. A kiedy pozostałe rzeczy już mamy, możemy składać klocki według tego, czego potrzebujemy. Nie musimy wdrażać wszystkiego naraz. My jednak zachęcamy i bardzo mocno proponujemy podejście całościowe: wdrożenie, prawdziwy onboarding, a potem odpowiedni pakiet szkoleń, żeby ludzie wiedzieli, jak wyciągnąć wartość, która została włożona we wdrożenie. I bardzo mocno wierzę, że przy tym, jak szybko ten ekosystem się rozwija i jak szybko dochodzą nowe rzeczy, wartość dużych graczy, którzy dają rozwiązania z pudełka, będzie coraz bardziej maleć.

Szymon Warda: To się według mnie nie spina ani kosztowo, ani organizacyjnie.

Mikołaj Szczerbicki: Super. Jestem naprawdę mocno przekonany i zostaję z tym, co wytłumaczyłeś mi ostatnio. To hasło zostaje z tyłu mojej głowy: proaktywność, a nie reaktywność. I to, że observability to nie jest system, SaaS ani aplikacja, którą instalujemy, tylko zmiana kultury organizacyjnej w monitorowaniu i działaniu naszych systemów.

Szymon Warda: Wbrew temu, co mówi wielu producentów: że wystarczy zainstalować i masz tę moc.

Mikołaj Szczerbicki: Dziękuję Ci bardzo za dzisiejszą rozmowę. Mam nadzieję, że będziemy mieli okazję kontynuować ten temat w następnych odcinkach. Wam wszystkim też bardzo dziękuję i do zobaczenia.

Szymon Warda: Dziękuję.