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
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.
Tak, ale dojdziemy sobie do tenantów i rozdzielania tego, bo to jest ciekawa sprawa w tym miejscu potem. Tak. Dobra. Mamy tyle. Znowu, z rzeczy małych, drobnych, o których właściwie by się nie pomyślało, to jest formatowanie. Ustalamy. Jest to JSON, jest to UTF i jest to w tej linii. Koniec. Tak, tu nie ma co prowadzić większej dyskusji tak naprawdę. Szczególnie ta jedna linia. Naprawdę, jeżeli możemy, to formatujemy to do jednej linii. To jest prosty replace na jakimś tam tekście, żeby to było w jednym linii. Szczególnie te stacktrace'y. I to naprawdę nam nieraz uratuje życie, jak głównie w sytuacji, jak się aplikacja wywali i będziemy po prostu obsrani. Mówię to bardzo prosto.
Pokazano wszystkie 2 dopasowania. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Kliknij, aby znaleźć fragmenty, w których pada.