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

31–40 of 72 posts

Re: OpenTelemetry

#31

Post by kortex »

dmitrygr wrote: post #5

Not a mention of "opt-in only, because we respect privacy"... Please stop helping spy on users! Be the change you want to see in the world!

Ugh, not this again. Every time opentelemetry gets on the front page, people grouse about spying.

OT is for distributed tracing across services. It's a glorified profiler (not to downplay how awesome OT is). Has nothing to do with spying on end user behavior any more than URLs, JavaScript or HTTP headers has to do with spying.

Could you use it to spy? Yes, you can use anything to spy, if you choose to.

Re: OpenTelemetry

#32

Post by jakozaur »

I belive OpenTelemetry will make distributed tracing mainstream. Traces are the best tool to debug problems, yet as their are expensive (both in dev work and license) to implement they are way less popular than logs.

Historicaly APM (application performance monitoring) also owned collection, vendor locked-in and didn’t evolve price per value.

Open-source collection standard allows users to choose or switch to the best vendor.

Personally, I recommend Sumo Logic (disclaimer: I work there). We have rich full-text query capabilities on spans with parsing and aggreagations on query time…

Re: OpenTelemetry

#33

Post by robbedpeter »

haswell wrote: post #26
robbedpeter wrote: post #19

Earlier quoted context omitted.

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.

If you're collecting data from software running on someone's device, that's someone else's user data. I think the term of art is metadata.

In some ways, such information is just as important as biometrics and passwords and pii.

Deanonymizing becomes possible when metadata is cross-referenced. Metadata should be subject to as strict protection and consent rules as documents, health info, or any other "obvious" private data.

If it's running on your server and not logging third party activity or metadata, the information belongs to you. Else, you need the third party's consent, etc.

"It's just for benign development purposes" doesn't cut it anymore regardless of intentions. We need a cultural and legal area change with regards to privacy and primacy of private data protections.

Re: OpenTelemetry

#35

Post by jeffbee »

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.

Perhaps you will be surprised to learn that your web browser sends requests all over the place.

Re: OpenTelemetry

#36

Post by kall »

splittingTimes wrote: post #17
lizthegrey wrote: post #13

Earlier quoted context omitted.

OpenTelemetry allows you to measure performance of your frontend and backend, but it's not a survey tool. DataDog is one of many compatible backends that works with OpenTelemetry, but you can also use Jaeger OSS, Honeycomb, Lightstep, and others.

Strictly only the performance or can it also answer usage questions like: When customers go through this workflow step, they use this option/button 90% of the time and the other options are used rarely?

It may be possible, but it will not be pleasant to use tracing to answer those kinds of questions. Sounds like something you can do with off the shelf product analytics tools like Amplitude or Mixpanel. Do you already have something like that?

Re: OpenTelemetry

#37

Post by jeffbee »

It is nice that the proto files are unambiguous that trace time is represented as unix epoch nanos, and it is declared `fixed64` the way Jesus intended, but it's too bad the specification made it to 1.0 without simply mandating that timestamps are always in unix epoch nanos. Having uncertainty about the precision of timestamps has caused and will continue to cause loads of bugs. If there is some language platform out there that can't figure out the time in nanos, that language platform should simply be ignored.

Re: OpenTelemetry

#38

Post by jeffbee »

beeandapenguin wrote: post #4
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?

For the long running scenario, why not use Links? The specification describes[1] a similar scenario and how links can be leveraged to causally relate spans even across trace boundaries. As for the crashing scenario, this seems like an application-level concern. Ideally it is not waiting until the crash to send traces. Depending on the environment, the application could handle the crash and deliver the telemetry leadi…

Yes, logging the beginning and ending of a span to your observability platform is a common and valuable approach, since you can figure out from the open spans of a dead process what requests might have been running when it died, making it easier to diagnose requests of death.

Re: OpenTelemetry

#39

Post by erik_seaberg »

jeffbee wrote: post #37

It is nice that the proto files are unambiguous that trace time is represented as unix epoch nanos, and it is declared `fixed64` the way Jesus intended, but it's too bad the specification made it to 1.0 without simply mandating that timestamps are always in unix epoch nanos. Having uncertainty about the precision of timestamps has caused and will continue to cause loads of bugs. If there is some language platform out…

From what I’ve read, you have to accommodate ±1 ms NTP clock skew unless you have an atomic clock or GPS source in each datacenter, so the extra precision isn’t reliable.

Re: OpenTelemetry

#40

Post by jeffbee »

erik_seaberg wrote: post #39
jeffbee wrote: post #37

It is nice that the proto files are unambiguous that trace time is represented as unix epoch nanos, and it is declared `fixed64` the way Jesus intended, but it's too bad the specification made it to 1.0 without simply mandating that timestamps are always in unix epoch nanos. Having uncertainty about the precision of timestamps has caused and will continue to cause loads of bugs. If there is some language platform out…

From what I’ve read, you have to accommodate ±1 ms NTP clock skew unless you have an atomic clock or GPS source in each datacenter, so the extra precision isn’t reliable.

That's fine. Many clocks are off by much more than 1ms. But the timestamps should be represented as nanos everywhere.
Post reply on HN