TL;DR:

Branża observability wreszcie realizuje obietnicę narzędzi, które faktycznie diagnozują problemy, nie tylko zbierają dane
Paradoks telemetrii: góry niewykorzystanych danych i jednocześnie brak kluczowych kontekstów do debugowania
Koszt testowania spada do zera dzięki AI, ale zdolność generowania bugów może wyprzedzić ludzkie możliwości ich wychwytywania
Agenty potrzebują weryfikacji przez człowieka, bo brakuje im „kollektywnej pamięci” projektu
AI generuje kod „operacyjnie ślepy” – działa technicznie, ale nie raportuje kontekstu biznesowego
Przyszłość to dynamiczna telemetria na żądanie zamiast prewencyjnego hoardingu wszystkich danych
Połączenie historii kodu z observability to niedoceniana szansa na lepsze debugowanie

Notatki z panelu „Are you ready for agentic observability?”

To są notatki z panelu dyskusyjnego o transformacji observability w erze sztucznej inteligencji. W rozmowie wzięli udział Michele Mancioppi (współzałożyciel Dsyrum, opiekun projektu OpenTelemetry) oraz Thomas Dohmke (współzałożyciel i CTO Multiplayer), którzy od 15-25 lat zajmują się systemami rozproszonymi i observability. Wszystkie przemyślenia i obserwacje w tym artykule pochodzą bezpośrednio od rozmówców. Checklisty, biblioteka promptów oraz kluczowy insight stanowią moją interpretację na podstawie informacji z dyskusji.

Co się zmienia w observability

Michele zauważa, że po raz pierwszy od dekady branża jest gotowa spełnić swoją główną obietnicę. Narzędzia observability wreszcie potrafią naprawdę wskazać, co jest nie tak. To jednak nie jest dla niego najważniejsze.

Prawdziwa rewolucja leży gdzie indziej – w możliwości wyrażania złożonych koncepcji w formie tekstowej, elastycznej, zwięzłej. Michele ujmuje to tak: „Cały ten dashboard mógłby być telegramem”. Zamiast rzucać w użytkowników tysiące pikseli, linii i liczb, można dać im treściwe podsumowanie z opcją pogłębienia na żądanie.

Thomas dodaje perspektywę systemów samonaprawiających się. Dzięki otwartym standardom można zbierać dane w jednym miejscu, przekazywać je agentowi jako kontekst, a agent debuguje i tworzy pull request. Może jeszcze nie automatyczny deployment, ale kierunek jest jasny.

Koniec „brudnej roboty” i powrót do terminala

Dla panelistów największą wartością agentów nie jest samo pisanie kodu, lecz przejęcie najbardziej nużących zadań. Thomas podkreśla, że dzięki AI znika konieczność ręcznego tworzenia boilerplate’u oraz rusztowań projektu. W rezultacie programiści mogą szybciej przejść do rozwiązywania faktycznych problemów biznesowych, zamiast tracić czas na konfigurację.

Co ciekawe, ta technologiczna zmiana przywraca do łask pracę w terminalu. Zamiast polegać wyłącznie na graficznych interfejsach IDE, agenty umożliwiają efektywne działanie z poziomu wiersza poleceń, tmuxa czy Gita.

Michele zwraca uwagę na aspekt wielozadaniowości. Ponieważ dużą część dnia spędza na spotkaniach, wykorzystuje AI do pracy równoległej – agent w tle pisze i testuje fragmenty kodu, które człowiek weryfikuje w przerwach między rozmowami. Rola programisty przesuwa się więc z twórcy na recenzenta.

Paradoks telemetrii – za dużo i za mało jednocześnie

Michele diagnozuje kluczowy problem branży: „Nasze stogi siana stały się naprawdę ogromne”. Rewolucja OpenTelemetry przyniosła coś dobrego – telemetria stała się powszechna. Efekt uboczny jest jednak bolesny. Ludzie gromadzą dane niczym Smaug złoto. Metryki nigdy nie odpytywane, ślady nigdy nie przeglądane, logi nigdy nie czytane. Co więcej, AI tonie w tym równie głęboko jak ludzie.

Michele pokazywał na jednej z konferencji, że mniej niż 1% logów to faktycznie error i fatal, a cała reszta to prawdopodobnie strata pieniędzy. Szczególnie jeśli są wysyłane cały czas.

Z drugiej strony Thomas wskazuje na przeciwny problem – jako deweloper brakuje mu danych do debugowania. Potrzebuje requestów, odpowiedzi, nagłówków, danych skorelowanych z sesją. Bug dzieje się konkretnemu użytkownikowi po konkretnej sekwencji działań, a dostaje wielki bucket bez kontekstu.

Według Thomasa typowe „wielkie kubły danych” są bezużyteczne przy debugowaniu konkretnego zgłoszenia. Aby agent AI mógł zadziałać w modelu self-healing, potrzebuje precyzyjnego kontekstu: nagłówków, pełnych treści zapytań i korelacji sesji. Bez tych szczegółów maszyna zgaduje tak samo jak człowiek.

Ślady rozproszone tego nie dają. Sprawdzają się świetnie dla ogólnego obrazu systemu, lecz okazują się bezużyteczne dla konkretnego buga.

Michele zgadza się częściowo. Tak, brakuje niektórych źródeł danych. Większość podejść do tracingu unika przechwytywania requestów i odpowiedzi z powodów bezpieczeństwa. Wyjątek stanowi observability dla serverless, gdzie nie ma wyboru – bez możliwości wpiąć debuggera potrzebne są dane.

Dodaje również, że obecny przemysł wyrósł na wykorzystywaniu ludzi, którzy generują za dużo telemetrii zamiast generować właściwą. Dlatego potrzeba kogoś, kto zmieni zasady gry i zacznie cenić sygnał oraz jakość zamiast wielkości stogu siana.

Problem architektoniczny tail sampling

Michele wyjaśnia, co frustruje wielu inżynierów. Tail sampling brzmi jak święty graal – podejmij decyzję o zapisaniu śladu po tym, jak zobaczysz całość. Jeśli był błąd, zachowaj. Jeśli wszystko ok, wyrzuć.

Problem? Kompletnie nie pasuje do architektury OpenTelemetry Collector. Jak Michele to ujmuje: tail sampling to decyzja odroczona w czasie, scentralizowana. Collector to komponent strumieniowy, rozproszony, działający na żywo. Te dwie rzeczy naprawdę nie pasują do siebie.

Przypomina też historię: distributed tracing narodził się faktycznie jako sygnał debugowania na żądanie. Oryginalny paper Dapper Tracer miał poziomy samplingu epickie – 1 na 10,000. Narzędzie nie było stworzone do ciągłego zbierania wszystkiego, lecz do włączania gdy coś poszło nie tak.

Testing w erze AI – TDD wraca przez tylne drzwi

Thomas przyznaje wprost: w produkcji jest teraz więcej bugów przez AI. Kod wygląda przekonująco, jednak psuje się w nieoczekiwany sposób. Iterator zwraca więcej wyników niż zakładano – rzeczy, które deweloper wychwycił przy pisaniu, bo myślałby „a co jeśli…”.

Mimo to jest druga strona medalu. Koszt testowania spada do zera. Szczególnie testy jednostkowe – praktycznie darmowe. Testy integracyjne również stają się coraz tańsze. Wcześniej nikt tego nie robił, bo to ogromny pain.

Michele zauważa jednak, że zdolność AI do generowania kodu (i ukrytych w nim błędów) może wkrótce wyprzedzić ludzkie możliwości testowania systemów. To realne ryzyko, które trzeba mieć na uwadze.

Thomas śmieje się, że nienawidził TDD i nigdy tak nie pracował. Teraz jednak zmusza swoje agenty kodujące do pracy w TDD. Może teraz wziąć kredyt za to.

Michele dodaje kluczową uwagę o „kollektywnej pamięci”. Agent może sprawdzić kod debuggerem teraz, jednak agenty nie mają pamięci między sesjami. Nikt nie zapamięta za miesiąc, że ta funkcja musiała zachowywać się w określony sposób. Dlatego testy są niezbędne – jako dokumentacja oczekiwań.

Może nie pamiętasz co robił twój kod wczoraj, ale przynajmniej testy pamiętają.

Tool calling – właściwa magia zaczyna się tutaj

Michele buduje właśnie system, gdzie operator może połączyć się z klastrem Kubernetes i zebrać dane na żądanie. Dane, które byłyby za drogie do ciągłego zbierania i statystycznie bezużyteczne przez 99.999% czasu.

Dlaczego stogi danych rosną? Bo zbieramy wszystko prewencyjnie. Nie potrafimy zebrać telemetrii na żądanie w czasie rzeczywistym. Agenty to zmieniają.

Michele ma wizję przyszłości: w świecie, gdzie AI faktycznie operuje aplikacjami i złożonymi systemami, większość zbierania telemetrii będzie działać na żywo. Będzie tylko tyle danych, by robić wartości bazowe, a potem większość rzeczy będzie włączana i wyłączana. Bo czas reakcji maszyn będzie rzędami wielkości lepszy niż ludzi. Maszyny są dostępne zawsze, o ile jest moc obliczeniowa. My utykamy w spotkaniach i potrzebujemy pagera, żeby nas wyciągnąć.

Thomas maluje wizję przyszłości debugowania, gdzie sama rozmowa z chatbotem o kodzie przestaje wystarczać. Przyszłość należy do wywołań narzędzi (tool use), czyli agentów bezpośrednio ingerujących w środowisko deweloperskie:

Otrzymuje zgłoszenie błędu wraz z pełnym kontekstem sesji
Samodzielnie uruchamia kod z włączonym debuggerem
Ustawia breakpointy, sprawdza stan pamięci i zmiennych
Weryfikuje poprawkę, uruchamiając testy

Czasami musisz zobaczyć tę instrukcję if, na którą gapisz się od 30 minut. Twój mózg zamienia miejscami rzeczy, jednak agent może ustawić breakpoint, przejść przez kod, sprawdzić faktyczny stan aplikacji i zweryfikować czy poprawka działa.

Michele przypomina: to nie zastępuje testów. Problem w tym, że agenty nie pamiętają. Sprawdzisz teraz, ale przy następnej zmianie kodu nikt nie będzie pamiętał, co miało działać.

Kiedy AI zacznie generować własną instrumentację

Michele porusza coś, co go najbardziej ekscytuje – a czego jeszcze nie widział. Modele AI/LLM są trenowane na kodzie, który ludzie piszą, szczególnie publicznym, a tam jest bardzo mało niestandardowej telemetrii.

Ludzie nie piszą niestandardowej instrumentacji w projektach open source. Dodają podstawowe logi, może jakieś metryki, jednak kontekst biznesowy pojawia się rzadko. W efekcie AI tworzy funkcje, które działają technicznie, ale nie raportują tego, co robią w kontekście biznesowym.

Michele chciałby zobaczyć moment, gdy aplikacja będzie generowana z sensowną, niestandardową instrumentacją, która faktycznie przechwytuje kontekst biznesowy. To będzie przełomowe.

Zmienia to grę, bo teraz AI kopiuje nasze złe nawyki. Co jednak jeśli zacznie robić to lepiej niż my? Automatycznie dodawać śledzenie transakcji biznesowych, metryki konwersji, kontekst użytkownika? Thomas natychmiast łapie: to byłoby rewolucyjne.

Co musi się zmienić w observability stack

Thomas jest bezkompromisowy: potrzebujemy lepszych danych, nie więcej danych. Obecnie są wielkie przełączniki jak sampling. Albo zbierasz wszystko, albo rzucasz monetą. To nie działa.

Potrzebne są requesty, odpowiedzi i nagłówki dla pewnych problemów, lecz nie dla wszystkiego. Kontrola musi być bardziej granularna:

Debug logging dla konkretnej sesji użytkownika, nie dla wszystkich
Eskalacja zbierania danych dla sesji, w której wystąpił błąd
Połączenie w czasie rzeczywistym z aplikacjami
Możliwość nie wysyłania danych wcale, jeśli wiesz, że zostaną odrzucone

Michele proponuje inną perspektywę. Problem nie leży w zbieraniu, lecz w przechowywaniu. Stogi są problemem tylko gdy zaczynasz je piętrzyć.

Każda metryka istnieje, bo ktoś kiedyś potrzebował tych danych. Nikt nie tworzy metryk dla zabawy. Problem? Statystycznie są bezużyteczne. Przydają się okazjonalnie.

AI mogłoby włączać i wyłączać odrzucanie telemetrii blisko aplikacji. Gdy Java ma skoki opóźnień odpowiedzi, wszyscy myślą o garbage collection. Można wtedy „otworzyć tamę” i zebrać dane o GC na żądanie.

Albo inne podejście: telemetria użyteczna to ta, którą użytkownicy faktycznie przeglądają w dashboardach. Stworzyłeś dashboard? Okej. Jednak czy go otwierasz? To najprawdziwsza deklaracja użyteczności.

Thomas zgadza się, dodaje jednak: to wymaga wysłania i pozyskania dużej ilości danych. A potem płacisz za to. Lepiej nie wysyłać danych wcale, jeśli wiesz, że zostaną odrzucone.

Michele przyznaje rację – gdzie ma być „kran” zależy od kontekstu. W aplikacjach mobilnych musisz filtrować blisko użytkownika końcowego, bo przepustowość kosztuje, natomiast kolektor blisko aplikacji też ma sens dla większości przypadków.

„Shift left” vs rzeczywistość deweloperów

Michele ma ciekawe zdanie o popularnym haśle shift left – przesuwaniu odpowiedzialności za observability na deweloperów.

Według niego większość deweloperów ma już wyzwanie sprawić, by ich obecne systemy działały, bez dodawania większej odpowiedzialności i obciążenia poznawczego. To nie oznacza, że deweloperzy nie powinni rozumieć observability, jednak bardziej chodzi o to, by narzędzia były lepsze w generowaniu użytecznej telemetrii automatycznie. Nie każdy musi być ekspertem.

Małżeństwo Git i observability – niedoceniana szansa

Michele zauważa, że rzadko się łączy: historia jak oprogramowanie ewoluuje, zmiany infrastruktury przy wdrożeniu oraz observability. Wszystko istnieje osobno.

Ogromny potencjał leży w połączeniu wersjonowania kodu z observability. Wersja serwisu w OpenTelemetry może odpowiadać konkretnemu commitowi w kodzie, dzięki czemu agenty mogłyby na dużą skalę wnioskować jak zmiany są powiązane.

Thomas natychmiast łapie: to świetny pomysł. Połączyć observability ze zmianami w kodzie przez agenta.

Bug, który widzisz dziś, prawdopodobnie został wprowadzony w ostatnim tygodniu. W jakimś pull requeście. Większość bugów to świeże błędy, nie legacy sprzed lat.

Michele dodaje frustrację: jego agent rzadko zagląda do historii Git. Mówi „tak, zrobiliśmy to trzy dni temu, cofnij”, a agent odpowiada „Och, odkryłem ten problem!”. Brakuje im pamięci. Dla nich to zawsze dzień pierwszy. Zawsze nowy stażysta.

Koniec statycznych dashboardów?

Michele mówi wprost: ludzie pytają go czy statyczne dashboardy są martwe. Odpowiedź: nie. Jednak ich użyteczność będzie ograniczona do węższych przypadków.

Dlaczego? Bo gdy można polegać na AI tworzącym dashboardy w czasie rzeczywistym wyjaśniające sytuację, statyczne są potrzebne głównie do sprawdzania stabilnych metryk. Ile zarabiamy? Statyczne KPI. Wszystko inne? Na żądanie.

Zamiast wpychać w twarze użytkowników statyczne dashboardy przepełnione informacją, masz analizę sytuacji jeszcze przed jej wystąpieniem. AI doskonale konsumuje co się dzieje i co z tym zrobić. Buduje dashboard w czasie rzeczywistym dla konkretnej sytuacji.

Thomas w pełni się zgadza.

Weryfikacja – ostatnia bariera

Thomas mówi: jeszcze nie widział samonaprawiających się systemów w akcji, ale to nadchodzi.

Zbudował mały system, który monitorował czy model GPU używa przyspieszonej atencji. Nie mógł debugować – czarna skrzynka. Zapytał model. Ten zaczął eksplorować: rozmiar pamięci, użycie CPU, jeszcze jeden parametr. Na podstawie tych trzech wymiarów wyinferował, że SDPA nie jest włączone.

Teraz to mały gotowy prompt. Odpala go gdy podejrzewa problem. „Nie, w porządku”. Albo „Tak, znowu się dzieje”.

Następny krok? Automatyczna naprawa. Jednak weryfikacja trzyma nas w tyle. Nikt nie jest gotowy na automatyczne wdrażanie pull requestów. Są halucynacje, brakuje lepszych narzędzi weryfikacji.

Thomas cytuje starą terapeutkę: „Żadnego słowa na P”. Powinien. Ale powinniśmy być w stanie wypuścić to wszystko. Są testy funkcjonalne, świetne testy jednostkowe (teraz darmowe). Powinno działać.

A jednak wciąż potrzebujemy człowieka w pętli. Na jak długo? Nikt nie jest pewien.

Biblioteka promptów z panelu

Uczestnicy dyskusji podzielili się konkretnymi schematami poleceń, które wydają swoim agentom w procesie debugowania. Poniżej znajdują się praktyczne instrukcje wraz z wyjaśnieniem ich zastosowania.

1. Weryfikacja intencji poprawki

Kiedy stosować: Gdy agent dokonał poprawki w kodzie i chcemy zweryfikować, czy rozumie skutki tej zmiany w aplikacji, zamiast polegać tylko na braku błędów kompilacji.

Prompt:

"Here is the issue, I'm changing this with the expectation that with these inputs,

this path and this state of the application will exist at the end of this function 
that I just fixed."

2. Generowanie testów z sesji

Kiedy stosować: Gdy dysponujemy nagraną sesją z błędem (dane observability) i chcemy, aby agent na jej podstawie stworzył testy regresyjne.

Prompt:

"Here's a session, here's what happened. Write some unit tests.

Let's see whether it works all the time."

3. Szybki health check

Kiedy stosować: Do cyklicznego sprawdzania specyficznych parametrów systemu, które są trudne do ręcznego debugowania (np. wykorzystanie akceleracji GPU), używając stałego, gotowego zapytania.

Prompt:

"Is this happening?"

[w kontekście wcześniej zdefiniowanych parametrów pamięci i CPU]

4. Dodawanie telemetrii biznesowej

Kiedy stosować: Gdy AI wygenerowało działający kod, ale chcesz upewnić się, że będzie możliwy do monitorowania w produkcji.

Prompt:

"Teraz dodaj do tego kodu dedykowaną telemetrię, która pozwoli mi zrozumieć

biznesowy kontekst tej operacji w logach."

Checklista: Przygotuj observability na erę AI

Na podstawie dyskusji Michele i Thomasa, warto rozważyć następujące kroki:

Dane i telemetria:

Przejrzyj które metryki faktycznie używasz w dashboardach (99% prawdopodobnie nigdy nie jest oglądane)
Zidentyfikuj brakujące konteksty debugowania (requesty, odpowiedzi, dane sesji)
Postaw kolektor blisko aplikacji do filtrowania przed wysłaniem
Rozważ zbieranie na żądanie zamiast prewencyjnego gromadzenia wszystkiego
Sprawdź ile Twoich logów to error/fatal vs info/debug – czy płacisz za szum?

Testowanie:

Wykorzystaj AI do pisania testów jednostkowych (koszt spadł do zera)
Traktuj testy jako dokumentację oczekiwań (agenty nie mają pamięci)
Rozważ wymuszenie TDD dla agentów kodujących
Nie polegaj wyłącznie na debuggerze – następny deweloper (lub agent) nie będzie pamiętał kontekstu

Integracje:

Połącz observability z historią Git (wersja serwisu → hash commitu)
Skonfiguruj wywołania narzędzi dla agentów (dostęp do klastrów, debuggerów)
Przygotuj eskalację zbierania danych dla konkretnych sesji/bugów
Eksperymentuj z instrumentacją biznesową generowaną przez AI

Workflow:

Zachowaj człowieka w pętli dla weryfikacji (na razie)
Przygotuj się na dynamiczne dashboardy generowane na żądanie
Ogranicz statyczne dashboardy do stabilnych KPI
Przestań cenić „wielkość stogu” – zacznij cenić jakość sygnału

Blokady autonomii do monitorowania:

Brak „pamięci zbiorowej” – agenty nie znają historii projektu ani kontekstu decyzji
Halucynacje weryfikacji – kod wygląda poprawnie, ale psuje się w przypadkach brzegowych
Brak integracji z historią Git – agenty mogą cofać celowe modyfikacje

Kluczowe wnioski

Według Michele i Thomasa observability stoi przed największą transformacją od dekady. Nie chodzi o kolejne dashboardy czy metryki, lecz o fundamentalną zmianę podejścia: od prewencyjnego gromadzenia wszystkiego do inteligentnego zbierania tylko tego, co potrzebne, dokładnie wtedy gdy jest potrzebne.

Połączenie telemetrii z historią kodu, dynamiczne włączanie instrumentacji, wywoływanie narzędzi przez agenty, AI generujące własną sensowną instrumentację – to wszystko już nie jest science fiction. To dzieje się teraz.

Zostają jednak dwie bariery. Pierwsza: weryfikacja. Agentom brakuje pamięci, dlatego człowiek w pętli wciąż jest potrzebny. Na jak długo? Michele i Thomas się zgadzają – niedługo. Może miesiące, może rok-dwa.

Druga: trzeba przestać cenić wielkość stogu siana. Obecny model biznesowy observability nagradza zbieranie ogromnych ilości danych. Potrzeba kogoś, kto zmieni zasady gry i zacznie cenić jakość sygnału zamiast ilości terabajtów.

Kluczowy insight

Pułapka niemego kodu AI

Standardowo myślimy: Skoro AI generuje poprawny, działający kod funkcjonalny, to zadanie jest wykonane i możemy wdrażać rozwiązanie.

W praktyce okazuje się, że: AI generuje kod „operacyjnie ślepy”. Modele LLM uczone są na publicznym kodzie Open Source, z którego przed publikacją zazwyczaj usuwa się specyficzną logikę biznesową i metryki. W efekcie AI tworzy funkcje, które działają technicznie, ale nie raportują tego, co robią w kontekście biznesowym.

Dlaczego to jest istotne: Wdrażasz do produkcji „czarne skrzynki”, które przy pierwszej awarii będą niemożliwe do zdiagnozowania bez ręcznej reimplementacji. To w dużej mierze neguje zysk czasu wynikający z użycia AI.

Test na jutro: Następnym razem, gdy poprosisz AI o wygenerowanie funkcji, nie akceptuj pierwszego wyniku. Wpisz prompt: „Teraz dodaj do tego kodu dedykowaną telemetrię, która pozwoli mi zrozumieć biznesowy kontekst tej operacji w logach”. Porównaj czytelność operacyjną obu wyników.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je w udostępnionym dokumencie z transkryptem panelu „Are you ready for agentic observability?„

Tag: Tool Use

Observability w erze AI – koniec gromadzenia śmieci, początek inteligentnego zbierania danych #EN374