Live data from Hacker News

Why and how GitHub is adopting OpenTelemetry

github.blog

101–110 of 113 posts

Re: Why and how GitHub is adopting OpenTelemetry

#101
post #93

Earlier quoted context omitted.

then why name it open "telemetry" in the first place? you know it has an extremely bad connotation to spyware. > which puts into question the "after reading this" > without even checking what the article is talking about will do that. please don't do that, this is against the HN guidelines. https://news.ycombinator.com/newsguidelines.html

Telemetry is the in situ collection of measurements or other data at remote points and their automatic transmission to receiving equipment (telecommunication) for monitoring. The word is derived from the Greek roots tele, "remote", and metron, "measure". Why name it the precise thing that it literally is ? Telemetry is used everywhere: rockets, drones, airplanes, boats, water meters, microservices, applications, and…

And how do you know if GitHub is spying on you with this system? Am I able to "opt-out" of this telemetry on GitHub?

In a closed source backend system like GitHub (Microsoft) how do you exactly know that this tool is also being used for spyware?

I wouldn't be surprised if this 'OpenTelemetry' system is being used for exactly that.

Re: Why and how GitHub is adopting OpenTelemetry

#102
post #93

Earlier quoted context omitted.

Telemetry is the in situ collection of measurements or other data at remote points and their automatic transmission to receiving equipment (telecommunication) for monitoring. The word is derived from the Greek roots tele, "remote", and metron, "measure". Why name it the precise thing that it literally is ? Telemetry is used everywhere: rockets, drones, airplanes, boats, water meters, microservices, applications, and…

And how do you know if GitHub is spying on you with this system? Am I able to "opt-out" of this telemetry on GitHub? In a closed source backend system like GitHub (Microsoft) how do you exactly know that this tool is also being used for spyware? I wouldn't be surprised if this 'OpenTelemetry' system is being used for exactly that.

You're doing it again.

"Telemetry" doesn't have spyware connotations. You choose to view it as such. Telemetry means taking remote measurements.

OpenTelemetry facilitates this. It doesn't facilitate Github installing spyware on your system. It's an internal tool. Something you'd understand, even as someone unfamiliar with it, if you would actually have paid any attention to the article.

And OpenTelemetry IS in fact open source, so your argument, confusing as it is, falls flat on that too.

Note that it's very hard to give you the benefit of the doubt when you're so incredibly hostile to a word you've chosen to view as bad, it sounds like telemetry is just a trigger word for you.

Re: Why and how GitHub is adopting OpenTelemetry

#105
post #19

I think it would be great to show the performance impact of these SDKs because it is one of the really important aspects of monitoring (being non-intrusive).

I've noticed that orgs where I've worked vary between being totally insensitive to observability cost to being real hardasses about it. But I think most smaller shops are falling into the former category. I've even heard in meetings crazy shit like "It's very low overhead, only about 5%" which would get you laughed out of the office at, say, Google. Unfortunately (to me) the focus on ease-of-use has meant that OpenTe…

I want to point out that OpenTelemetry is explicitly designed to decouple the API from the SDK, allowing for other people to reimplement parts of the SDK as needed while maintaining compatibility with not only other SDK components, but also the overall ecosystem. This was one of the major changes we introduced as part of the OpenTracing/OpenCensus merger.

Re: Why and how GitHub is adopting OpenTelemetry

#106

Earlier quoted context omitted.

Why not using Datadog?

We are in the health care industry, so we are not keen about sending our data to third parties. We also prefer open-source technologies.

The "simplest" self-hosted tools are probably Prometheus (https://prometheus.io) and Jaeger (https://jaegertracing.io), but they're big distributed systems. Running them may or may not be worth the cost, though you might be using something like Prometheus already.

I really would love to see a simpler set of tools that works better for small / medium companies to self-host if they really can't send data to a vendor for some reason.

Re: Why and how GitHub is adopting OpenTelemetry

#107
post #70

For anyone interested in learning how to use Open Telemetry for distributed tracing in go, I recently made a demo app to share with some friends: https://github.com/michaelperel/otel-demo . To run, clone it & docker-compose up

Amount of "otel" instrumentation required in your code by LOC looks ridiculous to me. Isn't it a better approach to just use logs? e.g. defer ctx.WithField("path", path).Trace("opening").Stop(&err) from https://medium.com/@tjholowaychuk/apex-log-e8d9627f4a9a

Your counterexample is misleading, because a single simplistic function call is what happens in most of the code, e.g. creating spans for an arbitrary point in the code is like, 1 function call[1] after setup. I don't see anything egregious here. Of course, you also have to record where the span ends, but that's part of the game you're playing when you move beyond logs. You have to record that.

What you're probably looking at is all the boilerplate set up, e.g. configuring the provider and backend to point to the right stuff. It reminds me of SL4J, which isn't actually an insult. It's just boilerplate, because people want a lot out of their logging and tracing systems.

Demo applications like this are often easily misleading because there are only like 50 lines of "business logic" and 50 lines of tracing setup, so it makes it seem like the tracing is excessively hard. But those two things don't scale the same way. In a large application where tracing is really valuable, you'll have 100,000 lines of business logic, and still only 50 (or maybe like 100) lines of tracing setup, per application.[2] Actual usage at the call sites remains only a line or two in most cases, and easy to add as you need, where you need it, just like a logger.

It is also worth noting in other ecosystems like when I played with tokio_trace, I found integrating tracing easy, even at the very start. So some of this definitely involves the "philosophy" of the client library.

[1] https://github.com/michaelperel/otel-demo/blob/master/cmd/cl...

[2] I guess if the 100,000 LoC running your business is split into 2000 microservices with 50 lines each, then yes, it may be excessive.

Re: Why and how GitHub is adopting OpenTelemetry

#108

Earlier quoted context omitted.

And how do you know if GitHub is spying on you with this system? Am I able to "opt-out" of this telemetry on GitHub? In a closed source backend system like GitHub (Microsoft) how do you exactly know that this tool is also being used for spyware? I wouldn't be surprised if this 'OpenTelemetry' system is being used for exactly that.

You're doing it again. "Telemetry" doesn't have spyware connotations. You choose to view it as such. Telemetry means taking remote measurements. OpenTelemetry facilitates this. It doesn't facilitate Github installing spyware on your system. It's an internal tool. Something you'd understand, even as someone unfamiliar with it, if you would actually have paid any attention to the article. And OpenTelemetry IS in fact o…

The fact that this thing is open source is entirely irrelevant.

It's quite simple. You don't know what Github is doing privately with this tool running in their backend systems.

I still don't understand the praise and the excitement of telemetry (open or not) at all from engineers.

They may think that they are doing this 'tracing' or whatever that is, when in-fact it is still spying.

Again, can I opt-out of this 'telemetry' on GitHub? If I cannot and I did not agree to this, then this is very troublesome.

Re: Why and how GitHub is adopting OpenTelemetry

#109

Earlier quoted context omitted.

You're doing it again. "Telemetry" doesn't have spyware connotations. You choose to view it as such. Telemetry means taking remote measurements. OpenTelemetry facilitates this. It doesn't facilitate Github installing spyware on your system. It's an internal tool. Something you'd understand, even as someone unfamiliar with it, if you would actually have paid any attention to the article. And OpenTelemetry IS in fact o…

The fact that this thing is open source is entirely irrelevant. It's quite simple. You don't know what Github is doing privately with this tool running in their backend systems. I still don't understand the praise and the excitement of telemetry (open or not) at all from engineers. They may think that they are doing this 'tracing' or whatever that is, when in-fact it is still spying. Again, can I opt-out of this 'tel…

> You don't know what Github is doing privately with this tool running in their backend systems.

What of it? You don't know what they're doing regardless. You're attacking a strawman, because of its name. Please for the love of everything, take a step back and understand what you're even arguing about.

YOU are not the target of said telemetry. Their frickin' servers are.

Re: Why and how GitHub is adopting OpenTelemetry

#110
post #52

Earlier quoted context omitted.

Who will be doing this spying? It certainly wouldn't be opentelemetry itself as that's just a interface you add adapters to. Are you thinking a man in the middle would spy? How would that work? This information is pushed over secure connections on the backend likely in a VPN. On the front end, it'd be transmitted over HTTPS. Shouldn't we be more fearful of information collected from DNS than encrypted data sent over…

We're forming the best, most complete, competent view of computing-that's-happened that we've ever formed. You have a bunch of weird straw men that I don't get. I tried to de-emphasize the role of behavioral analytics & user-tracking, because I think it's just one small part of what this will be used for. But I am fairly confident we will eventually start to do more user-tracking via these systems. I've used half a d…

I thoroughly agree about the event-based-computing model but telemetry (as per the current common definition) won't drive this far enough. We need to take the telemetry model one step further and have the easy facility to insert shims at set levels (e.g. between the business layer and the data store) with open auth to be able to insert subscribers in an open manner to the entire payload. This should then be mandated by any org implementing a product and especially any gov org to prevent vendor lockin and allow easy extensibility. Same concept, but more data.
Post reply on HN