Łukasz: Cześć. Słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…

Szymon: …i Szymon Warda. Wszystkie linki do tego odcinka znajdziecie na www.patoarchitekci.io/21 . To od linków zaczynamy?

Ł: Tak, od linków. Co przygotowałeś?

S: Znalazłem ciekawe repo na GitHubie, dość duże, niekodowe. Bardzo cieszę się, że je znalazłem, bo często dostaję pytania od osób, które chciałyby albo chcą zostać architektami.

Ł: Albo pytają się, co to jest.

S: Ewentualnie…

Ł: „co to za zwierzę".

S: Starają się zostać architektami i nagle jest pytanie „co ja właściwie powinienem robić i jak wygląda ta praca". Ta praca jest zupełnie inna niż na przykład developera, team leadera – zupełnie inna bajka. To repo jest ciekawe, bo listuje częste aktywności leadera i tam tego kodowania jest dużo mniej, a potem proponuje taką pętlę zwrotną zdarzeń: design, decide, simplified code, document, communicate, estimate, estimate & evaluate, balance, consult & coach. I na końcu market. Mnie tu cieszą bardzo trzy pozycje: simplify – bo często ludzie to zapamiętają, szczególnie kiedy mają opcję „Budujemy to słynne opus magnum". Communicate – bo wielu deweloperów ma tendencję do tego, żeby jednak zamknąć się w swoim pokoju i generalnie tylko kodować: „Zobaczą moje wspaniałe dzieło". Wreszcie consult & coach – bo elementem pracy, obowiązków developera powinno być właśnie coachowanie i tak naprawdę trenowanie swojego następcy.

Ł: To, co mi się akurat w tym podoba to, że w consult & coach jest open door session, czyli jest się dostępnym. To jest jedno. Drugie pewnie ten communicate bym u Ciebie zamienił na „balance", który tu się znajduje, ale to już z mojej praktyki.

S: Tak, możliwe. Jeszcze o market myślałem, bo to też jest często rzecz, o której zapominamy jako architekci. To jest ważne, żeby jednak reklamować te rozwiązania, czy one są dobre. To jest ważne.

Ł: Wielkość organizacji.

S: Zdecydowanie.

Ł: Przy tym projekcie, w którym ja siedzę, to akurat balance i consult & coach są najbardziej istotne przy aktywnościach, bo to bardziej aktywność niż projekt.

S: Ja ostatnio coraz więcej mam potrzeby jednak tego „market".

Ł: Jedna rzecz mi się w tym nie podoba. Tak zarzucę do obejrzenia, ten technology road map jest chyba na siłę wrzucona. I książki.

S: Jest parę obszarów, które nie są idealne, zgodzę się. Ale powiem tak: gdybym ten link miał rok temu, to dużo by obsłużył takich właśnie pytań. Na start? Super.

Ł: Super. Important skills na pewno, a reszta z przymrużeniem oka.

S: Pamiętaj, że patrzysz z innej perspektywy. Na start dla kogoś, kto się w tej roli znajduje, sporo z tego wyniesie. Ciekawe. Dobrze. Co u Ciebie?

Ł: A ja dla odmiany trochę mięcha i bebechów od Twojego. Post na temat tworzenia w Golangu, używania tak naprawdę, wbudowanej klasy HTTP serwera w sposób resilient, czyli wysoko, niezawodnie dostępny. I jest pokazane na temat podstaw, które trzeba pamiętać. Tu są dwie. Jeden to są „time-outy", drugie…

S: Circuit breaker?

Ł: Nie. context cancellation, bo to od strony implementacji serwera.

S: Tak. Całkiem fajna rzecz.

Ł: Więc tutaj jest to wprowadzone, w jakiś sposób to wygląda w Golangu. Nie oszukujmy się – w większości języków wygląda to bardzo podobnie, bo zaczyna się od tego, że mamy pięknie pokazane graficzne przedstawianie czym jest time-out i jak w ogóle trwa taki cały cykl requestu, który mamy, żadania do serwera.

S: Naprawdę całkiem nieźle i faktycznie jeszcze fajnie zwizualizowane. Niezły wpis. Dobrze, to o czym dziś?

Ł: To wracamy do observability. Tym razem metryki. Szymon, przypomnijmy sobie, uporządkujmy to podejście. Powiedz nam te trzy kluczowe obszary observability.

S: Logi, w poprzednim odcinku, metryki i na końcu mamy tracing.

Ł: Mamy metryki. W dwóch zdaniach powiedz nam, czym jest metryka.

S: To jest akurat proste. Jest to para klucz-wartość, gdzie klucz jest stylingiem, a wartość jest liczbą. Tyle.

Ł: Dobrze. Za mocno to uprościłeś. Tak na moje, zapomniałeś jeszcze o czasie.

S: Specjalnie, bo tak naprawdę ten czas jest generowany często albo przez system do agregowania logów albo ten system do przechowywania tych logów. Tam ten czas się dopiero znajduje, dodatkowy wymiar.

Ł: Przejdźmy: mamy system agregujący i przetwarzający w kontekście metryk. Rozwiń to, bo troszkę robi to taki mały „mindfuck".

S: Tak.

Ł: Tutaj mówisz „agregujący i przetwarzający". Czy to nie powinno być jedną całością?

S: Właśnie. Często jest tak, że metryki, które generujemy, to jest dużo danych. I w dużych systemach, gdzie je generujemy jest ich dość sporawo. Stawia się często po drodze, czy między naszym systemem te metryki generuje albo z którego zbieramy metryki, a bazą danych, która je przechowuje. Jest coś takiego co się nazywa statsd. Prosta aplikacja, która co robi? Zbiera te *metryki, agreguje i w pewnym okienku czasowym je upraszcza, uśrednia, żeby jednak tych metryk wysyłanych do naszego serwera, który je przetwarza, żeby było ich mniej, bo po prostu byśmy sobie nie poradzili z tym volumenem danych.

Ł: Można uprościć. Tak jest na przykładzie statsd, czyli jest to klocek, który tak naprawdę robi za proxy, za bufor, przed wejściem.

S: Tak.

Ł: Być może mieć kawałek logiki. A przetwarzający to już jest ta baza time series, która przechowuje metryki.

S: Dokładnie tak.

Ł: To mamy. Metryki tak naprawdę nie są tak proste, jak powiedziałeś.

S: Nie są proste.

Ł: Tak.

S: Komplikują się właśnie. Często, co widzę u deweloperów to jest to, że jakąś metrykę, klucz-wartość, zapominają o tym elemencie, tym wymiarze czasu. Czyli tym, co się stanie za ta metryką jak zaczniemy zawężać nasze okienko. Prosty przykład: patrzymy na okienko, gdzie są kolejki 10-sekundowe. Czyli te 10 sekund upraszczamy do jednego punktu i jak w tych 10 sekundach mamy na przykład trzy pomiary, to co się z nimi stanie? To już przestaje być takie trywialne, bo to co daje nam Grafana to, że możemy patrzeć na wymiar czasu, co się działo w systemie w godzinie w ostatnim roku. Wiadomo, że w tym momencie te liczby będą wyglądały inaczej, co się z nimi powinno dziać.

Ł: Dobrze. To zacznijmy sobie od tych typów pod spodem i od najprostszego, jaką jest metryka typu counter.

S: To brzmi jako najprostsza wartość. Aplikacja wysyła wartość dodatnią lub ujemną, dodatnia podbija niejako licznik, ujemna zmniejsza ten licznik. Oczywiście, time grain, czyli to czym jest statsd, to jest ten obszar okienka, który będziemy upraszczali. Będziemy te metryki squashowali do jednej wartości. W tym momencie dajemy informację do naszego systemu, że w tym okienku należy zsumować te wartości.

Ł: Teraz bardzo ważne. statsd jest utrzymywany po stronie aplikacji, która wysyła, bo powiedziałeś, że zincrementowany bądź zmniejszany.

S: Tak. Bo aplikacja de facto wysyła wartość, a tą sumę ogarniają systemy dalsze. Aplikacja nie musi się martwić, co się dzieje. De facto, aplikacja wysyła taką wartość relatywną, nie absolutną.

Ł: OK. Możesz dać jakiś przykład?

S: Jasne. Przykładem, który ja widzę, to jest: patrzymy na stan elementów w magazynie. Systemy, które przyjmują rzeczy do magazynu zwiększają liczniki, systemy, które wydają albo monitorują cokolwiek, w tym momencie te liczniki zmniejszają. To są dwa osobne systemy. One nie mają dostępu do tego samego, ale dzięki temu , że podbijają albo zmniejszają tę samą metrykę, my mamy stan absolutny w danej sytuacji. To jest fajne.

Ł: To mamy podstawowo omówiony system jakim jest counter. Następny jest gauge.

S: Tu patrzymy trochę inaczej. Musimy bardziej spojrzeć na to, jak taka metryka jest odczytywana. W tym momencie ma ona większy sens. To jest metryka, której wartość jest równa ostatniej aktualnej wartości. Nieważne, czy to zaraportowanie wartości było 5 sekund temu czy 2 godziny temu. Po prostu patrzymy na ostatnią wartość. Przykład: liczba podów w cubermetresie. Praktycznie ta wartość się nie zmienia, póki nie zostanie niezaraportowana ta zmiana, czyli counter tu nie ma żadnego znaczenia. Wiemy, że jak 10 minut temu była taka sama wartość, to nic się nie zmieniło do tego czasu. Tu jest jedna uwaga: raportowanie metryki typu gauge wymaga znajomości stanu absolutnego systemu. Na przykład w cubermetrisie mamy kogo się zapytać i mamy tę informację.

Ł: Czyli musimy znać realnie ten stan, żeby się prawidłowo o to dopytać.

S: Dokładnie.

Ł: Dobrze. Teraz dorzućmy sobie trochę wymiarów czasowych i bardziej skomplikowanych do tych metryk, czyli histogram.

S: Dobrze. Czym jest histogram? Histogram jest rozkładem ilościowym wartości po jakimś wymiarze. W histogramie często naszym wymiarem jest wymiar czasowy. To jest bardzo ważne. Typowy przykład histogramu: czasy odpowiedzi dla danego requestu, czyli widzimy jak on się rozkładał i jakie są ramy czasu. Na przykład, odpowiedzieliśmy w ciągu 3 sekund dla 200 requestów, a dla 3,5 sekundy na przykład 2,500 requestów. To daje nam zdrowie systemów w skali czasu, ale bardziej interesuje nas nie jak się zmieniało w czasie, tylko rozkład. Histogram pewnie każdy kiedyś widział na jakimś obrazku.

Ł: Czyli mamy histogram. Drugi podobny tryb metryki to summary, czyli podsumowanie.

S: Tak. Summary jest taką obudówką wokół histogramu, bo dodaje konfigurowalne percentyle. Tak naprawdę mówimy, że okej, jak już słyszymy o percentylach to oczywiście nam się kojarzy z SLA, SLO itd. Bardzo słusznie. Mamy w SLA, SLO ustalone, że system ma odpowiadać w danym czasie w 95 przypadkach requestów. Summary właśnie nam to daje: czy jest w porządku czy trochę gorzej wyglądamy. To jest bardzo ważny wykres do monitorowania i wizualizacji. Jeżeli mamy jakikolwiek SLA albo my korzystamy z tego SLA, co jest ważne, albo my wystawiamy SLA.

Ł: Czyli tak naprawdę dla nas SLO - Service Level Objective. Dobrze. Jak jesteśmy przy metrykach, przy tych detalach, jest jeszcze coś takiego jak gradacja z czasem rozdzielczości.

S: Tak. To się bardzo mocno wiąże z tym, co statsd robi. Mianowicie, metryki jako takie to są klucz-wartość, większość systemów potrafi przyjmować dziesiątki tysięcy metryk na sekundę. Tych danych zaczyna się trochę robić. Następne pytanie to czy chcemy te wszystkie dane zbierać i kolejne to na ile ważne i na ile wartościowe są metryki sprzed roku w rozdzielczości co 100 milisekund. Mają raczej wątpliwą wartość. Więc większość systemów Influx umie to robić, Prometheus nie. Umie metryki niejako degradować, jakość tych metryk, czyli zmniejsza ich rozdzielczość. Na przykład, w dniu dzisiejszym mamy co 100 milisekund, po tygodniu mamy co 500 milisekund, a po roku widzimy tę rozdzielczość w przedziale minuty. To bardzo oszczędza storage i przyspiesza zapytania.

Ł: Ja się po roku akurat przyzwyczaiłem do dniowych albo tygodniowych, przy niektórych rzeczach capacity.

S: Tak często może być. To jest już do ustalenia.

Ł: Dobrze, teraz punkt, przy którym między sobą ustalaliśmy co my przez to rozumiemy, bo każdy nazywał to inaczej. Ja powiedziałem to o evencie, Szymon o adnotacjach. Więc czym są adnotacje, co jest prawidłową nazwą przy metrykach. Czym jest adnotacja, jak patrzymy na metryki observability?

S: Po pierwsze: tyle wygrać, żeby Łukaszowi udowodnić – yes! Po drugie: czym są adnotacje. Adnotacje są kolejnym featurem, który widzę, że jest często zapominany, bez którego patrzenie na metryki dla mnie traci bardzo dużo wartości. Przykład z życia: jak zaczynamy wdrożenie nowej wersji na produkcję albo na jakiekolwiek środowisko, wiemy, że CPU nam podskoczy. Jak teraz będziemy patrzyli na nasze wykresy patrząc tydzień wstecz, widzimy, że był Spike w CPU i we wszystkim. Jednak on jest oczekiwany. Czym są zatem adnotacje? Adnotacje są wizualnie pionowymi liniami albo przedziałami czasowymi, gdzie możemy powiedzieć: „Okej, tu się coś zaczęło dziać, tu się coś skończyło dziać" i patrząc na wykresy możemy je wizualizować. To jest takie adnotowanie czasu i historii, co się wtedy działo, i tłumaczenie potomnym. Bardzo przydatna informacja.

Ł: Czyli pokazanie tego zdarzenia. Stąd mieliśmy tą dyskusję, bo pokazujemy jakieś zdarzenie, które zaszło w systemie i ma realny wpływ na monitoring, który mówi, że „W tym momencie albo w ogóle na to nie patrz, bo będzie czerwona przez najbliższe 10-15 minut, albo zacznij od tego miejsca – to jest miejsce, gdzie wprowadziliśmy zmiany w konfiguracji, o! poszło do góry, daliśmy ciała".

S: Tak. Teraz przykłady: mamy start release’u – tam jest konieczna adnotacja. Przedziały od kiedy do kiedy jest dana wersja, na przykład start nowej wersji – to też jest w porządku. To są naprawdę przydatne wartości, bo tego nie będziemy pamiętali. Chyba, że chcemy przechodzić przez różne docsy i patrzeć po ticketach w Jira czy w czymkolwiek innym, kiedy były releas’y i co się działo. Te rzeczy powinny być jak najbardziej na metrykach. Koniec kropka.

Ł: Dobrze. To jeszcze dorzucę, bo była dyskusja. Czyli powinniśmy mieć adnotacje na pewno na release’y.

S: Na pewno na release’y.

Ł: Start / Stop release’u.

S: Tak.

Ł: …i że jest nowa wersja działająca na produkcji jako już nie przedział, tylko po prostu znacznik.

S: Tak.

Ł: Dobrze. Co z circuit breakerem? To jest metryka czy adnotacja, jeżeli zmieni się jego stan?

S: To jest metryka. Zdecydowanie.

Ł: Dobrze.

S: Czemu? Bo metryki są uproszczone, nie mają w tym momencie wszystkich operacji matematycznych, a przy circuit-breakerze mamy prosty myk. Metryka jest porównywana globalnie, na dany przedział czasowy, to jest adnotacja do czasu. Jeżeli mamy jednak parę instancji typu circuti-breaker’a to chcemy wiedzieć, gdzie się otwierały. I tego adnotacjami już byśmy nie zrobili. Dlatego metryka.

Ł: Dobrze. Teraz pójdźmy do kolejnej, ciekawej rzeczy jaką w metrykach jest nie zawsze do końca złapana. Prometheus dość dobrze to wymusza w pewnych miejscach – tagowanie metryk.

S: Wytłumaczę też, czemu to jest czasem niewymagane. Metryki historycznie idąc od Grafite’a nie miały tagów. Dopiero Influx i Prometheus to wprowadził. Tagowanie – bardzo ważne. Te informacje wokół tego, z czego metryka wynika, czego dotyczy i jakiej grupy. Jest seria tagów, które po prostu muszą być. Środowisko, instancja, nazwa i rola tej metryki – generalnie, co ona właściwie pełni. Takie ogólne informacje, że jak ktoś spojrzy, to wie, gdzie to umieścić i co więcej, dorwać wszystkie metryki danej kategorii, środowiska itd. Znacząco poprawia widoczność.

Ł: To ja dorzucę od siebie jeszcze dobrą praktykę. Warto te same tagi trzymać przy logach. To potrafi dużo pomóc, jeżeli robimy analizę, tudzież ładnie tłumacząc na polski - śledztwo", bo możemy zobaczyć i to ze sobą złączyć; co się działo, kiedy te logi występowały. W świecie Cloud Native teraz jak sobie popatrzymy na Prometheusa oraz nową zabawkę z tamtej rodziny, czyli Logiego do zbierania logów. One mają właśnie te metryki z pudełka, pozwalają na otagowanie tak samo metryk jak i logów, tymi samymi parametrami.

S: To jest to, o czym mówiliśmy w poprzednim odcinku. To jest dodanie kontekstu do logów, co jest bardzo, bardzo ważne. Często rzeczy typu rozdzielenie środowisk w logach robi się przez inne indeksy Elastic Search’a. Ale tak jeżeli bierzemy logi? Jak najbardziej.

Ł: Teraz prosta rzecz, ale szybka: push czy pull?

S: Jedno i drugie. Dlaczego? Z serwerów będziemy zawsze pullowali, ale jak chcemy wysłać metryki z aplikacji, to będziemy je pushowali, bo w tym momencie dajemy większy kontekst i wiemy, co mamy zrobić. A jak dochodzimy do wysyłania metryk z aplikacji, to dochodzimy do rozdzielenia bardzo ważnego, między metryki techniczne a biznesowe.

Ł: Właśnie, bo mamy metryki techniczne i biznesowe. W teorii techniczne wydają się prostsze.

S: W teorii tak, ale rządza się większym bałaganem. Metryka biznesowa, uporządkujmy co przez to rozumiemy, bo też mieliśmy całkiem długą dyskusję, jest metryka rozumiana przez manager’a nietechnicznego średniego szczebla.

Ł: Określiliśmy sobie ten level odcięcia jako średni szczebel.

S: Tak. Ktoś, kto przychodzi i spojrzy na wykres czy cokolwiek i będzie wiedział czy jest okej i czy dla niego wartości, które system wypluwa są w porządku. To ważne. Często te metryki biznesowe są zawarte w SLA naszej umowy, w kontraktach, itd.

Ł: Tak. Takiej osobie jest łatwo zobaczyć, czy spełniamy kontrakt albo się zbliżamy. Mogą to być czasy odpowiedzi, często ilość przetworzonych dokumentów.

S: Ważne: dokumentów, a nie wywołanych requestów. Zgadza się.

Ł: Ja jeszcze dodam do metryki biznesowej, przy finansówce mamy dość ciekawą rzecz, jeżeli mamy system płatności, to czy nam się salda na kontach zgadzają.

S: Tak.

Ł: Czy ilość wpływów, które powinny być zgadza się z tym, co faktycznie wpłynęło. To też ciekawie porządkuje.

S: Wiesz, trochę tak bilansuję między metryką a health-checkiem, ale zgodzę się, że jeżeli możemy w czasie rzeczywistym monitorować, to jak najbardziej powinniśmy.

Ł: Dobrze. To mamy. To jeszcze pierwsze podejście do monitoringu, w szczególności metryk technicznych. Jest coś, co od jakiegoś czasu zdobywa popularność, co nazywa się RED. Czym jest ten RED?

S: Monitorowaniem wejście / wyjście, procent i procent wyjątku. Czyli wszystko, co możemy zbierać w trywialny sposób, od dowolnego serwera HTTP albo dowolnego systemu, który przyjmuje wiadomości. To mamy niemal zawsze z pudełka.

Ł: Czyli tak naprawdę bierzemy sobie logi z reverse prox, metryki z reverse proxu od Balancer’a. Proxy to wystawiają cudownie teraz w tych formatach.

S: Wszyscy to wystawiają.

Ł: Tak. Serwery aplikacyjne, czy ciekawe, bo ten RED tłumaczy się na Request Error Duration, tak samo możemy to wziąć z kolejki IN / OUT.

S: Dobrze, że to poruszyłeś, bo często ludzie zapominają o tym, że kolejka też jest ważnym elementem do monitorowania, a ta może naprawdę ciekawe rzeczy wyciągnąć. My właśnie ostatnio monitorowaliśmy dość sporo i ciekawostki wyszły w kontekście Rabbita.

Ł: Za długo leżące?

S: Nie, niepotwierdzone wiadomości w Rabbicie bedą przetworzone dopiero, kiedy serwer się rozłączy. Ta-dam!

Ł: Mamy już metryki techniczne i biznesowe. Teraz ostatnia rzecz, bo powiedzieliśmy, że przy logach nie robimy alertów i metryki są tym miejscem.

S: Przy metrykach zdecydowanie robimy alerty. Metryki biznesowe, które zdefiniowaliśmy, mogą wynikać z metryk technicznych. Mamy dane techniczne, mapuje się to na metrykę biznesową. Więc na biznesowych musimy, bo to potencjalnie płacimy za mało płacimy za dużo, albo ktoś za chwilę zapuka i powie, że: „No chłopaki, mamy problem, bo tmy musimy komuś zapłacić więcej". W technicznych, żeby bronić się od realnych problemów i to monitorować, czy aplikacja żyje czy czas odpowiedzi, takie podstawowe rzeczy, żebyśmy wiedzieli, czy jest ona zdatna do pracy i czy wiemy co robi.

Ł: Można na tym bardzo łatwo zaobserwować, przy alertach w ogóle i przy wykresach można zobaczyć wtedy degradację systemu jak i potem jego awarie.

S: Tak. Co ważne, dzięki właśnie takim zachowaniom możemy ładnie sobie scrollować, będziemy się cały czas uczyli tego, jak te alerty robić. To nie jest, że raz konfigurujemy i one będą cały czas aktualne. To jest coś, co będzie zawsze ewoluowało razem z aplikacją.

Ł: W kontekście alertów bardzo warto dodać anomality detection jak i cały machine-learning, który może się pojawić na metrykach, który się pojawia w produktach czasowych.

S: On się pojawił i naprawdę jest fajny. Czym właściwie jest anomality detection?

Ł: Odchyłem od normy. Naprawdę wykryciem odchyłu od normy tego, jak nasz system działa.

S: Tak.

Ł: Na bazie wytrenowanego modelu na naszych metrykach.

S: To jest hiper ważne, bo często widzimy, że metryki są zapinane na wartości absolutnej, na przykład na liczbę błędów. Nie oszukujmy się – nie ma takiej aplikacji, która nie rzucałaby raz na jakiś czas błędem. To nie jest powód, żeby robić on-calla, zbierać się, że system za chwilę wybuchnie. Problem pojawia się, jak nasz system rzuca nagle dużo więcej błędów niż normalnie w tym samym czasie rzucał. I to bardzo fajny cache robi tzw. Smash detection w application insides.

Ł: Tak. W Microsoft to jest Smart Detection.

S: Muszę powiedzieć, że korzystam. Działa dobrze.

Ł: Tak. Miesiąc nauki na produkcji i zaczyna wysyłać przydatne alerty.

S: I naprawdę sensowne i jak coś się faktycznie dzieje.

Ł: Czas na podsumowanie.

S: Dobre praktyki – jest ich kilka. To co ja praktykuję to jest, że jeżeli mamy metryki, to miejmy też dokument, który opisuje, która metryka co znaczy. Z całym szacunkiem, ale po nazwie i tagu, jakbyśmy wpisywali to nie będzie aż tak czytelne po pół roku czasu.

Ł: Przy czym dokument ma nie straszyć. Nazwa metryki i w jaki sposób jest wyliczana.

S: Tak. I skąd się bierze. Chociażby Microsoft to fajnie opisuje w counterach: jest to dość nieźle zrobione.

Ł: Potem sobie popatrzymy na przykładowe dashboardy, bo z wizualizacjami zawsze jest problem.

S: Co więcej, one powodują mniejszy próg wejścia, żeby ludzie zaczęli korzystać, szczególnie przy biznesowych.

Ł: Róbmy proste rzeczy, wzorujmy się na tym, co polecaliśmy np. RED, bo tam jest jeden dashboard dla każdej usługi, więc warto zobaczyć i wzorując się weź gotowe dashboardy dla jakiś rozwiązań typu MySQL, Postgres, Kubernetes czy Prometheus. Zobacz jak taki dashboard naprawdę fajnie wygląda i skopiuj go do swoich rzeczy, bo one dobrze pokazują, jak jest monitorowane takie rozwiązanie. S: Cieszę się, że to powiedziałeś, bo teraz dochodzimy do innego obszaru, który też staramy się mocno promować. To jest, żeby na jednym dashboardzie mieć wiele data source’ów. Dlaczego? Ponieważ mamy różne źródła prawdy. Przykład: możemy mieć raportowanie, ile nasza aplikacja przyjęła albo ile razy wołał się handler aplikacyjny. Drugi wykres mamy na tym samym dashboardzie, na przykład jak duża jest kolejka, ile razy było potwierdzeń, ile było wiadomości. Czyli weryfikujemy, że wartości, które powinny być takie same są czy nie są. Często te wartości nie będą takie same i nagle dowiemy się czegoś nowego, jak nasz system w ogóle działa.

Ł: Kolejna rzecz: metryki to nie audyt. Jest to dość istotne do zrozumienia, że metryki służą do zaobserwowania i monitorowania, a nie do audytowania.

S: Tak. Z czym ja się spotkałem to, że biznesowe metryki były widziane jako wartości absolutne i powiedzmy, że z ilości przetwarzanych dokumentów były na przykład inne działy rozliczane i co się tam dzieje, itd. Pamiętajmy, że większość metryk leci po UDP, mogą być tam błędy, możemy gubić pakiety i to jest coś co będziemy upraszczali, szczególnie w pierwszym okresie czasowym po wdrożeniu. Tam będziemy mieli sporo błędów, także to nie jest audyt.

Ł: Ostatnią rzeczą będzie skalowanie na bazie metryk.

S: Bardzo ważne. Co możemy robić? To w sumie pojawia się w chmurach autoscaling up-serwisów, że możemy zmieniać zachowanie naszego systemu w zależności od tego, co się dzieje nie po ilości kolejki na http, tylko od systemów dużo wcześniejszych, ile mamy wiadomości w kolejce, gdzie znając proces biznesowy możemy robić bardziej reaktywne zachowanie całego systemu i skalowanie infrastruktury.

Ł: Cieszę się, że powiedziałeś „biznesowy", bo dla mnie genialną rzeczą przy bazie metryk kiedy będziemy implementować pierwsze biznesowe, niekiedy to będzie ilość requestów na sekundę, ale możemy przestać skalować infrastrukturę po zużyciu CPU i RAMu w wielu miejscach.

S: CPU to jest wynik jakiegoś działania, więc jak reagujemy na samo CPU to jest trochę za późno na to, żeby cokolwiek się wydarzyło. Wtedy mamy problem. Więc to skalowanie się dużo wcześniejsze na wcześniejszych elementach systemu robi robotę.

Ł: Dobra, kończymy.

S: Kończymy? Dzięki wielkie. Hej!

Ł: Dzięki. Na razie!