Mentionsy

I do tego wszystkiego na koniec część na temat wybierania stosu aplikacyjnego, technologicznego i odpowiedzenie sobie na pytanie, czy Kubernetes i ekosystem CNCF-u to lekarstwo na wszystkie nasze potrzeby, jeżeli będziemy budować aplikacje.

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...

Czyli sposób, żeby zobaczyć jak Kubernetes działa pod spodem, jeżeli chodzi o infrastrukturę, logikę komponentów, ich komunikację.

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.

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.

Drugi element to jest to, że okej, mamy logi i właściwie nie umiemy z nich korzystać, jak naprawdę.

przypomniał, zrozumiał i wyszukał logi, które mogą pomóc w tym pakowaniu odpłynie sekcji.

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.

Logi na przykład z naszego ingresa, albo z naszego Mongo, albo z takich typowo

Ja bym to powiedział tak, ci, którzy chcieli wdrożyć i jeszcze nie przekazali do platformy, ci na te logi patrzą.

Teraz mamy taki element, który już jest trochę rozmyty, bo to nazywają przez takie logi biznesowe, czyli żeby śledzić zdarzenia 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.

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?

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.

Bo teraz patrzymy z kontekstu tego, jak oglądamy te logi, a nie jak te logi wysyłamy.

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ć.

Mianowicie pogodzenie się z tym, że pewne logi będą małaganem, po prostu. ...

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.

Jak mamy logi strukturyzowane, najlepiej JSONie oszukujmy się.

Niektóre logi będziemy wzbogacali o pewne levely.

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.

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ą.

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.

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.

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.

Bo możemy w tym momencie wzbogacać te nasze logi.

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?

Ewentualnie Szymonu bym dorzucił, jeżeli, tak jak w Logi, mamy ten anty.

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.

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żą.

A potem możemy to już w sytuacji, w której otrzymaliśmy logi, to możemy tam już zwyłanie te new line'y porozbijać i to możemy spokojnie usłyszeć.

To już taka trochę bajka, trochę moja, trochę twoja, czyli ustalamy jawnie, że bo jestem komunikacją, z czego zbieramy w ogóle te logi.

I tak wygląda menadżer, który mówi, że chce mieć wszystkie logi, żeby potem troubleshootować.

Okej, czyli chcesz w takim razie logi systemowe z Windowsa, jak zeszła ta loga z Windowsa.

Logi wszystkie, to naprawdę jest bardzo dużo logów, do których z reguły nie mamy żadnej potrzeby użycia.

Zbieramy obowiązek, to są logi z aplikacji.

Z drugiej strony logi z bazy, no i tutaj będzie taka... W większości przypadków logi na przykład, wiesz, z dużej części infry, na przykład...

Jeżeli mówimy o Kubernetesie, to wiadomo, logi systemowe z node'ów, co tam się w ogóle dzieje i jak one się zachowują, to też się przydaje, żeby też weźmieć jakieś rzeczy.

I dlatego się między innymi nie piszemy na terminal, bo terminal jest zapisany w synchronicznym i można go bardzo zwolnić, ale żeby ustalony, żeby deweloperze, nie ma to pomysłu, że nieraz wysyła te logiki, powiedzmy, po Open Terminal Protocol czy czymkolwiek innym i czeka na ten zapis.

Ona też musi mieć retry, powtarzanie, też musi mieć jakieś buforowanie i raportowanie też, wpisywanie, że nie mogła się skomunikować i jak się nie mogła skomunikować, to te logi wypisuje na SNDA o tym razie czego.

Żeby nie było tylko, że aplikacja zarobuje, a nie mogę połączyć się z OpenTelemetry kolektorem, ale te logi to tam właściwie trudno się mówi, no nie?

Odzyskanie tych logów i potem odzyskanie też paru terabajtów z arkera też będzie nas kosztowało i to dużo będzie mało przyjemne, więc też podzielmy, które logi trzymamy na dłuższy czas i trzymamy nam tylko te niezbędne, które musimy trzymać.

My potrzebujemy logów dobrej jakości, a nie po prostu wszystkiego, co ktokolwiek wpadł na pomysł, żeby kiedykolwiek... Czasem mam wrażenie, że logi przypominają nasze troubleshooting dupą w niektórych momentach.

Druga rzecz to jest ustalmy, gdzie te logi są wysyłane, czyli że po pierwsze to wysyła aplikacja i czy wysyła do systemu logowania, czy wysyła do czegoś po drodze.