Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenTelemetry

github.com

Post reply on HN
Print view View original

21–30 of 66 posts

Re: OpenTelemetry

#21

Post by tignaj »

sa46 wrote: post #20
jeffbee wrote: post #16

Earlier quoted context omitted.

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 think Datadog's trace_id is 64 bits which I thought was a good balance between efficiency and uniqueness. Pretty sure Dapper used 64 bits as well. 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?

Disclaimer: I work on OpenTelemetry spec.

Many tracing solutions settled on 128bits/16 bytes trace ids. Here is Jaeger's rationale: https://github.com/jaegertracing/jaeger/issues/858

It is also recommended by W3C: https://www.w3.org/TR/trace-context/#trace-id

Re: OpenTelemetry

#22

Post by tignaj »

otherview wrote: post #14

The tracing package is pretty solid. The metrics, is still changing. I 100% support this I think theres great work behind it. Eager to see how they tackle logs.

Here is the draft plan for logs: https://github.com/open-telemetry/opentelemetry-specificatio...

Logs are not going to be part of OpenTelemetry 1.0 release (only traces and metrics will). Logs are coming later (no specific timeline yet).

Disclaimer: I work on OpenTelemetry spec and wrote most of the linked doc. Comments/issues/PRs welcome in the repo.

Re: OpenTelemetry

#23

Post by tonyhb »

tignaj wrote: post #18
candiddevmike wrote: post #4

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.

Disclaimer: I work on OpenTelemetry specification and Collector. 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 free…

But it's been around for 5 years. First as opentracing (actually thanks Ben and LightStep!), then google decided to compete with opencensus (no thanks google), and now we have opentelemetry.

It's really, really, really annoying. After 5 years you might expect things to have calmed down. It was great at the start - like, actually. Even when baggage was rusty it had a direction and was usable. It probably still is, but the churn is crazy.

You say making dozens of companies agree is difficult, and yeah - it is - but thats because of other companies throwing out specs trying to compete with Lighttstep.

Re: OpenTelemetry

#24

Post by austinlparker »

aryc19 wrote: post #9

I'm really looking forward to using this project when it's stable. I briefly experimented with their Python SDK to try and record metrics but their documentation seemed either out of date or non-existent for some features. I'll wait for them to reach 1.0 in the hope that the documentation gets better and existing issues are resolved.

disclaimer: i'm an otel maintainer (specifically on community/web stuff!)

to echo some points from comments, I'm painfully aware of the state of the official documentation. I'm actually in the process of revamping the site to provide a framework for docs in each language to try and alleviate this. I expect it to be ready by 1.0.

Re: OpenTelemetry

#25

Post by jkwatson »

setheron wrote: post #5

The reference Java implementation uses too much hard-coded static variables. Look sexy for demonstration, but is it configuration nightmare. I had a lot more success and ease of use using open zipkin, highly recommend.

One of the maintainers of the java implementation here.

If you have issues with the configuration story for the java SDK, please let us know! We're trying hard to make it very configurable and extensible, and user feedback would be very valuable to have.

Thanks!

Re: OpenTelemetry

#26

Post by jkwatson »

svcrunch wrote: post #17
aphexairlines wrote: post #11

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).

For Java, what's the advantage of using this library, versus directly using JMX? Are the abstractions better? I took a look at the documentation and it wasn't clear to me.

Maintainer of the java implementation here.

OpenTelemetry is really orthogonal to JMX. We're trying to provide a standard way to capture spans (traces) and metrics and send them to observability systems, both open source and vendor-provided. Those metrics might originate from JMX, or any other source of metrics you might have. Our APIs do provide a way to directly capture metrics, but also to hook into existing metric providers (like JMX or JFR).

Re: OpenTelemetry

#27

Post by lucb1e »

I don't quite get it, what does this do?

The readme says absolutely nothing (e.g. "The OpenTelemetry specification describes the cross-language requirements and expectations for all OpenTelemetry implementations." and goes on to describe how to submit changes or on which proprietary platform meeting minutes can be found) and the Overview document goes into depths about terminology (what a trace is, what a span within a trace is, how to link spans, etc.).

Nowhere does it say if this is supposed to, for example, replace proprietary crash reporting in apps so that we can know what is being reported back to the mothership, or if this is something completely different.

Re: OpenTelemetry

#28

Post by jkwatson »

aphexairlines wrote: post #11

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).

Java implementation maintainer here.

Our context propagation story is still evolving and under active development. We are hyper-aware of the issues with managing propagation with asynchronous contexts, and are working on building a solution that instrumentation authors can use to manage the propagation of context both synchronous and asychronous. If you have expertise in this area, we would love help and feedback on what we're building!

Re: OpenTelemetry

#29

Post by harpratap »

lucb1e wrote: post #27

I don't quite get it, what does this do? The readme says absolutely nothing (e.g. "The OpenTelemetry specification describes the cross-language requirements and expectations for all OpenTelemetry implementations." and goes on to describe how to submit changes or on which proprietary platform meeting minutes can be found) and the Overview document goes into depths about terminology (what a trace is, what a span within…

You can check the first link that states the overview - https://github.com/open-telemetry/opentelemetry-specificatio...

It's a distributed request tracing specification & set of libraries implementing the said spec

Re: OpenTelemetry

#30

Post by harpratap »

tonyhb wrote: post #23
tignaj wrote: post #18

Earlier quoted context omitted.

Disclaimer: I work on OpenTelemetry specification and Collector. 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 free…

But it's been around for 5 years. First as opentracing (actually thanks Ben and LightStep!), then google decided to compete with opencensus (no thanks google), and now we have opentelemetry. It's really, really, really annoying. After 5 years you might expect things to have calmed down. It was great at the start - like, actually. Even when baggage was rusty it had a direction and was usable. It probably still is, but…

This is not in competition to lightstep or any one vendor in particular. It is to converge all open source & proprietary solutions to follow a common spec and allow them to build on top of a common base.

OpenTracing dealt only with Tracing, it didn't care about logs or metrics. OpenCensus did all 3. This is combining the best of OpenTracing (which is Tracing) with idea that OpenCensus brought - just one library to collect and ship all the observability data that your application is supposed to emit.

Post reply on HN