microcks / microcks/microcks-cli
feat: add OpenTelemetry tracing support for CI/CD observability
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 52
- Forks
- 68
- Avg merge
- 6h 54m
- Merged PRs (30d)
- 10
Description
### Reason/Context
When `microcks test` fails in a CI/CD pipeline, platform engineers have no way to correlate the CLI execution with what happened on the Microcks server or the API under test. The CLI is a complete black box — no trace context, no span data, no correlation IDs in logs.
Modern platform teams run observability stacks (Grafana/Tempo, Jaeger, Datadog) and expect every tool in their pipeline to emit trace context. Without it, debugging a failed API test requires manually cross-referencing timestamps across multiple systems.
Since Microcks is a CNCF Sandbox project, adding OTel tracing aligns directly with CNCF's observability principles and makes Microcks significantly more attractive to enterprise platform teams who already run OTel collectors in their infrastructure.
### Description
Add opt-in OpenTelemetry (OTel) distributed tracing to `microcks-cli` so engineers can trace a full test lifecycle from CLI invocation → Microcks server → target API endpoint.
**Activation:** via standard OTel environment variable — `OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4317`
- If the env var is absent → zero overhead, zero behavior change, no new output
- If set → CLI initializes an OTLP exporter and emits spans for key operations
**Spans emitted:**
- `microcks.test.create` — when a test result is created on the server
- `microcks.test.poll` — each polling iteration waiting for test completion
- `microcks.import.upload` — when an artifact is uploaded
**W3C Trace Context:** injects `traceparent` headers into all outgoing HTTP requests so the Microcks server can participate in the same trace.
**This is a non-breaking change.** Fully opt-in via environment variable. Existing users see zero difference unless they explicitly set the OTLP endpoint.
### Implementation ideas
New package `pkg/observability/tracing.go` — initializes the OTel provider and returns a shutdown function:
```go
func InitTracer(serviceName string) (func(context.Context) error, error) {
// reads OTEL_EXPORTER_OTLP_ENDPOINT from env
// returns no-op tracer if unset
}
Wire into `cmd/root.go` PersistentPreRun — initialize once, shutdown in PersistentPostRun.
Wrap the HTTP client in `pkg/connectors/` using `otelhttp.NewTransport`:
Dependencies to add:
- go.opentelemetry.io/otel (CNCF graduated project)
- go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp
Fully opt-in — no Kubernetes or external collector required. Works with any OTLP-compatible backend (Jaeger, Tempo, Datadog). Happy to implement if the approach looks good.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading cmd/root.go and the connector code under pkg/connectors, then review the proposed pkg/observability/tracing.go entry point and the OTel HTTP instrumentation requirements. Done means tracing is opt-in through OTEL_EXPORTER_OTLP_ENDPOINT, the listed test, poll, and upload operations emit spans, outgoing requests carry traceparent headers, and existing behavior is unchanged when the variable is absent.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli, distributed-systems, observability
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100