Comment ajouter de la surveillance à un projet Go sans modifier le code

Réfléchissez au nombre de fois où vous avez reporté l'implémentation du tracing complet dans un projet simplement parce que c'était trop fastidieux de passer des contextes à chaque méthode ? Ou pire, quand vous deviez tracer un chemin de requête à l'intérieur d'une bibliothèque tierce dont vous ne contrôlez pas le code source. Habituellement dans ces cas-là, vous deviez soit réécrire la moitié de la logique métier pour correspondre à l'API OpenTelemetry, soit accepter des « zones d'ombre » dans votre surveillance.

L'équipe OpenTelemetry semble avoir trouvé un moyen d'éliminer ce travail fastidieux. Le dépôt opentelemetry-go-compile-instrumentation propose un outil qui injecte la télémétrie directement pendant le processus de build de l'application.

En quoi consiste cette magie

Le projet est un utilitaire otelc. Il fonctionne comme une couche au-dessus du compilateur Go standard. Au lieu d'importer manuellement les bibliothèques OpenTelemetry et de placer des spans, l'outil le fait pour vous au moment de la compilation. Il trouve les bons emplacements dans votre code et ses dépendances, puis insère les appels nécessaires.

Ce n'est pas juste de « l'automatisation » — c'est un changement de paradigme. Vous écrivez du code propre axé sur les tâches métier, et l'observabilité devient une couche d'infrastructure qui se superpose.

À quoi cela sert-il concrètement

Le point fort ici est l'absence totale de modifications au code source. Si demain vous décidez de changer de fournisseur de surveillance ou d'abandonner complètement le tracing, vous n'aurez pas besoin de nettoyer des centaines d'importations dans tout le projet.

Les capacités intéressantes de l'outil :

• Travailler avec des bibliothèques tierces. Vous pouvez obtenir des traces depuis les profondeurs du code de quelqu'un d'autre qui est connecté via go.mod.
• Zéro surcharge à l'exécution. Comme le code est injecté au moment de la compilation, le programme n'a pas besoin de consacrer des ressources à l'analyse dynamique ou à la réflexion pendant l'exécution.
• Intégration flexible. L'outil s'intègre facilement dans les pipelines CI/CD. En essence, vous changez simplement la commande de build.

Comment cela fonctionne en interne

L'outil modifie le processus de build. Au lieu du familier go build vous utilisez otelc go build. En coulisses, l'utilitaire analyse l'arbre de syntaxe abstraite (AST) de votre code et de ses dépendances. En fonction de règles prédéfinies (Instrumentation Rules), il injecte les extraits de code nécessaires.

Le dépôt contient des guides d'architecture détaillés. Si vous êtes curieux de savoir exactement comment fonctionne la substitution des appels et comment décrire des règles pour de nouvelles bibliothèques, jetez un œil au dossier docs/. Tout y est documenté : de la conception de l'API aux conventions sémantiques.

Par où commencer

D'abord, vous devez construire l'outil lui-même. C'est une procédure standard pour les projets Go :

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

Après cela, vous aurez le binaire otelc. Pour le tester en action, vous pouvez exécuter l'application de démonstration du dépôt. L'ensemble du processus se résume à une commande :

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

Si tout s'est bien passé, votre application commencera à générer des données de télémétrie, bien que vous ne trouviez pas une seule mention d'OpenTelemetry dans son code source.

Qui bénéficiera de cela

Le projet ressemble à un excellent outil pour ceux qui maintiennent des systèmes hérités ou d'énormes monolithes où l'implémentation manuelle du tracing prendrait des mois. C'est aussi une bouée de sauvetage pour les équipes qui souhaitent garder leur code « stérile » vis-à-vis des dépendances d'infrastructure.

Cependant, il convient de considérer que le projet nécessite de comprendre le fonctionnement des règles d'instrumentation. Si vous avez besoin de quelque chose de spécifique qui n'est pas couvert par les règles standard, vous devrez vous plonger dans les fichiers de configuration YAML et éventuellement écrire vos propres hooks.

Cela vaut définitivement le coup d'essayer l'outil si vous êtes fatigué du code répétitif autour des contextes et des spans. C'est un pas vers ce que devrait être l'expérience développeur moderne : les choses complexes comme l'observabilité fonctionnent « out of the box » et ne gênent pas l'écriture du code.