Hoe monitoring toevoegen aan een Go-project zonder codewijzigingen

Denk eens aan hoe vaak je de implementatie van volledige tracing in een project hebt uitgesteld alleen maar omdat het te lastig was om contexten door elke methode heen te passen? Of erger nog, wanneer je een request-pad moest traceren binnen een bibliotheek van derden waarvan je de broncode niet beheert. Meestal moest je in zulke gevallen de helft van de bedrijfslogica herschrijven om in het OpenTelemetry API te passen, of "blinde vlekken" in je monitoring accepteren.

Het OpenTelemetry-team lijkt een manier te hebben gevonden om dit lastige werk te elimineren. De opentelemetry-go-compile-instrumentation repository biedt een tool die telemetry direct injecteert tijdens het build-proces van de applicatie.

Wat is deze magie

Het project is een utility otelc. Het werkt als een laag boven op de standaard Go-compiler. In plaats van dat je handmatig OpenTelemetry-bibliotheken importeert en spans plaatst, doet de tool dit voor je tijdens het compileren. Het vindt de juiste plaatsen in je code en afhankelijkheden, en voegt daar de noodzakelijke aanroepen in.

Dit is niet zomaar 'automatisering'—het is een paradigma verschuiving. Je schrijft schone code gericht op bedrijfstaken, en observability wordt een infrastructuurlaag die er bovenop zit.

Waar is dit in de praktijk nuttig voor

Het belangrijkste hoogtepunt hier is de volledige afwezigheid van wijzigingen in de broncode. Als je morgen besluit om van monitoringleverancier te wisselen of tracing helemaal op te geven, hoef je geen honderden imports door het hele project op te ruimen.

Interessante mogelijkheden van de tool:

• Werken met bibliotheken van derden. Je kunt traces krijgen uit de diepten van iemand anders code die verbonden is via go.mod.
• Geen runtime-overhead. Omdat code wordt geïnjecteerd tijdens het bouwen, hoeft het programma geen resources te besteden aan dynamische analyse of reflectie tijdens de uitvoering.
• Flexibele integratie. De tool past gemakkelijk in CI/CD-pipelines. In wezen hoef je alleen het build-commando te wijzigen.

Hoe het intern werkt

De tool wijzigt het build-proces. In plaats van het vertrouwde go build gebruik je otelc go build. Onder de motorkap analyseert de utility de abstract syntax tree (AST) van je code en zijn afhankelijkheden. Op basis van vooraf beschreven regels (Instrumentation Rules) injecteert het de noodzakelijke codefragmenten.

De repository bevat gedetailleerde architectuurgidsen. Als je nieuwsgierig bent naar precies hoe call-substitutie werkt en hoe je regels beschrijft voor nieuwe bibliotheken, neem dan een kijkje in de docs/ folder. Alles is daar gedocumenteerd: van API-design tot semantische conventies.

Waar te beginnen

Eerst moet je de tool zelf bouwen. Dit is een standaardprocedure voor Go-projecten:

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

Daarna heb je de binary otelc. Om het in actie te testen, kun je de demo-applicatie uit de repository draaien. Het hele proces komt neer op één commando:

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

Als alles goed is gegaan, zal je applicatie beginnen met het genereren van telemetry data, ook al zul je geen enkele vermelding van OpenTelemetry in de broncode vinden.

Wie heeft hier baat bij

Het project lijkt een uitstekende tool voor degenen die legacy-systemen of enorme monolithen onderhouden waar handmatige tracing-implementatie maanden zou duren. Het is ook een reddingsboei voor teams die hun code 'steriel' willen houden van infrastructuurafhankelijkheden.

Het is echter de moeite waard om te overwegen dat het project vereist dat je begrijpt hoe instrumentatieregels werken. Als je iets specifieks nodig hebt dat niet wordt gedekt door de standaardregels, moet je in YAML-configs duiken en mogelijk je eigen hooks schrijven.

Het is zeker de moeite waard om de tool te proberen als je moe bent van boilerplate rond contexten en spans. Dit is een stap naar wat de moderne developer-ervaring zou moeten zijn: complexe zaken zoals observability werken 'out of the box' en komen niet in de weg te staan bij het schrijven van code.