Open yurishkuro opened 6 years ago
What if we moved all Zipkin-related code into another repository and have people run it as a sidecar instead of being part of the main Jaeger collector?
What do you mean exactly? Have a separate zipkin-collector
importing jaeger?
IIRC openapi dependencies are used to generate and validate the model.
What if we moved all Zipkin-related code into another repository and have people run it as a sidecar instead of being part of the main Jaeger collector?
Interesting idea. This is actually how NATS export their Prometheus metrics: they have a sidecar that makes the bridge between Prometheus and NATS, translating the internal metrics format into Prometheus'.
Reference: https://github.com/nats-io/prometheus-nats-exporter
What do you mean exactly? Have a separate zipkin-collector importing jaeger?
not collector, a bridge that consumes zipkin formats and forwards to jaeger-collector
518 introduced a pretty large, and largely unnecessary, dependency on
github.com/go-openapi/*
packages (https://github.com/jaegertracing/jaeger/pull/518/files#diff-395f41b2a27b70ce44399c91c82158c2R45).What if we moved all Zipkin-related code into another repository and have people run it as a sidecar instead of being part of the main Jaeger collector?
Alternatively, we should consider if we really need all these runtime dependencies on
github.com/go-openapi/*
- in the end all we're doing is implementing a singlePOST /api/traces
endpoint and converting from Zipkin model to Jaeger. The endpoint implementation does not requirego-openapi
mechanics, the only thing that's needed is generating the data model from zipkin swagger file, which can be done offline.cc @pavolloffay