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

31–40 of 66 posts

Re: OpenTelemetry

#31

Post by austinlparker »

disclaimer: otel maintainer, etc.

one thing I want to point out is that, eventually, we'd like for a lot of the complaints people have to be... well, things that you don't have to complain about, because it's not important. three or four years from now, it'd be nice to see a world where most people don't actually have to interact with otel at all because it's either built-in to the libraries/frameworks they're using, or because they're using some kind of wrapper that helps with best practices.

you can see an example of this with something we're doing at lightstep - we're introducing launchers that wrap upstream otel and standardize config format/defaults between multiple languages (https://github.com/lightstep/?q=launcher), and trying to provide "missing link" documentation (https://otel.lightstep.com).

i suspect that eventually the question of "how do i use opentelemetry" becomes a moot point because it's already there.

Re: OpenTelemetry

#32

Post by austinlparker »

harpratap wrote: post #29
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

we also explain it a bit on our website, https://opentelemetry.io

Re: OpenTelemetry

#33

Post by jeffbee »

tignaj wrote: post #21
sa46 wrote: post #20

Earlier quoted context omitted.

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

Neither Jaeger nor W3C seem to present any justification for 16 byte trace identifiers, just FUD.

Re: OpenTelemetry

#34

Post by systemvoltage »

austinlparker wrote: post #32
harpratap wrote: post #29

Earlier quoted context omitted.

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

we also explain it a bit on our website, https://opentelemetry.io

The fact that this is the top comment and most people are confused about what Open Telemetry is about should indicate that it is not clear.

This is too often a mistake - not knowingly. It's like proof reading, I always think my writing is correct until someone else points out mistakes.

Re: OpenTelemetry

#35

Post by austinlparker »

systemvoltage wrote: post #34
austinlparker wrote: post #32

Earlier quoted context omitted.

we also explain it a bit on our website, https://opentelemetry.io

The fact that this is the top comment and most people are confused about what Open Telemetry is about should indicate that it is not clear. This is too often a mistake - not knowingly. It's like proof reading, I always think my writing is correct until someone else points out mistakes.

Thanks for the feedback, I just opened a PR to add a link from the spec readme to our website to hopefully guide people to better information.

Re: OpenTelemetry

#36

Post by jeffbee »

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

Async style is not incompatible with storing the trace context in thread-local storage. You just capture the trace context when you create the callback. That's how Dapper works, in C++ and Java. See section 2.2 of the Dapper paper.

https://storage.googleapis.com/pub-tools-public-publication-...

Re: OpenTelemetry

#37

Post by giulianob »

I've been using the opentelemetry package for C# to push tracing data to Honeycomb and it's really good. It takes a bit of learning but it's extremely powerful. Once you're over the hump it's very easy to quickly add new telemetry and its night and day difference to typical logs/metrics.

Re: OpenTelemetry

#38

Post by bitbckt »

tignaj wrote: post #21
sa46 wrote: post #20

Earlier quoted context omitted.

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

BigBrotherBird (now OpenZipkin... thanks legal, sigh) used 128b trace_ids when we first built it at Twitter. I don’t recall the reasoning, but that’s the first system I know of which chose that size.

Dapper used 64b IDs for span and trace, but being locked inside the Googleplex probably limited its influence on compatibility issues.

My point is that 128b is the common standard now, and that’s all that I really care about - that the standard exists and APM systems conform to it. To that end, I am very pro-otel.

Thanks for your work.

Re: OpenTelemetry

#39

Post by systemvoltage »

austinlparker wrote: post #35
systemvoltage wrote: post #34

Earlier quoted context omitted.

The fact that this is the top comment and most people are confused about what Open Telemetry is about should indicate that it is not clear. This is too often a mistake - not knowingly. It's like proof reading, I always think my writing is correct until someone else points out mistakes.

Thanks for the feedback, I just opened a PR to add a link from the spec readme to our website to hopefully guide people to better information.

I want to clarify about my comment and what I meant - when you're working on your own product for many months and years, it is hard to know what others don't know about the product. Similar to proof reading, your eyes just "gloss" over :) I didn't mean to patronize or say you made a mistake.

Re: OpenTelemetry

#40

Post by tonyhb »

harpratap wrote: post #30
tonyhb wrote: post #23

Earlier quoted context omitted.

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 co…

On the fundamentals you agree with me: the goalposts shifted from telemtry to logging.

IMO they're different things. One deals with call graphs, timings, and associated baggage. The other is logs. Should we hold off on the spec for another 5 years and add datadog/prometheus metrics too?

I dont think that one spec should be all encompassing. Opentracing is great for tracing. Logs can be baggage. Memory use can be baggage. The temperature of the CPU and the current disk space is another platform altogether.

It's like saying everything in the world should run webassembly, and no other ISA matters. It's an idea! But, certainly a distraction from the benefits. Why not let tracing deal with tracing before messing with the 1.0?

Post reply on HN