Jak przestać przepisywać kod pod kątem logów i metryk

Wyobraź sobie taką sytuację: masz tuzin mikroserwisów Java działających w produkcji. W pewnym momencie jeden z nich zaczyna „lagować". Otwierasz logi, ale nic tam nie ma — standardowe komunikaty nie wystarczają, żeby zrozumieć, na którym dokładnie etapie żądanie się zatrzymuje. Znajoma historia? Zazwyczaj w tym momencie developer zagląda do kodu, dekoruje metody adnotacjami, dodaje zależności do śledzenia, przebudowuje projekt i wdraża go ponownie. A co jeśli masz setki usług napisanych na różnych frameworkach?

W ekosystemie OpenTelemetry istnieje projekt, który rozwiązuje ten problem elegancko i, co szczególnie miłe, niemal bez wysiłku. To opentelemetry-java-instrumentation. To specjalny agent Java, który potrafi wstrzyknąć się do twojej aplikacji „w locie" i zbierać telemetrię bez napisania ani jednej linijki nowego kodu.

Co to za agent i dlaczego go potrzebujesz

Essencjonalnie to plik JAR, który dołączasz przy uruchamianiu JVM. Wykorzystuje dynamiczne wstrzykiwanie kodu bajtowego. Gdy twoja aplikacja ładuje klasy z popularnych bibliotek (na przykład Spring, Hibernate, gRPC czy Kafka), agent ostrożnie wstrzykuje logikę tworzenia spanów i zbierania metryk.

To idealne rozwiązanie w dwóch scenariuszach. Po pierwsze, gdy musisz szybko dodać observability do projektu legacy, którego dotknięcie budzi strach. Po drugie, gdy chcesz standaryzować zbieranie danych w całej firmie bez konieczności ręcznej konfiguracji SDK przez każdy zespół.

Trzy świetne funkcje, które ułatwiają życie

Automatyczna magia out of the box

Agent obsługuje ogromną liczbę bibliotek. Jeśli używasz standardowego stosu jak Spring Boot z PostgreSQL i Redis, nie musisz nic konfigurować. Po prostu dołączasz agenta i w systemie monitoringu (na przykład Jaeger czy Zipkin) otrzymujesz drzewo wywołań: od przychodzącego żądania HTTP przez zapytanie do bazy danych po odpowiedź z cache.

Propagowanie kontekstu do logów (MDC)

Jedną z najbardziej przydatnych rzeczy w codziennym debugowaniu jest automatyczne wstawianie Trace ID do logów. Agent sam znajduje twoje loggery (Logback, Log4j2) i dodaje identyfikator bieżącego trace'a do MDC. Teraz, gdy widzisz błąd w logach, możesz po prostu skopiować ID i znaleźć całą ścieżkę tego żądania we wszystkich usługach. Koniec z zgadywaniem, który użytkownik wywołał ten NullPointerException.

Elastyczna konfiguracja bez przebudowy

Wszystkie parametry — gdzie wysyłać dane, jak często próbkować, jakie atrybuty dodawać do spanów — przekazujesz przez zmienne środowiskowe lub właściwości systemowe Java. Oznacza to, że ten sam binarny plik twojej aplikacji może wysyłać dane do konsoli w środowisku dev i do ciężkiego klastra OpenTelemetry Collector w produkcji.

Jak to uruchomić

Proces konfiguracji jest zaskakująco prosty. Najpierw pobierz najnowszą wersję opentelemetry-javaagent.jar ze strony z wydaniami. Następnie dodaj jedną flagę do polecenia uruchomienia aplikacji:

java -javaagent:path/to/opentelemetry-javaagent.jar \
     -Dotel.resource.attributes=service.name=my-cool-service \
     -jar myapp.jar

Domyślnie agent oczekuje, że gdzieś działa collector akceptujący dane przez protokół OTLP pod adresem localhost:4318. Jeśli chcesz użyć czegoś innego, na przykład Zipkin, zmieniasz to jedną flagą: -Dotel.traces.exporter=zipkin.

Pod maską i rozszerzalność

Ciekawe jest to, że projekt nie ogranicza cię do „automatyzacji". Jeśli wbudowane możliwości nie wystarczają, możesz skorzystać z mechanizmu rozszerzeń. Możesz napisać własny plik JAR, który doda niestandardowe reguły instrumentacji lub atrybuty specyficzne dla firmy.

Dla tych, którzy w ogóle nie ufają magii agentów, projekt dostarcza te same biblioteki instrumentacji osobno. Możesz dodać je jako zwykłe zależności i skonfigurować ręcznie, ale wtedy musisz zaakceptować konieczność modyfikacji kodu.

Czy warto z tego korzystać

Często spotykam się z opinią, że agenty Java to „czarna skrzynka", która może spowolnić aplikację. Jest w tym trochę prawdy: agent faktycznie zużywa zasoby na transformację kodu bajtowego przy starcie i dodaje niewielkie obciążenie przy wykonywaniu żądań. Jednak w 95% przypadków to obciążenie jest pomijalne w porównaniu z korzyścią, jaką otrzymujesz podczas tropienia błędów w systemie rozproszonym.

Komu sprawdzi się to szczególnie dobrze:

1. Zespołom przechodzącym na mikrousługi i duszącym się bez śledzenia.
2. Wsparciu technicznemu, które potrzebuje „wczoraj", żeby zrozumieć, dlaczego stary monolith jest wolny.
3. Architektom wdrażającym ujednolicony standard monitoringu.

Jeśli jeszcze nie próbowałeś OpenTelemetry w swoich projektach Java, ten agent to najszybsza i najmniej bolesna droga, żeby zacząć. Po prostu spróbuj uruchomić go lokalnie i zobacz, ile interesujących rzeczy dowiesz się o zachowaniu swojego kodu pod obciążeniem.