Mentionsy
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
Szukaj w treści odcinka
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.
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.
To jest, Szymon, ja bym to podkreślił, że jest tutaj prawo Conwaya, które jest też dla Kubernetesa, że struktura namespace'ów, klastrów na Kubernetesie odzwierciedla strukturę komunikacyjną w firmie i struktura tenantów też to będzie odzwierciedlała.
Ostatnie odcinki
-
Short #76: Human in the Loop, OpenAI Postgres n...
20.02.2026 07:00
-
PoC agentowe: Kill, Iterate, Scale
13.02.2026 07:00
-
Chmura w małej skali
06.02.2026 07:00
-
Nasz "Vibe working" 2026
30.01.2026 07:00
-
"Chmura at scale" - Brownfield
23.01.2026 07:00
-
Intro "Chmura at scale" | #Discord
16.01.2026 07:00
-
Short #75: IBM kupuje Confluent, Skills vs Agen...
09.01.2026 07:00
-
Jak Łukasz agentów popędza - publikacja pato
19.12.2025 07:00
-
AWS RE:Invent 2025
12.12.2025 07:00
-
Helm vs Kustomize
05.12.2025 07:00