OpenTelemetry kontra proprietarne agenty APM: co wybrać?

Jaki problem próbujesz rozwiązać za pomocą APM

Zespoły zwykle wdrażają APM, bo coś już boli: wolne strony, losowe błędy lub awarie, które zajmują za dużo czasu, żeby je zrozumieć. Pierwszy tydzień może wydawać się wygraną. W końcu widzisz ślady, kilka wykresów i schludny ekran „zdrowia usługi”. Potem przychodzi następny incydent i wciąż zajmuje to godziny, alerty dzwonią „na nic”, a ludzie przestają ufać pulpitom.

Przydatna obserwowalność to nie zbieranie więcej danych. To szybkie uzyskiwanie odpowiedzi z wystarczającym kontekstem, żeby podjąć działanie. Dobre rozwiązanie pomaga znaleźć dokładne wadliwe żądanie, zobaczyć, co się zmieniło, i potwierdzić, czy użytkownicy są dotknięci. Również zmniejsza liczbę fałszywych alarmów, dzięki czemu zespół reaguje, gdy to ma znaczenie.

Większość czasu nie idzie na instalację agenta. Idzie na przekształcanie surowych sygnałów w coś niezawodnego: wybieranie, co instrumentować (a co jest szumem), dodawanie spójnych tagów jak środowisko i wersja, budowanie pulpitów pasujących do sposobu myślenia zespołu, strojenie alertów i edukowanie ludzi, jak wygląda „dobrze”.

Tu wybór między OpenTelemetry a proprietarnymi agentami APM staje się rzeczywisty. Agent proprietarny może szybko dać „pierwsze dane”, ale często popycha cię w stronę nazewnictwa, próbkowania i pakowania tego dostawcy. Po miesiącach, gdy dodasz nowy backend, zmienisz chmurę lub sposób obsługi logów, możesz odkryć, że pulpity i alerty zależą od zachowań specyficznych dla dostawcy.

Prosty przykład: budujesz wewnętrzne narzędzie administracyjne i portal klienta. Na początku potrzebujesz głównie widoczności błędów i wolnych endpointów. Później potrzebujesz widoków na poziomie biznesowym, jak nieudane transakcje zakupowe czy problemy z logowaniem według regionu. Jeśli twoje ustawienie nie może ewoluować bez przerabiania instrumentacji i ponownego uczenia się zapytań, płacisz tę cenę w kółko.

Celem nie jest wybór „najlepszego” narzędzia. Celem jest podejście, które utrzymuje debugowanie szybkim, alertowanie spokojnym, a przyszłe zmiany przystępnymi kosztowo.

Szybkie definicje: OpenTelemetry i agenty proprietarne

Kiedy ludzie porównują OpenTelemetry i proprietarne agenty APM, porównują dwie różne idee: wspólny standard zbierania danych obserwowalności kontra zapakowany, należący do dostawcy stos monitoringu.

OpenTelemetry (często skracane do OTel) to otwarty standard i zestaw narzędzi do generowania i wysyłania danych telemetrycznych. Obejmuje trzy podstawowe sygnały: ślady (co się działo w usługach), metryki (jak system zachowuje się w czasie) i logi (co system powiedział w danym momencie). Kluczowe jest to, że OpenTelemetry nie jest jednym dostawcą monitoringu. To wspólny sposób generowania i przesyłania sygnałów, dzięki któremu możesz wybrać, gdzie one trafią.

Proprietarny agent APM to biblioteka lub proces specyficzny dla dostawcy, który instalujesz w aplikacji (lub na hoście). Zbiera dane w formacie, którego oczekuje dostawca, i zwykle działa najlepiej, gdy używasz też backendu, pulpitów i alertowania tego dostawcy.

Kolektory, bramy i backendy (prosto)

Większość potoków telemetrycznych ma trzy części:

• Instrumentacja: kod lub agent, który tworzy ślady, metryki i logi.
• Kolektor (lub brama): pośrednia usługa, która odbiera sygnały, pakuje je, filtruje i przekazuje dalej.
• Backend: miejsce, gdzie dane są przechowywane, zapytywane i przekształcane w pulpity i alerty.

W przypadku OpenTelemetry kolektor jest wspólny, bo pozwala zmienić backendy później bez zmiany kodu aplikacji. W agentach proprietarnych rola kolektora może być zintegrowana z agentem, albo dane mogą iść bezpośrednio do backendu dostawcy.

Co naprawdę oznacza „instrumentacja”?

Instrumentacja to sposób, w jaki twoje oprogramowanie raportuje, co robi.

Dla backendów zwykle oznacza to włączenie SDK lub auto-instrumentacji i nazwanie kluczowych spanii (jak „checkout” lub „login”). Dla aplikacji webowych może to obejmować ładowania stron, żądania frontendu i akcje użytkownika (z zachowaniem prywatności). Dla aplikacji mobilnych to często wolne ekrany, wywołania sieciowe i awarie.

Jeśli budujesz aplikacje na platformie takiej jak AppMaster (która generuje backendy w Go, aplikacje webowe Vue3 i mobilne w Kotlin/SwiftUI), te same decyzje nadal obowiązują. Spędzisz mniej czasu na szablonach, a więcej na uzgadnianiu spójnego nazewnictwa, wybieraniu istotnych zdarzeń i routingu danych do wybranego backendu.

Zależność od dostawcy: jak to wygląda w praktyce

Lock-in zwykle nie polega na tym, czy możesz odinstalować agenta. Chodzi o wszystko, co wokół niego zbudowałeś: pulpity, alerty, reguły nazewnictwa i sposób, w jaki zespół bada incydenty.

Gdzie lock-in pojawia się na co dzień

Pierwszą pułapką jest przenośność danych. Nawet jeśli możesz eksportować surowe logi czy ślady, przeniesienie miesięcznej historii i zachowanie użytecznych pulpitów jest trudne. Narzędzia proprietarne często przechowują dane w niestandardowym modelu, a pulpity polegają na języku zapytań dostawcy, widgetach lub „magicznych” polach. Możesz zachować zrzuty ekranu, ale tracisz działające pulpity.

Drugą pułapką jest sprzężenie w kodzie i konfiguracji. OpenTelemetry też może tworzyć sprzężenia, jeśli polegasz na eksportach specyficznych dla dostawcy i metadanych, ale agenty proprietarne często idą dalej z niestandardowymi API do błędów, sesji użytkownika, RUM czy dodatków do baz danych. Im więcej wywołań tych API w kodzie aplikacji, tym bardziej zmiana później będzie refaktorem.

Cennik też może tworzyć lock-in. Zmiana pakietowania, opłaty za wysoką kardynalność czy różne stawki za ślady vs logi mogą podnieść koszty w momencie, gdy użycie rośnie. Jeśli reagowanie na incydenty zależy od UI dostawcy, negocjacje stają się trudniejsze.

Zgodność i governance też mają znaczenie. Musisz mieć jasne odpowiedzi, gdzie dane idą, jak długo są przechowywane i jak traktowane są pola wrażliwe. Staje się to pilne przy multi-cloud lub surowych wymaganiach regionalnych.

Znaki, że utknąłeś:

• Pulpity i alerty nie dają się eksportować w formacie wielokrotnego użytku
• Kod aplikacji używa wywołań SDK tylko dla jednego dostawcy w kluczowych miejscach
• Zespół polega na polach proprietarnych, których nie da się odtworzyć gdzie indziej
• Koszty rosną, gdy dodajesz usługi lub ruch wzrasta
• Opcje lokalizacji danych nie pasują do wymogów governance

Strategia wyjścia to głównie wczesna dokumentacja. Zapisz kluczowe SLO, konwencje nazewnictwa i progi alertów. Miej krótką mapę, które sygnały zasilały które alerty. Jeśli kiedykolwiek odejdziesz, chcesz odbudować widoki, a nie przepisać cały system.

Jakość sygnału: porównanie logów, metryk i śladów

Jakość sygnału zależy mniej od narzędzia, a bardziej od spójności. Praktyczna różnica polega na tym, kto ustala zasady: agent dostawcy może dać „wystarczająco dobre” domyślne ustawienia, podczas gdy OpenTelemetry daje kontrolę, ale oczekuje, że zdefiniujesz konwencje.

Logi: struktura i kontekst

Logi wytrzymują presję tylko wtedy, gdy są strukturalne i niosą spójny kontekst. Agenty proprietarne czasem automatycznie wzbogacają logi (nazwa usługi, środowisko, request ID), jeśli korzystasz z ich zestawu logowania. OpenTelemetry może zrobić to samo, ale musisz ustandaryzować pola między usługami.

Dobry standard: każda linia logu zawiera trace ID (i span ID, jeśli to możliwe), plus identyfikatory użytkownika lub najemcy tam, gdzie to właściwe. Jeśli jedna usługa zapisuje JSON, a inna zwykły tekst, korelacja staje się zgadywanką.

Metryki: nazewnictwo i kardynalność

Metryki zawodzą cicho. Możesz mieć wiele wykresów i wciąż brakować wymiaru, którego potrzebujesz podczas incydentu. Agenty dostawców często dostarczają gotowe metryki z stabilnymi nazwami i sensownymi etykietami. Z OpenTelemetry możesz osiągnąć tę samą jakość, ale musisz wymusić nazewnictwo i etykiety między zespołami.

Dwie częste pułapki:

• Etykiety o wysokiej kardynalności (pełne ID użytkownika, e‑maile, ścieżki z osadzonymi ID) które eksplodują koszty i spowalniają zapytania.
• Brakujące wymiary, np. mierzenie latencji bez podziału na endpointy czy zależności.

Ślady: pokrycie, próbkowanie i kompletność

Jakość śledzenia zależy od pokrycia spanów. Auto‑instrumentacja (często mocna w agentach proprietarnych) może szybko uchwycić wiele: żądania webowe, wywołania baz danych, popularne frameworki. OpenTelemetry auto‑instrumentacja też może być dobra, ale nadal możesz potrzebować manualnych spanów, by uchwycić kroki biznesowe.

Próbkowanie to miejsce, gdzie zespoły się zaskakują. Duże próbkowanie oszczędza pieniądze, ale tworzy przerwane historie, w których brak ważnego żądania. Praktyczne podejście to próbkować „normalny” ruch, a utrzymywać wyższe próbkowanie dla błędów i wolnych żądań.

Korelacja między usługami to prawdziwy test: czy możesz z alertu przejść do dokładnego śladu i logów dla tego samego żądania? To działa tylko wtedy, gdy nagłówki propagacji są spójne i każda usługa je honoruje.

Jeśli chcesz lepszych sygnałów, zacznij od lepszych konwencji:

• Standardowe pola logów (trace_id, service, env, request_id)
• Nazwy metryk i dozwolone etykiety (oraz lista zabronionych etykiet wysokiej kardynalności)
• Minimalna polityka śledzenia (co musi być śledzone i jak próbkowanie zmienia się dla błędów)
• Spójne nazwy usług we wszystkich środowiskach
• Plan ręcznych spanów w kluczowych przepływach biznesowych

Wysiłek i utrzymanie: ukryta część decyzji

Zespoły często najpierw porównują funkcje, a prawdziwy koszt odczuwają miesiące później: kto utrzymuje instrumentację czystą, kto naprawia zepsute pulpity i jak szybko otrzymujesz odpowiedzi po zmianach w systemie.

Czas do pierwszej wartości często faworyzuje agentów proprietarnych. Instalujesz jeden agent i masz gotowe pulpity i alerty, które wyglądają dobrze od pierwszego dnia. OpenTelemetry może być równie potężne, ale wczesny sukces zależy od posiadania backendu do przechowywania i oglądania telemetrii oraz sensownych domyślnych nazw i tagów.

Instrumentacja rzadko jest w 100% automatyczna w obu podejściach. Auto‑instrumentacja pokrywa popularne frameworki, ale luki pojawiają się szybko: wewnętrzne kolejki, niestandardowe middleware, zadania tła i kroki specyficzne dla biznesu. Najbardziej użyteczna telemetria zazwyczaj pochodzi z niewielkiej ilości pracy manualnej: dodania spanów wokół kluczowych przepływów (checkout, tworzenie zgłoszeń, generowanie raportów) i zapisywania właściwych atrybutów.

Nazewnictwo usług i atrybuty decydują o tym, czy pulpity są użyteczne. Jeśli jedna usługa nazywa się api, druga api-service, a trzecia backend-prod, każdy wykres staje się łamigłówką. Ten sam problem pojawia się z tagami środowiska, regionu i wersji.

Praktyczne minimum nazewnictwa:

• Wybierz jedną stabilną nazwę usługi na jednostkę deployowalną
• Ustandaryzuj environment (prod, staging, dev) i version
• Trzymaj wartości wysokiej kardynalności (jak ID użytkownika) poza etykietami metryk
• Używaj spójnych pól błędów (type, message, status)

Różni się też narzut operacyjny. OpenTelemetry często oznacza uruchamianie i aktualizowanie kolektorów, strojenie próbkowania i rozwiązywanie problemów z utraconymi sygnałami. Agenty proprietarne redukują część tego setupu, ale i tak zarządzasz aktualizacjami agentów, narzutem ich wydajności i specyfiką platformy.

Planuj też rotację zespołu. Najlepszy wybór to ten, który zespół potrafi utrzymać po odejściu oryginalnego opiekuna. Jeśli budujesz aplikacje na platformie takiej jak AppMaster, warto udokumentować jeden standard instrumentacji, żeby każda nowa aplikacja stosowała te same konwencje.

Krok po kroku: jak ocenić obie opcje w twoim systemie

Nie instrumentuj wszystkiego od razu. Utoniesz w danych, zanim cokolwiek się nauczysz. Uczciwe porównanie zaczyna się od małego, realnego wycinka systemu, który odpowiada temu, jak użytkownicy doświadczają problemów.

Wybierz jedną lub dwie krytyczne ścieżki użytkownika, które są ważne dla biznesu i łatwe do rozpoznania, gdy się psują, np. „użytkownik loguje się i ładuje pulpit” lub „checkout kończy się i wysyłany jest email z potwierdzeniem”. Te przepływy przecinają wiele usług i dają wyraźne sygnały sukcesu i porażki.

Zanim zaczniesz zbierać więcej danych, uzgodnij podstawową mapę usług i zasady nazewnictwa. Zdecyduj, co liczy się jako usługa, jak ją nazywasz (przyjazne dla ludzi, stabilne nazwy) i jak separujesz środowiska (prod vs staging). Ta jednorazowa dyscyplina zapobiega temu, że to samo pojawi się pod pięcioma różnymi nazwami.

Użyj minimalnego zestawu atrybutów, aby móc filtrować i łączyć zdarzenia bez nadmiernych kosztów: env, version, tenant (jeśli multi‑tenant) oraz request ID (lub trace ID), który możesz skopiować z błędu i śledzić end-to-end.

Praktyczny plan pilotażowy (1–2 tygodnie)

• Instrumentuj 1–2 ścieżki end-to-end (frontend, API, baza danych i 1–2 kluczowe integracje).
• Wymuś zasady nazewnictwa dla nazw usług, endpointów i kluczowych operacji.
• Zacznij od minimalnych atrybutów: env, version, tenant i request/trace ID.
• Ustal plan próbkowania: zachowuj błędy i wolne żądania częściej; próbkowanie dla ruchu normalnego.
• Mierz dwie rzeczy: czas do diagnozy i hałas alertów (alerty, które nie były przydatne).

Jeśli eksportujesz i uruchamiasz wygenerowany kod (na przykład backend w Go i aplikację webową z AppMaster), traktuj go jak każdą inną aplikację w pilocie. Chodzi nie o perfekcyjne pokrycie, lecz o to, które podejście pozwala najszybciej przejść od „coś jest nie tak” do „oto wadliwy krok” przy najmniejszym ciągłym wysiłku.

Uzyskiwanie użytecznych pulpitów i alertów (bez nieskończnego strojenia)

Pulpity i alerty zawodzą, gdy nie odpowiadają na pytania zadawane podczas incydentu. Zacznij od małego zestawu sygnałów powiązanych z bólem użytkownika, a nie infrastrukturą.

Praktyczny zestaw startowy to latencja, błędy i saturacja. Jeśli widzisz p95 latencji na endpoint, wskaźnik błędów na usługę i jeden sygnał saturacji (głębokość kolejki, połączenia DB lub wykorzystanie workerów), zwykle szybko znajdziesz problem.

Aby uniknąć przebudowy paneli dla każdej nowej usługi, bądź rygorystyczny w nazewnictwie i etykietach. Używaj spójnych atrybutów jak service.name, deployment.environment, http.route i status_code. Tu zespoły często odczuwają różnicę: OpenTelemetry promuje standardowy kształt, podczas gdy agenty proprietarne mogą dodać przydatne dodatki, czasem w polach specyficznych dla dostawcy.

Trzymaj pulpity małe i powtarzalne. Jeden „Przegląd usługi” powinien działać dla każdego API, jeśli wszystkie usługi emitują te same podstawowe metryki i tagi.

Alerty wskazujące wpływ na użytkownika

Alerty powinny odpalać się, gdy użytkownicy to zauważą, a nie gdy serwer wygląda na zajęty. Silne domyślne reguły to wysoki wskaźnik błędów na kluczowych endpointach, p95 latencji powyżej uzgodnionego progu przez 5–10 minut oraz saturacja przewidująca awarię. Dołącz też alert „braku telemetrii”, aby zauważyć, gdy usługa przestanie raportować.

Gdy alert się odpali, dodaj jedną lub dwie notatki w runbooku w opisie alertu: który pulpit otworzyć najpierw, które ostatnie wdrożenie sprawdzić i które pola logów przefiltrować.

Zaplanuj też odpowiedzialność. Umieść krótką miesięczną przeglądówkę w kalendarzu. Jedna osoba usuwa hałaśliwe alerty, scala duplikaty i dostraja progi. To też dobry moment, żeby upewnić się, że nowe usługi stosują te same tagi, aby istniejące pulpity działały dalej.

Częste błędy marnujące czas i budżet

Najszybszy sposób zmarnować pieniądze na obserwowalności to włączenie wszystkiego naraz. Zespoły włączają wszystkie opcje auto‑instrumentacji i potem zastanawiają się, czemu rachunki skaczą, zapytania się spowalniają, a ludzie przestają ufać pulpitom.

Dane wysokiej kardynalności to częsty winowajca. Umieszczanie ID użytkownika, pełnych URLi czy surowych treści żądań w etykietach i atrybutach metryk może rozdmuchać koszty i uczynić prosty wykres drogim.

Problemy z nazewnictwem to kolejny cichy zabójca budżetu. Jeśli jedna usługa raportuje http.server.duration, a inna request_time_ms, nie porównasz ich i każdy pulpit staje się pracą ręczną. Jest gorzej, jeśli nazwy spanów i szablony tras różnią się dla tego samego przepływu użytkownika.

Domyślne ustawienia narzędzi mogą marnować tygodnie. Wiele produktów dostarcza gotowe alerty, ale często dzwonią przy małych skokach albo milczą podczas prawdziwych incydentów. Alerty bazujące na średnich pomijają ogon latencji, gdzie użytkownicy odczuwają ból.

Brak kontekstu to powód, dla którego dochodzenia się przeciągają. Jeśli nie tagujesz telemetrii wersją (i często środowiskiem deploymentu), nie powiążesz błędów i latencji z wydaniem. To ma szczególne znaczenie dla zespołów, które często wdrażają lub regenerują kod.

Traces nie zastępują logów. Ślady pokazują ścieżkę i czasy, ale logi często zawierają ludzkie szczegóły: błędy walidacji, odpowiedzi z zewnętrznych usług i reguły biznesowe.

Szybkie poprawki, które często się spłacają:

• Zacznij od małego zestawu endpointów i jednej kluczowej ścieżki użytkownika
• Uzgodnij zasady nazewnictwa dla usług, tras, nazw spanów i kodów statusu
• Dodaj wersję i środowisko we wszystkich sygnałach zanim zbudujesz pulpity
• Dostosuj alerty do symptomów odczuwalnych przez użytkowników (wskaźnik błędów, p95 latencji), a nie do każdej metryki
• Trzymaj logi i ślady połączone wspólnym request/trace ID

Przykład: wybór dla małego produktu i jednego narzędzia wewnętrznego

Wyobraź sobie zespół pięciu osób prowadzący dwie rzeczy: publiczne API używane przez płacących klientów oraz wewnętrzne narzędzie administracyjne używane przez support i ops. API potrzebuje szybkiej reakcji na incydenty. Narzędzie administracyjne zmienia się co tydzień wraz z przesuwającymi się workflowami.

W takiej sytuacji lepszy wybór zależy często mniej od technologii, a bardziej od tego, kto będzie dzierżył codzienną operację.

Opcja A: zacznij z agentem proprietarnym (szybko teraz)

To najszybsza droga do „widzimy błędy i wolne endpointy dziś”. Instalujesz agenta, wykrywa popularne frameworki i dostajesz pulpity oraz podstawowe alerty szybko.

Co zwykle robi się trudniejsze później, to zmiana. Pulpity, progi alertów i zachowanie próbkowania mogą być powiązane z konkretnym dostawcą. W miarę jak narzędzie administracyjne się zmienia (nowe endpointy, zadania w tle), możesz ciągle dostrajać ustawienia specyficzne dla dostawcy i płacić za większe zużycie.

Po 2 tygodniach zwykle masz mapy usług, top błędów i kilka użytecznych alertów.

Po 2 miesiącach lock-in często ujawnia się w pulpiciach, języku zapytań i niestandardowej instrumentacji.

Opcja B: zacznij z OpenTelemetry (elastyczność później)

To zajmuje więcej na początku, bo wybierasz eksportera i definiujesz, co oznacza „dobrze” dla logów, metryk i śladów. Możesz potrzebować więcej ręcznego nazewnictwa i atrybutów, aby pulpity były zrozumiałe.

Zaletą jest przenośność. Możesz kierować te same sygnały do różnych backendów, utrzymać spójne konwencje między API a narzędziem administracyjnym i uniknąć przepisywania instrumentacji przy zmianie wymagań.

Po 2 tygodniach możesz mieć mniej dopracowane pulpity, ale czystsze struktury śladów i nazewnictwo.

Po 2 miesiącach jesteś bardziej skłonny mieć stabilne konwencje, wielokrotnego użytku alerty i łatwiejsze zmiany narzędzi.

Prosta reguła decyzyjna:

• Jeśli inżynierowie wsparcia potrzebują odpowiedzi w tym tygodniu, proprietarne rozwiązanie na start może być właściwe.
• Jeśli produkt zmienia się co tydzień i spodziewasz się zmiany dostawcy, zacznij od OpenTelemetry.
• Jeśli jedna osoba zajmuje się ops częściowo, wybierz szybkie domyślne ustawienia.
• Jeśli zespół zajmuje się ops, faworyzuj przenośne sygnały i jasne konwencje.

Szybka lista kontrolna i następne kroki

Jeśli tkwisz między OpenTelemetry a agentem proprietarnym, decyduj na podstawie tego, na czym polega twoja codzienna praca: przenośność, czysta korelacja sygnałów i alerty prowadzące do szybkich napraw.

Lista kontrolna:

• Przenośność: czy możesz zmienić backend później bez przepisywania instrumentacji lub utraty kluczowych pól?
• Korelacja: czy możesz przejść z wolnego żądania do dokładnego śladu i powiązanych logów szybko?
• Pokrycie sygnałów: czy masz podstawy (nazwy tras HTTP, typy błędów, spany baz danych), czy są luki?
• Użyteczność alertów: czy alerty mówią, co się zmieniło i gdzie, czy są po prostu hałaśliwymi progami?
• Wysiłek operacyjny: kto odpowiada za aktualizacje, rollout agentów, zmiany SDK i próbkowanie, i jak często to się będzie działo?

Lock-in jest zwykle akceptowalny, gdy jesteś małym zespołem, który chce szybkiej wartości i jesteś pewny, że zostaniesz z jednym stosem przez lata. Jest ryzykowny przy wielu środowiskach, mieszanych stackach technologicznych, ograniczeniach compliance lub realnej możliwości zmiany dostawcy po przeglądzie budżetu.

Aby uniknąć nieskończnego strojenia, przeprowadź krótki pilotaż i najpierw zdefiniuj wyjścia: trzy pulpity i pięć alertów, które naprawdę pomogą w złym dniu. Potem rozszerzaj pokrycie.

Utrzymaj pilotaż konkretnym:

• Zdefiniuj 3 pulpity (stan usługi, top endpointy, baza danych i wywołania zewnętrzne)
• Zdefiniuj 5 alertów (wskaźnik błędów, p95 latencji, saturacja, zaległość w kolejce, nieudane zadania)
• Zapisz konwencje nazewnictwa (nazwy usług, tagi środowiskowe, wzorce tras)
• Zamroź małą listę atrybutów (tagi, na których będziesz polegać do filtrowania i grupowania)
• Uzgodnij reguły próbkowania (co jest zachowywane, co próbkowane i dlaczego)

Jeśli budujesz nowe narzędzia wewnętrzne i portale klientów, AppMaster (appmaster.io) może pomóc szybko tworzyć kompletne aplikacje. To daje przestrzeń do wyboru podejścia do obserwowalności, a potem stosowania go konsekwentnie w miarę wdrożeń i iteracji.