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