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

OpenTelemetry

opentelemetry.io

Post reply on HN
Print view View original

21–30 of 72 posts

Re: OpenTelemetry

#21

Post by dyladan »

spullara wrote: post #2

I hate that this specification and most of the other ones use spans that have a beginning and end rather than events that start and end the span. What if it crashes before it sends out the span? What if it is taking a very long time to complete?

The span is simply the way the data is modeled. The way the tracing works is it calls a component called a Span Processor on both span start and end. It would be possible to implement a Span Processor that sends span_start and span_end events to your backend without waiting for the span to start.

In terms of crashing and taking a long time to complete, these are problems that are very difficult to solve on the backend as well. Simply having the start event without the end event is not enough info to say for sure that there will _never_ be an end event. For low data volumes and simple use-cases this may not seem like a big deal, but it gets complex extremely quickly.

Re: OpenTelemetry

#22

Post by zls »

I love OpenTelemetry, but for Java, I wish adoption would slow down until the implementation catches up.

For example, if you visit the OpenCensus site, it tells you on every page that OpenTelemetry is the way to go now. Yet OpenTelemetry's Java metrics implementation is still listed as alpha, and functionality as basic as tags didn't work when I last tried it.

Or, I've been working with Datadog lately, and I want to add dynamic span metadata. My options appear to be either to wire up the (deprecated) OpenTracing client, or set up a full collector/agent suite of OpenTelemetry processes (whose default tutorial configurations appear to be invalid in places).

worth I guess, but bumpier than I'd like.

Re: OpenTelemetry

#23

Post by dyladan »

Thaxll wrote: post #8
iddan wrote: post #7

I really hope we’ll have an open standard for tracing. Right now the common solutions are vendor-locking and can’t be integrated in OSS projects

Open tracing works just fine.

OpenTracing and OpenCensus have been merged into the OpenTelemetry project. I think OT isn't sunset officially yet, but the future is OTel.

Re: OpenTelemetry

#24

Post by haswell »

dmitrygr wrote: post #11
sveiss wrote: post #6

Earlier quoted context omitted.

That's because this tool has nothing to do with "spying on users". It's a set of tools and a specification for instrumenting applications and collecting logs/metrics/traces from them. It's used to ask questions like "why is this page slow to load?" and get answers like "because it talks to the billing microservice which has a really slow SQL query". This isn't the same sort of telemetry that desktop software vendors…

Sadly, it seems you are wrong: https://opentelemetry.io/docs/js/ "the browser" That means they are running code on my machine and exfiltrating data out.

This response really strikes me as throwing the baby out with the bath water.

The OpenTelemetry project is focused on Observability use cases and not user analytics/tracking/etc. The fact that of all the libraries, a JS browser library exists doesn't automatically mean the parent comment is "wrong".

I suggest anyone making snap judgements about OpenTelemetry spend a few minutes reading more about the project. This general pattern of comments surfaces every time this project is posted here.

Re: OpenTelemetry

#25

Post by tonyhb »

zls wrote: post #22

I love OpenTelemetry, but for Java, I wish adoption would slow down until the implementation catches up. For example, if you visit the OpenCensus site, it tells you on every page that OpenTelemetry is the way to go now. Yet OpenTelemetry's Java metrics implementation is still listed as alpha, and functionality as basic as tags didn't work when I last tried it. Or, I've been working with Datadog lately, and I want to…

Yeah, OpenTelemetry was OpenCensus, and before that it was OpenTracing. The go client faces some of the same churn; metrics are in alpha and the API isn't documented, though spans and traces are on more solid ground than the Java client it seems.

It's been a lot of change and I can't wait for things to settle down and for companies to stop trying to get their piece. I feel like everyone (Datadog, NewRelic, Google, etc.) saw Lightstep as a competitor and wanted to get involved with a competing spec, which is how we ended up in this consensus mess.

Still, it's good progress and it's so much better than raw logs. Would recommend.

Re: OpenTelemetry

#26

Post by haswell »

robbedpeter wrote: post #19
rad_gruchalski wrote: post #16

Earlier quoted context omitted.

Define “they”, please.

They as in "they" who are receiving the data being collected about the user. It isn't hard to see who the bad guys are. If this is implemented in a totally transparent, user controlled, consensual way, and the collected data made ephemeral and subject to user request for deletion and viewing on demand while being stored, then there's nothing bad going on. Anything less is unacceptable - a line is being crossed. Right…

> "they" who are receiving the data being collected about the user

I'm curious why you automatically assume data is being collected about the user? OpenTelemetry is about Observability, not user tracking.

Re: OpenTelemetry

#27

Post by phillipcarter »

robbedpeter wrote: post #19
rad_gruchalski wrote: post #16

Earlier quoted context omitted.

Define “they”, please.

They as in "they" who are receiving the data being collected about the user. It isn't hard to see who the bad guys are. If this is implemented in a totally transparent, user controlled, consensual way, and the collected data made ephemeral and subject to user request for deletion and viewing on demand while being stored, then there's nothing bad going on. Anything less is unacceptable - a line is being crossed. Right…

I feel like this is sort of a "you reposted in the wrong neighborhood" moment.

OpenTelemetry is a vendor-neutral framework and standard for generating performance data (spans, metrics, logs) about systems, particularly distributed ones where it's impossible to just load up a debugger to figure out why something is failing or slow. It's not a framework for collecting user data. User data and performance data are completely separate things.

Your concerns about privacy are important, but not really relevant to the topic.

Re: OpenTelemetry

#28

Post by lizthegrey »

tonyhb wrote: post #25
zls wrote: post #22

I love OpenTelemetry, but for Java, I wish adoption would slow down until the implementation catches up. For example, if you visit the OpenCensus site, it tells you on every page that OpenTelemetry is the way to go now. Yet OpenTelemetry's Java metrics implementation is still listed as alpha, and functionality as basic as tags didn't work when I last tried it. Or, I've been working with Datadog lately, and I want to…

Yeah, OpenTelemetry was OpenCensus, and before that it was OpenTracing. The go client faces some of the same churn; metrics are in alpha and the API isn't documented, though spans and traces are on more solid ground than the Java client it seems. It's been a lot of change and I can't wait for things to settle down and for companies to stop trying to get their piece. I feel like everyone (Datadog, NewRelic, Google, et…

Lightstep was one of the originators of the combined spec -- but yes, the churn has been really painful, and we're sorry for the pre-1.0 pain. Now that the spec is 1.0 and most of the language SIGs have put out 1.0 API/SDK releases for tracing, hopefully that pain will reced.

Re: OpenTelemetry

#29

Post by [deleted] »

dmitrygr wrote: post #11
sveiss wrote: post #6

Earlier quoted context omitted.

That's because this tool has nothing to do with "spying on users". It's a set of tools and a specification for instrumenting applications and collecting logs/metrics/traces from them. It's used to ask questions like "why is this page slow to load?" and get answers like "because it talks to the billing microservice which has a really slow SQL query". This isn't the same sort of telemetry that desktop software vendors…

Sadly, it seems you are wrong: https://opentelemetry.io/docs/js/ "the browser" That means they are running code on my machine and exfiltrating data out.

[deleted]

Re: OpenTelemetry

#30

Post by rad_gruchalski »

FateOfNations wrote: post #20
rad_gruchalski wrote: post #16

Earlier quoted context omitted.

Define “they”, please.

The developer of the web app... who is already running all sorts of other code in your browser.

Sure. Like any JavaScript. As long as the provider of the service is transparent about what is collected, what’s the problem? There’s nothing preventing a system provider from making this collection opt-in.

What’s with the assumption that the service provider cannot observe how their system performs?

Post reply on HN