argos

Argos est une bibliothèque d’instrumentation déclarative OpenTelemetry destinée aux microservices Go, construite autour d’une discipline de zéro allocation. Le README la présente comme une alternative à deux autres approches de l’écosystème Go : il n’existe pas d’équivalent à l’instrumentation bytecode -javaagent de Java, et l’option « zero‑code » (eBPF) nécessite des privilèges élevés, un noyau Linux récent et ne couvre qu’un ensemble limité de bibliothèques. Argos adopte plutôt une approche low‑code : un appel d’initialisation au démarrage, suivi d’un wrapper explicite, prêt à l’emploi, pour chaque bibliothèque cliente réellement utilisée, sans monkey‑patching ni réflexion sur le chemin critique. Un seul appel argos.Run connecte Init, l’arrêt déclenché par SIGINT/SIGTERM et Shutdown, en acceptant des options fonctionnelles telles que WithServiceName. Le README indique qu’une paire Init/Shutdown de niveau inférieur est disponible lorsqu’un contrôle plus fin est nécessaire. La configuration peut être fournie via des options fonctionnelles ou chargée depuis un fichier YAML. Le module racine expose les aides Trace/TraceFunc, Resource, Propagation, Logger avec journalisation globale ambiante, ainsi qu’un package argostest. Par défaut, les traces et métriques sont exportées via OTLP vers localhost :4317 et fonctionnent en mode fail‑open, de sorte que les requêtes continuent même si aucun collecteur n’est en cours d’exécution. Chaque wrapper SDK fournisseur réside dans son propre module Go avec son propre go.mod, de sorte qu’importer l’un n’entraîne pas les dépendances transitives de l’autre. La couverture documentée comprend les serveurs HTTP (net/http, chi, gin, echo, fiber, gorilla/mux), tout http.RoundTripper en tant que client HTTP, tout driver database/sql, GORM, go-redis v9, le driver MongoDB v2, gocql pour Cassandra, Sarama pour Kafka, amqp091-go pour RabbitMQ, Azure Service Bus, GCP Pub/Sub v2, gRPC, pkg/sftp et net/smtp. Chaque module est censé fournir de vrais tests, un benchmark baseline vs instrumenté, et de passer golangci‑lint, gosec et govulncheck. Un modèle de contribution et un arbre de décision sont fournis pour les bibliothèques encore non couvertes. Le module racine ne possède délibérément aucune dépendance SDK fournisseur. Huit microservices exécutables sont documentés, chacun avec son propre docker-compose.yml et README. Six associent un routeur à une pile de données ou de messagerie (par exemple gin + GORM/PostgreSQL + Kafka, ou fiber + Cassandra + SFTP) ; inventory‑api et inventory‑worker forment une paire coopérative dont la requête génère une trace unique couvrant les deux processus. Un CLI cmd/doctor analyse les imports d’un projet Go et suggère toute intégration Argos correspondante qui n’est pas encore configurée ; l’option -strict transforme les suggestions en échec CI, et -init génère un argos.config.yaml de démarrage ainsi qu’un extrait main.go. Le dépôt est organisé comme un espace de travail Go multi‑module contenant le module core, les intégrations, cmd/doctor, les samples, les exemples, un site de documentation mkdocs‑material et une configuration Docker avec une pile Grafana LGTM et OTel Collector ainsi que les systèmes backend utilisés par les samples. Les cibles Make couvrent la construction, les tests, les benchmarks, le lint, le formatage, l’analyse de sécurité et le déploiement/démontage des piles de télémétrie ou backend. Tous les modules sont encore en version v0.x, de sorte que l’API publique de n’importe quel module peut changer entre versions mineures, bien que les versions existantes restent résolubles. Les exigences et les preuves sont décrites avec des mises en garde explicites : Go 1.26 ou supérieur est requis, les versions antérieures ne sont pas prises en charge. Les fonctionnalités d’interception et de masquage en option sont seulement partiellement renforcées — capture.MaskSQL a été vérifiée grâce à des tests de fuzzing soutenus qui ont découvert et corrigé un vrai bug, tandis que l’interception des en‑têtes et du corps sur les intégrations client HTTP, serveur HTTP et gRPC est couverte par des tests unitaires mais n’a pas bénéficié du même passage de fuzzing. Un test de résistance d’une heure sur la paire inventory‑api/inventory‑worker, exercant HTTP, gRPC, SQL, Redis, Kafka, MongoDB et Cassandra sous un trafic mixte de succès et d’erreurs (~245 k requêtes), n’a montré aucune croissance de goroutine ou de mémoire, mais cela constitue une preuve uniquement pour les intégrations testées, pas une garantie globale — RabbitMQ, GCP Pub/Sub, Azure Service Bus, SFTP et SMTP n’ont pas de test de résistance dédié, et les exécutions supérieures à une heure n’ont pas été couvertes. Les benchmarks sont de courts pics plutôt que des vérifications sous charge soutenue. Le projet est sous licence MIT.