11–20 of 66 posts
This will cause pain and suffering in the presence of async, multithreaded code: your trace context will be present in the thread where your request handler began, but won't be present in threads running callbacks from non-blocking IO libraries (netty, akka-http, async-http-client, redisson, etc).
So how does this differ from open census, openmetrics, opentracing? It would be great if one open-something combined metrics and other observability tools in one spec/toolset like application insights does. Otherwise, developers waste a lot of time evaluating various open-whatevers, and having to use more than one.
At the very least, it's forcing some standardization among APM vendors (DataDog 64b trace_id, I'm looking at you).
Also, related: https://www.w3.org/TR/trace-context/
I 100% support this I think theres great work behind it. Eager to see how they tackle logs.
Earlier quoted context omitted.
I agree. They were very quick to update their website to say "we're making a new thing", but the new thing isn't ready. I used the metric implementation in Go (as someone with extensive Prometheus experience), and was shocked at how they managed to write so much code to do so little. You will be amazed at how many levels of indirection there are, with a little assumption hard-coded at every single point of indirectio…
Which Jaeger go library are you using? https://github.com/jaegertracing/jaeger-client-go ? For prometheus, I was using the official Go client, but I found the victoria metrics one to be a lot simpler and lighter. My go.mod was a lot smaller after swapping.
Jaeger is a little annoying in that what configuration the library accepts depends on the language. For example, you have to modify your code to emit B3 (zipkin-compatible) traces, which is annoying. Leads to PRs like this: https://github.com/grafana/grafana/pull/17009
I don't use any of their libraries, but follow the spec closely. At the very least, it's forcing some standardization among APM vendors (DataDog 64b trace_id, I'm looking at you). Also, related: https://www.w3.org/TR/trace-context/
The java implementation seems to lean on trying to pass context objects around implicitly as a ThreadLocal. This will cause pain and suffering in the presence of async, multithreaded code: your trace context will be present in the thread where your request handler began, but won't be present in threads running callbacks from non-blocking IO libraries (netty, akka-http, async-http-client, redisson, etc).
Here be dragons. I really want to use this project, but the spec and libraries keep changing. I would not adopt this yet, too much is in flux. As an aside, I think this project is suffering from analysis paralysis. Ship a stable 1.0, iterate towards a 2.0 eventually based on user feedback. You aren't going to release a perfect 1.0.
It is true that the spec and libraries have been changing. This is to be expected since we haven't yet made a stable release. We are aiming for 1.0 GA release this year. The current plan is to freeze trace spec this week, followed by metric spec freeze in 3 weeks, followed by the release of several language implementations in 4 weeks after the spec freeze.
Like everyone else I wish we could release earlier, but the reality is that making dozens of companies agree on a standard takes time. I am very excited that we are approaching the finish line.
Here be dragons. I really want to use this project, but the spec and libraries keep changing. I would not adopt this yet, too much is in flux. As an aside, I think this project is suffering from analysis paralysis. Ship a stable 1.0, iterate towards a 2.0 eventually based on user feedback. You aren't going to release a perfect 1.0.
I agree. They were very quick to update their website to say "we're making a new thing", but the new thing isn't ready. I used the metric implementation in Go (as someone with extensive Prometheus experience), and was shocked at how they managed to write so much code to do so little. You will be amazed at how many levels of indirection there are, with a little assumption hard-coded at every single point of indirectio…
I don't contribute to Go implementation but I encourage you to submit the feedback to https://github.com/open-telemetry/opentelemetry-go or https://gitter.im/open-telemetry/opentelemetry-go
You can also attend Go SIG meetings and provide the feedback directly. SIG meetings are open for attendance: https://github.com/open-telemetry/community#special-interest...
I am sure the Maintainers of Go implementation will appreciate your feedback.
I don't use any of their libraries, but follow the spec closely. At the very least, it's forcing some standardization among APM vendors (DataDog 64b trace_id, I'm looking at you). Also, related: https://www.w3.org/TR/trace-context/
Even 32 bytes is completely over the top for trace ID. Even the 16 bytes in this spec is pretty much just wasted space.
I also don't understand the purpose of the 16 bytes for the trace_id in the spec. That's a huge range of numbers. Anyone know the rationale?