Standaryzacja logów - nudne rzeczy, które trzeba ustalić
“Moim faworytem była firma z 15 poziomami logów. Piętnaście.” Szymon opisuje chaos w organizacjach: zespoły szukają logów w czterech różnych miejscach, Elastic pożera budżety, a deweloperzy dodają logi “na czuja” bez strategii. A Łukasz doprecyzowuje problem: “Logi mają wredną tendencję - tylko je dodajemy, nigdy nie usuwamy.” Popularne “rozwiązania”? Sampling? “Zawsze będzie złem, bo odsampluje to, czego właśnie potrzebujecie.” Stdout jako standard? “Absolutne zło i ostateczność.” A wewnętrzne dyskusje o nazewnictwie? “Jeżeli macie dyskusję w firmie jak coś nazwać, oznacza to, że pierdolnik będzie kontynuowany.” Jak z tego wyjść? Rozwiązanie zaczyna się od fundamentów: structured logging w JSON, Open Telemetry jako standard (koniec kłótni o “fatal” vs “critical”), Open Telemetry Collector do wzbogacania i filtrowania. Plus dokument definiujący pola, retencja zamiast samplingu, tenanty zamiast jednego indeksu, budżety zamiast bezładnego logowania wszystkiego. Czy twoja organizacja tonie w logach, których nikt nie umie czytać? Sprawdź, zanim ktoś doda szesnasty poziom logowania. ⚠️ A teraz nie ma co się obijać! 👉 Wpadajcie na naszego Discorda: https://discord.gg/78zPcEaP22 ! 🔥Tam możecie się z nami pokłócić o przyspieszanie SQL-a, podyskutować o naiwnych nadziejach na AI albo po prostu podzielić się swoimi IT-owymi przemyśleniami. 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 - Nasze sociale i linki - Materiały do odcinka - Pato szkolenia
O! rady. Więc jeżeli możemy, pozbądźmy się tego po prostu. To jest najlepszy scenariusz. 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ć. Dobra. Jak już mamy pola, to... Przekląłbym, ale nie będziemy tego robili. Ustalamy sobie, składamy sobie repo, gdzie pisujemy, które pole, co znaczy. Żeby to nie było ustalone na borde tu i teraz, że tak powiem. I tam ma być jasna decyzja, jak to się zmieni i tak dalej. To jest szczególnie tyle ważne, że te pola będą się zmieniały. Będą dorzuciły nam pola konkretne, biznesowe. Niektóre z poły będą miały konkretne swoje osobne pola. Czemu? I to powiem za chwilę. Więc to musi być dokumentalne, które pole, co znaczy.
Dokładnie tak. I to będzie już, to tak, z mojej działki patrząc się na to, to też jest problem, bo tak jak rzuciłeś sobie, tak jak zapisałeś przykłady, dobra. Z ingres kontrolerów jest to must have, żeby potem też tam dojść, coś troubleshootować. 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... Jedyna, jaką korelację złapiesz, jakbyś chciał zrobić mega kwerendę, to zauważ, że twoja piękna strukturyzacja się rozwali w pył. Oczywiście, że tak. Tak i jedyną rzeczą, którą zrobisz, to korelację linijek po czasie. Wiesz co, mi bardziej chodzi o coś innego, że na przykład dowiedzieliśmy się na przykład po czasie, jaka zeszła zaoczenia, jaka z PiSu, że na przykład baza jest, baza na przykład ma, raportuje, że ma opóźnienia w zapisach.
Pokazano wszystkie 2 dopasowania. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Kliknij, aby znaleźć fragmenty, w których pada.