Jak dodać monitoring do projektu Go bez zmian w kodzie

Pomyśl, ile razy odkładałeś implementację pełnego śledzenia w projekcie tylko dlatego, że było zbyt żmudne przekazywanie kontekstów przez każdą metodę? Albo jeszcze gorzej — gdy musiałeś prześledzić ścieżkę żądania wewnątrz biblioteki zewnętrznej, do której kodu źródłowego nie masz dostępu. Zazwyczaj w takich sytuacjach musiałeś albo przepisać połowę logiki biznesowej, żeby dopasować ją do API OpenTelemetry, albo pogodzić się z „martwymi punktami" w monitoringu.

Zespół OpenTelemetry najwyraźniej znalazł sposób, aby wyeliminować tę żmudną pracę. Repozytorium opentelemetry-go-compile-instrumentation udostępnia narzędzie, które wstrzykuje telemetrię bezpośrednio podczas procesu budowania aplikacji.

Na czym polega ta magia

Projekt to narzędzie otelc. Działa jako warstwa na szczycie standardowego kompilatora Go. Zamiast ręcznie importować biblioteki OpenTelemetry i umieszczać spany, narzędzie robi to za Ciebie w czasie kompilacji. Znajduje odpowiednie miejsca w Twoim kodzie i zależnościach, a następnie wstawia tam niezbędne wywołania.

To nie jest tylko „automatyzacja" — to zmiana paradygmatu. Piszesz czysty kod skupiony na zadaniach biznesowych, a obserwowalność staje się warstwą infrastrukturalną, która leży na wierzchu.

Do czego to się przydaje w praktyce

Główną zaletą jest całkowity brak zmian w kodzie źródłowym. Jeśli jutro zdecydujesz się zmienić dostawcę monitoringu lub całkowicie zrezygnować ze śledzenia, nie będziesz musiał usuwać setek importów z całego projektu.

Interesujące możliwości narzędzia:

• Praca z bibliotekami zewnętrznymi. Możesz uzyskać trace'y z głębi cudzego kodu, który jest podłączony przez go.mod.
• Brak narzutu czasu wykonania. Ponieważ kod jest wstrzykiwany w czasie budowania, program nie musi zużywać zasobów na dynamiczną analizę ani refleksję podczas działania.
• Elastyczna integracja. Narzędzie łatwo wpija się w pipeline'y CI/CD. W zasadzie wystarczy tylko zmienić polecenie budowania.

Jak to działa pod maską

Narzędzie modyfikuje proces budowania. Zamiast znanego go build używasz otelc go build. Pod maską narzędzie analizuje abstrakcyjne drzewo składniowe (AST) Twojego kodu i jego zależności. Na podstawie wcześniej opisanych reguł (Instrumentation Rules) wstrzykuje niezbędne fragmenty kodu.

Repozytorium zawiera szczegółowe opisy architektury. Jeśli ciekawi Cię dokładnie, jak działa podstawianie wywołań i jak opisywać reguły dla nowych bibliotek, zajrzyj do folderu docs/. Wszystko jest tam udokumentowane: od projektu API po konwencje semantyczne.

Od czego zacząć

Najpierw musisz zbudować samo narzędzie. To standardowa procedura dla projektów Go:

git clone https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation.git
cd opentelemetry-go-compile-instrumentation
make build

Po tym będziesz mieć binarkę otelc. Aby przetestować ją w działaniu, możesz uruchomić aplikację demonstracyjną z repozytorium. Cały proces sprowadza się do jednego polecenia:

cd demo/app/basic
../../otelc go build
./basic

Jeśli wszystko poszło dobrze, Twoja aplikacja zacznie generować dane telemetrii, choć w jej kodzie źródłowym nie znajdziesz ani jednej wzmianki o OpenTelemetry.

Kto skorzysta na tym rozwiązaniu

Projekt wygląda na doskonałe narzędzie dla osób utrzymujących systemy legacy lub ogromne monolicie, gdzie ręczna implementacja śledzenia ciągnęłaby się przez miesiące. To również ratunek dla zespołów, które chcą utrzymywać swój kod „sterylny" od zależności infrastrukturalnych.

Warto jednak wziąć pod uwagę, że projekt wymaga zrozumienia, jak działają reguły instrumentacji. Jeśli potrzebujesz czegoś specyficznego, co nie jest objęte standardowymi regułami, będziesz musiał zagłębić się w konfiguracje YAML i ewentualnie napisać własne hooki.

Zdecydowanie warto wypróbować narzędzie, jeśli masz dość boilerplate'u związanego z kontekstami i spanami. To krok w kierunku tego, czym powinien być nowoczesny developer experience: złożone rzeczy jak obserwowalność działają „out of the box" i nie przeszkadzają w pisaniu kodu.