Sobre el proyecto
Argos es una biblioteca declarativa de instrumentación OpenTelemetry diseñada para microservicios en Go, construida alrededor de una disciplina de cero asignaciones de memoria. El README la plantea como alternativa a dos enfoques del ecosistema Go: no existe equivalente a la instrumentación por bytecode de Java (-javaagent), y la opción "zero-code" (eBPF) requiere privilegios elevados, un kernel Linux reciente y cubre solo un conjunto limitado de bibliotecas. Argos sigue una ruta low-code: una única llamada de inicialización al inicio, seguida de un wrapper explícito y compatible para cada biblioteca cliente utilizada, sin monkey-patching ni reflexión en el hot path.
Configuración y ciclo de vida
Una única llamada a argos.Run conecta Init, el apagado activado por SIGINT/SIGTERM y Shutdown, aceptando opciones funcionales como WithServiceName. El README indica que también está disponible un par Init/Shutdown de menor nivel cuando se necesita más control. La configuración puede suministrarse mediante opciones funcionales o cargarse desde un archivo YAML. El módulo raíz expone helpers Trace/TraceFunc, Resource, Propagation, Logger con logging ambiental global, y un paquete argostest. Por defecto, las trazas y métricas se exportan por OTLP a localhost:4317 y fallan de forma abierta, de modo que las solicitudes continúan funcionando cuando no hay ningún collector ejecutándose.
Integraciones
Cada wrapper de SDK de proveedor reside en su propio módulo Go con su propio go.mod, por lo que importar uno no arrastra dependencias transitivas de otro. La cobertura documentada incluye servidores HTTP (net/http, chi, gin, echo, fiber, gorilla/mux), cualquier http.RoundTripper como cliente HTTP, cualquier driver database/sql, GORM, go-redis v9, el driver de MongoDB v2, gocql para Cassandra, Sarama para Kafka, amqp091-go para RabbitMQ, Azure Service Bus, GCP Pub/Sub v2, gRPC, pkg/sftp y net/smtp. Cada módulo afirma incluir tests reales, benchmarks comparativos entre versión base e instrumentada, y pasar golangci-lint, gosec y govulncheck. Se proporciona una plantilla de contribución y un árbol de decisiones para bibliotecas aún no cubiertas. El módulo raíz carece deliberadamente de dependencias de SDK de proveedores.
Ejemplos y herramientas
Hay ocho microservicios ejecutables documentados, cada uno con su docker-compose.yml y README. Seis combinan un router con una pila de datos o mensajería (por ejemplo, gin + GORM/PostgreSQL + Kafka, o fiber + Cassandra + SFTP); inventory-api e inventory-worker forman un par cooperativo cuya solicitud genera una única traza que abarca ambos procesos. Una CLI cmd/doctor escanea las imports de un proyecto Go y sugiere las integraciones de Argos que aún no están configuradas; -strict convierte las sugerencias en un fallo de CI, e -init genera un archivo argos.config.yaml básico junto con un snippet de main.go. El repositorio tiene una estructura multi-módulo de Go workspace que contiene el módulo central, integraciones, cmd/doctor, samples, ejemplos, documentación mkdocs-material y un entorno Docker con Grafana LGTM, collector de OTel y los sistemas backend usados por los samples. Los targets de Make cubren build, test, bench, lint, formateo, análisis de seguridad y el levantamiento/apagado de stacks de telemetría o backend.
Estabilidad y limitaciones declaradas
Todos los módulos siguen en v0.x, por lo que la API pública de cualquier módulo puede cambiar entre versiones menores, aunque los lanzamientos existentes permanecen resolubles. Los requisitos y evidencias se describen con salvedades explícitas: se requiere Go 1.26 o posterior, no se soportan versiones anteriores. Las funciones opt-in de captura y enmascaramiento están parcialmente endurecidas: capture.MaskSQL ha sido verificado mediante fuzzing sostenido que encontró y corrigió un bug real, mientras que la captura de headers y bodies en las integraciones HTTP client, HTTP server y gRPC está cubierta por unit tests pero no ha pasado por el mismo proceso de fuzzing. Una prueba de absorción de una hora en el par inventory-api/inventory-worker, que ejercitó HTTP, gRPC, SQL, Redis, Kafka, MongoDB y Cassandra bajo tráfico mixto de éxito y error (~245k solicitudes), no mostró crecimiento de goroutines ni de memoria, pero esto se presenta como evidencia para las integraciones probadas, no como garantía universal: RabbitMQ, GCP Pub/Sub, Azure Service Bus, SFTP y SMTP no tienen pruebas de absorción dedicadas, y no se cubrieron duraciones superiores a una hora. Los benchmarks son de ráfaga corta, no de verificación bajo carga sostenida. El proyecto tiene licencia MIT.
Comments
0 Rating appears after 10 ratings
Sign in to join the discussion.