OpenTracing vs OpenTelemetry
obfuscated-developer opened this issue · 5 comments
According to opentracing.io the OpenTracing project is now archived and OpenTelemetry is the new version of that. Is the opentracing package compatible with OpenTelemetry?
After going through the code, it does look like adding a new reporter should do the trick. Though I'm still in the process of investigating atm. I'll try to remember to update this issue once I have more data
UPD: OpenTelemetry collectors can receive data in Jaeger format, so I could re-use most of the opentracing and opentracing-jaeger stuff. However, the collector didn't work until I specified the content type in the request header, so I had to rewrite a couple of things
newJaegerCollector :: Otel.JaegerCollectorOptions -> IO Otel.JaegerCollector
newJaegerCollector opt = do
rq <- mkReq
-- Otel.JaegerCollector is a newtype but the module where it's defined doesn't
-- expose the constructor, so I had to use unsafeCoerce to make this work
fmap Coerce.unsafeCoerce
. Otel.newBatchEnv
. Lens.set Otel.boptErrorLog (opt ^. Otel.jcoErrorLog) . Otel.batchOptions
$ reporter (opt ^. Otel.jcoManager) (opt ^. Otel.jcoErrorLog) rq tproc
where
mkReq = do
rq <-
Client.parseRequest
$ "http://" <> Lens.view (Otel.jcoAddr . Otel.addrHostName) opt
<> ":"
<> show (Lens.view (Otel.jcoAddr . Otel.addrPort) opt)
<> "/api/traces?format=jaeger.thrift"
pure rq
{ Client.method = "POST"
, Client.secure = Lens.view (Otel.jcoAddr . Otel.addrSecure) opt
, Client.requestHeaders
= ("Content-Type", "application/x-thrift") : Client.requestHeaders rq
}
tproc = Otel.toThriftProcess (opt ^. Otel.jcoServiceName) (opt ^. Otel.jcoServiceTags)
It works now but it would be nice if the header was set by the library so that it can be used out of the box
Yeah, that does the trick 👍