Standaryzacja logów - nudne rzeczy, które trzeba ustalić

Sampling zawsze będzie złem, bo wam odsampluje to, co właśnie potrzebujecie i sampling jest trudny i realnie jest nie do wykonania, żeby to miało ręce i nogi. Jeżeli macie dyskusję w firmie, jak coś nazwać, zrobić, oznacza to, że pierdolnik będzie kontynuowany. Jeżeli możemy, zamieniamy new line'y, żeby one jednak były w jednej linii. Ilość nie idzie w parze z ekoszczą. My potrzebujemy logów dobrej jakości, a nie po prostu wszystkiego... Cześć. Słuchajcie, Patarwiotu prowadzą Szymon Warda i Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na patarchitekci.io i prawdopodobnie tu na dole.

Zakładamy, że już mniej więcej jakąś tam wiedzę macie, po co w ogóle monitorować, czym jest obserwabilnie i tak dalej. I to jest takie czysto techniczne szkolenie, które skupia się na tym, jak używać tych rzeczy grafanowych, plus temperamentowych oczywiście. jeżeli chodzi o nawet składnię, jak ona potem działa, jak się zachowuje itd. I zrozumienie tego jest bardzo, bardzo ważne. To nie są narzędzia typu Elastic, że sobie wpisujemy error i działa. Działa w sumie. Pierwszą rzeczą, która przychodzi, to jest login, czyli mianowicie system do agregacji logów i dużej agregacji logów, który skaluje się fenomenalnie, jest tani w utrzymaniu, jednak UI i język kwerent nie jest taki, powiedzmy sobie, intuicyjny, jakby to mogło być, ale...

I tak szkolenie też się zamyka. Bardzo, bardzo mocny nacisk na właśnie na część techniczną i to jest szkolenie, na którym wychodzicie i znacie składnie. W pełni praktycznie. No i więc tyle. Zapraszam. W każdym razie jeszcze jedno. Tak. 16 grudnia i będzie to Kubernetes the Hard Way. Czyli sposób, żeby zobaczyć jak Kubernetes działa pod spodem, jeżeli chodzi o infrastrukturę, logikę komponentów, ich komunikację. I tutaj założenie jest takie, że omawiamy już bardziej w detalach architekturę klastra Kubernetes pod spodem, co się dzieje. i potem każdy z uczestników na przygotowanym labie dostaje gołe wirtualki i będziemy wspólnie stawiać Kubernetesa z binarek, od podszewki, zaczynając od przygotowania wszystkich configów, certyfikatów, więc zaczynamy od przygotowania sobie narzędzi, budowy własnego load balancera, następnie postawienie całego CA i wygenerowanie wszystkich certyfikatów do MTLS-a.

I po całym dniu wiecie, gdzie te elementy w Kubernetesie są, co za co odpowiada tak naprawdę i dziękujecie w większości przypadków, tak jak jest jedna z tych komentarzy, że docenia już teraz Azure AKS, że nie musi się z tym męczyć, i utrzymywać tego, więc można zobaczyć cały flow, jak wygląda pod spodem Kubernetes, ile jest tam decyzji i z drugiej strony, jeżeli uważamy, że coś jest nielogiczne w Kubernetesie albo głupie, można też zrozumieć, z czego to dokładnie się wywodzi. Tutaj od razu taka podpowiedź, trzeba patrzeć na Kubernetesa jak na cepa i wtedy od razu wiemy, dlaczego coś nielogicznego jest bardzo logiczne. Tak, dokładnie. Poznać, z czego wynikała decyzja, żeby zrozumieć, dlaczego właśnie została taka podjęta.

Dobrze, to tyle z parafialek, tak naprawdę. To lecimy. O czym dzisiaj? Dzisiaj, Szymonie, chcę cię przepytać z logów, bo pojawiło się gdzieś tam na zaprzyjaźnionym Discordzie pytanie też tam i dyskusje o logi. Nie oszukujmy się, to co widzimy, to twoja działka najczęściej, no to widzisz bałagan z nimi. Jaki jest główny problem z logami? Główny problem z logami to są właśnie dwa problemy. Pierwsze to jest to, że jest ich za dużo i po prostu organizacja zaczyna tonąć od ilości, od kosztów ich utrzymania. Elastik, elastik szczególnie, z tym nie oszukujmy się, bo to jest ten główny element. Drugi element to jest to, że okej, mamy logi i właściwie nie umiemy z nich korzystać, jak naprawdę. To jest szukanie, przepraszam za wrażenie, ale dosłownie napałem, byle coś znaleźć.

I jest to takie próba łowienia. I jeżeli jest potrzeba, to właściwie z logów ciężko nam jest wnioskować, co się właściwie stało, jak się stało i co było powodem. A finalnie tak naprawdę to trzeba znaleźć z reguły dewelopera od konkretnego systemu, żeby on przypomniał, zrozumiał i wyszukał logi, które mogą pomóc w tym pakowaniu odpłynie sekcji. Tak, u naszego jednego klienta ogarnęło mnie trochę przerażenie, że w trakcie, mieliśmy jakieś tam prace serwisowe grubszej zmiany w Infrze i kiedy ludzie z zespołów aplikacyjnych szukali w czterech różnych miejscach logów, czy wszystkich komponent działa i to jest przerażające. albo onka stwierdzają, że nie, to trzeba zmienić poziom logowania, bo ta wiadomość pewnie jest na innym poziomie.

Dobra, słuchaj, to teraz tak, to jest rzecz, z którą się trochę kłócimy, trochę zgadzamy, ale słuchaj, jakie mamy rodzaje logów, jeżeli teraz popatrzysz? Dobra, to pójdźmy o to, gdzie się zgadzamy. Mamy tak, aplikacyjne, czyli całe rzeczy, które wysyłają nasze aplikacje. Zgadzamy się, tak, zgadzamy się, dobrze, bardzo mocno. systemowe, czyli mamy takie typowe infrastrukturalne, czyli co tam się wydarzyło w naszym klasterku biznesowym, co loguje na przykład. Co leci na std.auta, bo to są logi, które powinny trafiać na std.auta i co powiedzieć szybko, aplikacja żyje, nie żyje, nie było stack trace'ów. Dobrze, to teraz takie ziarnko zapytania. Logi na przykład z naszego ingresa, albo z naszego Mongo, albo z takich typowo

aplikacyjnych kompetencji infrastruktury, gdzie je zaliczysz? Wiesz co, one pójdą sobie do, właśnie i widzisz, teraz jest problem, bo ingres to są rogi dostępowe zazwyczaj, bo to jest akces, to jest akces, kontrol zazwyczaj, to są rzeczy, które są albo dostępowe, albo bezpieczeństwa, a tak jak powiedziałeś, rzuciłeś Mongo, to raczej jest to, co wypluwa Mongo, to jest systemówka. Tak, to by znowu implikowało, że w tym momencie potencjalnie na przykład patrzy na to już nie deweloperzy, tylko patrzy na to bardziej opsi, admini i tak dalej. Raczej każdy z nich może to oglądać, to jest problem. Ja bym to powiedział tak, ci, którzy chcieli wdrożyć i jeszcze nie przekazali do platformy, ci na te logi patrzą.

Nie, poważnie, bo tak to powinno działać. Każdy może sobie, okej, chcesz mieć jakiś system inny, to teraz go utrzymuj. Dobrze, idziemy kawałek dalej. Ruszyłeś dostępowe, więc faktycznie mamy. Mamy cały element ingresa, który nam chodzi. Jak najbardziej wiemy, co weszło, jak weszło. To jest kluczowe, przede wszystkim to potem będzie w przeliczeniu. jakiegoś tam SLA, jeżeli nie mamy metryk. Może tak się zdarzyć. Idziemy dalej. Bezpieczeństwo. Kto się zalogował? Kiedy się zalogował? W jakiej roli? I co zrobił? Typowa audytówka. Teraz mamy taki element, który już jest trochę rozmyty, bo to nazywają przez takie logi biznesowe, czyli żeby śledzić zdarzenia biznesowe. Ja bym tu już wchodził, a wy sobie użyj metryk.

No właśnie, bo zobacz, jest teraz tak, to jest ten problem, który jak sobie popatrzymy, aplikacyjne versus biznesowe. I to jest bardzo duży problem, bo zwykle potem to, co powiedziałeś o tym pierdolniku, ja zawsze oglądam, że logi techniczne są wymieszane z logami biznesowymi i to jest jeden wielki pierdolnik. Nie jest wymieszane. My próbujemy wnioskować zdarzenia biznesowe z logów technicznych. Właśnie wiesz, i teraz jest pytanie, czy to są statusy, które są de facto jednak rzeczą, które są w produkcie w naszych, czy to powinny być logi tak naprawdę, czy to są jednak eventy, które są w naszym stanie aplikacji?

Dla mnie to jest taka opcja. Jeżeli to jest tylko takie, żeby zorientować się, jak to wygląda, okej, używamy metryki. Jeżeli to ma być coś, z czego rozliczamy, z całym szacunkiem, zapisujemy to do jakiejś bazy i mamy jakieś kwerendy, które nam to wyliczają. Jeżeli chcę mieć absolutne źródło prawdy, to zarówno logi, może zdarzyć się, że coś się gubi, co gubi, tak samo i metryki, może zdarzyć się, że gdzieś się machniemy, coś się wydarzy, więc dla mnie takie logi biznesowe nie mają obecnej zastosowania w systemach. To powinno wylatuje do metryk. I wylatuje do bazy danych, tam gdzie to się dzieje, ten proces. Tak, gdzie mamy jakieś zapytania i jakąś raportówkę, jeżeli do tego potrzebujemy. Dobra. I na końcu diagnostyka, która znowu kolejny element dla mnie do ubicia, to powinny być tracy.

I teraz to jest moment, kiedy powiedziałeś o tym, że aplikacje kiedy logują. Tak, i to właśnie jest bardzo ważne to powiedzenie, z którego my kontekstu patrzymy. Bo teraz patrzymy z kontekstu tego, jak oglądamy te logi, a nie jak te logi wysyłamy. Bo... Dochodzimy teraz do tego, że mamy takie zabawki, jak na przykład oponenty telemetry kolektor, który może filtrować logi, więc aplikacja może logować więcej niż potrzebuje, a my potem pewne rzeczy ucinamy. To jest może taki oponenty telemetry kolektor, ale możemy dynamicznie, bez restartu ich, zmienić konfigurację i nagle zacząć wysyłać wszystkie logi i je zbierać. I to jest dopiero fajna zabawka. Więc aplikacja będzie wymagała restartu, nie oszukujmy się, z reguły. Albo będziemy mieli jakiś feature flagi, który na logowanie, a to nie ma żadnego sensu, powiedzmy.

Dużo robotu, mały zysk. Dobra, Szymon. I teraz tak, jeżeli mówimy o... sprzątaniu, czyli zastajemy pierdolnik w organizacji, jeżeli na to popatrzymy, to jak wygląda sprzątanie tego? Dobra, sprzątanie wygląda na kilka poziomów. Możesz jeszcze powiedzieć sobie, co w ogóle możemy posprzątać. Mianowicie pogodzenie się z tym, że pewne logi będą małaganem, po prostu. ... ale możemy ograniczyć ilość logów, które są bałaganem i to jest ważne, tak jak prawda. Zaczynamy przede wszystkim od tego, żeby ustalić, jaki mamy format tych logów, no nie? I teraz to jest ważne, bo i też jak te aplikacje mogą wysyłać. I tu idziemy dwojako, bo pierwszy element, gdzie ja polecam, to jest przejście na to, żeby aplikacje zaczęły wysyłać do naszego systemu logowania, pośrednio czy bezpośrednio, nasze logi.

Czemu? Bo daje nam to możliwość używania logów ustrukturyzowanych. Jak mamy logi strukturyzowane, najlepiej JSONie oszukujmy się. To się sprawdzi najlepiej. To możemy jawnie określić, które pola są i które pola jak będą nazywane i jak się znajdą na naszym systemie do zbierania logów. To jest bardzo ważne. To jest też bardzo ważna rzecz. Nie zawsze jest to, że aplikacja wszystko wie. Niektóre logi będziemy wzbogacali o pewne levely. Więc musimy określić, co my chcemy mieć w naszym systemie do zbierania logów i co aplikacja nam może wysłać. I potem dalej tą dziurę, gdzie nam czegoś brakuje, określamy, gdzie to możemy wzbogacić. To jest super ważne. Więc określamy tak naprawdę, gdzie logujemy i godzimy się z drugim faktem, że pewne logi, jeżeli mówimy, że aplikacja będzie wysyłała, pewne logi będziemy musieli skrypować z SED auta.

I określamy dokładnie, w jakiej sytuacji te logiki będą dużo gorszej jakości, mają być wysyłane. Czyli... Mówimy prosto, tylko w sytuacjach krytycznych, jak nie możemy wysłać, w sytuacjach, jak nie mamy połączenia z systemem centralnym, jak nam się te kompetenty zewnętrzne wywaliły, to jest ostateczność. Więc wprowadzamy pewną formę, bo niestety się zamordowaliśmy, no sorry, tak po prostu musi być. Jak popatrzymy, to to, co mówisz, to stdout to jest miejsce na logi systemowe, żeby szybko podejrzeć, co się dzieje, co jest nie tak, a nie na tą część aplikacyjną. Bardziej dla mnie to jest taka ostateczność, że jeżeli coś się pojawiło na SDO-cie, to znaczy, że mamy już problem. Więc wiesz, ja trochę też patrzę z perspektywy obsowej, że ktoś mi się konkretnie gdzieś grzeje, to pójdę, zobaczę logi na podzie od instancji na przykład, w tym, że to jest takie miejsce z perspektywy osoby utrzymującej do szybkiego również sprawdzenia tego, co się dzieje w niektórych miejscach.

To wchodzimy teraz w całą długą dyskusję odnośnie wejścia na poda generalnie i kto tam może wejść. Z perspektywy obsowej... Tak częściowo, no bo w tym momencie OBS będzie nie zna kodu aplikacji, nie zna samych vlogów aplikacji, więc generalnie jeżeli coś będzie widział w vlogach aplikacji, no to już tam generalnie znaczy, że jest niewesoło, powiedzmy sobie szczerze. Developer nie powinien wchodzić na... Na STD auta, tak. Tak. To już jest stacja. Dobra. Wspomnieliśmy odnośnie samego wysyłania. Dla mnie to jest teraz określenie elementu... który będzie ważny, bo jeżeli mówimy, że aplikacja powinna wysyłać logi do naszego systemu, to w tym momencie poruszamy temat. to do czego ona wysyła? Bo możemy ustalić tak.

Jeżeli on mały system, mały wolumen, to wysyłajmy do tego naszego systemu docenowego. Jeżeli to jest jakaś, nie wiem, nawet jakaś usługa, nie wiem, jest to będzie jakiś elastik, log i tak dalej, nie bawmy się. Bierzemy sync'a czy jakiegoś writera, który umie komunikować się w naszym protokole, pewnie będzie to oponenty metry protokolowe, albo będzie jakiś tam właściwy protokol do komunikacji z naszym systemem do zbierania logów i tam wysyłamy bezpośrednio. Nie bawimy się z tym. Zabawa zaczyna się właśnie w sytuacji, jak mamy średni wolumen i duży wolumen. Bo w tym momencie wchodzi nam buforowanie, kilka obszarów, buforowanie i batchowanie. O co chodzi? Czym się one od siebie różnią? Buforowanie to znaczy, że nasz system do zbierania logów może mieć kawkę, może cię dostępne, więc musimy gdzieś ten bufor mieć.

To właśnie jest problem. Tą rolę mamy dwojaką. My widujemy często właściwie kawkę, bo jak nie wiadomo, co zrobić, to trzeba użyć kawki. Ja bym polecał, może jednak nie do końca, przez tego powodu. Mamy właśnie OpenTelemetry Collector, mamy Grafany Alloy, które umieją uforować, umieją tę rolę spełniać de facto. Kolejny proces to, że mają też mogą batchować, czyli nie wysyłać logów per linie, tylko wysyłamy w tym momencie logi w samych batchach. Zyskujemy oczywiście dużą wydajność i zyskujemy... lepsze utrzymanie, lepszego wykorzystywania i tak dalej. A teraz jeszcze czemu mamy tego Aloja albo OpenTelemetry Collector? Bo możemy w tym momencie wzbogacać te nasze logi. Możemy dodawać labele, pola, które nas interesują i tak dalej, o których czasami ta aplikacja może nie wiedzieć.

Możemy filtrować. I też możemy pilnować, to jest nasze narzędzie z poziomu cat opsów i naszej platformy, gdzie pilnujemy, czy te lobby są dobre i nie dopuszczamy na przykład tego całego bałaganu, który nam się nagle pojawi w naszym systemie do logowania i możemy robić dużo, dużo, dużo wcześniej tak naprawdę. Mamy polityki na przykład na kolektorze, nasi sklep deaf test i wtedy po prostu nie przypuszczamy. Znaczymy, że ktoś użył fatal, a my ustaliliśmy, że ma być pole nazywa się critical, no nie? Poziom. blogów. Śmiejesz się, Łukasz? Ile razy widziałeś ora, gdzie ktoś szukał fatal albo critical? No i jest takie coś, ja wiem, bo to są w tym... Tak, to jest problem. Jak się pali, to ktoś tego ora zapomni dać i nagle części logów nie widać.

Wiem, wiem, inaczej. Ja się z tego śmieję, ale jest to prawdziwy... Szymon, to jest prawdziwy napisane krwią i dupogodzinami oglądania takich przypadków. Albo troubleshooting tego, inaczej. Dla mnie z tym poziomem... albo jeszcze nadawanie jakiegoś własnych custom poziomów. Wiesz, że takie, widziałeś takie rzeczy, że ktoś uważał, że musi mieć swojego płatka śniegu dedykowanego. Moim faworytem było, jaki on miał 15 custom poziomów logów. Piętnaście. Piękna sprawa, po prostu bym powiedział. Dobra. Ustaliliśmy klikacze. Dalej. Jak już zaczęliśmy takie typowe podstawy postaw. Kolejny rzecz. Ustalenie, w jakim formacie jest ta data i w jakim czasie jest ta data.

Doskonale wiesz, że ile razy w sytuacji generalnej, gdzie opitujesz się o logi, jest pytanie, ej, ale logujemy tu w UTC czy w czasie lokalnym? Przecież to jest A najlepiej jest to, jak mamy jeden system lokuje w UTC, a inny w czasie lokalnym. Tak. To są rzeczy drobne. Tu nie będziemy mówić o żadnych rewolucjach, ale to są rzeczy, które jak macie awarię i jest to ułożone, to oszczędzacie naprawdę godzinę czasami. Dobra, więc przyszliśmy dość późno do tego. Musimy ustalić, jakie pola mają znajdować się w systemie do zbierania logów. Niekoniecznie to są pola, które aplikacja robi. Fajnie, gdyby aplikacja logowała jak najwięcej z nich, ale nie muszą.

Prognozuje większość konfliktów. Dobra. Dalsza opcja. Określamy typ. Jak już nauka kasa robi, to określamy, czy to mamy jakieś, powiedzmy, czy to są audytowe. To nie jest zupełnie problem, no bo najlepiej w ogóle te audytowe były w innym strumieniu w ogóle wysyłane. Inaczej filtrowane. Tak, to jest w ogóle... Czy rzecz, z którą się tam można pokłócić, jeżeli zrobimy prawidłowo event sourcing... ... ... ... Tak, ale to też wychodzi na to, że ten log audytowy z tego, co się działo w systemie, też w niektórych miejscach zmian na obiektach mógłby być spokojnie w bazie danych.

Ale nie zawsze jest. Tak to bywa. Czy to jest problem aplikacyjny? Nie, więc bywa. Dalej. Kolejne pole, które w sumie staje się opcjonalne, bo ono jest zależne od tego, jak mamy ułożone, czyli środowisko. Jeżeli mamy system do zbierania logów, parę środowisk, to to pole po prostu omijamy. Nie ma sensu, żeby to pole było przeznaczone. Ewentualnie Szymonu bym dorzucił, jeżeli, tak jak w Logi, mamy ten anty. O, to tak za chwilę w ogóle powiemy, jak to w ogóle podzielić, bo to jest też bardzo, bardzo ważne. Tak, jeżeli nasz system do logowania używa tenantów, to też wtedy to pole staje się opcjonalne. Tak. Kolejne pole to jest service name. I kolejna dyskusja, żeby była... Ci śmiejesz.

pierdoła, cieszy i to też pokazuje widoczność, co jest źródłem prawdy. Dobra, idziemy dalej. Trace ID, Span ID, te dwie rzeczy nie trzeba tłumaczyć, bo chcemy czasami znaleźć wszystkie logi odnośnie Trace'a, czyli całego procesu i logi odnośnie Spana, czyli czynności. Czyli jak popatrzymy sobie, tak, trace właśnie i teraz, bo wrzuciłeś jeszcze parent trace ID i to jest taki problem, który jest, czy my powinniśmy mieć jeden kontekst ID zrobiony na cały taki właśnie request ID, żeby prześledzić cały, czy jak to się powinno ułożyć? No właśnie i teraz dopóźnijmy, bo nie powiedziałem o tym na starcie, z prostego bardzo powodu. To jest trochę opcjonalne. Zależy, jaką mamy granularność tych trace'ów.

Czemu jest na końcu? Bo z reguły coś się rozjeżdża. I tu super ważne. Jeżeli możemy, zamieniamy new line'y, żeby one jednak były w jednej linii, Tylko pomyśl, ale nie mam czytelności. Tak, nie mam czytelności. Ale w sytuacji, jeżeli nie będziemy czegoś udało zrobić i będziemy musieli wypisać ten error na SAT auta, to nam się logi nie rozjeżdżą. Z reguły parsuje per nowa linię. To jest standardowa klasyka. Jak obsłużyć multilina, żeby nie zostało różnie rany? Nie da się. To są godziny, naprawdę, dziesiątki osób o godzin, napisanie jakichś regaksów, które ewokują kolejny przykład, kolejnego new lina. Ja wiem, chciałem powiedzieć, że ludzie będą się kłócić w komentarzach pewnie, bo to jest znane, że w tym zawsze dla... Nie osiągniemy tego generycznie.