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

41–50 of 66 posts

Re: OpenTelemetry

#41

Post by tmd83 »

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…

A specific question I had was tracing seems to be all about distributed context (from the way everyone talks/market it) where each distributed call is captured in a span.

But I didn't see (perhaps I missed it) about tracing inside a single instance where I want the individual method call to be traced to know which method call was expensive within that instance.

Re: OpenTelemetry

#42

Post by harpratap »

tonyhb wrote: post #40
harpratap wrote: post #30

Earlier quoted context omitted.

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

> the goalposts shifted from telemtry to logging

Telemetry has always included logging as one of it's components.

> Should we hold off on the spec for another 5 years and add datadog/prometheus metrics too?

I think you should look at OTel once again. OTel already includes metrics and supports exporting to Prometheus.

And I don't want to reply to the rest of your comments because I don't feel you understand this problem space enough before making such remarks on it.

Re: OpenTelemetry

#43

Post by harpratap »

tmd83 wrote: post #41
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…

A specific question I had was tracing seems to be all about distributed context (from the way everyone talks/market it) where each distributed call is captured in a span. But I didn't see (perhaps I missed it) about tracing inside a single instance where I want the individual method call to be traced to know which method call was expensive within that instance.

You can check out Mastering Distributed Tracing by Yuri Shkuro (the author of Jaeger). Lesson 2 talks about tracing monoliths - https://github.com/yurishkuro/opentracing-tutorial/tree/mast...

Re: OpenTelemetry

#44

Post by tonyhb »

harpratap wrote: post #42
tonyhb wrote: post #40

Earlier quoted context omitted.

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

> the goalposts shifted from telemtry to logging Telemetry has always included logging as one of it's components. > Should we hold off on the spec for another 5 years and add datadog/prometheus metrics too? I think you should look at OTel once again. OTel already includes metrics and supports exporting to Prometheus. And I don't want to reply to the rest of your comments because I don't feel you understand this probl…

Fair. I worked with Ben to integrate opentracing into docker before Kube won, and at that point it was tracing only. Tracing as in spans, annotations, and baggage spanning services. So, it has changed from call graphs/timing etc to telemetry in the broad sense.

We're talking about churn here, not my knowledge, and I think considering how you say I don't understand it we can both agree it has churned into something else. As OP said, there is a lot of churn. Too much for your common system to keep up with in the (pun intended) span of a couple years. 3 rebrands in fewer years isn't promising.

Re: OpenTelemetry

#45

Post by watt »

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

why not just put a couple paragraphs on top of the readme to explain what it is, what does it do, and add this link, instead of posting in a forum where nobody will see it.

Re: OpenTelemetry

#46

Post by oaiey »

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…

And like always when vendors / standards are built: It takes a while. Not surprised here.

Re: OpenTelemetry

#47

Post by m12k »

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.

With so many people finding things via GitHub, I'd highly recommend also including a single paragraph at the top of the repo readme to explain what it is, rather than expect people to be curious enough to go digging for more info. E.g. you could use the explanation from the website: "OpenTelemetry provides a single set of APIs, libraries, agents, and collector services to capture distributed traces and metrics from your application. You can analyze them using Prometheus, Jaeger, and other observability tools."

Re: OpenTelemetry

#48

Post by maurys »

tmd83 wrote: post #41
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…

A specific question I had was tracing seems to be all about distributed context (from the way everyone talks/market it) where each distributed call is captured in a span. But I didn't see (perhaps I missed it) about tracing inside a single instance where I want the individual method call to be traced to know which method call was expensive within that instance.

Spans are intervals with a start and stop and a set of tags for querying.

These can be local or cross-service.

I guess the documentation focusses on the "distributed" part of tracing but it works perfectly well for local spans too.

Re: OpenTelemetry

#49

Post by maurys »

Just a quick summary.

Trace - One unique id for an "action", say customer purchasing an item. A set of spans exist under a trace.

Span - An interval with a start time and duration. Can add tags for querying. Can add logs for richer information but not indexed. Each span belongs to exactly one trace.

Baggage - key value pairs you can pass between services. They aren't tagged as part of the span or trace, but the receiving service can use these values to make decisions or add them to its local spans as logs or spans.

Under the hood, it's just a set of HTTP headers passed between services. The first span creates a trace id and passes that to all downstream services as a header.

Each service independently pushes it's span data into a centralised collector which indexes the data and exposes it over an UI/API.

OpenTelemetry provides a specification and some reference implementation across languages.

At least, this is my understanding of it. I've dabbled with Jaegar but I'm not affiliated with any of these.

Re: OpenTelemetry

#50

Post by boggsi »

maurys wrote: post #49

Just a quick summary. Trace - One unique id for an "action", say customer purchasing an item. A set of spans exist under a trace. Span - An interval with a start time and duration. Can add tags for querying. Can add logs for richer information but not indexed. Each span belongs to exactly one trace. Baggage - key value pairs you can pass between services. They aren't tagged as part of the span or trace, but the recei…

To all the OpenTelemetry people reading this page - please include the above description somewhere in your project. I actually googled the definition of telemetry because I had no idea what you were talking about, I thought it had something to do with space observations given all the telescopes? My second guess was that it had something to do with the way data from accelerometers was handled? Standardising tooling for sensors?

This comment was the first thing to explain that it's better logging. That's actually something I'd be interested in, running several different datascience services/analyses, logging was something I implemented then gave up on because it sucks so much. You're losing a lot of potential players because you have given 0 effort to explaining in simple terms what you are. A "From logging to telemetry" primer would probably garner you a lot more interest.

Post reply on HN