argos

Argos é uma biblioteca de instrumentação declarativa do OpenTelemetry voltada para microsserviços em Go, construída em torno de uma disciplina declarada de zero alocação. O README a apresenta como uma alternativa a duas outras abordagens no ecossistema Go: não existe um equivalente à instrumentação de bytecode -javaagent do Java, e a opção "zero-code" (eBPF) requer privilégios elevados, um kernel Linux recente e cobre apenas um conjunto limitado de bibliotecas. Em vez disso, o Argos adota um caminho de baixo código: uma chamada de inicialização na partida, seguida por um wrapper explícito e substitutível para cada biblioteca de cliente realmente em uso, sem monkey-patching e sem reflexão no hot path. Configuração e ciclo de vida Uma única chamada argos.Run conecta Init, o desligamento acionado por SIGINT/SIGTERM e o Shutdown, aceitando opções funcionais como WithServiceName. O README observa que um par Init/Shutdown de nível inferior está disponível quando mais controle é necessário. A configuração pode ser fornecida por meio de opções funcionais ou carregada de um arquivo YAML. O módulo raiz expõe auxiliares Trace/TraceFunc, Resource, Propagation, Logger com logging ambiente global e um pacote argostest. Por padrão, rastreios e métricas são exportados via OTLP para localhost:4317 e falham abertamente, para que as requisições continuem funcionando quando nenhum coletor estiver em execução. Integrações Cada wrapper de SDK de fornecedor reside em seu próprio módulo Go com seu próprio go.mod, portanto, importar um não traz as dependências transitivas de outro. A cobertura documentada inclui servidores HTTP (net/http, chi, gin, echo, fiber, gorilla/mux), qualquer http.RoundTripper como cliente HTTP, qualquer driver database/sql, GORM, go-redis v9, o driver MongoDB v2, gocql para Cassandra, Sarama para Kafka, amqp091-go para RabbitMQ, Azure Service Bus, GCP Pub/Sub v2, gRPC, pkg/sftp e net/smtp. Diz-se que cada módulo envia testes reais, um benchmark de linha de base versus instrumentado e passa no golangci-lint, gosec e govulncheck. Um modelo de contribuição e uma árvore de decisão são fornecidos para bibliotecas ainda não cobertas. O módulo raiz deliberadamente possui zero dependências de SDK de fornecedores. Amostras e ferramentas Oito microsserviços executáveis estão documentados, cada um com seu próprio docker-compose.yml e README. Seis combinam um roteador com uma pilha de dados ou mensagens (por exemplo, gin + GORM/PostgreSQL + Kafka, ou fiber + Cassandra + SFTP); inventory-api e inventory-worker formam um par cooperativo cuja requisição produz um único rastreio abrangendo ambos os processos. Um CLI cmd/doctor verifica as importações de um projeto Go e sugere qualquer integração Argos correspondente que ainda não esteja configurada; -strict transforma sugestões em falha de CI, e -init gera um argos.config.yaml inicial mais um snippet de main.go. O repositório é um layout de multi-módulo de workspace Go contendo o módulo principal, integrações, cmd/doctor, amostras, exemplos, um site de documentação mkdocs-material e uma configuração Docker com uma pilha Grafana LGTM e OTel Collector, além dos sistemas de backend usados pelas amostras. Os targets do Make cobrem build, test, bench, lint, formatação, varredura de segurança e a ativação/desativação das pilhas de telemetria ou backend. Estabilidade e limites declarados Todos os módulos ainda estão na v0.x, portanto, a API pública de qualquer módulo pode mudar entre versões menores, embora as versões existentes permaneçam resolvíveis. Requisitos e evidências são descritos com ressalvas explícitas: é necessário Go 1.26 ou posterior, com versões anteriores não suportadas. Os recursos de captura e mascaramento opt-in estão apenas parcialmente consolidados - o capture.MaskSQL foi verificado por meio de testes de fuzz sustentados que encontraram e corrigiram um bug real, enquanto a captura de cabeçalho e corpo no cliente HTTP, servidor HTTP e integrações gRPC são cobertas por testes unitários, mas não passaram pelo mesmo processo de fuzzing. Um teste de soak de uma hora no par inventory-api/inventory-worker, exercitando HTTP, gRPC, SQL, Redis, Kafka, MongoDB e Cassandra sob tráfego misto de sucesso e erro (~245k requisições), não mostrou crescimento de goroutine ou memória, mas isso é apresentado como evidência para as integrações exercitadas, não como uma garantia geral - RabbitMQ, GCP Pub/Sub, Azure Service Bus, SFTP e SMTP não possuem teste de soak dedicado, e execuções superiores a uma hora não foram cobertas. Os benchmarks são de rajadas curtas em vez de verificação de carga sustentada. O projeto possui licença MIT.